From a quality and manufacturing perspective, I am intrigued by the appalling product development failure rates. My background is primarily in manufacturing and quality, departments in which being even slightly over-cost or shipping late is a cardinal sin. By comparison, most development projects I've been involved with have been grossly late and over budget and some are off by several multiples of the original projections.

People think I'm a pessimist when I predict at the beginning of a product development project that it will be terribly late or over-budget, but I'm just being realistic and betting on odds that are in my favor. When projects start with poor planning, poor feature specifications or poor scheduling (like most projects), it's a sure bet to be a failure—and you can see it in the first few weeks.

I've also been intrigued by product development failures because it has such a profound affect on quality. As any experienced quality professional knows, late projects usually lead to rushed efforts and quality problems that are more expensive to fix in the field than if they had been addressed during the design cycle. A rushed project can devastate a customer.

Engineering project development is an issue that must be addressed from all angles. I recently read an article that shed insight on one aspect of product development. The study by Kurt R. Linberg was published in the The Journal of Systems and Software and was titled, “Software developer perceptions about software project failure: a case study.“ The study focused on software, but I feel its insights apply to all product development projects. The study analyzed a software development project that was more than four times the planned cost and took nearly twice the expected time. Sadly, I think this is typical.

The article is unusual because it examines the “soft side“ of project management by focusing on the perceptions of the programmers. Of the 18 engineers involved with the project, half said this late and terribly expensive project was the best project they had ever worked on because it was a technical challenge, the product worked well, and the team performed well. One team member said, “The project was not a success because it was over budget and beyond schedule. But it wasn't a failure. A project failure, I believe, can only occur if there is customer discontent. If canceled, the project may not be a failure. I've been part of projects that have been canceled. They were not failures because we learned a lot that could be directly transferred to the next project.“

Another interesting finding was that the high job satisfaction on the development team appeared to be disconnected from the organization's cost or schedule goals. The company defined project success as being on-time, on-budget, and meeting product specifications. The developers felt that success was based on schedule and cost performance compared to industry norms, not company plans. Developers felt that projects that were cancelled because they were late and over-budget could still be a success if they learned something that could be applied to future projects.

I think we have a long way to go in mastering new product development projects. The study done by Linberg reveals an aspect of project management that is clearly misunderstood. The good news is that this type of insight gives a direction that can lead to quality improvement. I feel that the engineering stage of product development is clearly the best opportunity for improvements that can pay back the initial effort a thousand times over by reducing field failure costs.

Have you seen product development projects fail one after another? Are quality professionals and project managers under-valuing the “soft issues“ like disconnects in perceptions of success? Send me an e-mail. I am interested in hearing what you think.

This disconnect between how the company defines success and how the individual engineer defines success is a major, unexplored clue as to why so many projects fail.