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.

Tipping Points for Teams

Last evening, I watched my 11-year-old son's hockey team in a playoff game. Winning would eliminate the opposing team and allow our guys to move onto the quarter-finals. Our opponents had a better season record, but we hadn't dropped a game to them all year. Pre-game confidence was high. It was in the bag. We lost 0-3. The series is now wide open.

So what happened? Our boys are a capable team. When all 17 play with their heads and their hearts in the game, they cannot be beat. They have stared down older, higher-ranked, and bigger teams and shown some amazing depth. It's not an issue of capability.

The tipping point for this team is confidence. Too little and they fold like a cheap shirt. Too much and they engineer their own defeat. Maybe not enough of the 17 hearts were in it last night. You could say the other team had one or two more heart muscles pumping for the win.

And so it often is with my project teams. Our ability to find success as a team hinges more often than not on the will to win - a desire to achieve something worth achieving. Not for the company or even the other members on the team, but for themselves. I may not get it from all the team members; that may not even be realistic. But I will need enough hearts in the game to reach my tipping point. If my team is coming up short, I reach out to those on the team who can close the distance. I help my team members evolve the project goals so that they resonate. And that's less about being a project manager and more about being a coach and colleague. Cool!

So, our next game is tomorrow. The coaches will be thinking about what it will take to unleash this team's will to win.

What's the tipping point for your team?

Myths and Procurement

Most companies that buy goods and services employ some kind of procurement system. The logic is simple - to ensure that the organization gets good value for its dollar. But for many organizations, something has gone off the rails. Processes that were intended to allow for dispassionate acquisition are now crushingly bureaucratic reality shows. Rules are invented to frustrate the respondents. And the system is gamed, more often than not by the very people who insist that procurement processes are vital to the company's well-being.

Earlier this year, I reviewed an RFP outline of the rules of engagement for the process. One paragraph noted that respondents who do 'X' will be disqualified from further consideration. A later paragraph said that respondents who did NOT do 'X' would also be disqualified. This discrepancy was raised by vendors during the Q and A. The issuing organization's answer? Do your best to figure out what is the correct way to respond. It's a testament to the imbalance of power in the procurement world that some organizations actually responded.

So how can you tell when your procurement system is polluted? Check for some of these behaviours:

1. Have suppliers ever been involved in writing evaluation criteria for your RFPs? Try asking a car salesman to help you determine what you need in a car. I guarantee you the criteria will revolve around their differentiator.
2. Do responding rules promote a level playing field (e.g., open Q and A sessions)? Or do they create hurdles that may help you filter, but not really evaluate, respondents (e.g., disqualifying submissions that deviate from a prescribed format)?
3. Do you cancel RFPs routinely? Of course, by wasting your vendors resources you raise the prices you pay.
4. Are procurement rules routinely circumvented? Do senior managers follow them? Do employees chop up their acquisitions to keep them under certain thresholds in order to avoid justification processes associated with larger procurements? Mix with bullet 1 and you've got the Ontario Premier's nightmare.
5. When creating an RFP, do you try to ensure that the distribution of risk is fair between the supplier and the buyer? Or do you try to get as much as you can without having any of your own skin in the game? What would you do on the receiving end of this kind of tactic?
6. Do you rely on cost-minimization strategies to select vendors? These days, this antiquated view of value propositions is routine in public institutions like hospitals and often coupled with bullet 5. Trying to minimize both cost and risk may seem like a noble strategy, but it is incredibly naïve.

Your procurement system can do much to support an 'arms-length' dispassionate approach to buying? Or it can just 'stiff-arm' potential partners that could provide real value to your business? And if that's what happening, who is it really hurting in the end?

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 Views: What is 'Communications' Again?

I've done a fair bit of work of late as a subject matter expert in the area of Project Communications. Even so, I struggle to understand what it really *is.* I have an 807 page book on my shelf about Project Communications that goes on and on about how to manage it, but never defines it!

I feel about communications the same way I feel about the colour orange. Some days it seems like it's a colour all its own, but often enough it just seems to be a variation of red or a saturated yellow. And maybe that's it. Perhaps communication isn't so much a thing unto itself as it is a vehicle for, or enhancement of, something else.

When I'm really communicating with someone, I feel a sort of *click.* I can often see it in the other person as well. Something happens that is bigger than either of us. It is the most energizing part of managing projects for me - getting to the point of *getting it* so that my team and my stakeholders can share in project success.

Effective communications in projects is like model airplane glue. Applied well, you don't really notice it in the end product. Used sloppily, you end up with gobs of glue all over the place. Sure, the airplane is held together, but it's best to stand back a few feet so you don't notice the disaster of the execution. And if I spend too much time around communications *templates* I start to hallucinate anyway.

PM Stories: High-Risk Advocating

I was managing a project to produce a web-based application for use during a scheduled training event at a client’s site. On one side was my sponsor that was extremely eager to launch. On the other side were developers trying to create code for complex business rules. As my team struggled to get the application to behave as required, they became concerned about their ability to complete and test in time for the event. My sponsor and team were at odds over the project schedule and became adamant that their respective interests be accommodated.

As project manager, I needed to address two contradicting positions. First, my team needed to feel that their concern about the deadline was taken seriously. An unheard attitude of “we’re not going to meet the deadline” can become a self-fulfilling prophecy. I didn’t want us to subconsciously undermine efforts to succeed in order to prove that our predictions were right. My team needed to be confident that I was communicating the schedule risk appropriately.

Second, I wanted our sponsor to be confident that every effort was being made. If I simply informed them that we were projecting a schedule overrun, the sponsor would likely have implemented their own strategies to meet the date - completely understandable even if it was a long shot. I communicated status using a blend of progress (what we’ve done) with a qualitative assessment of its impact on schedule risk. Next, I laid out our forecast (what we’ll do), again with prediction of risk impact.

In the end, we didn’t launch at the scheduled event (you thought I was going to claim success?). In a way though, we were successful. The development team had flown to the client site, and both sponsor and team felt that all efforts had been made to meet the deadline. The sponsor was not caught by surprise because they had been kept up-to-date concerning risks all along. Eight hours before the event, the sponsor rescheduled the planned launch, perhaps not thrilled, but satisfied with the team’s commitment to the sponsor’s goal. Everyone ended up on the same page.

Moral: A project manager’s ability to advocate for both sponsor and team makes it possible for those with differing interests to work toward a common goal.

PM Practice: Tips for Tasks

Sorry … I should say ‘activities’ … not tasks. Pardon my non-PMI-speak.
Early in my coaching career, I worked with a bright project manager on developing his schedule. We talked a little about how to create a WBS and then how to define activities. I gave him those steps as an assignment and left him to it. When we met again, I was surprised to discover that he had no idea how to structure work. His activities ebbed and flowed in different directions. Some bore no relationship to the project, while others seemed to bleed into each other. Imagine defining activities for a dinner party. This fellow would have included activities like:

• “Prepare ingredients in the fridge” (what about the ones in the cupboard),
• “Buy and broil meat” (is that all you are buying … and aren’t there a couple activities in there?)
• “Bring salad to the table holding bowl with 2 hands” (the 2 hands part is a specification, not an activity).

Since then, I have thought more carefully about how I actually define activities so that I can talk about it to the less systematic among us (a group I identify with more as I get older). Apart from saying ‘it looks weird,’ here are some tips that have helped:

1. Activities involving performing work. It follows then, that activities should be structured using a verb-noun structure, as in “Do Something.” I worked with an event planning team that included activities like “Hotel.” I asked if they were planning to book it or build it.
2. Team members should be able to agree on what done looks like. Most people would say that “Write Draft Document” would end with an essentially-complete first pass at the deliverable, so that’s a good one. “Conduct Research” is trickier. Adding some specifications as a note to your activity may help.
3. Completing the effort associated with an activity should move the project measurably forward. “Execute Test Plan” should yield a performance result. I saw a plan once with an activity called “Develop Team.” I suggested they change it to “Hold Team Spa Day.” At least you know there’s no going back once you’ve had sweated it out in a sauna with your analyst.
4. Activities can be big or small. There is no hard and fast rule here, but I like each team member to focus on between 1 and 3 activities in a week, plus 1 project administration activity that remains open for the duration of the project. This usually means that activities will range between 8 and 60 hours of effort. Activities that are too small lead to administrative overload when you collect actuals from your team each week (which of course you do …). Activities that are too large are difficult to monitor for progress. “Create Requirements Document” can be a 6 to 8 week process with only 1 measureable deliverable at the end. Without a near-term checkpoint, activities like this long tend to get longer. I was brought into a project once that had spent 12 months on requirements for a supposedly 18-month project. I would break this activity into a set of iterations of draft and review.
5. If the effort transitions from 1 person to another, that’s probably a new task. “Write …” is one task. “Review …” is another.
6. A waiting time often signifies a break in tasks. Keep this in mind with projects that involve paint or concrete.

Activities are foundational to project monitoring and control. Getting a solid model of defined activities for the project will pay off later with fewer gaps or overlaps in scope and the team’s improved ability to deliver to expectations.