“So, when will you be done with your design?”
Not exactly the question a typical design engineer is looking forward to. You’re at the start of a new project and it is time to commit to a development schedule. Now what? Your first instinct is to be vague. Use verbs like “should” and “hope” and lots of conditional statements. But you know that’s not going to fly. You can give your best estimate. But you’re usually too optimistic and then you will get yelled at when you don’t meet that commitment.
Or you can pad the heck out of it. At least that way you know you will not be bothered for many weeks. But now your manager and your peers may start to see you as a sandbagger whose input is not to be taken seriously. So what is the best way to come up with a schedule for the design phase of your project?
At Touchstone Semiconductor, we’re having some success with a simplified version of the approach described in the book “Critical Chain” by Eliyahu Goldratt. What Goldratt describes is especially applicable to large complex development schedules with lots of interdependencies. Our design teams are small, usually just one to three engineers, and that helps to simplify the planning. These are very driven, very motivated and highly qualified professionals with many years of experience, but even then, it proves quite difficult to come up with a realistic schedule of the design tasks.
A schedule that is too much padded just invites inefficiency and typically, the allotted time will be used up anyway. Over-aggressive schedules will always be missed, and because of that, they lose their significance, and even demotivate the team. The critical-chain method attempts to avoid both those pitfalls.
The concept starts with estimating the time needed for completing each sub-task. These should be reasonable estimates that have a 50%-60% chance of being realized. Then, for each of the sub-tasks, estimate safety or buffer needed to almost certainly meet the schedule. That buffer is not added to each of the sub-tasks, but instead, all individual buffers are added together to form a project buffer.
The goal is then to keep this project buffer intact as long as possible, which means focusing on the tasks that still need to be completed, rather than at the ones that are completed already. This keeps the urgency on the need to meet the project milestones, while allowing for setbacks that inevitably will occur, not on all, but on some of the sub-tasks.
What does project scheduling methods are used at your workplace and are they effective?
Welcome your comments,