1. Losing Control of the Product Development Costs

A team is armed with a good kick-off scenario. The project is launching with a well-defined scope and set of requirements. Targets have been properly designated. The team knows the mission and its goals. Six months into the project, the project engineer runs a projected, costed bill of materials and then… SHOCK. The bill of materials projection rollup vastly exceeds the target cost. What happened?

In this scenario, the team lost focus on the projected cost implications in a myriad of technical decisions in the course of execution. Bad news can happen but, what you want is to have bad news discovered early. One tip for helping to identify bad news early (when there is time to course correct) is to start with sub-system and key component cost budgets. These need to be established early and validated frequently -- bi-weekly is not too frequent.

As an example, on complex product design projects involving electronics systems, establish early budget targets for the electronics (to the board level) and mechanical components or expected cost drivers. The numbers will likely vary as the project progresses but constant monitoring will enable the “puts and takes” to be assessed and over-runs remediated in a timely way. Worst case, cost vs. feature vs. requirements trade-offs can be made early in scenarios where it is anticipated that “the wheels are falling off the bus.” The sooner variances are confronted, the lower the impact to the project cost and schedule, or the disappointment when the features have been delivered at a cost that kills market acceptability.

2. Losing Focus on the Product Requirements

In the heat of the project, it is easy to lose sight of the complete nature of the requirements that need to be driven into the product being developed. Often, these oversights are not discovered until late in the development process. The design may be so far along that missing features cannot practically be incorporated. Best case, correcting for the missing requirements may be quite costly in terms of schedule or development budget. Missing requirements can play havoc with trying to control product cost projections, as well.

READ RELATED ARTICLES ON DESIGN NEWS:

3. Failure to Monitor Schedule

Again, in the heat of the project, it is not unusual for the team to lose sight of the project schedule. While hindsight is 20:20 and easy to realize, it takes effort to monitor and track schedules to completion. Some companies have elaborate tools for monitoring estimates to completion (ETC). Managing very large projects may involve regular activity to keep ETC under control. In smaller companies, startups, and smaller projects, such controls are often missing or not monitored frequently enough. There is an old saying that there is no project so small that it cannot be mismanaged. Often, the loss of schedule control is a factor in making even small projects grossly over-run in schedule. And, by the way, time is indeed money. In almost every case, for a given set of work, the one that takes longer on the calendar will cost more than one completed more quickly.

4. Unchecked Scope Creep

This is often the “death of a thousand cuts.” A small, incremental change to adjust the product functionality can have a huge impact. This small change in itself may not kill a project’s schedule, budget, or product cost. However, the cumulative effect of change after change can wreak havoc with project control. Careful review of requirement changes along with the effects on project cost, schedule, or product cost needs to be performed. Companies frequently will do this for big changes, but routine review of the baseline and any changes is a key to keeping the scope under control.

5. Inadequately Resourced Project

A well-designed project starts with a reasonable definition of requirements and features along with projections for budget and schedule. Once a decision is made to “go,” organizations are ready to get moving right away. However, it is often the case that a project starts slowly with gradual ramp up of the necessary talents and funding. As an example, consider a project with a kick-off plan starting with a team of five engineers ramping up to an eventual team of 15. What happens when the project team kicks off but only two of the engineers are actually working the program? What happens when the five engineers show up but each of them is beginning the new project while still ramping down from older projects? What results is a slow project start. Often, no amount of overcompensation with extra resources on the backend can resolve the problems of a slow launch.

Notwithstanding the prior list, mistakes will be made. Those in product development for many years are painfully aware of the Peter Principle (an article topic for another day) and the parable that Peter was an optimist. Though mistakes will be made, the listed mistakes are ones that occur again and again. By avoiding these mistakes, you can better avoid unsuccessful projects, delayed launches, and missed market opportunities -- and better manage your product development projects for success.

[image via iosphere/freedigitalphotos.net]

Mitch Maiman is the president and co-founder of Intelligent Product Solutions (IPS), building on a vision of delivering a new model for software and hardware product development that integrates the full spectrum of design and engineering disciplines as a single-source solution.