With the perspicuity that more than a decade of watching other people manage projects brings, I can say with strong certainty that most project managers are not very good schedulers, at least not skillful enough to produce the network integrity necessary for a detailed resource-loaded schedule to produce highly reliable predictive work load data. Note that I exclude big projects with dedicated resources, schedulers, and planners. With a team of specialists at hand, supporting your scheduling efforts, you can get great data; but achieving this level of precision is out of reach for the mainstream project manager working in a typical IT department. Not only is it an unrealistic expectation, it is an unnecessary burden.
Even when project schedules start out all shiny, bright people seem to mangle them during tracking. Open up the average schedule and you find planned work in the past, actual work in the future, circular relationships, and the list goes on. And, what about those project schedules that go for weeks without updates? Does that happen where you work? All software systems that accept human-entered data, whether from timesheets or an email program, are the constant recipients of bad data. People make mistakes.
The resource usage represented in project schedules does not align with the resource manager’s plans. Of course it doesn’t and often it should not align. During the planning phase, a good project schedule shows the optimal path through the project without constraining resources. Common sense dictates that an optimized schedule is not a realistic model for basing demand. The plans that resource managers maintain are the most relevant choice for this, yet very much excluded from consideration in typical project execution practices and as reflected by the lack of resource manager tools in many project management applications.
For portfolio management purposes, managers should work resource-loading models from high-level resource plans rather than from detailed tasks. Substantial projects should have multiple models, or at least the portfolio modeling approach should support multiple resource plan versions. Focus the project schedule effort on maintaining accurate, near-term demand, such as the next 30, 60, 90 days to avoid acute bottlenecks. Overall, organizations must start to look at resource demand from more than one perspective adopting a more prismatic view.
Agree? Disagree? What are your thoughts?
-------
Gary Chefetz is founder and Chief Executive Officer of MSProjectExperts. For more than a decade, Gary has won the Microsoft Project MVP ward, recognized by Redmond for his expertise and willingness to share his expertise through the Microsoft Communities and through the numerous books he authors, edits, and publishes covering Microsoft Project and Project Server.
Well Gary, thanks for the thinking. You bring up some great points that are a fact of life but I disagree with your conclusion.
ReplyDeleteYes, schedules get mangled, PMs are under trained and there are many examples of messes out there. But throwing away the baby with the bath water has never been a good solution.
If resources are the gasoline that powers the engines of enterprise, would you put duct tape on your gas gauge so that you ignore the warning signs of an empty tank? Cough cough, sputter sputter.
If you’re flying a plane, do you care about the pounds of fuel on board? Flameout in engine 2?
Project does something interesting when resources are connected to tasks, and it is that connection where the pain and power come together. Separating resources from schedules is like managing your finances on an excel spreadsheet. It’s all well and good until you look in the bank account and find nothing there.
I think a better solution is to provide folks with a framework for diagnosing and correcting resource allocation issues, without requiring the manual reconciliation which (by the way) rarely gets done.
Paired with a well configured Project Server to aggregate demand and calculate capacity, and some guidelines for resource modeling (30 people on a task? No. Assignment Units at 420,000%? No… there are plenty others out there) a resource loaded Project schedule can actually provide insight which is incredibly valuable.
Yes, it’s very helpful to provide some artful reporting that exposes issues (heatmaps, thresholds and report cards) and what you are actually doing is developing a feedback loop that changes behavior.
Teams will respond to quantitative issues more quickly when they are visible.
It seems to me that there is a difference between the optimistic schedule that doesn’t take into account the resources, and a realistic one that does the hard work of modeling who’s doing what.
Which one is more likely to succeed? It largely depends on the skill of the PM, yes. But arm one with good resource information and they have an advantage.
Always looking forward to talking more about this with you.
Mark, a very thoughtful reply and I do not diagree with one point, but I do believe you missed my point completely, which simply states that resource loaded schedules are not sufficient to provide a *single source* for measuring demand across a shared resource pool. I am suggesting that we need both coupled and decoupled models to make any sense of resource demand.
Delete