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 browser-based reporting and 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 might still have been 1 week late. It is not a planning issue, but an execution issue. It is pointless trying to plan out what appears an ‘inherent’ lateness. It is something to be managed.
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 stretch target 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 contingency approach would have said 1 week in fact 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 output quality. There is no shame in being a week late on an overly ambitious deadline. There is only shame in setting a cautiously long deadline (and then still be late!).
In wanting to get to the bottom of the phenomena and to resolve our plan execution 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, all of the design teams within the global group showed a similar pattern of deviation – it was not just a local issue for us.
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 design 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.
- Optimistic people can naturally tend to be over-ambitious about what is achievable within the given resources and time, and we try not to destroy the drive that comes with optimism. Instead, we go along with the ambition – even when we know it will be tight.
Design process efficiency
The measure for efficiency is what we get when dividing the value-creation by the time + 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 output 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.
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 + 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.
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, but keep the team grounded to avoid creating an unsustainably high momentum (bottom ball trajectory example). 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, design process management is about creating some initial good momentum – and then maintaining it. As illustrated by the bottom path in the kinematic physics analogy, I believe it is conceivable that pushing the design and development team too hard at the beginning of a project risks peaking the energy levels too early and/or encouraging the inclusion of more non-essential features to be detailed. This would result in the process efficiency gradient plateauing earlier and then 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.