As a result of the intranet concept design phase, a specifications document is created. This document is attached as a part of the request for proposals (RFP) for possible vendors. Carefully prepared requirement specifications function as a general guideline throughout the whole intranet implementation.These tips will lead you to even better results when drawing up your own specifications
North Patrol is a consulting firm specialized in the design of digital services and information systems. We shape ideas into a vision and service concept, find the best architectural and technological solutions, design a functional user experience, and compete to find the ideal partner for implementation work. We do not sell implementation projects, nor do we sell licenses; we are genuinely on the side of the customer.
1. A specifications document is neither a bulleted list of individual technical requirements nor a pile of stylishly playful layout suggestions
Instead, it is a document which mostly contains text, which gives an overview of the service that you want to purchase, and what the result should be like. It contains a comprehensive description of the goals, users, structure, functionality, and the UI principles for the intranet.
Typically, a visual concept created by a graphic designer is not included as a part of the requirement specifications. Instead, the visuals will be purchased from the vendor as a part of the implementation project. A well-made specifications document can be used as the basis for lists of individual parts of the implementation (e.g. product backlog).
2. Be precise enough
Requirement specification must be done at a level of detail which allows the vendor to estimate the workload for the implementation, and provide their quotation based on it.
3. Don’t go into too much detail
In the end, you should be able to rely on the vendor’s professional ability to choose the best technical solution. Define clearly what you want. However, especially in situations that are unclear to you, do not restrict the vendor with too many details, such as stipulating the building blocks for the implementation.
Think of the vendor as the chef at a catering service: they will – according to your wishes – prepare the courses from appetizers to dessert for the event where you have invited the guests and set the goals, the nature of the get-together, limitations for the menu, as well as the budget. If the implementation relies on the basic functionality of a certain product, it is not necessary to list all these functions. Focus on the most important deviations and particularities.
4. Don’t be ambiguous
Keep ambiguity out of the requirement specifications. Either a functionality is included within the scope, or it is not. Do not write down anything vague in the specifications, since it will probably raise the cost (in case the vendor prepares themselves for the worst) and/or create unjust differences between vendors (in case the vendors have differing interpretations of the terms).
Blurred visions may be entered in a separate section as suggestions for future development.
5. Draw the big picture
Illustrate the key aspects of the intranet with a drawing. You may include other, closely related systems and the links between them in the illustration.
6. Present the structure
Make sure you introduce the plans for the intranet navigation and/or content structure. This brings the concept to life and helps to piece together the whole entity. However, you must remember that the vendor responsible for the technical implementation is not particularly interested in the contents of the basic content pages or the order between them – even if you hold these things very dear yourself. A requirements specification document maintains its focus on issues that must be taken into account in the technical implementation.
7. Illustrate the UI with wireframe models
You can use wireframe models to firm up your message. Create wireframe images for the page templates, especially if they deviate greatly from what is commonly seen, or from the default page templates of a product candidate. Wireframe models can also be used to illustrate some of the most important views of the intranet, such as the home page.
8. Use terms consistently
Use a single term for a single entity, and do it carefully and coherently. For instance: do you call a certain thing “an element”, “a component”, “a section”, “a part”, “a site” – maybe “an entity” as well?
9. Give a roadmap for the future
Even though the intranet to be implemented is a clearly defined package, you may very well dedicate a separate chapter for possible future development plans for the intranet. Make it clear that these plans are not part of the entity that is implemented in the first stage (and for which RFPs are requested). Plans for future development may be very approximate in their nature, and they are not binding for any of the parties involved. However, they may motivate the partner to provide their tender with the thought of possible future work in mind.
10. Seek professional help
Just like intranet implementation, specifying the requirements can also be outsourced. You can have people from the partner that is going to build the intranet help you specify the requirements, or you can enlist an independent consultant like North Patrol.
Requirement specification professionals know what kind of content should be included in the specifications document, and which level of detail yields the best results. They also know, what the partners responsible for technical implementation expect of a requirement specification. Often they are also able to bring other types of expertise, experiences from other organizations, and new ideas into the process. If the requirement specification professionals do not work for the future implementation partner, it is more likely that they can suggest easier and more reasonably priced alternatives for given functionalities.
Consultants often work closely with the client, and facilitate workshops, where the consultants together with the client’s project team refine the goals for the implementation, service concept and the key functionalities. The consultant’s role is to bring forth good practices, to offer their expertise on technical platforms and to create a specifications document based on the concept created by the team.
