Scope definition

It continues to amaze me how many projects proceed against a poorly-written scope document or no scope document at all.

It also makes me wonder on what basis tenders are made. If I am ever asked to provide input input work estimation, I insist on seeing a baselined statement of scope first. Without it, I am essentially being asked “How long is a piece of string?”

In case you are not already aware, scope creep is the single biggest threat to software projects. The nemesis of scope creep is change control, but you cannot control changes to the project’s requirements if there is no agreed scope and it is very hard to control changes if the scope is poorly written.

The statement of scope is possibly the most important document in the project. It needs to be written by a very experienced person whose command of the English language (assuming it is being written in English) is second to none.

When projects end in acrimony, I’d bet hard earned money that the root of the problem is poorly defined and poorly managed scope.

Click here for an example layout for a scope document, in case you need it. Feel free to make use of it, but also feel free to suggest improvements.

Takeways:

• Customers: Consultancies often underestimate the soft skills needed in a BA. Insist that your consultancy provide you with a Senior BA (i.e., experienced and with qualifications) to help draft your scope document. Do not let them fob you off with a junior BA or, worse, a graduate trainee.
• Consultancies: Don’t pull the bait-and-switch on your customer. It will cost you in the end. See above.
• Project Managers: A well-written scope document will be a valuable asset. See my advice to customers above.
• Analysts: If you have never done this before, insist on being supervised by someone experienced. Be pedantic in your use of precise and correct language.

Kind regards,

Declan Chellar