PMI Global Insights

by , , , , , , , , , , , , , , , , , , , , , , , , , ,
The Project Management Institute's annual events attract some of the most renowned and esteemed experts in the industry. In this blog, Global Conference, EMEA Congress and experienced event presenters past, present and future from the entire PMI event family share their knowledge on a wide range of issues important to project managers.

About this Blog


View Posts By:

Cameron McGaughy
Kristy Tan Neckowicz
Jack Duggal
Saurayan Chaki
Dan Furlong
Marcos Arias
Danielle Ritter
Marjorie Anderson
David Maynard
Sandra MacGillivray
Deepa Bhide
Karen Chovan
Nadia Vincent
Lawrence Cooper
Michelle Stronach
Kristin Jones
Yves Cavarec
Laura Samsó
Fabio Rigamonti
Sarah Mersereau
Gina Abudi
David Davis
Nic Jain
Emily Luijbregts
Cheryl Lee
Priya Patra
Karthik Ramamurthy

Past Contributers:

Catalin Dogaru
Carlos Javier Pampliega García

Recent Posts

Day Three, a Truly Triple Treat at #PMIEMEA18

#PMIEMEA18 - #DifferenceMakers : We are making dreams a reality !

#PMIEMEA18 – Day 3 : #FutureDefiners :Trust your team, lead with agility, befriend the machine and be human

PMIEMEA18 - Conference Summary

PMIEMEA Conference - Day 3:Time flies by!

Backward Expert


This is a backward blog posting!

This will be my final post before leaving for Chicago tomorrow morning.  So, I wanted to do this one more like the way I think about things – BACKWARDS.  Instead of telling what areas I can help with, I thought I’d ramble about what areas I like to talk about!  I guarantee it would be an entertaining discussion.  Just make select an open appointment here:  then wander over, say hello and lets just talk about one of MY favorite things.

1.  Project failure.   I know more than I ever wanted to know about this.  There was a group of us that Left NASA at the same time and moved to Orlando to start a company dedicated to turning around troubled projects, programs and operations.  When we started, we thought we’d seen just about all the problems that project can get into.  WRONG.  For the next 5 or 6 years we only worked on turning around projects that were at least 100% over budget, perhaps 3 or 4 years late, had irate customers… or simply failed to deliver anything of value. 

It’s not easy to judge project failure!  EVA won’t do it.  It’s a very subjective thing.  “Could anyone have done better in the same situation?” is a basic test, but there are many more. 

So, we fired, hired, replaced, improved… bought contracts, had contracts “novated” to us, and were very successful ending up with a stand-along building and 70 employees.  There’s a lot of trouble out there!   There were project mistakes made that I didn’t think cold be made.   We worked on Casino projects, entertainment projects, airline projects, and many other types.  

Our group learned a lot!  I love to talk about a failed project and how it can be recovered.  Number 1: be ready for stress.  We called being personally ready “the full wax job.”  Exercise, diet, mental toughness, how you dress…  no kidding!  But you need to be prepared.

2.  Working with a team that has widely diverse skills.  If the team gets diverse enough, sometimes you can’t understand what the other people are saying.  I’ve managed teams with theoretical physicists, mathematicians, brilliant engineers and more – of course, they were totally convinced they were ALL CORRECT, don’t even think about doubting their work.  This was great fun.  I loved it and learned a whale of a lot about things they didn’t teach me (a humble engineer) in school.

3. Project risk.  How to think about it, how to predict it, how to anticipate it, how to communicate it, how to budget for it, how to look for the often-neglected positive risk.  It’s CRITCAL that project managers and their teams master this skill.   I’ve had friends die a horrible death  because we (in a larger sense) didn’t manage risk well.

4.  Have the courage of your convictions.  Tell people what you believe, tell the bosses what your project team believes.  Don’t fall into the trap of “drinking your own bath water” or the “echo chamber.” 

Well, I feel better!   Wander over and chat with me!

-- Dave Maynard


Don’t forget about ASK THE EXPERTS!

Stop by and talk to Dave Maynard or one of the other experts.  There’s more information about it at

Sign Up Now

Posted by David Maynard on: October 26, 2017 01:47 PM | Permalink | Comments (4)

Rethinking the Charter

Since I retired after 26 years in one company, I have had assignments in various PMOs in different industries.  I’ve been in the energy sector, the insurance sector, credit card services, industrial/manufacturing, and now healthcare.  Every industry has struggled with the project charter.  What does baselining it mean? Does it ever get updated? Who should issue it? And the list goes on.  And while PMOs in all these industries try to invent the perfect process – we are ignoring one important aspect.

The project charter, as defined by PMI, does not meet the needs of today’s business!

Before you call me a heretic and an incompetent – hear me out.  The problem I have with the charter is it becomes a reformatting of existing information, bloated, and redundant – and it doesn’t provide the project team with the most important information it needs.  Shouldn’t the charter give the team a definition of what success looks like?

I propose the charter should be extremely streamlined.  After all, how many people, let along executives, will read a 14 page charter?  Many charter templates contain information that is already in one artifact and will no doubt be included in another.  I propose we throw away the bloated all-inclusive charter of today and replace it with a simple charter.

Project Organizational Wrapper

You need to have the organizational wrapper of project control structures.  If the project pipeline has a defined Demand Process and there is a demand id, it should be in the charter.   This should also be aligned to the business case information – what went into the approval, and other justifications.  No need to repeat them in the charter – they already exist in a corporate database of record.  If information is in two places – that doubles the risk of inconsistency, confusion, and delay.

If you have an integrated project management system (IPMS) that tracks project work in process – then that project id should be there. Projects assume titles and identify from the ideation phase through project initiation.  That title, or name, should be included in the charter because that’s the lingo that has defined the initiative.

Should be results focused

Once the project is ready to kick off, the work initiative needs to be focused on the results.  If your organization is mature enough to be doing Benefits Management Realization, the charter should map directly to the benefit register.  The next section of the charter should be:

What does success look like?

Quite simply – what is the vision in reality?  Knowing what success is far outweighs the value of several scope bullet points.  The definition of success can be expressed in several ways including:

Critical success factors

The essential areas of activity that must be performed well if you are to achieve the mission, objectives or goals for your business or project.

What can we do in the future that we can’t do now?

How do we measure success?

Not calling for specific key performance indicators here, but should have an idea of how we will measure success.  It also provides requirements for the product and what are the critical success factors.

External/legal requirements

If you are driven by a legal requirement or an industry standard (HIPPA or an ISO requirement comes to mind) than that should be identified.  The charter must identify conformation to external factors.

What benefits are being realized?

Again, if you have a mature benefits realization process, then the entire benefits quantification/qualification should be in place and your project is delivering outcomes and capabilities to realize the defined benefits.

Organizational RACI

The charter must be able to identify all the organizations that are impacted by the initiative.  After all, how did you get high level estimates for the business case if you didn’t have a means of identifying organizations involved?  This RACI should then be driven to know which groups need to receive and approve the charter. 

Time Frame

What time frame is expected for the organization to start to realize benefits?  Let’s avoid the charade of bottom up estimates and defining the schedule after you have all requirements defined etc.  We are driven by budget cycles and funding is only approved to last so long.  This isn’t to say those things can’t and shouldn’t happen, but at a Charter level – the approval has a defined end time.  This also helps define the scope.

I have purposely omitted several pieces of what is considered part of a charter.  Not that I don’t think they are important, I do, but they belong in defined sections of the project plan.  There is no need for budget as that should already be in the business case approval – and I don’t know if it directly contributes to the definition of the outcomes and capabilities.    Scope is implied in what success looks like and the Critical Success Factors.  If during requirements definition, a question is raised that doesn’t directly support the definition of success, than it is out of scope.  Assumptions, risks, issues, and constraints are all important, but they live elsewhere.  The charter should identify the future state, not dwell on the challenges of the present state.  And the charter should be a onetime document that is not modified or have addendums.  It initiates the work – other artifacts ebb and flow during the project life cycle.

In closing – the purpose of the charter is to authorize the project manager to start delivering on the project.  It is not to cut and paste from all over to make an all-inclusive summary of all business intelligence that justified the project.  I propose to make it a lean document focused on the outcomes and capabilities and the definition of success.  Items that have a workflow/life cycle (risks, assumptions, issues, etc.) do not need to be in a charter, they are taken care of elsewhere.  A lean, concise, and easy to read charter allows the team to focus on delivering within the success criteria.



Please sign up for a 1:1 with me while at the PMI Global Conference! We can talk about PMOs, healthcare project management, teaching project management, or any other topic related to project management!

To schedule a 1:1, use the SIGN UP button on this page.

Posted by David Davis on: October 21, 2017 06:03 PM | Permalink | Comments (6)

I've Learned

Right after the Global Conference, I will be flying out to Vancouver to give presentations at ProjectWorld.  One of my presentations is on Influence and Advising as a Project Manager. This is my closing slide.

As a project manager, we are frequently in a position of advisor or influencer.  We need to understand our interactions have long term impact.  Not only for our self, but also our organization.  It's the feeling of value required in the trust relationship.  

The last bullet is most important, there may sometime be the "drop the mic" moment where you win a heated discussion - but the odds are good you will still need to work with that person - so give them an opportunity to save face.  That 15 seconds of satisfaction might be the prelude to months of resistance.  


Posted by David Davis on: October 05, 2017 12:38 PM | Permalink | Comments (7)

Who is an Expert?

Who is an Expert?  What makes them an expert? 

I don’t pretend to be a cognitive scientist, nor have I done much research on the topic – but it is a fascinating field.  And there is a *lot* of literature, books, theses, and studies on the topic to choose from all the way back to Plato and perhaps before.  This blog entry is based upon what I’ve read plus personal opinions and thoughts.  The question “What is an Expert” was planted in my brain by the good folks at who have asked me (and others) to participate in “Ask the Experts.”  

Please let me know if you disagree or feel I need to add something!   

An expert is generally considered to be a person with extensive knowledge or ability based on a combination of personal research, experience and occupation and in a discipline.  In our case, Project Management and related topics.

I found a  scale by which experts can be judged within a specific field (Germain's scale 2006) that  gives some interesting hints…

  • Specific education, training, and knowledge
  • Required qualifications
  • Ability to assess importance in work-related situations
  • Capability to improve themselves
  • Intuition
  • Self-assurance and confidence in their knowledge

More down to earth definitions exist.  Mark Twain defined an expert as "an ordinary fellow from another town." Will Rogers described an expert as "A man fifty miles from home with a briefcase."

Application to Project Management

I’d going to tailor this write-up for Project Management as well as drift away from academic studies and simply express my own views.

  1. Has experience: There is clearly a level of experience required to be an PM expert.  My guess is that 10+ years as a full-time PM are required.  This experience can be either specific to a field or it could be spread across many different fields that have projects.  I don’t think that makes much difference.

  2. Survived failures: I also believe that an expert has had a lot of failures, and made a lot of mistakes; big and small.  I don’t mean to say that an expert always fails, or only fails, but that their projects stumble and recover or may even fail outright. That’s the hard learning that occurs during the years of experience in number 1 above.   Perhaps if a project manager had never had a failure, they could not be an expert… 

  3. Is observational:  A PM is always observing what works, what doesn’t what almost worked and is thinking about what to do next time.  So, combined with item 2, It’s not just about recovering from mistakes, it’s about recovering the project in the smartest, best way and learning what *not* to do next time and how to avoid getting into that mess again.   They also observe small details in the project’s operation that don’t appear to be important.  These are all signs that can be read and parsed out to see how things are going and what the general health of the project is. 

  4. Highly Confident: An expert PM has confidence in what they say and do.  Of course, this combined with number 2 makes for a wild ride.  We’re letting loose people that, with confidence – make mistakes and then recover, which leads me to point number 5.

  5. Story Teller:  I’d like to substitute the often-quoted top-job of a PM is communication with the most important skill a PM has is 'Story Telling'.  I’m not talking about making up stories, I mean explaining what has happened, or what is expected to happen in an easy-to-follow cogent fashion.  *They don’t lose the listener*.  How story telling is learned is something I’m still struggling with.  I have a few ideas, but of course practice helps!

  6. Strong Sense of Mission: The expert Project Manager carries within them a “sense of mission” in other words, a sense of the value of the project.   It’s the answer to “Why are we doing this anyway?   Every action, decision and communication is made with the internalized, overriding strong sense of mission of the project.  It’s expressed in meetings, to people working on the project, to stakeholders – everyone and, the PM believes it… strongly.

  7. Feels the Flow of the Project:  Once all the above are in-place, confident, has failed (and recovered) many times can tell the story of the failure, and can sense the smallest details of a project and how they inter-relate, they’ve arrived.  I’d declare them to be an expert. 

OH!  They’d have to have at least one PMI certification as well! 

Posted by David Maynard on: September 06, 2017 07:53 PM | Permalink | Comments (12)

Tip #5 For Managing a Cross-Functional Team


(How to herd a group of cats, cows, sheep, goats, dogs and llamas….)

Meetings Don’t Waste Money, If They’re Done Right

Often in a meeting someone will count the number of people there, multiply by some number and come up with a cost then declare the amount of money ‘being wasted.’  It’s certainly possible to waste money (salaries) having people in a non-product meeting.  It’s easy!  Meetings are sometimes called “the practical alternative to work.”  AVOID THIS.  Don’t do this.  Have well-run meetings. 

How?  With Team Rules

Create a set of team rules!   The rules don’t have to be detailed, they shouldn’t come close to resembling a “Roberts Rules of Order.”  Our teams typically had about 8 or 10 rules.  We would post them on the wall of the meeting room.  Again, if you are meeting virtually, the same thing can be done.  Everyone can print out the meeting rules tape it someplace, or put it on their desk.  Whatever.  But actually seeing the rules written down in front of everyone is important.

Here’s a photograph of a set of rules from a very stressful turn-around project.  If you can see it, the last rule was a fine.  We’d fine people $1.00 if they were late for meetings – these funds were later converted to liquid and consumed by all.

A slightly edited version of our rules are

  1. Neatness doesn’t count; accuracy does
  2. If in doubt, write it on a big piece of paper
  3. Bad news is good; good news is great!
  4. Truth is permitted
  5. Keep your charts / status up to date at all times
  6. Don’t roll over or give up
  7. Read the charts!
  8. Stay focused
  9. All meetings are held here – on time!

Shout Them Out

We shout these out if someone violates a rule.  For instance, our mathematician might say: “Whatever… I can do what you want, if you really want to do it that way.”  Everyone will shout out “RULE 6 VIOLATION!”  as loud as possible.   I must admit, I’ve been called out for “rule 8 violation” several times…

Rule number 4 sounds odd.  “The truth is permitted.”  This means that team members can say things you wouldn’t normally hear in meetings. “I’m late getting that done.”  Or, “This is never going to work.”  “Our solution is awful!” The only correct answer from the team for someone speaking to Rule 4 is “THANK YOU.”   Then, the team starts working on solving whatever issue just came up. 

There’s harmless humor in every situation

In any project, epically difficult ones – humor helps.  I’d like to refine this a bit to say “harmless humor.”  One fellow on our team was late for a meeting and arrived sweaty.  He promptly took off his tie and threw it on the floor.  “What’s wrong with you?”  It turned out he was shredding papers and got his tie caught in the shredder – while he reached everywhere to find an off switch.  From that day on, we awarded the tie to people for “lack of attention to detail.”  Later, the goat tie tack was added for an extra honor.   Everyone loves it.  Except perhaps the prize winner.

Mindreading doesn’t work

This one is pretty simple.  If you think the rest of the team should hear it – SAY IT.  It’s surprising how often teammates (who speak a different technical language) assume the rest of the team knows what they’re thinking.

Continual Questions

Part of the project leader’s job is to dig in to find problems.   The problems are then scheduled for “demolition.”  To find problems, we always, always ask the following questions

  • What would ruin your plans?
    • Make me cry!  Make me very, very sad.
    • (Or, bad news is good)

Whatever it that makes the Project team cry must be dealt with.  The worse it the problem is – the better we like it, so “bad news is good.”

  • Are we fooling ourselves?
    • Maybe we’re all just agreeing
    • (Group think)

Another favorite question, after all is  settled and we’re ready to move onto doing “work” as opposed to “meeting” is “are we fooling ourselves?”  “Are we drinking our own bathwater?” This is a conscious effort to avoid the DEADLY enemy of group think.  Nearly nothing is worse for a team than “group think.”  There are many examples, many documents, many books on the topic.  But, from personal experience I can tell you – it can KILL.





Posted by David Maynard on: September 21, 2016 04:06 PM | Permalink | Comments (8)

I hate asking for change. They always make a face. It's like asking them to donate a kidney.

- George Costanza