PMI Global Insights

All,

I just had to post something that happened to me today that fits exactly into our topic at the upcoming PMI North America Congress Session.  We had a review today on a set of customer communications that will occur in series.  Today's review was different than what was agreed upon last week.  It almost gave the feel like folks went off for the weekend and forgot after some heavy tailgating.  LOL   Ever have that happen to you?  

A little More Detail:  The inital plan would 1) issue a welcome email, 2) send customers a return equipment email, 3) send them a second equipment return email, and then 4) send them a final equipment return email.  Last week, we agreed to consolidate it down to two communications instead of four.  Today, we were talking about four again.  Sounds like Groundhog Day, right??  

This is not a chastisement of anyone in particular.  This happens all the time to very good, smart people.  In this case, the team was able to refer back to semi-official notes and memory to get folks aligned again.  

What happened to your project(s) recently that you can share with all??? 

Are We Defining, Measuring & Communicating Project Success in the Right Way?

This is a beautiful question that we need to be re-thinking, particularly in today’s disruptive world.  We all measure projects in some way, but do we measure what matters? This is the question we will be discussing in an interesting new format of an ‘interactive’ session at the upcoming North America Global Congress in Phoenix next month. This session will also be available live to a virtual audience. I am excited to lead and facilitate this session as I have been on a pursuit of finding better ways to ‘measure what matters’ for a number of years. I have posed this questions to hundreds of project and program managers around the world and written about it. Most organizations have all measure of key performance indicators, metrics and measurement systems, but the more you look under the covers measurement is a joke in many organizations. In this engaging and interactive session we will explore, why this is so?

 Along this pursuit I am outlining four objectives for our discussion:

1) Ask the tough questions and challenge the current ways of measuring & communicating project success.

2) Discuss how do we define project success?

3) List measures and performance indicators that stakeholders care about.

4) Gain new insights and actionable pointers to measure and communicate project success.

To get us started, here is a preliminary list of questions to think about:

•        What do you currently measure? What are common measures in today’s world?

•        What kind of behaviors do our current measures promote? 

•        Do we measure what matters?

•        How do you define project success?

•        How do we measure what our stakeholders care about?

•        What makes stakeholders happy?

•        How do you communicate project status and progress?

•        What tools / templates / platforms / dashboards / scorecards are appropriate to communicate project success?

•        How do you know that customer requirements have been met?

•        How do you know that the project outcomes have been met?

Are you ready for the dialog… What are your challenges in this area? What other questions you would like to explore?

As I was thinking about getting ready for PMI Congress and our upcoming Project Management Communication War Stories Session, I kept coming up with example after example of communication moments that affected projects.  It was like a deluge of past historical (and some hysterical) episodes.  I was thinking of stressful ones that could have been avoided with a little more "chatter" among the team members and stakeholders.  Also, I was thinking of funny ones that made us all laugh for how we let that happen.  In addition, i was thinking of crazy ones that made us wonder how in the world we got here.  

So there I was coming up with all these examples, when one hit me real-time right in the eyeballs.  You might relate to this one:  I call it a "jump ball."  

Bascially, it is a situation in which everyone has somewhat clear roles, but the work task at hand has elements of many players and spans several responsiblities.  In most cases (as in the one that hit my team), instead of going for the ball and owning it, players shy away from it expecting another team member to take it.  Everyone rationalizes it, but no one communicates why he/she expects the other(s) to run with it.  Bottom line is that the ball gets dropped.    

Have you been there?  Obviously, I was in one for sure.  In my particular example, the team is launching a new capability within a device.  The lead team member designs the capability/functionality.  The engineering team designs the technical specifications by which this new capability works.  My team was supporting the effort by providing the network functionality by which this new capability would leverage and work.  Three groups...three roles...one effort.  Simple enough, right?  

Well, the lead team set up the business requirements but expected the functionality to be worked by another group.  The engineering team set the specs, but could not leverage my team's network.  My team thought that since engineering could not use our design and they had their own home grown option, that we were regulated to SME status and our work was basically over.  Engineering thought the lead team had overall oversight.  The lead team thought my team was driving the solution.  

The problem is that we had no owner and no ETE solution that took the capability from the device and linked it to a network server that completed the "circuit" so to speak and provided the solution.   The team was months along on the project and effectively had no solution.  This was a true "jump ball" with no one running with it.  

Does anyone reading this have examples of "jump balls" in which lack of communication and clarity of who is actually owning a task imperils a project?  I would love to hear some "war stories" if you have them.  

When I saw PMI’s call for papers for their 2014 North American Congress, I debated which topics I would propose to write and speak about. Over the last 10 years, I have presented at various PMI Congresses on topics of Project Management Maturity, Scheduling, Project Portfolio Management, Earned Value Analysis, Setting and Achieving Stretch Goals, and Effective Communication and Collaboration Skills. It is clearly time for something different, I thought, something on Program Management perhaps. It is one of those topics that doesn’t get enough attention. Most people assume you would just do the same thing as you would for Project Management, only that you would do it to a group of related projects.  Well, in my opinion that’s both correct and incorrect. So it’s decided then. I will speak about Program Management at this year’s PMI North American Congress.

When I’m in the planning phase for a Program, the processes I use for Program Management match those of Project Management exactly. I gather requirements for the complete scope, make sure the requirements are clear and can be met. I use the same decomposition technique to break down the scope to a manageable level which I can then assign to project managers. Call it what you want, but my Enterprise Project Structure or Program Breakdown Structure look very much like a project Work Breakdown Structure.  I even use the same tools and techniques for analogous estimating, evaluating trade-offs (build, buy or partner) and planning procurement and HR activities. Along the way, I carefully manage stakeholder expectations, taking the “cautiously optimistic” approach. I personally like to under-promise and over-deliver – but that is difficult to do because sponsors have a way of making me say “yes” to their laundry list of wishes. Even so, I have been called a “Spoiler” by my executive sponsor on many occasions.  So at least for me, planning a program is very much the same process as planning a project, only I stop at a higher level of detail and let the assigned project managers take over from there.

Once the Program Plan is approved and projects can begin, the Program’s execution, monitoring and control phases are also similar to those in Project Management. The key difference, is the effective summarization of the relevant project details so that I can “see the forest for the trees.” I need to know the program progress at a high level, while making sure important events and trends are not missed (or worse, hidden!) As a program manager, I also need to play match-maker between project managers, and reminding them how each project is dependent or impacting another project in the program.  I find that project managers can become myopic (probably for their own sanity and self-preservation!) about their own projects and they often forget (or avoid) to inform the related projects which they impact. Information about project progress needs to flow up and down at the appropriate level of detail so program decisions can be made effectively and in a timely manner. When done well, it’s why Program Managers deserve to “make the big bucks.”

In my presentation at Congress, I will share some real examples to show how Program Management is different and challenging at the same time.  If you are managing programs or large projects that contain many sub-projects, I hope you will attend and share your experience with all of us. Until then, be well.

In late October 2014 many of us will be gathering in Phoenix for the PMI Global Congress 2014 - North America.

And I can't wait to get there! Hey! Why should I have to wait? Why can’t we have the Congress tomorrow?

Like all good things, this Congress will come in time! And, it is the "wait" that makes it worthwhile.

It is during the "wait" that speakers are lined up, topics chosen, and events planned.

It is during the "wait" that lecture content is developed, and powerpoints created.

It is during the "wait" that presentations are rehearsed, and delivery skills polished.

It is during the "wait" that white papers, the intellectual property that propels our profession to new highs, are written and published.

And so it is with any project that we are asked to tackle. We are always excited (ok, maybe not always) to be given a new challenge, and naturally we immediately want to jump in, dig around, pull together a team, and start the project.

But is this the best approach? Shouldn’t we “WAIT” to ensure that the team is really ready to begin the project?

I would suggest that we have done a good job, as a profession, in slowing down enough to do more planning before we jump into the work itself. However, there is still something missing before we even start the planning, which has the potential to greatly improve upon our planning and execution efforts.

If you study the PMI Project Management Framework there is a process buried under the Executing Process Group – Develop Project Team – that is often incorrectly considered something we do later in the project due to its placement on the framework. Yes, I know that physical placement on the framework has nothing to do with practice, but it is just hard to think of a process that sits smack dab in the middle of the framework to be something you must do from day one!

But it IS something that must begin doing on day one.

The best time to train your team is at the start. As Maria from the Sound of Music would say, “Let’s start at the very beginning. A very good place to start.” Why? Because you need the team to move from forming to storming to norming to performing as quickly as possible, and the earlier you begin the journey the more quickly they will become that rock-star-team you always dreamt about.

Surely we can all agree that there is value in building your team before they are expected to perform as a team. And, that there is value in training your team before they are expected to use their new skills. And, that there is value in having your team know, and understand, the project management tools, techniques, and processes before they are expected to use and follow them.

But every project is unique, as is every project team, and therefore they require tailored training based upon the experience, diversity, knowledge, aptitude, and attitude that the members bring to the group. But it is possible to develop one training program that can be used across multiple situations, and it is plausible that this program can deliver 80 to 100% of the training required for any given project team – with the remaining training needs being fulfilled from a toolbox of “session plug-ins” as needed.

How would you design such a training program? What should it include, how long should it last, how much detail should it attempt to deliver, and in what format should it be delivered? Does the team really need to understand the tools and techniques you will use or is it simply enough that the project manager does?

My advice is that the next time you are ready to jump in and start the work (even if it is just planning), remember to STOP! WAIT! TRAIN!

And then be rewarded with a stronger team!

[Bookmark this page as over the coming weeks we will discuss potential answers to the above questions, and, include examples of successes and failures regarding pre-project kickoff training. In the meantime, I would be interested in knowing your thoughts about this concept, as well as your experience in this area, so that your ideas can be incorporated into future postings here.