Management thrives on data -- it makes decision-making so much easier, because it takes some of the risk out of the equation. Hard facts and data are therefore a powerful tool for persuading management that a project's schedule is wholly unrealistic. The data must unequivocally show that even if the team acheived best-in-class productivity, the schedule is still not achievable because the staffing allocated to the project is not communsurate with the design's complexity and the schedule constraint.
When presented with this, management has little choice but to reduce the scope of the project, relax the schedule constraint, add more resources and/or reblance the project portfolio (i.e. reduce the number of projects).
Thanks for the comment.
An interesting article, I have worked in the semi industry for more than 15 years and never found a schedule realistic. Too often the designers presented a real schedule to the management and it was tweaked to meet some arbitrary set of deadlines. This is oftentimes the real cause of "schedule slip" it is non-realistic schedules being adopted as real. Specs do change, resources do disappear, software has issues these are not unexpected and should be accounted for but as I stated the real schedule does not meet the management's target dates. Until that is addressed, development will always be "late".
Well stated -- it is all about company culture. Politics and project planning often go hand-in-hand, because the project planning phase is when funding decisions are made. It is almost axiomatic that money begets politics. In my experience, the most effective and efficient way to cut through politics is with facts/data, which incidentally has a tremendously positive impact on culture. Once established, a fact/data-driven culture can persist for a long time, which is a key ingredient for sustaining competitive advantage.
Thanks for the comment.
It is definitely obvious -- but remarkably, a great many semiconductor organizations don't understand it. As for an advertisement, you are again correct -- it is an advertisement to think differently about schedule predictability.
Great article. CPM schedules are inherently challenging as the forecasting tool of choice for development type projects. Due to the high degree of uncertainty and iterative work/re-work, traditional CPM Gantt chart type forecasting rarely gives an accurate picture - hence the frequent perception that the project finished late - i would suggest that instead, we simply didn't plan accurately enough. Worse, given projects teams are aware of this shortcoming, the original 'plan on the wall' simply becomes a static picture that doesn't reflect the latest updates, changes and impacts due to risk. An alternate approach is to create a risk-adjusted schedule using a combination of a CPM schedule (e.g. MS Project) combined with a project's risk register and model the impact of the latter on the former using Monte Carlo analysis. Not only does this approach give more realistic forecasts, it is also a means of getting team buy-in into the agreed upon plan. I agree with the author that these projects are indeed predictable; we simply need to do a better job of including the non-deterministic work/outcomes in the original plan/schedule. More thoughts on this at http://goo.gl/KQTuz
Blog Doing Math in FPGAs Tom Burke 24 comments For a recent project, I explored doing "real" (that is, non-integer) math on a Spartan 3 FPGA. FPGAs, by their nature, do integer math. That is, there's no floating-point ...