Seriously. You can’t make a perfect project. You can’t just “will” a project to success. Too many variables. But you can do all that you can do to make a project engagement successful. And the two biggest ingredients to that success that the project manager can have a great deal of control over is practicing effective and efficient communication and seeing to it that no works starts without good, detailed, complete-as-possible requirements that read well and mean something to both the customer and the project team. Today, we’re going to talk about requirements.
Requirements are the lifeblood of the project
I’ve said this time and time again. And I’m going to say it here again. Requirements are the lifeblood of the project. Bad requirements = an extremely risk situation wrought with conflicts, change orders, disputes, customer dissatisfaction, budget overruns and missed deadlines. Good, detailed requirements = far less risk, much greater chance for project success, fewer change orders because the project scope is well defined, and a much happier project client.
That project client often comes to the table with an idea of what the project requirements are or should be. But make no mistake, only the foolish project manager takes whatever requirements the customer hands over and starts to build a solution around them. The smart project manager considers these to be a start and builds time into the project schedule to dig deeper – to ask the tough questions to determine the real project, the real need and the real, detailed requirements for the engagement. That’s the first step for the project team on the road to project success…find out what the real requirements are. And take the right amount of time to get there.
Customers don’t do requirements
They try. They really do, but customers can never really come up with good, detailed, complete requirements on their own. They may do a great job of mapping out their business processes – both as-is and going-to-be. But as far as requirements go, every time a customer has told me going into an engagement that they have already documented their requirements, they ended up being clearly off the mark. Most customers don’t really understand what the delivery team needs from requirements in order to move productively forward. And a big problem with requirements is, as we all know, they are ever changing. So it is imperative that they be as well documented as possible from the outset.
The customer ‘expects’ you to help them extract the necessary requirements. It’s happened to all of us, right. The customer is paying the price for the project so they naturally think they can go into the engagement with just some high-level requirements drawn up by a few SMEs and the rest will just get during the planning process.
What is a good requirement?
When putting together requirements, all parties involved need to be asking if each requirement meets the following criteria…
- Is the requirement correct? Does the requirement specify a true need, desire, or obligation? Have you identified the root cause that necessitates the requirement?
- Is the requirement complete? Is the requirement stated as a complete sentence? Is the requirement stated entirely in one place and in a manner that does not force the reader to look at additional information to understand the requirement?
- Is the requirement clear? Is the requirement unambiguous and not confusing? Does everyone agree on the meaning of the requirement?
- Is the requirement consistent? Is the requirement in conflict with other requirements? Is the terminology used consistent with other requirement and glossary terms?
- Is the requirement verifiable? Can you determine whether the system satisfies the requirement? Is it possible to define a clear, unambiguous pass or fail criterion? Is it possible to determine whether the requirement has been met through inspection, analysis, demonstration, or test?
- Is the requirement traceable? Is the requirement uniquely identified so that it can be referenced unambiguously?
- Is the requirement feasible? Can the requirement be satisfied within budget and on schedule? Is the requirement technically feasible with current technology? Is the requirement physically achievable?
- Is the requirement design independent? Are all requirements that impose constraints on the design, thereby limiting design options, justified? Is the requirement stated in such a way that there is more than one way that it can be satisfied?
- Is the requirement conjunction-free? Does the requirement statement define exactly one requirement? Is the requirement statement free of conjunctions (and, or, but) that could indicate multiple requirements?
Good requirements are the launch pad to success
Some key benefits of having good, well-documented and meaningful requirements prior to beginning any design work on the project are:
- Significantly reduce or eliminate the need for change orders, thus reducing the overall cost of the project
- Reduced change orders means reduced timeframe for the project meaning it is more likely to be delivered on time without extending the schedule to accommodate changes
- Test cases can be written earlier in the process due to requirements that are not moving around – meaning better test cases and better prep for UAT
- Better end product – if requirements are well understood early on and are not a moving target, it is easier for the delivery team to deploy the solution that the customer really wants which also means less post-deployment work and likely less cost to the customer
These are just a few of the benefits…there are often many more. The plain truth is this: requirements drive the project. Poor or non-existent requirements mean an extended project, budget overruns, and missed milestones. Solid requirements mean a much greater chance for on time and on budget delivery of a solution the customer wants and needs and ultimately greater customer satisfaction. Of course there are no guarantees…and an Agile approach that allows for requirements to shift and for the project to react can help mitigate the overall impact to the project.
Summary
There are many ingredients to project success and many of those ingredients can be things far beyond the control of the project manager, anyone on his team, and anyone at the customer organization. It can be a 3rd party vendor relationship going well or going poorly, it can be financial stemming from an executive funding decision, it can be almost anything. And you, the project manager, may have no control at all over what causes a project to fail – or even to succeed. But one thing you can do is manage the requirements definition process well and not let the project start until you have a consensus that requirements are complete and well documented. Without those in place, you’re likely to experience re-work, fighting over change orders and scope issues, and customer management will be difficult as your project client will likely feel that you’ve not managed the process well if issues consistently arise as a result.
