This blog post is one in a series of 10 based on a presentation I developed, “Top 10 problems new (and not so new) Project users have, and what you can do to ease the pain.” I first gave this talk at a Puget Sound PMI chapter meeting. I later gave an updated version of the talk to my local chapter of the MPUG Project User Group. As you might expect, at the PMI meeting the discussion tended more towards the broader project management issues, while at the MPUG meeting more towards specific features in Project. In fact at the MPUG meeting I had my computer projecting and we played around with Project features that related to some of the issues I brought up.
Top Ten List
In the process of writing the Project Step by Step books (starting with the 2000 edition and continuing through the current edition) with my co-author Tim Johnson, I observed first-hand some of the problems Project users encounter. Some of these problems are straight-forward gotchas in the software, but many common problems were really about how people define, understand and practice project management. In this and the other posts in this series, I’ll guide you through each of the top ten problems new or inexperienced project managers encounter, and what you can do to help identify and address these problems.
Problem #1: Forget that the schedule is not the project
You're a project manager who's invested thousands of hours building and maintaining a complex project plan. Sometimes the smartest thing to do is to just throw away the plan.
On a Journey of a Thousand Steps, the First Step is the Most Dangerous
It's a peculiar truth that at the time you're building a plan for an upcoming project, you can say with 100% certainty that over the entire project's duration, right at that up-front planning stage you absolutely, positively have the least accurate information about the project. How can this be so?
Think about it: as soon a planning ends and execution begins, you start learning all kinds of things. You learn more about the nature of the work being performed. You learn more about the real capabilities of your resources. You begin to see that some assumptions you had to make in planning were just plain wrong. As more time passes, you may see some external issues come into greater clarity--issues in the white space beyond your Gantt Chart, if you will.
By now you may be thinking, "Well of course this is how it works. That's why we're so rigorous in our planning: metrics-based estimates; top-down and bottom-up rigor; leave no stone unturned." All well and good. But for complex knowledge work projects, it may do us some good to acknowledge that as a predictive tool schedule planning is by its nature far less than 100% accurate. Is it 90% accurate? 50%? 20%? There likely have been real projects where all these values proved to be true.
Red Nine, Stay on Target!
A problem I've observed, and frankly been guilty of committing myself, is that a project manager who really, really invests in a specific project plan can tend to become overly attached to that plan. "Staying on course" becomes more important than having a frank discussion along the lines of "Wait, this is starting to look like the wrong course to be on." In a broad sense this is an example of what is sometimes described as the difference between managing and leading. Business managers do things right. Business leaders do the right things. I don't know of any fail-safe litmus test for the project manager to know when their plan may become the wrong plan to proceed with, but for some of my projects I've recognized it in retrospect.
The issue I'm describing is what I'd call (and you might say unfairly) a symptom of waterfall methodology. In some representations of project management, clear boundaries are drawn between broad phases of planning, execution and delivery. Build a great plan, execute on that plan, and deliver what you planned on time, within budget and with expected scope. What's wrong with this?
When I discuss this issue in classrooms, I ask people how they expect some big, physical object to be built. Where I live a lot of people are expecting a new replacement bridge across Lake Washington (the 520 bridge). Should the new bridge be fully specced, designed, and engineered before construction commences? You bet! Do I want the construction workers installing the middle span of the bridge to get creative with, say, a new bonding material they cooked up last week? You bet not! In short, for a big, physical thing like a bridge (or a building, or an airplane) I want close to a 100% exact match between what was planned and what was delivered. For any delta between the two, I want the change requests to go in front of the most learned, conservative group of change approvers ever assembled. In short, I want all the design creativity to be front-loaded into the overall project. Really, just go crazy during design. However I want the execution to be, frankly, a stone cold competent and ideally even boring process.
Can I Get Some Agility in the Back Row?
Not so with most knowledge worker projects, however. Many of the projects I've participated in had, at the start at least, at best fuzzy end results in mind. We needed a high degree of flexibility to basically find our route as we went, and learn from our results (both positive and negative). In short, we needed a high degree of agility. For those of you in the software engineering word you recognize of course that I'm referring to Agile with a capital A methodology. There's a lot to Agile that I'm not qualified to speak to, but the project management aspect of Agile fascinates me. One common Agile scheduling technique is called Scrum. Scrum turns some big tenets of traditional or waterfall project management on their ears--issues like who decides what work should be done, how we measure success, and what's the right cadence for natural cycles of work. I'll have more to say about Scrum and MS Project in later posts, but I bring it up here because it helps to address the original problem I described: the project manager who becomes too invested in a specific project plan, despite mounting evidence that it is no longer the best plan, or even the right plan.
###
Comments