We continue our series on rescuing troubled projects by Bob Louton, PMP.
This article discusses the 4th-most urgent of all process areas, requirements management. After you have addressed the big problems with the plan, you can turn your focus to the next on the list.
I’ve seen at least three causes. For one, most teams and most companies seem to be profoundly ignorant about the value of requirements analysis as a skill set. When you have the good fortune to work with good-quality requirements, it’s like hearing a virtuoso violinist in concert after enduring years of high-school recitals. For the second cause, hard constraints on project planning tend to be set before the requirements are written. Consequently, requirements are cranked out quickly because development needs to start before the requirements are done. Thomas Hardy once said, “A resolution to avoid an evil is seldom framed till the evil is so far advanced as to make avoidance impossible.” Finally, teams that fall behind often take shortcuts which, in turn, contribute directly to the project’s problems.
The only time to be dogmatic about requirements is while they are being written in the first place. Once they are signed off, then the job is to find the least expensive way to live with them. Let me put it this way: the best time to paint an apartment is before you move your stuff in because when you live there, painting is far more disruptive. It becomes a series of trade-offs between making the painting job easier and keeping the chaos bearable.
When written requirements are contractually binding, then there is a legal consideration that effectively becomes item #3 on this list.
When requirements are not contractually binding, it might be impractical to rewrite them. If there is no formal contract, the customer – such as a product manager or business manager – is internal. . There can be creative stopgap ways to reach agreement with internal customers. Of course if there are only a few changes, then use formal change management. In my experience, requirements usually have extensive problems on rescue projects.
There are other more creative options, too. You must bear in mind that every shortcut increases project risk. You must manage the risk you add by using a band aid.
Consequently, the test coverage was inadequate and many test cases held no semblance to the design. To avoid revamping the requirements, my solution was to hold a series of meetings to walk through the requirements with QA as an audience. QA took whatever notes they needed to be able to rework their test suites. This satisfied the need for knowledge transfer. It wasn’t pretty. But it got the job done with the least schedule impact and manageable risk.
I discovered that formal tests missed a lot of the combinations and permutations. In other words, the test coverage was woefully short. Of course, the root cause was that the requirements were not written well. The reality was that the project couldn’t handle the delay to rewrite them. Instead, we had a short seminar on the technique to analyze these requirements and write tests for them. The test phase had to be replanned in light of substantially more testing. Although the cost and schedule took a hit in the replan, rewriting the requirements would have exacerbated the impact considerably. In the end, the rate of bugs missed declined around 2 orders of magnitude. Here again, the solution was not to rework the requirements but to do what was needed to make them effective for knowledge transfer.
(Stay tuned for part five of this series next week).