Anyone who has ever worked on a product development project has asked this question. And has come up with many, many causes! A systems engineer might collect and categorize all these causes in a fishbone diagram. I created the following diagram based on my experience developing medical devices:

Once we have made a fishbone diagram, we can use it to analyze the causes and come to an understanding of ways to address them. As it turns out, there are good systems engineering practices that, if followed, reduce the chances that your project will be late.

Category 1:  Product Design

1.1 Missing User Needs

Make the effort to identify and understand user needs before designing the product.  If you miss an important user need at the beginning of the project and discover it during development, you must make an unpleasant choice:  Either ignore the need (and develop a product that doesn’t fully satisfy the customer) or rework the design (which adds time and money to the development effort). more time and money to add features to the product to meet the need.

Understand the context in which the product will be used.  What is the workflow?

1.2 Wants Confused with Needs

When gathering user needs, you will often encounter very opinionated users who insist that the product must include a particular feature. Talk to a wide variety of users to determine which needs are common and which are unique to a particular user. 

Users often express their needs in terms of features.  Understand why someone wants a particular feature.  Document the need, noting that the feature is one way of meeting the need.  As you design the product, you may decide on a different implementation that would satisfy the user need.

There is never enough time or resources to develop a product that meets everyone’s wants.  If you have accurately identified the user needs, you will design a product that provides a basic level of satisfaction.  You can add the most popular wants in a later version of the product.

Your initial product design will probably include several of the most important user wants in addition to all of the user needs.  When the project is behind schedule, you might be able to reduce the scope of the project by not implementing features that satisfy wants rather than needs.

1.3 Poor Architecture Design

As you are developing the system architecture for your product, put a lot of thought into how functions are allocated to subsystems and components.  This is not an easy task!  You must iterate designs to come up with a set of subsystems and components that best support the product design.  However, if you do this well, you will end up with subsystems and components that are internally coherent and have simple interfaces between each other.  This in turn supports a development process where many subsystems and components can be developed in parallel and then integrated.

Conversely, if you do this poorly, you will forego opportunities for concurrent development and you will greatly complicate the task of system integration.  If the pieces and how they fit together aren’t well thought out, you can expect a very messy and time-consuming integration process. For an illustration, see Lessons from a Model Car Kit.

Use a good MBSE tool to put together proposed architectures and allocation.  This allows you to create and compare several system architectures relatively quickly.  The tool allows you to focus on the intellectual effort of design.

Pay attention to the interfaces between components and subsystems.  If the interfaces are complicated, it may indicate that you haven’t yet come up with a good allocation.

If you are modeling the system architecture, pay attention to the aesthetics of the model!  A model with lots of boxes scattered everywhere and connected with many lines indicates that more intellectual work is needed to come up with a better architecture. 

1.4 Interfaces Not Defined

Don’t be tempted to skip this task!  If your interfaces are not well defined, you can’t be sure that your architecture fully supports the desired functionality.  You can’t test subsystem or component interfaces before integration, making the integration process much more messy.

This also applies to external interfaces – how the product will communicate with other systems.

Use a good MBSE tool to make this task easier.

Category 2: Schedule

It is very useful to think of a schedule as something that models a proposed project. For a detailed discussion, see the post Schedules are Models.

2.1 Missing Tasks

If your schedule doesn’t include all of the necessary tasks, you will discover them during development. Your program will be delayed while the missing task is completed. Other tasks that depend on the missing tasks may also be delayed.

2.2 Dependencies Poorly Defined

If you don’t analyze and document the dependencies between tasks, the program will perform tasks out of order.  Tasks that are performed before their prerequisite tasks are completed will have to be redone.

The program will also miss opportunities for parallel development.

2.3 Testing Tasks not Defined

Allocate adequate time for creating, debugging and executing test protocols.  This includes protocols for unit tests, interface tests, subsystem tests and integration tests. Be aware that testing time is often underestimated. We all want to believe that our work will be so good that even the first iteration will pass all tests. Allow time for some rework and retesting.

2.4 Integration Tasks not Defined

Far too little thought is given to integration.  Successful integration depends on good systems engineering design work to determine the appropriate subsystems, the interfaces between them and the sequence of integration.  For an illustration, see Lessons from a Model Car Kit.

2.5 Inaccurate Time Estimates

There are many reasons that time estimates are never perfectly accurate:

• The task itself is not perfectly defined.
• The task has never been done before, so there is no experience to base an estimate upon.
• The person who makes the estimate will also do the work. On the one hand, this person has the most knowledge and experience to make a good estimate. On the other hand, since people prefer to be praised for completing a task early to being criticized for taking longer than expected, they will be tempted to pad the estimate. Parkinson’s Law ensures that padded estimates become a self-fulfilling prophecy.
• The task will be done in the future. Therefore, the time estimate is a prediction. Predictions are never perfectly accurate.

In theory you could improve inaccurate time estimates by creating another model – one that takes a task time estimate and models what the actual time would be. But this new model might not improve the accuracy of the time estimates enough to justify the effort it would take to make the model. Perhaps that is why I have never seen anybody do this.

So don’t expect that task estimates will always be accurate and don’t waste time trying to make them perfect.  If estimates are made in good faith, the over-estimates and under-estimates balance out and the overall schedule is accurate enough for any reasonable business or project management purposes.

2.6 Inappropriate Task Granularity

Task granularity refers to the average duration of the tasks in the schedule.

If the granularity is too coarse, the schedule will contain many tasks that are expected to take several weeks. This often indicates that not enough thought has been put into defining what the task entails. Furthermore, long tasks are more difficult to track. Managers don’t want to go for weeks without any idea if progress is being made on a task, so they will be tempted to request a percent complete for the task. Since it always seems like tasks are stuck at 90% for a very long time, managers still don’t get an accurate picture of the project’s progress.

On the other hand, if the granularity is too fine, the schedule will contain many tasks that are expected to take only a day or two. The effort expended to define and track at this level of granularity adds time to the development project.

If most of your tasks are between 3 days and 2 weeks, the granularity of your schedule is probably about right.

Category 3: Risk Management

3.1 Risks not Identified

Identify risks as part of the iterative design process.  After coming up with a proposed design, evaluate it for risks.  Determine how to mitigate the risks and incorporate the mitigations into the next iteration of the design.

If you wait to identify risks until they reveal themselves during product development or testing, they will be much more expensive to mitigate.

3.2 Using Unproven Technologies

You may have good reasons to incorporate unproven but promising new technologies in a product.   However, it is important to allocate time and resources to prove that the new technology will work as hoped in the product being designed.

Category 4: Testing

4.1 Poor Task Completion Criteria

You need to define unambiguous task completion criteria so that test protocols can be written to determine when a task is completed.  If you don’t do this, the team can claim a task is finished as soon as (for example, in software) the coding is done.

4.2 Interfaces not Tested

Write a separate protocol to test the interface to a component or subsystem.  Do not begin integration testing until all of the components being integrated have passed their interface protocol.  If you do not do this, integration testing will be much more difficult.

4.3 Inadequate Test Protocols

A test protocol may not fully test all features of the component being tested or may omit some test cases.  There are often far more tests than one realizes.  Consider automating protocols with lots of test cases.

You can automate testing by developing a software program to run through all the test cases.  Write this program in tandem with the development of the unit.  The testing department then runs the test software on the unit to determine if the unit is working.  This process makes regression testing much easier.  When a new build is released, the testing software is re-run on it and problems are quickly identified.  Of course you need to be able to prove that the test software itself is working correctly!

If your team is using a good MBSE tool, run simulations on the models for that unit.  This will uncover design issues BEFORE development begins, when they are much easier to fix.

4.4 Inaccurate Test Protocols

Debug your protocols before using them!  A protocol that reports an incorrect result will cause confusion and rework.

4.5 Overly Complex Test Protocols

Written protocols can be so complex that the people running them don’t understand how they work and the results are unreliable.  The causes of this problem may include a design that is too complex or lack of thought into good ways of testing, or testing at the wrong level (i.e. unit tests for something that should be tested at the integration level.)

4.6 Compromised Testing

The testing department must be independent from the developers.  The testing department decides whether a unit or subsystem is working – not the developers.  Program managers use the testing results to determine if a task is finished – not the opinion of the developers.  If the test team is not independent from the development team, test results become compromised even with the best of intentions.

The testing department should also have enough independence from management to resist pressure to fudge the results.

The testing department should have adequate resources (people, space, test equipment) to do their work. 

4.7 Antagonism Between Testers and Developers

Develop a good working relationship with the test department.  They are there to help you achieve the common goal of a good product. 

Category 5: Resources

5.1 Untrained People

You need people with the proper skills to develop your product.  Either hire skilled people or put the time and money into training them properly.

5.2 Too Few People

If your program can’t hire as many people as it needs, the project will take more time.

5.3 Too Many People

You may have too many people on your team at the beginning of the project when you only need a small team to do the design and risk mitigation work.  These extra people will need something to do.  In a poorly managed project, they start development work on components that haven’t been adequately designed yet.  They will distract the people doing the design work.  They will need to redo their work after the design is finalized.

You may also have too many people on your team during the later phases of development.  When management sees that a project is running late, they will add more people to the project.   This will slow down the project while the existing people train the new people. If it is difficult to train people or if the project is nearly complete, adding more people to the team may actually delay completion.

5.4 Inadequate Development Tools

When selecting tools, make sure you take into account the productivity improvement expected when using the tool and not just the purchase price.  For example:  Consider a tool that costs $2,000 per year but improves the productivity of an engineer by 2%.  If you are paying this engineer $150,000 per year in salary and benefits, it will increase their productivity by $3,000 per year.  The company will gain $1,000 per year on its investment – a 50% return! On the other hand, a tool that is free, but reduces the productivity of this engineer by 2% will cost the company $3,000 a year. 

True story:  a few years back, the company I worked for decided to start using MBSE.  Management selected a free tool for us to use.  Management liked it because it was free (no up-front costs!), but the tool was not well designed, documented or supported.  It lacked many essential features.  We made no progress implementing MBSE as long as we used that tool.  When we finally purchased a good modeling tool recommended by a new employee (which cost $2000/license/year) we finally made progress!

5.5 Inadequate Test Equipment

Test equipment, like development tools, should be seen as an investment in employee productivity.  Calculate your costs accordingly.

Category 6: Execution

6.1 Ineffective Design Meetings

Successful and productive design meetings depend on how well the meeting is led. Read more at Leading a Design Meeting.

6.2 Execution Control Meetings

(See existing post)

6.3 Schedule Misuse

(See Parkinson’s Law below)

6.4 Parkinson’s Law

Managers are tempted to tell the engineers that they must finish their tasks within the time allocated by the schedule. If they fall into this temptation, Parkinson’s Law ensures that the program will fall behind schedule. How does this happen? Read more in Parkinson’s Law for Schedules.

6.5 Offshore Development Teams

Offshore development teams were all the rage for many years.  Managers were seduced by the attraction of using high-skill low-cost labor and round-the-clock development to reduce product development costs and speed product development. 

The management fad for offshore development teams has abated somewhat. Management greatly underestimated the challenges of communicating with, let alone managing an offshore development team.  Anticipated cost savings evaporated and some projects collapsed under the effort.

True story:  I worked on a very large development program that employed teams in both the United States and India.  Both teams were highly capable:  either team could probably have completed the project by itself in about half the time that the combined team took.  But the program never mastered the challenges of communication, coordination and management.  When the project was 2 years late, a new manager pulled all of the work being done in Bangalore back to the Salt Lake City office and the project was finally completed a year later.

What did we do wrong?  First, the team designing the system skimped on the work of subsystem allocation, interfaces and test criteria.  This meant that we were not able to assign well-defined tasks to the offshore development teams.  They didn’t know what we wanted and of course had lots of questions.

But the 11 ½ hour time difference between Salt Lake City and Bangalore made it extremely difficult to schedule teleconferences where both sides were awake, let alone alert!  Major issues could not be resolved over the phone, so management ended up sending several engineers to Bangalore for weeks at a time to work things out in person.  This of course was expensive and time consuming. 

However, there was one set of teams that handled things differently – the one I was leading from Salt Lake City. I had personally met my Indian counterpart when he had visited Salt Lake a year earlier and had established a rapport with him.  He was exceptionally intelligent and very kindly.  Early on, we decided that we would be each other’s agents and we would call each other twice a week to keep in touch.  If people on the Bangalore team had questions or issues, they would ask him.  He would deal with everything on his end and would keep me informed about what they decided.  If he needed help from me, he would ask.  And vice versa.  This agent system worked so well that I never got a free trip to India.

In the past, before instant worldwide telecommunication and air travel, this was a common way of doing business.  The seductions of modern communication technology made us think that we could work with offshore development teams as if they were just located in the building across the parking lot.  Not true.  There was wisdom in the older way of doing things.

6.6 Doing Things Out of Order

It seems obvious that this would lead to projects being over schedule and over budget, but it is almost impossible to NOT do things out of order if you haven’t thought through the dependencies among the tasks in your schedule nor have you carefully planned the subsystem integration. 

6.7 Poor Team Culture

Teams that cultivate honesty, trust, respect and teamwork perform better than teams that don’t.