We're all guilty of sometimes hearing what we want to hear – but when it's a client, is it their fault or ours? Now there's not a lot you can do to change how other people interpret information, so let's assume the onus is on us to make sure this does not occur.
We need to be crystal clear in our communications and have a something in writing to back us up, such as a Terms of Reference (TOR), Scope Document, Statement of Work or Requirements Specification – one of the essential deliveries of the requirements investigation phase of a project.
However, the title of the document is not as important as what's in it – and who signs it off.
In terms of content, typical headings will cover:
Business problem / opportunity – This is the first thing a business manager will read so it needs to be relevant and expressed in business terms. If it's a problem then what's it stopping us from doing – what's the impact on customers, on the organization and on staff?
If it's an opportunity, what will we be able to do that we can not do now? Avoid general statements like improved communications between departments as these types of projects are easily canceled in tough times. Try to describe opportunity projects in terms of a problem eg poor communications between departments is costing us X hours per person per week in performing re-work.
Customers – Everything starts and ends with the customer, they buy our products which in turn pays out wages. Government departments have customers too – the public and politicians. How will this project impact our customers?
Project sponsor – Who is sponsoring this project? Every project needs a sponsor – a senior manager who is behind it, who is prepared to back it and, depending upon the business culture, prepared to finance it. Sometimes the sponsor may not have the budget to pay for the project but will have the authority to seek funding from upper management. If in doubt as to who the sponsor is, find out who's hurting the most then work up from there.
Objectives – Describe out what the project must achieve. Aim for one or two statements that succinctly and fairly say what is to be achieved. Not how it will be achieved – that's the solution that you're going to derive. Be careful not to have too many objectives – you can only shoot an arrow at one target. A good test of whether an objective has been met is to ask if the problem described above has been resolved.
Users – Who will use the new capabilities that the project deliveries? The department or teams affected need to be identified.
Stakeholders – Are there other people, departments, or outside organizations that have an interest in this project? Name them and list their contact details.
Scope – Set out clearly what is included within the project scope, and what is not. This may include facilities, organizational areas or functions. Use the words 'this project includes …' and 'this project excludes …'. It is a rare project where the scope is fully known at the beginning, you may have to re-visit this paragraph later.
Constraints – Set out the constraints within which the project must be connected. The more you have of these, the more difficult your project may be to manage. However, you need to be aware of claimed and assumed sources, as well as the 'obvious' ones. Most constraints will be in one of three categories – time, money and functionality (quality) of the end deliverable.
Justification – Some initial ideas on the likely savings and benefits to be achieved by the project. This information should be sourced from the project sponsor. Explain the impact the problem is having – it needs to be big enough to be worth fixing. Management often request a cost-benefit analysis (CBA) at the TOR stage. Be aware that this is impossible to derive without some idea of a project plan, a reasonably solution and an implementation plan. In other words, it would be nice to have a CBA but it can not be done accurately at this stage unless a separate Feasibility and Costing Study has been performed.
Resist the urge to put any dollar figures in this section!