Food for thought
Planning to fail is planning to fail
neil johnson
1/31/2013 9:06 PM EST
Is it getting any better?
It appears not.
When asked if the likelihood of delivering behind schedule has decreased over time, the majority - 61% - of respondents believe there has been no improvement in their team’s ability to deliver hardware on time with respect to original project estimates.
One
obvious explanation for a lack of improvement involves a team’s
appetite for reflection. Only 55% regularly critique their approach to
project planning.
Another possible explanation for that lack of improvement is the disconnect between an individual’s confidence in their approach to project planning and that of their management. An unsettling 74% of respondents perceive that their management sees their approach to project planning gives a high chance of success. With such a disconnect between the confidence of individuals and their management, teams may feel they lack the collective imperative to improve planning practices and instead settle for the status quo.
Early project planning recommendations
From early analysis, we believe teams have opportunities to significantly change their approach to project planning in a way that improves confidence within the team and chance of timely delivery. Given the data and our own experience in hardware development, we recommend the following:
Where do we go from here?
With mixed support for current project planning practices and schedule overruns reported from 87% of recent projects, we feel the survey data support our hypothesis that confidence in hardware project planning is unacceptably low; also that success rates for hardware projects, with respect to initial project scheduling, are dismal. We believe project planning to be an extremely important area of research that can lead to greatly improved planning practices and much higher success rates.
We plan on continuing with our analysis of the full set of survey data in the coming weeks on www.AgileSoC.com (the complete survey includes a list of 36 questions, many of which are not discussed here). In addition, we intend to share the data freely with anyone from the hardware and project management communities interested in participating directly, providing feedback on recommendations and/or doing their own analysis.
If you are interested in obtaining the data from our project planning survey, you can contact us directly at neil.johnson@agilesoc.com or cll@cll-group.com.
Neil
Johnson has been working in ASIC and FPGA development for more than 10
years. He currently holds the position of Principal Consultant at
XtremeEDA Corp, a design services firm specializing in all aspects of
ASIC and FPGA development. Neil is also co-moderator for AgileSoC.com, a
site dedicated to the introduction of Agile development methods to the
world of hardware development.
Catherine Louis, founder of www.cll-group.com, has over 20 years of software development experience in complex product development in large telecommunication firms. Her focus is on Agile methods, Agile R&D, and managing organizational Agile transitions: Enabling change to build speed and flexibility in business. You can reach her at cll@cll-group.com, or via twitter @catherinelouis.
If you found this article to be of interest, visit EDA Designline where you will find the latest and greatest design, technology, product, and news articles with regard to all aspects of Electronic Design Automation (EDA).
Also, you can obtain a highlights update delivered directly to your inbox by signing up for the EDA Designline weekly newsletter – just Click Here to request this newsletter using the Manage Newsletters tab (if you aren't already a member you'll be asked to register, but it's free and painless so don't let that stop you).
It appears not.
When asked if the likelihood of delivering behind schedule has decreased over time, the majority - 61% - of respondents believe there has been no improvement in their team’s ability to deliver hardware on time with respect to original project estimates.
Another possible explanation for that lack of improvement is the disconnect between an individual’s confidence in their approach to project planning and that of their management. An unsettling 74% of respondents perceive that their management sees their approach to project planning gives a high chance of success. With such a disconnect between the confidence of individuals and their management, teams may feel they lack the collective imperative to improve planning practices and instead settle for the status quo.
Early project planning recommendations
From early analysis, we believe teams have opportunities to significantly change their approach to project planning in a way that improves confidence within the team and chance of timely delivery. Given the data and our own experience in hardware development, we recommend the following:
- Measure confidence in project planning in a way that is transparent between all levels within an organization to expose misconceptions between individuals and their managers.
- In our opinion, having 55% of teams regularly critique their approach to project planning is far too low. We recommend teams critique their approach to project planning regularly using supporting data where possible.
- We recommend teams avoid standardizing planning practices until they demonstrate successful project planning. While standardization seems like an opportunity to increase productivity, it may unintentionally result in the enforcement of practices that are fundamentally ineffective.
Where do we go from here?
With mixed support for current project planning practices and schedule overruns reported from 87% of recent projects, we feel the survey data support our hypothesis that confidence in hardware project planning is unacceptably low; also that success rates for hardware projects, with respect to initial project scheduling, are dismal. We believe project planning to be an extremely important area of research that can lead to greatly improved planning practices and much higher success rates.
We plan on continuing with our analysis of the full set of survey data in the coming weeks on www.AgileSoC.com (the complete survey includes a list of 36 questions, many of which are not discussed here). In addition, we intend to share the data freely with anyone from the hardware and project management communities interested in participating directly, providing feedback on recommendations and/or doing their own analysis.
If you are interested in obtaining the data from our project planning survey, you can contact us directly at neil.johnson@agilesoc.com or cll@cll-group.com.
Neil
Johnson has been working in ASIC and FPGA development for more than 10
years. He currently holds the position of Principal Consultant at
XtremeEDA Corp, a design services firm specializing in all aspects of
ASIC and FPGA development. Neil is also co-moderator for AgileSoC.com, a
site dedicated to the introduction of Agile development methods to the
world of hardware development.Catherine Louis, founder of www.cll-group.com, has over 20 years of software development experience in complex product development in large telecommunication firms. Her focus is on Agile methods, Agile R&D, and managing organizational Agile transitions: Enabling change to build speed and flexibility in business. You can reach her at cll@cll-group.com, or via twitter @catherinelouis.If you found this article to be of interest, visit EDA Designline where you will find the latest and greatest design, technology, product, and news articles with regard to all aspects of Electronic Design Automation (EDA).
Also, you can obtain a highlights update delivered directly to your inbox by signing up for the EDA Designline weekly newsletter – just Click Here to request this newsletter using the Manage Newsletters tab (if you aren't already a member you'll be asked to register, but it's free and painless so don't let that stop you).
|
|
|
|
|
Navigate to related information
Sparky_Watt
2/1/2013 7:09 PM EST
This is fundamentally flawed. The flaw is that I have seen very few companies that PLAN a project. They put together "project plans" but they haven't planned the project. They just take a wing at what they think they can do and call that a plan. Often the plan includes make-or-break constraints that are put there by someone that has no clue (we have to have this in six months, or our effort is wasted, failure is not an option). Let's face it. Planning is hard work and largely unproductive. What it really does for us is set expectations and allows us to prepare. And it allows us to choose intelligently. But, it can't be done in a half hour by a group sitting around a table. You need to research the requirements, estimate the needs and the uncertainties. It can then be assembled by that group, but it almost always is unacceptably long and expensive, so it gets arbitrarily cut. Then it isn't a plan anymore, it is a wish.
Sign in to Reply
nosnhojn
2/4/2013 12:41 PM EST
thanks sparky_watt. we contend hardware planning approaches are broken and I think your opinion that very few companies plan supports that idea. planning to fail, failing to plan, they both end up at the same place.
thanks for reading!
-neil
Sign in to Reply
WKetel
2/2/2013 10:33 PM EST
One additional fact is that having a really good plan does not by any means assure that the project itself is a one that will succeed. I have seen very good plans that carried out very dumb ideas very well. So even if it is possible to cover all of the individual things that must be done for a project, none of that effort makes the original idea a good idea that will certainly succeed.
Sign in to Reply
nosnhojn
2/4/2013 12:52 PM EST
WKetel, I agree with you. Our focus was strictly success wrt initial project plan (ie. planning/execution) to measure effectiveness of planning approaches. Obviously that's just 1 component of success that should include product quality, etc.
-neil
Sign in to Reply
dick_freebird
2/4/2013 1:14 PM EST
If you want to survive as a practicing engineer you had best get good at recovering gracefully because there will be first-pass failures, especially if you're the first to try (and where else would you want to be?). Planning-in the most sensible and cost effective mitigations (spares on chip, late-levels reworkability, backup lots and so on for the semiconductor types) will make some managers whine about cost (ditto telling them you need twice as much verification time and the tools to do it) but it's on you, so act accordingly.
"No battle plan survives contact with the enemy"
But you had better learn how to pack.
Sign in to Reply
philipoakley
2/4/2013 4:59 PM EST
Making predictions is hard, especially about the future. Such is the problem of planning development (i.e. new designs).
It is much easier to plan how long it will take to do 'the same thing' again.
The hard bit is identifying which parts are 'the same thing' and which parts are 'new and unknown'.
Even then, you still need to know how long it took / what it cost last time, which usually isn't available anyway as such data is fudged, hidden, held by others who aren't telling, etc.
The end result is to make a guess, double it, and then double again, so the programme manager can halve it, which then allows for when your optimism (guess) meets reality!
Sign in to Reply
Work to Ride comma Ride to Work
2/7/2013 2:40 PM EST
Usually the problem is that when engineering provides the Basis of Estimates (BOE's), the reality of what it takes to successfully complete the jobs clashes with the program management's Price to Win (PTW). Guess which always wins ??? Then of course later, engineering gets a black eye for being behind schedule and over budget. There is so much fodder for Dilbert cartoons we can't even begin to list it.
Sign in to Reply
LiketoBike
3/7/2013 1:35 PM EST
This has been my experience. Especially when doing something new, management is NEVER satisfied with a REALISTIC schedule. That's always too long. Well, one can squish the lines around on a Gantt chart all one wants, force-fitting a project into an arbitrary timespan...but things still take as long as they take. Working 20 hour days is NOT sustainable. Hire more people, accept less features, or spend more money (this sounds like, "Good, cheap, fast - pick two" :-) )
Sign in to Reply