Eliminate ambiguity

On an IT project, you will have probably lived and worked with the details for weeks, if not longer, before handing over the requirements document to the team that will eventually build the system. It is easy to assume that as you know exactly what you mean, they will too – but this is a dangerous assumption to make.

A D D R E S S I N G T H E P R O B L E M

Sarah, a project manager in the financial services sector, collated the require­

ments from her business users for a new IT system. They included the need for staff to be able to record clients’ address changes. Clients wanted their post to go to their old address until the day they planned to move house, and then from that date to their new address. The customer-facing team decided it would be easier to tell the system to store the new address and the date from which it was effective, rather than make a manual note of it and create more work for themselves later.

The system was built with a field for the new address and a field labelled

‘effective date’. While it was being tested, Sarah realized that when the ‘effect­

ive date’ arrived, nothing happened. The system did not automatically switch to using the new address. The developers had not correctly understood the need and had not built the functionality the users wanted. Fortunately, as she had planned for an adequate testing and revision stage, Sarah was able to ensure the change to her system was cheap, quick and pain-free – and that in the future, customers would be receiving mail sent to the right address.

Documenting scope is a laborious task, but it is essential to the success of your project that you get it right. That means not only including all the relevant details, but also writing it in a way that is unambiguous. Ursula K.

Le Guin gives this advice to aspiring authors in her book Steering the Craft:³⁰

Our standards for writing are higher and more formal than for speaking.

They have to be, because when we read, we don’t have the speaker’s voice and expression and intonation to make half-finished sentences and misused words clear. We have only the words. They must be clear.

Your project scope document is unlikely to be entered for any literary prizes, but Le Guin’s advice is still sound for those of us not writing novels. The project scope is not a document for you; it is a list of detailed instructions to someone else. You will not be there to clarify what you really mean when

Project Management in the Real World

they read it and are working from it, and so you have to make it completely clear.

When you are putting together business requirements for your project:

• Be absolutely certain that there is no ambiguity between what your business users want and your own understanding. Call a meeting and coax out of them what it is they really want from your project. This is an opportunity for complete blue-sky brainstorming – if they could have anything as a result of this piece of work, what would it be? Get them to be clear about their requirements, ask the stupid questions, and then negotiate. It might never be possible to have a dedicated customer service representative for each client or response times to customer calls within two seconds, but those requirements allow you to form an understanding of what is important to your customer: in this example, the business user.

• Once you have the list, add to it, making sure you are being as spe­

cific as possible. List colours, materials, brand constraints and any legislation with which the solution must comply. Are there any other systems with which it must integrate? What security is appropriate?

Detail exactly what is meant and spell out any assumptions.

• Verify the document with the business team before it goes to anyone else. This is their opportunity to point out that you have not under­

stood what they need. Even better, ask all the relevant parties to sign the requirements document.

Allowing stakeholders to review the document also means that if the system does not deliver what they were expecting when they first see it, you are in a better position to explain why: you gave them plenty of opportunities to add new requirements or clarify existing requirements. If the stakeholders didn’t take those opportunities, they will have to use the formal change control procedure to make any alterations or add new requirements to the project scope at this stage, if it is not too late.

• Once the document is written, test it: give the requirements list to someone who knows nothing about the project and ask them whether they could use it as the instructions to build something. If they think they can, and their solution is similar to what you are expecting, then your requirements document is probably pretty unambiguous. If it is wildly different, then it is time to think again.

H I N T

A good requirements document should not only ensure your product is built exactly as you wanted but also form a way of checking off users’ needs at the testing stage. It will form

Eliminate ambiguity

the basis of the user-testing documentation, and if it is very detailed it may save you time in writing test scripts.

I D O N ’ T H A V E T I M E T O D O A L L T H I S

It is inevitable that at some point in your career you will work on a project where there is simply not the luxury of time for a full requirements document.

Work with your team to revise things as you go along. It can be risky, but if it is a well thought-out and relatively simple project, this approach can save a lot of time. Just remember to update the requirements document as you go along, so at the end you have an accurate record of what has been done. If you do opt for the make-it-up-as-we-go-along approach, make sure you allow enough time in the plan to test your solution thoroughly, both technically and from a user’s perspective. It is much easier to alter things at the testing phase than after the project moves into a full implementation.

Finally, if you are in any doubt about whether your team can handle the ambiguity, take the time to do the requirements gathering and documenting exercise fully – it really will be worth it.

G O L D E N R U L E S

The users’ requirements form the basis and rationale for the entire project, and so it is essential to have them:

• documented;

• unambiguous;

• agreed by the users themselves.