Should Requirement Quality be Measured?

Measuring requirement quality can reveal opportunities for long-term improvements in requirement definition, can show you where to invest for improvements, and can help you develop your team.

Opportunities for improvement

If requirement quality isn’t measured, there will be no future improvement in requirements. Every project – in terms of requirements quality – will be a rerun of the last project. No lessons learned. No forward progression.

Did your last project have rework? Were there any crisis situations in testing? Were there customer complaints? A review of the last project’s requirements may show you how to avoid some of those same headaches on your current and future projects. Read more »

Scoping the Project for Better Requirements

Good scope before requirements

The earlier you define scope, the more efficient 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 debates.

If you do not give everyone writing or reviewing requirements your scope definition, they are likely to create their own. Imagine listening to a movie without watching it – as I have done many times on trips in the SUV listening to a movie several times but never seeing it as it’s playing in the DVD player behind my head. I have a vision – my own vision – of what’s going on and what the characters look like and what the set looks like, but if no one describes it to me in detail or I don’t see it for myself then that’s all it is … my own vision. And it likely differs greatly from the actual film itself. Read more »

Good Requirements vs. Rework – Part 3

The post is made possible by the great people at Seavus, creators of online Project Management tools such as ProjectOffice.net, Project Viewer, and Project Planner.  Please visit their site for more information.

As we concluded Part 2, we discussed what we all really already know – that bad requirements usually lead to cost or budget overruns, project timeframe slippages, frustrated and overworked employees, dissatisfied customers, lost profitability, and quite possibly shortened tenure with your company.

The ultimate cost of requirement errors and omissions can be huge beyond just the rework factor. Requirements drive more than just project and product quality. They drive product end-user usability. They drive the personnel skill levels for both product development and operation. They determine how the product will be used. Requirements for ease of operation, for example, lead to products that require less training before use and less time to accomplish tasks. Omitting operability requirements will result in a product that is inexpensive to purchase but costly to use. Worse, end-user operators may make more mistakes in the product’s use. Read more »

Good Requirements vs. Rework – Part 2

The post is made possible by the great people at Seavus, creators of online Project Management tools such as ProjectOffice.net, Project Viewer, and Project Planner.  Please visit their site for more information.

This article is based on information from Hooks and Farry’s book entitled, “Customer-Centered Products.”

“Better, cheaper, faster!” Remember how we discussed that in my previous article and closed out with the good news that “better, cheap, and faster” is actually possible?

Now the bad news: You have to change your approach to project and product development or procurement in order to realize “better, cheaper, and faster.” Repeating the mantra is not enough. Nor is it enough to tell your requirement definition team to simply “write better requirements.” If that was all it took, we all would have done that long ago. You, as the project manager, must identify the areas needing improvement and empower your people to change. Only a manager can eliminate many of the causes of bad requirements. The seeds of schedule and cost overruns as well as operational failures are planted early in projects, typically with pressure, often from management to procure or begin developing a product before fully defining it’s needs and use. Read more »

Measuring Project Progress

The post is made possible by the great people at Seavus, creators of online Project Management tools such as ProjectOffice.net, Project Viewer, and Project Planner.  Please visit their site for more information.

A section of Eric Verzuh’s book “The Portable MBA in Project Management” provides the basis for much of this article.

Measuring Progress

The key to finishing a project on time and on budget is to start out that way and stay on track throughout the project. When project managers start with challenging schedules and then fall behind, even by a little, they spend the rest of the project trying to catch up. Other projects, however, seem to have a self-correcting process built into them; if they fall behind a little, the problem is quickly identified and dealt with immediately. Progress measurements are the tools we use to identify problems when they are small and there is still time to catch up. Because cost and schedule progress comprise two-thirds of the cost-schedule-quality equilibrium, they are the primary focus of progress measurement. Read more »