Build a better PMO by Crashing the Net

In hockey, the 2nd forward into the attacking zone often scores the most goals. While the first forward may unleash the massive shot, it more often than not bounces off the goalie's pads. It is up to the 2nd forward, now in the crease, to finesse the puck up and over (or through) the goalie.

When I help my clients develop their PMO organizations, it is pretty much the same way. I usually participate in the second attempt to implement a PMO. That's because a lot of organizations build a PMO backwards the first time round. They violate one or both of the two fundamental flows of a PMO.

The first flow is that organizational capability is developed from people, to process, to tools. Break that order and your PMO will fail ... guaranteed. Many first-time PMO-builders set about procuring enterprise-wide project management tools as soon as they take the ice. You've heard the expression that the solution isn't in the software box? This is a mistake I have seen companies make to the tune of more than $10M, only to be abandoned every single time. It's like buying a $300 one-piece stick when you don't know how to handle the puck. What's the point? You could yank a branch off a tree and have the same impact.

The second flow is that project data moves from the bottom of the organization to the top, not the other way round! So many PMO-builders try to build a dashboard to manage their portfolio first. They blink and sparkle like a hockey scoreboard, but it's really just a hood ornament. The data driving the display is poorly synthesized because the project teams and managers have not yet developed a common understanding or approach for managing projects. Collating metrics this way is a misleading adventure at best. At worst, it'll open a huge riff right through the middle of the organization. I could tell you stories ...

When I work with organizations to develop their PMOs, I probe senior managers to understand what kinds of decisions they need to make concerning their portfolio. After that, I head straight for the project managers to help them get what they need to manage their projects better. That may involve developing a better understanding of how to manage, or coaching them to increase skills. Projects managers that have confidence in their abilities to run complex initiatives can feed the data engine of a dashboard quite naturally.

PMO development follows underlying fundamentals. And like hockey, if you want to put the biscuit in the basket, you're going to have to go with the flow.

PM Views: In Search of Better Goals

Some time back, I was working with a client to help them get better at managing projects. Of the many projects they committed resources to, very few had a clearly-defined and well-understood purpose to which team members and stakeholders could refer. They jumped all over the 'how' without really understanding the 'what.' So we set to work on building some definitions for our projects.

Of the 10 project managers I was working with, 4 of them developed charters and scope statements indicating that the main objective was 'to reduce the FTE count in Department X by Y%.' Big flapping red flag!

Me: "Who are these FTEs?"
PM: "Well, some end users and some team members."
Me: "What happens when FTEs are reduced?"
PM: "People get packaged out."
Me: "How's the project going?"
PM: "Not very well. No one's too excited about it."
Me: "Wonder why ..."

To me, there is an intimate relationship between this kind of thinking and the economic dive of the past year. Money has been treated as the only asset and people are just a commodity. It's a 'killing the golden goose' thing.

Project managers can influence this kind of thinking for the better. Let's engage our sponsors and stakeholders in a dialogue about the big picture. What might be possible for our organization if, through our project, we could free some of our talent to pursue things of higher value? Why not make THAT a goal of the project rather than simply shaving some dollars off the expense column? The PMI Code of Ethics completely supports this approach. And doing so distinguishes us as more than managers. It demonstrates leadership.

PM Practice: Using Milestones

While hiking on a trail outside a Swedish town where I used to live, we passed a milestone on the side of the path. This piece of stone was about a foot wide, 6 inches thick, 4 feet high and many hundreds of years old. There were a couple of features about it that caught my attention.

It was easy to spot from a distance, but it didn’t take up much space. The face of it was inscribed with one number indicating where we were on the path and a 2nd number informing travelers how far it was to the next major town. As we walked along the path, we were either moving towards it or, having passed it, moving away from it. The time that we spent ‘at’ the milestone was maybe a second. The parallels to project milestones make it clear why these ‘moments on the path’ share the same moniker:

• Milestones provide a clear measure of progress and are uniformly visible to all stakeholders. When you pass the ‘Design Complete’ milestone, pencils go down and girders go up. If you’ve still got a pencil in your hand, you haven’t passed the milestone yet.


• Milestones have no effort associated with them. Tasks do. ‘Design Complete’ is a milestone. ‘Complete Design’ is a task.


• Milestones have no duration. They’re just markers on a path. If you stop to marvel at your accomplishments upon reaching a milestone, fine - many people do. But that’s a task (‘Admire Progress’) that has nothing to do with the milestone.


• Milestones are either 0% or 100% complete. There is no ‘50% complete’ for milestones. Once you complete all the tasks needed to reach the milestone, the milestone is passed. Until then, keep working.


• Different milestones may hold the interest of different stakeholders. ‘Key’ milestones are of interest to everyone and often associated with either a major deliverable (‘Test Case Creation Complete’) or a change of the project phase (‘Testing Complete’).


• Milestones are placed with reasonable regularity. I aim for some kind of milestone about every 4 to 6 weeks. Agile Project Management leans heavily on this idea because sponsors need only commit to the process incrementally.


• Key Milestones are on the critical path. As a communication tool for progress, they work better when they don’t wobble around due to float.

Some milestones existing today have been in place for centuries, yet still convey accurate information (Stockholm hasn’t moved). They tend to be stable. Project milestones are similar.

PM Practice: The Right Way to Track Actuals

Most project managers I know track actuals at a task (e.g., 25% complete) or duration (e.g., 4 days spent, 3 days left) level. Effort (or work) is generally left to be managed by their scheduling tool. The method you choose for tracking actuals affects the ability of your schedule to predict final time, cost, or scope. The problems come when PMs use task-level tracking (low predictive power) in order to manage a project where high predictive power is required (i.e., project milestones are 'set in stone').

Effort is the real currency of most all projects. It measures, in hours, the heads-down work performed by individual members of the project team. It is a key determinant for the duration and cost of most tasks. Project managers that track actuals at an effort level are able to sort out what is causing delays or cost overruns because their project data is more granular. When I track actuals in my projects, I can make smaller, more targeted, corrections in concert with my project team. My projects still slip (after all, we only manage risk, we don't control it), but they do so less often, and usually less dramatically (and therefore more correctable).
Tracking actuals at the effort level is just as easy as other methods. I follow these steps:

1. Each week, my team reports ATD (actuals-to-date), in work hours, for any task that was ongoing at some point during the week. I build my schedules such that each team member will typically work on 1 to 3 tasks per week.
2. For each of these tasks, my team also provides and ETC (estimate-to-complete). Obviously tasks that they completed will have an ETC of 0 hours. Steps 1 and 2 take each team member about 5 minutes a week.
3. I set up a tracking view in my scheduling tool (whatever my client needs me to use) that allows me to apply ATD and ETC to individual tasks every week. There are tons of tools that will automate this process, but even if I do it manually, we are talking 10-15 minutes every Monday morning for a team of 30 people.
4. I save my project plan, updated with last week's actuals, and begin my weekly upkeep (a tidy schedule is a defensible schedule I always say!).

I have taught several hundred project managers the nuts and bolts of this process over the years and those still in the job today couldn't imagine not tracking their actuals another way. Anyone can learn how to do this and the impact on project manager performance is a blast to watch. New project managers gain confidence because they develop a better understanding of their projects. Experienced, capable PMs get a real boost from this method because it helps them validate their intuition about adjustments they may need to make.

Agile adjustment: This practice works with Agile, though you may choose to shorten the interval from a weekly timesheet to a daily verbal report of ATD and ETC. Properly measured, tracking effort can help Agile teams compensate for deficiencies in the organizational implementation of the development method ... but that discussion is for another time.

PM Laws: Ascend the Project Knowledge Slope

One of the truisms of projects is that you know the least about your project (or product) at the beginning and most about it at the end. This fact pervades every aspect of projects and how we manage them:

• When making a decision, you will always know more tomorrow. Some decisions are improved by waiting; some benefit from timeliness over gathering more knowledge. It's not always easy to know which is which.
• Budgets and dates are usually established at the beginning when we know the least about projects. There's a good reason for estimating these early, but it does make things more complicated.
• Project documents are intended to help us ascend the knowledge slope. Docs that help teams and stakeholders to learn collectively work best. Boilerplate text doesn't help.
• You may have planned your project expertly, but it will change almost as soon as you sink your baseline. Do you have a system that helps the plan evolve fluidly in concert with your understanding of the project?

The most successful project managers I've met are the ones that run their projects with awareness that they can't know everything from the get-go. Learning and adjusting will be the norm. The ones I've coached who struggle in the job are often railing against this reality. If you refuse to baseline your plan before your requirements are signed off, you're fighting the curve, my friend.

I Like Projects Because I Like Change

Most change needs the coordinated effort of more than one person and projects are the construct for achieving results from our efforts.

By construct, I mean that the word 'project' is simply the taxonomy we use to describe a way of doing something. If someone tells you, "I worked on a big project last year," what are they really saying?

• I was a key contributor to a significant outcome?
• I was focused on achieving a goal in concert with others?
• I suffered under an inflexible regime in order to keep my job?
• What's on the lunch menu today?

Projects can generate strong emotional reactions - both positive and negative. But projects in their basic form are neutral. They are just of way of getting something done. So, how does it happen that some projects earn the nickname 'crowning achievement' where others are called a 'death march'?

I think it's because at their core projects are human enterprises. They contain all the necessary ingredients for both great (hope, dreams, ambition, conviction) and underwhelming (ignorance, prejudice, ambivalence, conviction) achievement.

Projects engage me because they hold so much promise. They can encapsulate achievement, whether it's building a beautiful house, a useful program, or a better health care system. But they're not easy. The world is chock-a-block full of processes, methodologies, tools, dashboards, and all kinds of 'techniques' to help manage projects. But still, they're not easy. That's because success in projects comes from things that are deeper than dashboards. They come from and through … us.

I've been fortunate to make a decent living helping other people's projects work better. It's fun and rewarding and it lets me get to know some pretty talented clients. I know a project team is on the right track when they let go of the idea that their success is measured by some dashboard ("if we code the status yellow, they'll stomp all over us!"), and start to visualize what they could possibly achieve. It has almost invariably been more than the team initially realized!