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 doesn’t 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 deliverables of the requirements investigation phase of a project.
However, the title of the document isn’t 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 organisation and on staff?
If it’s an opportunity, what will we be able to do that we can’t do now? Avoid general statements like improved communications between departments as these types of projects are to easily cancelled in tough times. Try to describe opportunity projects in terms of a problem e.g. 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 precisely 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 solved.
Users – Who will use the new capabilities that the project delivers? The department or teams affected need to be identified.
Stakeholders – Are there other people, departments, or outside organisations 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, organisational 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 conducted. The more you have of these, the more difficult your project may be to manage. However, you need to be aware of implied and assumed constraints, 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 likely solution and an implementation plan. In other words, it would be nice to have a CBA but it can’t 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!