Guessing is not a strategy: How to build decision velocity with AI and real-time data
June 10, 2026 | Live Webinar
Viewing Posts by Michael Hatfield
A PMBOK® Guide for the Trenches, Part 2: Schedule
| Last time in my post, PMBOK® Guide for the Trenches, I discussed scope. Now, I'd like to cover some basic truths about schedules that project managers need to know, but won't find in A Guide to the Project Management Body of Knowledge (PMBOK® Guide). One vital truth that the PMBOK© Guide is clear on is that scheduling is only one aspect of effective project management, along with scope, cost, risk, communication, procurement, human resources, quality and integration. But you won't hear that from professional schedulers--no, no, no. It's often believed that the central tenet of project management is the ability to resource-load a schedule baseline into one of the more robust software packages that perform critical path analysis. This is part elitism and part what I refer to as "black box syndrome." Project team members are led to believe that if a certain software package is fed all the data it needs, then the push of a button will deliver all the management information needed to successfully complete a project. This, of course, is hokum, but I've seen it in many a project management office. On the other side of the coin, it's a fundamental truth that you cannot manage a schedule with a list of milestones or action items, no matter how elaborate that list may be. What tends to happen with action item lists or databases is that they essentially turn into, , polls and polls are not legitimate management-information systems. With a poll, there's always someone who has more recent information or more complete information than what's in "the system," rendering the data there unactionable. Note that I said the data in the system. There's a profound difference between data and information. Legitimate management-information systems process data into information using some kind of methodology. For schedules, this method is critical path. And it's a safe conclusion that there is no legitimate schedule management without critical path. For serious project work, a critical path network is absolutely essential. This no doubt contributes to the phenomenon of schedulers thinking critical path management is all that is essential in project management, with the other stuff kind of ancillary. I'm looking forward to everyone's comments. |
A PMBOK® Guide for the Trenches
| When you are introduced into a project environment, with a team who has never used project management and knows little of it, what is going to help most? Is A Guide to the Project Management Body of Knowledge (PMBOK® Guide) too airy and sophisticated? Put another way, if you find yourself in a World War I-era trench, which would you rather have: the operator's manual on your howitzer or The Art of War by Sun Tzu? Over my next few posts, I want to introduce my own version of the PMBOK® Guide, unencumbered by peer review (or even consistency). It will give me a chance to cut through some of the academic cobwebs that may have set into our practices, and illuminate recent issues and problems. We'll start with scope. Scope: (noun) the output or outcome for which your customer is willing to pay. You've probably already recognized that, by this definition, the customer can't request anything out of scope, since what they desire is, by definition, in scope. And you would be correct. So, if you don't want to find yourself in a situation where your (paying) customer is asking for more than you were originally willing to produce for a certain price, you had better have a very detailed agreement--otherwise, that most deadly of project ruination elements, scope creep, will devastate you, your team, your organization and your project. Here's further proof that my definition for scope is correct: If your customer wants to add work to your project and will to pay for it, what project manager would refuse to do it on the grounds that it wasn't in the original statement of work? No matter how absurdly the original work breakdown structure (WBS) was set up, if a person with sufficient organizational clout generated it, it can never be substantially changed. In fact, the very act of pointing out that a proposed WBS element is inappropriate is a serious career-limiting move, since everyone knows that the ability to create a valid WBS is the litmus test for real project managers and pretenders. I've found that the pretenders will attack any challenge with a ferocity rooted in their insecurity. Yes, it all begins with scope, but it obviously doesn't end there. Next up: schedule. |
Flawed Reasons for Avoiding Project Management, Part 2
| In my previous post I addressed two common, but profoundly flawed, reasons team members offer up to avoid implementing the systems to sustain project management capability. Here are reasons three through one: Objection 3: "If the cost and schedule performance reports indicate a negative variance, upper management will go on the attack, even if the reports are wrong." I'm sure this happens. What makes this objection so astonishing disingenuous, though, is that it's obviously an indictment against upper management, not the information system itself. Once a project has been baselined, the primary value of the work breakdown structure (WBS) is that it enables variance to be traced to their root causes. This analysis, known as "drilling down" through the WBS, quickly reveals if the variance is indicative of a genuine problem or simply a data anomaly. It it's a real problem, then is it not appropriate for management to get involved? And, if you're getting beat up over non-problems, then the cost/schedule system is still doing you a favor: It's telling you that you need to get another boss. Objection 2: "If the cost and schedule performance reports indicate a positive variance, upper management will want budget/money back." In addition to the problems with this objection addressed in No. 3, this push-back tactic is often indicative of a padded baseline. When creating the budget, some control account managers will inflate line items as a hedge against project risk. If all goes as planned for, say, the first half of the project, any earned value system worthy of the name will identify padded baselines and the extent to which they are overstated. The correct approach, of course, is to produce as honest a cost baseline as possible and then perform a risk analysis for identifying an appropriate contingency fund. But for those who don't want to go through the trouble of doing it right, the cost/schedule performance system represents quite the check against this particular cheat. Objection 1: "We don't need earned value or critical path to provide us with cost or schedule information because we're using (fill in the name of another system here)." As I discuss in my book, Things Your PMO Is Doing Wrong [PMI, 2008], one of the most effective but non-legitimate tactics is to employ rival systems. The quick reason behind this is that there is no project cost control without earned value, and it's next to impossible to control a schedule without critical pat, and anyone who asserts to the contrary is either insufficiently skills or attempting to deceive. Most of the time, it's not lack of skills in play. Feel free to offer your comments, and have a fantastic New Year! |
Flawed Reasons for Avoiding Project Management
| Implementing the information systems needed to sustain a project management capability will often meet with resistance from within the organization. And much of this resistance can be rather fierce. For now, I want to discuss the most commonly used objections I've heard over 20 years of work. These actually come from those opposed to doing project management, and my intention is to assess whether or not there arguments are reasonable. I'll concentrate on two in this post and then pick up the other three in my next. Objection #5: "Project management systems, like earned value (EV) or critical path, don't apply to this kind of work." These arguments occasionally have merit, especially in organizations that have experienced attempts to impose project management information systems on non-project work. However, if the work has three or more of the following characteristics, then you do have a project: -If has discernible beginning and end dates -It has a service or product that is delivered -Resources are dedicated to it -One person or organizational element is responsible for the work's completion There is no doubt that some unconventional project work will need adaptations from classic EV and critical path management systems. But to assert that project management has no place in managing the work is an excuse and should be left to personnel who are not involved in management decisions. Objection #4: "EV and critical path are too difficult and expensive to implement." Again there's enough credibility in this argument to provide a fig leaf of cover to project management antagonists. But a closer look utterly destroys the assertion. There are two aspects to project management information systems: They provide a valuable information stream on cost and schedule performance and they provide an audit trail for the customer in the event the project goes badly. It's this second aspect that makes these systems labyrinthine. The performance information stream, when simplified, is actually very easy and cheap to install. But as is so often the cases, when "experts" get together to document the "proper" way these systems should be implemented, the requirements quickly get out of hand. The audit trail aspects of EV and critical path can be overemphasized to the point that their ability to provide needed management information is eclipsed. However, I must emphasize that simple EV and CPM systems, when freed of their audit trail baggage, are cheap and easy to install--and even the simple systems can provide very powerful management information. |
Taking on Project Management Myths, Part 5
Categories:
Agile
Categories: Agile
| It's finally time to expose the biggest myth as I close out my taking-on-the-myths series, hopefully generating plenty of lively responses. Myth 2: Comparing your project's budget to actual costs is a natural way of assessing cost performance. Truth: Comparing budgets to actuals is not only useless, it's misleading. To back up this little piece of iconoclasm, I will invoke the widget example I use when teaching the subject of cost performance measurement. Imagine you are a project management assigned to a project to make 2,000 widgets in two months with a budget of US$2,000. You time-phase your budget US$1,000 in month one and US$1,000 in month two. At the end of the month one your accountant tell you that you've spent US$1,100. How are you doing? If you said "poorly" based on the fact that you have spent US$100 more than you budget, go to the back of the class. If you said, "It depends on how many widgets you've made," go to the front of the class. Because if you've made 1,300 widgets, and each widget is worth US$1, then the proper comparison is obviously the US$1,300 in earned value against the US$1,100 it took to make them. A very simple example, I grant you, but it starkly supports my assertion. The Biggest (in my opinion) Myth: Agile and scrum are novel improvements to traditional project management, tailored for the software industry. Truth: Agile and scrum were developed to allow IT projects to indulge in all the scope creep they wanted. My take is that the most lethal practice to project health is to allow informal changes to the technical baseline without changing the cost of schedule baselines--a practice commonly known as scope creep. The IT industry is particularly susceptible to this, since changing the size of a building or the speed of a ship is hard to miss and affect. But changing the look, feel and capability of a software package may require little more than adding a few lines of code--and how hard that can be. What started happening within the IT industry, on a common and costly basis, was that seemingly small changes in the various code modules created a configuration management nightmare. So, we see the introduction of tactics that "max out" project team communications, including co-location and employee roles that define the nature of their interactions with their colleagues, customers, and the technical agenda. But I have to ask: If the technical baseline was thoroughly and clearly defined at the project's start, and only changed formally, would any of this really be necessary. So what do you think? Myth or reality? Editor's note: PMI members who are interested in agile should check out PMI's new Agile Community of Practice. |