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
Our Biggest Unused Weapon
Categories:
Risk Management
Categories: Risk Management
| The primary capital ship of most blue-water navies is the aircraft carrier. According to Rob Stern, in U.S. Battleships in Action, Part 2 a pair of aircraft carriers can deliver around 35 tons to a target in one hour. A United States Iowa-class battleship can do the same job in 90 seconds. The U.S. Navy has four of these battleships, but, fortunately for enemies of the United States, only one is in the reserve fleet, while the others have been converted to museums. Why is such a clearly effective weapon not in use? It may be because of the relative ease with which aircraft carriers sank battleships during World War II, leading to the conclusion that the carriers were superior naval vessels in all respects. In the epic struggle to advance project management capability within our organizations, I think it's important to recognize that we are in competition with other management approaches and information streams. And in this competition, we may be failing to use the most powerful weapon in our arsenal: the capability of an Earned Value Management System (EVMS) to predict the future. Accurate prediction of the future is obviously a very useful capability. In the project management world, the key pieces of future information include: How much will this project end up costing, and how long will it take? These twin brass rings of project management information are hotly pursued in a variety of ways--most of them incorrectly, in my opinion. The most common approach is to re-estimate the remaining costs and duration of an on-going project, and to then add that amount to cumulative costs or duration. This method, despite being notoriously inaccurate and injecting hundreds (if not thousands) of purely subjective data elements into the mix, is often defended as the only appropriate approach. Conversely, the best approach--calculating the estimate at completion (EAC)--is commonly derided by so-called project managers, even though it's faster, easier and demonstrably more accurate than its re-baselining counterparts. The most familiar EAC formula, the Budget at Completion (BAC) divided by the Cost Performance Index (CPI), can be algebraically reduced to dividing the cumulative actual costs by the project's percent complete. This formula works with durations as well: Divide the cumulative duration by the percent complete, and you have an accurate idea of how long a given task will take. With such an easy, simple and powerful weapon in our arsenal, why aren't we using it more? |
The Acronym Mill
Categories:
Leadership
Categories: Leadership
| Are you failing to rake in the respect, admiration and monetary recompense that are consistent with your advanced level of project management expertise? If so, you need your own business or management model, complete with its own slick-sounding acronym, in order to truly set you apart and make you stand out in a crowd of (otherwise) management equals. This is easier than it looks. For example, someone can, say, set up a traditional Responsibility/Accountability Matrix (RAM), deconstruct them into detailed instructions with lot's of fuzzy terms like "strategic," "engage" and "implement", slap an acronym on it--like RACI (Responsible, Accountable, Consulted, Informed)--and voila! They've developed their very own management model. I love reading the synopses in the management course catalogues I get in the mail (yeah, I know, I need to get out more). You can almost track the entire debate among the Agile management practitioners, the Scrum advocates and the more traditional Waterfall Model believers just by reading what the instructors or paper presenters believe they are bringing to the table. I know: I'm inviting a truckload of comments questioning my intelligence. But Agile management strikes me as little more than the practice of loosening up baseline change control parameters to the point of almost begging scope creep to hit your software project in a bid to acquire the kind of managerial latitude needed to deliver software faster. Throw in some trendy tactics, like re-arranging the desks in the office and bring along the ever-present admonition to achieve better communications (especially with stakeholders), and then you can profoundly influence the conversation on management theory around the globe. I first became aware of the practice of deconstructing already-existing management practices and trotting them back onstage re-packaged during the 1980s, when "Activity Based Costing" was suddenly a hot topic. For you gen-exers out there, Activity-Based Costing (note how easily the acronym falls off the tongue: ABC) was the idea that a project's basis of estimate should be created at the lowest level of the Work Breakdown Structure, or activity level, and "rolled up" to total project cost. Problem was, this was the way that valid estimates had been created since the dawn of project management. Besides, what's the alternative? Estimating based on the availability of the organization's resources? For manufacturing, process or asset management, that might be a workable approach, but it was never so in the realm of project manager. Nevertheless, a plethora of ABC-themed paper presentations' titles started appearing in project management and cost engineering seminars. True to form, of the ones I attended, the content was made up of deconstructing the act of generating the basis of estimate into some sort of process guide--almost like a recipe--and then sprinkling in vague but trendy management-speak terms to make it appear new, or more sophisticated. To engage in a bit of deconstruction myself, at the end of the day all management models are nothing more than formulaic attempts at telling other people how they should be managing their projects. I can see why such models are appealing to consultants. But, for the rest of us, do they really merit all of the books, articles and presentations devoted to them? |
Your Problem Isn't ...
Categories:
Project Failure
Categories: Project Failure
| Project management practitioners who read the conventional wisdom on those things that threaten project success may be "getting sold a bill of goods" (a U.S. colloquialism meaning to be deceived). While project management-types usually don't stay in the industry for long before witnessing a project crash-and-burn firsthand, the ability to accurately identify and clearly articulate the proximate cause of that project failure is often elusive, with individual prejudices coloring analysis. Quality engineers tend to name a lack of quality capability as the main reason behind project failure, while estimators tend to believe inaccurate cost baselines or estimates at completion are the culprits. I have a pretty clear idea of the main, if not only, cause of project failure, but before I name it, let me tell you what it isn't: • No Six Sigma • Lack of Agile project management • Failure to engage stakeholders (see my previous post) • Inappropriate leadership style • Too few Project Management Professional (PMP®) credential holders • Insufficient procedures or written guidance I could go on, but this list should be sufficient to contradict the majority of management writers who are asserting the key causal factor in project failure. So, what is the main causal factor? The project manager and/or project team made bad decisions. This is not simply a semantic difference. The ability to make good decisions is absolutely critical to any and all project outcomes, including the ability to meet success criterion. This ability is influenced by several factors, including: • The education/capability of the project team • Some level of luck, certainly, but mostly: • The availability of adequate project cost and schedule performance information, which almost always clarifies the best project decisions So important is the generation and delivery of cost and schedule performance information that any manager who eschews such information has automatically signaled their incompetence, and inappropriate placement in any position of authority. I'm essentially calling out the anti-cost/schedule performance system crowd. (You know who you are.) If you have ever argued against the introduction of an earned value system on principle, stop calling yourself a project manager because you aren't one. Of course, I'd love to hear from anyone disagreeing with me on this, so, please leave a comment. |
The Scarlet FES
Categories:
Communications Management
Categories: Communications Management
| If I had a dime for every copy of every project management article that prodded the reader to further engage stakeholders, I wouldn't have to spend time writing this blog. I could probably buy New Zealand. Indeed, failure to engage stakeholders has become the cardinal sin of the project management industry if you read all the trade journals. I do believe that they are only a short distance away from requiring all managers of failed projects to wear a scarlet FES, for Failed to Engage Stakeholders, reminiscent of Nathaniel Hawthorne's novel of a very similar name. Being the hopeless iconoclast that I am, I can't help to make the opposite assertion: Project managers should eschew these all-wise, all-knowing stakeholders for the following reasons. First off, who are we talking about here? Which "stakeholder"? If it's the customer, then, of course, "engage" them (which, I assume means, you talk together). But keep in mind, customer involvement often involves their asking for additional stuff on your project or higher quality standards. The desire to accommodate these stakeholders is the most common cause of that most fatal of project-killers: scope creep. And, once a good dose of scope creep has wrecked your project, it won't do the culpable project manager any good to respond, "I was just engaging the stakeholders!" Then there are the stakeholders who are neither on your project team nor in your customer's organization: These are "nuisances." If the scope of your project involves doing something that provably impacts others in an adverse manner, that's your customer's problem, isn't it? They probably should have spent a little more time getting the appropriate permits before they ponied up the money for your baseline. And, if these stakeholders don't belong to your or your customer's organizations and aren't provably adversely affected, then they should probably shut up and go away. Does that sound harsh? Okay, they don't have to be ignored or exiled, but they absolutely should not be consulted on what should happen on your project. Indeed, to do so is akin to project management malpractice. So there. I was getting a little tired of nobody posting comments on my blogs, and I figure this piece will pretty much cure that. |
Beware the Implementation Trolls
Categories:
Project Failure
Categories: Project Failure
| Those project managers who have accepted the quest of advancing project management capability within your organization need to be aware of a very real threat on their path. Implementation Trolls are skulking all about you, ready to bring you down. For example, one favorite troll tactic is to lurk beneath a bridge and attempt to eat unwary travelers who attempt to cross. If we take the action of walking across a bridge as a metaphor for initiating any change, then the Implementation Trolls destroy you in transit, usually by ginning up to the organization's nominal resistance to change. While it is beyond debate that the amount of time and energy that goes into setting up a very simple earned value management system (EVMS) pays huge dividends in useful management information, the Implementation Trolls will complain long and loud about how even that small amount of effort is overly arduous. These beings complain so excessively about largely contrived grievances they should be made honorary members of the Trial Lawyers Association. Then, once you've crossed the bridge and approached the castle that serves as the keep for your sought-after treasure, an advanced project management information system, you will encounter an entirely different breed of Implementation Troll. Far from picking off your comrades for making people do stuff that's supposedly way to hard, these trolls will insist that anything you bring them is not good enough. These Implementation Trolls are invariably armed with clubs that have the infamous 32 EVMS criteria etched into them, and they take great pleasure in pummeling all those who approach. The infuriating thing about these trolls is that they will often present themselves as erstwhile allies to your cause, but will then gleefully destroy your efforts as being sub-standard. Like their notorious counterparts from Norse mythology, Implementation Trolls have what can only be described as bizarre senses of proportion and perspective, and will inflict their damage while pretending to occupy the intellectual high ground. I'm very interested in finding out what the project management blogosphere thinks about Implementation Trolls. |