Why are we always late?

design process efficiency

Years back I managed a smaller engineering product design team, which was 1 of 4 global teams totalling some 260 development engineers. Our team was assigned a variety of jobs, ranging from complete products to minor sub-components design. The global master projects office maintained a simple visual progress tracking system, called pilot charts. Our projects usually progressed well, initially, but invariably tended to fall behind in the later stages of the allocated time plan. I regularly had to make uncomfortable reports to the global group’s master planner.

One project was a minor redesign task, allocated 1 design engineer for 2 weeks. It should have been easy to manage the time plan. When I in week 2 had to concede that we would suddenly be 1 week late, the global master planner suggested that we should have allocated 3 weeks – because this would have protected both of us from the ear-full of criticism from our higher masters.

I couldn’t agree. My experience said that if we had allocated 3 weeks, or even 10 weeks, then we would likely still have been 1 week late. It is not a planning issue, but an implementation issue. It is pointless trying to plan out what appears an ‘inherent’ implementation lateness.

Parkinson’s Law: Work expands to fill the available time

Cyril Northcote Parkinson, 1955

We know that tougher time constraints improve productivity, without necessarily affecting quality – when done within reason. To optimise our engineering productivity, we must recognise the ‘inherent’ lateness – although without showing it as a tolerated norm. One way of assuring the 2 week implementation could have been to allocate just 1 week locally and for the global master plan containing an extra hidden ‘contingency’ week. However, not telling the design engineers about such a covert approach would have been unreasonably manipulative. On the other hand, overtly telling them about the approach would have said 1 week means 2 weeks, which again would result in 3 weeks. In the end I concluded it was preferable to stick to our original time planning approach and take a weekly ear-bashing for being late – rather than extending our plans and then still get an ear-full for lateness. For me, it was about protecting team productivity and quality.

Still wanting to get to the bottom of the phenomena and to resolve our implementation issue, I called together the team to review our recent pilot charts. We always seemed to do comfortably well in the first half of projects and then suddenly appeared to deviate. According to the master project planner, most the design teams within the global group showed a similar pattern of deviation – it was not just a local issue for us.

Why are we always late?
Pilot chart for tracking progress

We found that we had routinely under-reported our early progress and had in fact tended to initially be ahead our plans. Our activities never followed the linear pilot chart, but had followed a curve. The curve suggests an initial high productivity, which then appears to gradually decline over the project period. The causes for the gradual decline in output are several-fold:

  • The earlier concept phase naturally produces quicker, bigger value creation steps than the nitty-gritty detailed design phase. The initial rate of progress can give us a false belief that we are ahead of ourselves and have plenty of time in hand to complete the planned works. Parkinson’s Law then makes us add unnecessary details, which bogs us down later on in the project.
  • The design engineering team will always have old product maintenance jobs waiting in the background, which must be fitted in between new product design activities. The background maintenance jobs can usually wait for a while. There sometimes comes a time when the priority of the maintenance job can no longer wait and it eventually has to take priority and divert engineering resources. Such a diversion is more likely to be happen in the latter stages of new product design projects. In our example where a 2-week projected stretched to 3 weeks, it was not that we had spent 1 week doing nothing. We had more-or-less completed the project within 2 weeks, but over a 3-week period during which other ‘hidden’ jobs were also performed.
  • The excitement and enthusiasm energy that we gain at the beginning of a new project invariably declines over time. This makes us more easily distracted in the latter phases of the project, by other things that also needs doing – such as design documentation and timesheets administration that we forgot all about in our initial excitement.

Design process efficiency

The measure for efficiency is what we get when dividing the value creation by the time and cost of our product development efforts. When managing a project, we should continually understand and plan according to the prospect for process efficiency – and not to a linear assumption.

The design project will have a minimum value creation target, and a maximum allowable time and cost. The graph below indicate that a project may also have a maximum for its value creation. This refers to cases where a product must fit with other products within a wider value range. For example, if our task is to design a mid-price range car model, then the final product must represent more value than the economy range car model, or else it will not sell; but it must not have so much value that it starts ‘cannibalising’ sales from the premium range car models. The final design value in such case, therefore, must fit within a minimum and maximum target range.

Why are we always late?
Design process efficiency gradient

The graph here illustrates a straight target gradient line that starts at the graph origin, and ends at the point where the minimum value meets the maximum allowed time and cost. We should recognise that it generally proves easier to maintain a sense of value creation earlier on in a project, while the development team is more highly motivated by the novelty, and where we have not yet reached the detailing stage. A project team must be careful not to become complacent, due to its early perceived successes. We will get into trouble if we comfort ourselves with following the straight target line from the outset.

There comes a point towards the end of a project, where the ‘law of diminishing returns’ will set in, and the natural process efficiency gradient levels out. Our graph here illustrates the process efficiency through some example design phases. Project phases P1 and P2 progress as can be expected of a typical development. Phase P3 achieved only a relatively small value creation step, but its time and cost investment was proportionally even smaller, so P3 was well justified. Now the project team is faced with a decision to embark on the proposed P4 plan, which does not look good. Proceeding to P4, as the plan in the illustration stands, will result in the project remaining on the good side of the net target gradient; but when looking at the trend, in respect of the flattening efficiency gradient, it should warn us that the future phase P5 or P6 will probably fail in reaching the final target point. The project team, in this case, must go back to the plan, to find more ambitious options for increasing the value creation potential of phase P4 – by either being clever, knuckling down or shedding some of the unnecessary additions that Parkinson’s Law may have made us introduce earlier on when we thought time was plentiful. The QFD approach can help prioritise what is most important in this respect.

The principle for finding the most efficient project intensity curve has an analogy to the Brachistochrone curve in physics, demonstrated by the classic ball trajectory experiment.

Why are we always late?
The straight line is not necessarily the fastest

When planning the design and development activities, then we should take advantage of and liberate the naturally higher starting energy. Make the project plan initially ambitious. The later stages in the project becomes about stimulating and sustaining interest from the team, to avoid that the inevitable decline in efficiency doesn’t become too steep. When the organisation is large enough, then we could try to switch out team members – allowing some of those most competent in concepts development moving on to the next project, while taking in colleagues who are more competent with – and therefore find more joy in – detailing the design.

So, we have to create some initial momentum – and then maintaining it. As illustrated by the bottom path in kinematic physics analogy, I believe it is conceivable that pushing the design and development team too hard in the beginning of a project risks peaking the energy levels too early and/or creating more non-essential features to be detailed. This would result in the process efficiency gradient plateauing earlier and lower the overall efficiency for the total project. I guess there is some science to be done in evidencing this thinking and in defining a measure/indicator for optimum intensity across the span of a project.