We’ve had our first brave sole step up and offer his opinion based on data from our project planning survey! Our guest contributor is Gaurav Jalan, a design verification engineer with services firm SmartPlay in Bangalore. Gaurav, who runs his own blog focused on hardware verification, offers his opinion on variance in project plans.
Take it away Gaurav!
Executives busy in frequent meetings, program management is collecting information required to put together a high level plan of action, rumours of the next project kick off is doing the rounds, the grapevine is delivering gossip guided by real time updates and the engineers are preparing their wish list of the takeaways from the project or thinking of the schedule vs. their vacation plans. This kind of scene is common in the electronics design industry when a new project is about to commence. Next to this is initial project planning where the program managers, technical leads and gurus sit down to prepare the plan of action. Inputs from the developers are sought on need basis and finally the plan goes for approval after which the project formally takes off. During the execution, the plan continues to change real time for multiple reasons untill the final design is realized and delivered. The variance from the initial project plan to the final one when the product is out plays a vital role in deciding the market potential.
Catherine & Neil recently conducted a survey on the project planning with respondents from embedded software development, System integration & silicon development. The respondents were primarily the program managers, technical leads, architects and developers and a handful of executives. The outcome on the variance shows that the plan was off by around 25% to 50% in every 2 of 3 projects and 1 out of 5 projects suffered > 50% variance.
Typically program managers keep a buffer of 10% while preparing a project plan to ensure there is room for unforeseen risk mitigation. Still if the variance is >25% on top of that, it is substantial. Imagine if the project schedule is for a year, a 25% variance would mean the product is off by a quarter. Given the shrinking market window of the electronic products, getting it right the first time and on time is critical. With most of the product launches using an industry platform e.g. CES or own forums (apple), the dates are pre-decided and the schedule for development is worked backwards. If schedule misses, it not only affects the delay of that product but even the goodwill. While the survey didn’t include the reasoning on delays, there are some interesting points that come out. For ease of analysis the data is clubbed into 2 categories i.e. Agree/Disagree from the questionnaire.
75% of the respondents felt that the initial project plan did not accurately identify the amount of work required to be carried out during project execution, 67% voted that the initial project plan did not estimate the time for the projects accurately and 55% shared that the risks and impediments were not identified accurately.
When zoomed in onto individual tasks, the respondents shared that 86% of them were involved in creating the initial plan and 66% felt that the plan captured their project responsibilities accurately. However 71% shared that the plan didn’t capture the time required to complete the task accurately.
A disconnect comes out clearly. The plan either didn’t list out all the tasks to be carried out in and if it did, the total time required to complete the tasks as expected by the contributor wasn’t estimated correctly. Typical reasons why this variance enters the plan could be:
- A task that is a new addition to the project, affects the variance significantly.
- Constantly changing specifications resulting in rework not captured in the project plan.
- People contributing to the plan unable to converge on the total time required to complete the task.
- People contributing to the plan fail to voice their concern upfront.
- Management pushing for aggressive schedule keeping undisclosed buffer time.
- Dependencies (internal & external) not captured correctly or completely.
- Trying too much of parallelism in task allocation without considering Amdahl’s law.
- Quantum of unforeseen issues encountered during execution more than anticipated.
- Project plan reviews happen less frequently giving no room for real time risk mitigation.
- Plan never considered the holidays or vacations already planned by the team members.
- Not mechanism to learn from execution on previous programs.
There could be many more reasons of why the project plans fail to deliver on schedule and even though everyone in the team tries to pull hard for the last mile by spending weekends and late nights at work, the variance wins. Food for thought!
Thanks Gaurav for taking up the challenge!
Now it’s your turn. If you want to help steer discussion with your own analysis, contact me at firstname.lastname@example.org. We’ll supply you with raw data from our project planning survey from which you can draw and post your own conclusions regarding the planning habits of hardware engineers!