James John Wilson

A Project Manager/PMO Director’s Foundational Framework

Posted in 4 Project Management, Software Design by James John Wilson on February 11, 2009

It has been a rough few quarters, not just from the economy/business environment perspective, but for our PMO.   The problem I encountered was a lack of team work and cooperation.   I have had to really cooperation-two-mulesrollback and think about what it is I am trying to deliver.   What is the value of Project Management?  Not everyone sees things the same way.  I truly wish my last few months on every project manager or PMO director so they too can earn this merit badge, stripe.  I am thankful to the “difficult” team members that pushed back because they have been the most valuable team members I have ever worked with.

Throughout this process, I have been trying to distill down the information, tools and techniques that I have used (or should have used) from which to draw strength, resolve, and concrete value to put the right system in place, to “get er dun.”  As I list this out… I request that you as the reader ask yourself… “Is it right?”  What else should be there?  ALL INPUT IS WELCOME.   Remember though, that I am trying to keep this pretty high level.  These are the things that I need to keep readily in mind at all times to quickly answer those tough questions in meetings or make on the spot decisions whether to be tough or nice, to push left or right, and to guide project managers through each implementation.  This is what I have come up with so far.

At a high level, what is it that every PMO director must have?  I believe it comes down to three things.

  1. Why are we doing this?  What is the VALUE I am delivering?
  2. How are we going to get the team to do it?  How do I get the necessary COOPERATION to perform the right activities, to capture the right data, and to make the right decisions?
  3. What specifically are the Project Managers and team members going to have to do to be successful?  What is our EXECUTION FRAMEWORK?  What is the necessary advice or guidance?  The right templates, forms, and checklists to ensure we are doing the right things at the right level of detail?

So let’s get into some detail…  (I would KILL for people to help me flesh this out further so please comment)

  1. Crystal clear, concise, and readily communicated knowledge of value of project management.  What is the value of project management distilled down to its core? I think it is twofold.
    1. #1 – To Make Good Decision
      • Based upon some basic cost and schedule data, and using some simple calculations, I want to be able to provide Managers (of people, money and/or products) the ability to make good decisions.  Decisions that balance and deal with Quality, Scope, Time and Resources (people and money). I have some additional detail already in a previous post called, For what questions should the PMO provide answers? To whom? And why?.
    2. #2 – Provide a framework for predictable and reliable execution
      • Getting it done with a high level or reliability.
    3. This value can be used during general discussions, negotiations and to influence team members, managers and executives as to why things need things need to be put in place.
    4. I have a simple example I use all the time which is not grandiose but is concrete evidence I use over and over again.
      • In Q4 2008, we had an infrastructure project to update and standardize all production database servers to the Windows Operating System.  Initially there was some concern regarding ability of the team to deliver this project because it was not getting traction.  The PMO quickly assigned a project manager.  The PM developed a very simple plan, kept some basic schedule and cost performance data.  With several weeks to go before the end of the project, we were able to show that the project was going to go over budget, not by much, but still over budget.  We had a quick chat with the Infrastructure Manager and came up with a solution to remove two servers from scope due to nature of their role and previous reliability.  Ultimately, the two servers were kept till last anyway since we knew they were a low priority.  Removing these servers from scope allowed us to stay on budget and deliver on time.  A win!!  When one was not expected!! Project Management value DELIVERED!!   But how to do I get everyone functioning at this level?
      • I would suggest you find some evidence of your own.  Ideally, it should come from one of your own projects where things went right and use it to push your plan forward.
  2. Develop Approaches and a Foundation for getting Cooperation and Team Work
    1. Expect to have “Human Issues”.  People respond in many expected and unexpected ways.  Be prepared, do not take it personally (this is SO hard for me not to do!!).
    2. Have a clear set of PMO or Project Management goals and objectives that has been reviewed and agreed to by Senior Management.
      • I have listed our PMO goals and objectives in another blog, PMO Do Over, Sharing PMO Objectives, Sharing a Failure.  I had a discussion about PMO objectives with every member of our Senior Leadership team including the CEO, COO, CFO, CTO, CKO, VP Marketing and VP of Business Development.  I then followed this up with conversations with key Line Managers.   Each got a change to voice opposition, ask for clarity and/or more detail.  But I got 100% agreement!  (Was I lucky?  Was I given real agreement or am I going to be “Yes’ed” to death?)
      • The goals and objectives along with this executive support become the backbone used to garner cooperation from the larger organization through discussions, negotiation and influencing of team members.  The goals can be used to explain why certain activities or tasks are being requested and assigned to each team member.  Why certain processes were being put in place.
      • A goal example – “Making good decisions”. It is very powerful cooperation tool to be able to explain how an activity specifically ties back to a Manager’s ability to “make good decisions”.   Most, if not all, team members will generally not want to block their Manager’s ability to make the right decisions.   This works just as well to explain to a Managers why they should also cooperate because it will help them make good decisions.
    3. Always start with the end in mind.
      • Another way to state this is to “Start with the goals, then work on strategies, and then tactics“. Setting clear goals and objectives give you something to shoot for.
      • I am using many of the suggestions from Michael Hatfield’s book, “Things Your PMO is Doing WRONG“.   I reviewed this book in a previous post, Book Review: “What is your PMO Doing WRONG” by Michael Hatfield, PMP.  (I am happy to report that this post got the most traffic of any I have written)
        • In it he states, “[keep] with the management information system axiom that you always begin with the end in mind.
        • Specifically, he suggests developing PMO reports FIRST.  These are the reports used by management to “steer the ship”, “to make good decisions” (where have I heard this before).   Subsequently, when you are asking for cooperation to gather necessary data to populate the PMO reports you will encounter less resistance because the team will see that the performance data is actually being used by management and therefore is not a waste of time disappearing into some black box.    Few team members will want to be held responsible for causing reports to be incomplete or invalid.
    4. Implementation Strategies and Techniques
      • There will be people who do not participate in the team effort, who do not cooperate. Plan for this. Develop strategies and tactics.
      • Michael Hatfield’s book recommends an implementation approach which I also spoke to in a recent post.  I think it is quite profound, and is based upon the “Prisoner’s Dilemma” model for cooperation and defection.
  3. Execution Framework
    1. This is the PMBOK stuff, and almost goes without saying. These are the detailed processes and activities to be performed by Project Managers and team members.
    2. A Project Manger / PMO Director must have a clear understanding of all the steps that need to be performed to get the project done.  He must also have an approach to roll these out in a priority order based upon goals and objectives using the foundation for getting cooperation.

Going back to my tried and true example of the Q4 2008 infrastructure project….  It appears to be quite a simple and basic example.  It sounds simple?  Well it was BUT ONLY because the project manager on this effort produced a plan (according to a framework) with the team, and the team agreed to cooperate, to stick to the plan.  The team communicated changes and issues well.  The team was willing and knew the benefits of submitting basic performance data.  Without this cooperation and team work, the ability to make a good decisions was not possible.  There may well have been a different outcome of being over budget, late with finger pointing, poor performance review and perhaps a few stern conversations to boot.

Book Review: “What is your PMO Doing WRONG” by Michael Hatfield, PMP

Posted in 4 Project Management, Software Design by James John Wilson on January 28, 2009

First lets get a term out of the way, PMO means “Project Management Office” not “Pissed Me Off”.

Let’s get started…

I have been following Micheal Hatfield, PMP on the new PMI Blog, Voices on Project Managment.  I like his content and edge.   The original blog post that caught my eyes was  The Brass Ring of PMOs which talked about Cooperation and problems with implementing PMO.

but consider what you, the PMO director, are asking: You essentially want everybody else to change the way they’ve been doing business, for decades in some cases. I would submit that asking anybody to change anything they’ve been doing a certain way for years, even in the face of overwhelming evidence that the new way is better for everyone involved, is difficult in the extreme.

Scareface, PMO Director

Scarface, PMO Director

I agree.  I have the scars to prove this.  Pain sucks so I have been doing research and soul searching to avoid it!!!  Funny… they do not list  “must enjoy pain” in any of the job posts for PMO Directors.  They should.  Anyway… I digress.

Enjoying Michael’s posts, I decided that the topic was right and bought his book, Things Your PMO is Doing WRONG.  I am glad I did.  Michael challenges much of the typical wisdom, tactics and assumptions which I have personally been leaning on “to move things forward”.  I submit, that even if Michael is 100% DEAD WRONG in his analysis of implementation tactics, challenging long held assumptions is a VERY VERY GOOD THING.  For this reason alone, it is a MUST READ.

I am a little confused by one chapter though called “Cooperation and Defection” grouped under Part 2 of the book entitled “Tactics that Work”.  In this chapter Michael dives into CMM (Corporate Maturity Model) which I found sort of off topic, and then proceeds to state in his conclusion that…

While the capability maturity model provides a nifty gradation structure for furthering a given capability within the macro-organization, current writings on the subject fail to satisfactorily address a critical component: How to actually further a capability?

Hmmm…  So… then… this is then a tactic that does NOT work and should be under Part 1 of the book, “Tactics that Don’t Work”.    Further, there was nothing in the chapter about building cooperation or minimizing “defection” (not participating in the capability implementation plan) as tactics that work.  In fact, later in the book he more or less suggests to expect less than 100% cooperation and to just push forward!

I think there is merit in the approach suggested in the book.  The solution presents itself (pp 35) through the analysis of a winning program from a contest to find the best programmatic approach to maximize positive outcomes to the “Prisoner’s Dilemma” model for measuring cooperation and defection.   I intend to put it to use (future blog post?).  However, Micheal’s subsequent implementation plan, upon closer inspection, relies on some of the very tactics identified in Part 1 of the book, “Tactics that Don’t Work”.   For example…

  • There must be a mechanism for responding to project that attempt to opt out.
    • Paraphrasing… “[defection] must be punished immediately”.  This is ultimately a form of coercion which is reference more than once in Part 1 as really bad!!  Loss of job bad!!
    • HOWEVER, immediate punishment is balanced with the IMMEDIATE and COMPLETE forgiveness for cooperation so perhaps some of the damage can be restored?  I think it can.
    • In the examples, the punishment comes form Senior executive calling Project Managers and their teams on the carpet as to the lack of participation.  This is a form of having “Executive Buy-in” or “Leveraging Organizational Power” which again is reference in Part 1 as a problematic tactic.  I suppose there is a subtle difference here because the Executive is the one coercing.  People will still see the PMO Director as the puppet master.  Never the less, it is still going to force compliance.
  • Using the MIS (Management Information Systems) axiom, “Start with the end in mind.”
    • Get agreement from Executives as to the reports they need to “steer the ship” FIRST, and then build the system to generate those reports SECOND.
    • Again, this is a form of “Leveraging Organizational Power”, because we can now use this report to enforce compliance.  “You have to give me data to support this report, otherwise, I cannot generate the report for the CEO!!  Do you want to be the one to tell the CEO that you are unable to give two simple pieces of project status data because it is too hard and/or too time consuming!”

I think the key word is Balance which I made bold, underlined and italicized just above.  The PMO Director working to grow Project Management capabilities in his or her organizations needs to pull from a large and varied set of tools.   Therefore, many of the tactics suggested in Part 1 of the book, do help but cannot be the sole set of  implementation “drivers”.  A balanced use of many tactics is required and needs to be tailor depending on the audience, company and culture.

Most importantly, the book is a fast read, only 69 pages.  It is also well written.

Thanks Michael!