Part 2 in the series, “How to Shoot Yourself in the Foot: 7 ways to do software requirements poorly to set your project up for failure and what to do instead.”

In my last blog I mentioned Barry Boehm’s landmark study that showed that errors corrected at the end of the project lifecycle can cost 50 to 1,000 times as much to correct as correcting them close to the point where they were originally created. I went on to show that this is due to project artifacts to be corrected increase over time and more people need to get involved in defect correction as the life cycle progresses.  A poor requirement or an unneeded requirement will become the ‘tip of the iceberg’ for problems later in the project.

The risk and cost of not doing requirements at all should be obvious (though that does not keep some project teams from trying this out anyway). This blog I want to focus on the problem of short-changing the time spent on requirements. Project teams can give lip service to the importance of the requirements phase and still shoot themselves in the foot in one or more of the following ways:

The executive sponsor(s) sets the tone for a project: a concise and compelling vision, selling the team on the value to the business a successful project will bring and showing personal interest in the project by regular involvement – having ‘skin in the game’. The executive sponsor can short-change requirements by directly limiting the time spent on the elicitation, modeling and documenting of requirements to an inadequate level. If only this was the most common problem with executive sponsors, it would at least allow the opportunity to persuade the sponsor to not do this. The more common and subtle problems arise when executive sponsors show little or no interest in the requirements phase and instead keep asking the project team to “get on with the deliverables”. If the executive sponsor sees little value in requirements, the team will eventually follow along.

The project manager can short-change requirements time by not having adequate cross-functional involvement in the requirements phase. Stakeholders during the requirements phase should include representatives from all of the functional groups that will eventually be involved in the project. It is of course critical to have business involvement and involvement of the development team, but don’t forget the testing team, the marketing team, the technical writing team, the globalization/localization team, the customer support team, etc. Each of these groups can have valuable insights that will help produce the best possible requirements for a successful project.

The project manager can also short-change requirements time by waiting for an “almost done” Software Requirements Specification before involving stakeholders in the review. Even in projects using a Waterfall process, applying some Agile techniques and getting earlier, frequent reviews of requirements from the cross-functional stakeholders will yield better requirements sooner. In projects using an Agile process, the project manager can short-change requirements time by not doing the high-level requirements analysis prior to the first iteration. There needs to be a solid backlog containing prioritized features before the iteration starts.

The requirements engineer(s) short-changes requirements time by not listening to what the customer needs, not mapping this to the business needs and not prioritizing by business value. The requirements engineer(s) short-changes requirements time by not applying levels of abstraction in the requirements process. Looking back to the Boehm study, if the requirements engineer works on models first and reviews these with the SMEs and other stakeholders, errors found in the models cost less to fix than errors found in the larger set of derived requirements embedded in a large software requirements specification document.

The executive sponsor, the project manager and the requirements engineer can all contribute to poor use of requirements time to set the project up for failure or they can contribute to using requirements time effectively.

Next time I will look at “Don’t listen to your customer’s needs”.
Don’t shoot yourself in the foot on your next project!