Good Requirements Come From a Detailed Scope

good project requirementsI realize that sometimes requirements and scope are used interchangeably. In many discussions, the picture of the detailed requirements become the overall scope of the project that you then protect with oversight and change orders.

But there is also some work that has to happen up front to create that scope – that overall vision for the project and what will and won’t be included and what the ‘as-is’ will become. That overall scope of the project must be well-defined jointly with the customer so that everyone is working from a common vision before the first detailed requirement is written.

Good scope = good requirements

The team that can work closely with the project sponsor and customer team to define a detailed scope for the project will be more efficient and will work through the requirements definition process with the customer more effectively. The earlier you define scope, the more productive – and accurate – your requirement definition process will be. Work done before scope definition is usually wasted effort. An early scope definition keeps requirements writers from diverging, reduces requirement inconsistencies, and keeps the big picture in view. It also shortens the time required for requirement writing and rewriting and reduces conflicts, debates and inaccuracies.

If you do not give everyone writing or reviewing requirements a thorough scope definition, they more than likely will create or imagine their own. This is never going to be a good thing. You know how you read a fiction book and imagine the scene how you see it as described by the author? The town, the rooms, the characters…all vividly described in the text, but interpreted by you into your own personal movie in your head. Everyone who reads that same book will have a slightly to significantly different image in their head of what the author is describing. That’s how requirements will be without a well thought out, defined, discussed and documented scope. The result will be requirements written and reviewed from very different points of view – different goals, objectives, constraints, assumptions, operational concepts, and ultimately systems. Battles will be fought, not about requirements, but about these basic perceptions. You will end up with incomplete and conflicting requirements and the entire requirements definition process will take longer and be far more costly to your project than it needs to be. The project will be undoubtedly go over budget and off schedule and you will likely not deliver the end solution your customer is seeking.

If you guide your team through scope definition before anyone writes a requirement, you will prevent divergent and inconsistent requirements. You will reduce rework and wasted effort, which translates directly into reduced time and cost.

Defining and documenting scope pays huge dividends throughout your project life cycle, not just in requirement definition. The scope definition provides a lasting big picture reference for you and your team. It prevents you from losing sight of important constraints as well as customer needs. Long after requirement definition is officially complete, the scope definition will provide vision to the customer, designers, reviewers, testers, and maintenance personnel. This vision will enable these people to correctly understand the requirements in spite of their diverse backgrounds and knowledge bases.

Summary

Scope is a definition of what is important, meaningful and relevant to your project. It includes the needs, the goals and objectives, and the business cases, the high-level concepts, all of the key major assumptions, the project constraints like schedules and budgets, and the key discussion of authority and responsibility for particular areas or portions of the project. Of course, the relative importance of these items depends on the project and the customer, but usually most or all of these items should be included in the process. And yes, it’s ok to revisit and further define scope as needed throughout the requirements definition process because it’s a given that deep requirements analysis and definition will bring a more detailed and accurate scope vision as the process progresses.

Brad Egeland
Brad Egeland

Noteworthy accomplishments:
*20 year provider of successful technical project management leadership for clients across nearly every industry imaginable
*Author of more than 4,000 expert professional project management and business strategy articles, eBooks and videos over the past decade
*Articles/professional content receives over 40,000 page views monthly
*Named #1 in the 100 Most Inspiring People in Project Management
*Named a Top 10 Project Management Influencer to Follow in 2016
*The most read author of expert project management content on Project Times/BA Times for 2015
*Named most prolific provider of project management content over the past 5 years
*Noted for successful project management and financial oversight for $50 million Dept. of Education financial contract/program
*Chosen by the Dept of Defense as a subject matter expert (SME) to help select IWMS software provider for the largest IWMS implementation ever awarded

Articles: 179