Priority #4 in project rescue – Requirements management

For every project I’ve ever been on, the project team had a love-hate relationship with the requirements. On the one hand, it’s so nice for a team to know what to build. On the other hand, the art of good requirements gathering is as elusive as intelligible tax law. It’s common to see project teams bungle the requirements. Why?

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.

So project teams tend to bungle their requirements. Coincidentally, projects don’t allow for the typically hidden risk that badly handled requirements add cost and schedule.

Before talking more about how to address requirements, I want to address my most important point. When you come onto a troubled project and start to assess the health of the requirements, you need to make sure that you’re not the biggest obstacle.

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.

So how do you find the least expensive way to live with the requirements? Basically, you need to start with requirements at their most fundamental and add back discipline and process until the project is livable. In my mind, there are two fundamental roles for requirements on any project:

1. Knowledge transfer across the team 
2. Detailed agreement with the customer (internal or external) 

When written requirements are contractually binding, then there is a legal consideration that effectively becomes item #3 on this list.

When the requirements are contractually binding, then you don’t have many options. You must fix the ambiguities, the omissions, the conflicts, and the deletions by going through change management. Legal documents that don’t represent the verbal understanding simply must be fixed. You must involve upper management and your legal staff in every decision to shortcut the process.

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 some manageable band aids that can avoid the cost of redoing the requirements. One common band aid is to compile centralized interpretations of requirements. I’ve done this by using review “comments” if the requirements are in a Word document. I’ve also done this by adding an “interpretations” column in Excel to the traceability matrix. Another common band aid is to follow the spirit of a defunct change-control process by mimicking it with a team wiki. If you don’t use a wiki, it can be done via email.

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.

One project I helped on had decent requirements but bad change management. Over time, the team accumulated extensive interpretations as a verbal consensus. In many instances, the actual wording of the requirement had become completely obsolete. This would have been okay except that QA was left out of the discussions. In other words, this tribal knowledge didn’t include the whole tribe.

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. 

On another project, the requirements included the questionable practice of wording the requirements as complex lists of conditions and used compound Boolean phrasing with and’s and or’s. This was a big red flag for me. I immediately started reviewing test cases in detail and compared them to the requirements. (And just my luck, there was no traceability matrix of any kind!)

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. 

There are so many things that can go wrong or be done badly when it comes to requirements. If it’s a new project, you have a shot at doing it right. If it’s a rescue project, that ship has sailed. The goal is to enable the project team to be successful with the least expensive remediation for requirements. Once requirements management is good enough – not perfect but good enough – then you can turn your focus to the next item on my list. I will cover this in the next and last post.

(Stay tuned for part five of this series next week). 

Comments are closed.