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 »

Good Requirements vs. Rework

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!” “I want it yesterday!”

Everyone out there has heard one or more of these – how and when you’ve heard them depends on your industry. But they translate into the same headaches for everyone. If you are a product development manager, you must develop and deliver higher quality products in less time and for less money than you have in the past. If you are in charge of procuring products for use in your company, you must procure a quality product faster and cheaper than ever before – especially in this economy. Otherwise, you may not be able to stay in business. Read more »

How Much Effort Should Scope Definition Take?

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.

We’ve looked at how you go about communicating scope, now let’s look at the concept of how much effort should go into defining the scope of your project or product development process. This article is based somewhat on text from the book “Customer-Centered Products” by Hooks and Farry.

Scope definition is one of the most critical aspects of project or product management. Without proper scope definition, a project is destined to experience continual scope creep resulting in ongoing timeline and budgeting issues.

When the scope creep happens, the only way around the timeline and budgeting issues will be to introduce many change orders to your customer which will likely decrease their satisfaction level significantly. You’ll still have the timeline issues and the budget issues, but you’ll be able to justify them with the stack of change orders – assuming the customer actually approves all of them rather than flat out canceling the project altogether out of frustration. A much better route is to spend the proper amount of time up front correctly identifying and documenting scope and gaining agreement with the customer on that carefully defined scope. Read more »

A Nine-Step Process to Requirements Definition

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.

Until a few years ago, the requirements definition process was only briefly discussed in books that addressed project management, systems engineering, and software engineering. Many texts assume that the requirements are a given and show the requirement definition process as a single step on a waterfall chart. Most college curricula never even address the subject of requirements, much less the requirement definition process. Books devoted to requirement definition finally began to appear in the early 2000’s. Some outlined complex requirement definition processes, but more complex is not necessarily better. Most, if not all, of the benefits of a complex requirement definition process come from a few key steps. Overly complex processes use significantly more resources than simple ones do without significant incremental gain. Read more »