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
Laura Samsó
Cheryl Lee
Emily Luijbregts
Karen Chovan
Sarah Mersereau
Nic Jain
Lawrence Cooper
Yves Cavarec
David Davis
Fabio Rigamonti
Gina Abudi
Kristin Jones
Michelle Stronach
Nadia Vincent

Recent Posts

Interview to Thomas Walenta, PMI Board of Directors

What from PMI Global Conference will you put to work this week?

What I've learnt at #PMIcon17

The Agility of PMI

#PMIcon17 - A round up.

#PMIcon17 - Day 2

Today has been a really hectic day but it's been a really exciting day of listening to some great Project Managers and coaching them to a solution. One the best things about being part of the "Ask the Expert" group is being able to see so many different personalities and with such a different array of problems that they need help with. Here's a quick summary from today:

  • Dan: He's working in a government environment that has very limited project management skills and wants to help his organization implement better project management processes. We spoke about how he could sell this to his stakeholders and some pitfalls that he needed to be aware of. He's the only PMP in his organization and is trying to make the case for having his colleagues become PMP certified.
  • Sally: She was a technical project manager who was trying to transition into a Scrum Master. She was getting her certification but just didn't know where to start! How do you start being agile when you're struggling to see where to begin! We went through the initial processes that she could start with and additionally what she needed to NOT do. We then spoke about some of the issues that she's having in transitioning and what she's able to control in her transition.
  • Thomas: Thomas needed some career advice. He's a highly academic individual who works in a company that will not allow him to progress or develop. There's limited opportunity for him to develop and despite repeated requests to his managers, there's been no support or acknowledgement. We went through his options and how he can make himself more employable. We also discussed the various opportunities that networking with his local PMI chapter could provide.
  • Ruth: I spent an hour talking with Ruth about what she can do to 'find the love' in Project Management. She's been a job that isn't ideal for the past 5 years and the company is fine, the job is fine, but she's not enjoying it. We discussed what she enjoys doing and what she can do moving forward to improve her current situation and working environment. It was great to be able to leave Ruth with a list and plan of things that she can actively do moving forward.
  • Miguel: Miguel was struggling with his agile transformation and has been trying to go through the agile change with his traditional organization. We discussed the steps that he can do to help with the change management that he needs to do.

We've also had a few 'drop ins' on the couch as well which has been really fun to work together in a group and do some group coaching with people. We've spoken about: Closed industries and what you can do to break through, communication issues between cultures, working in a corrupt environment and how to talk to Senior Management.

We're going to be around tomorrow in case you want to drop by!

Posted by Emily Luijbregts on: October 29, 2017 04:59 PM | Permalink | Comments (4)

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)

Maybe you need to help your people Make a Diffference

On Monday through Wednesday of this week I was teaching our PMI-ACP course in Toronto. Over the three days, as we walked among the different frameworks, methods and practices that are part of the course, a common theme started to emerge among the participants.

While the students could see the clear benefits of each framework, method or practice, they also began to recognize the challenges they faced in being successful at applying them in their organizations; Organizations that still operate under traditional management approaches.

Some of the more obvious challenge areas noted included:

  • Finance – budgeting processes would still be based on the big upfront estimates that cover multiple planning years.
    • Traditional cost accounting operates over long time horizons.  
    • The budgeting process focuses on controlling variances over focusing on what may be the right thing to do  
    • Operating and capital expenses are segregated; Often  times this I fairly arbitrary to order to meet prescribed percentages of what should be in each
    • Audit is focused on looking for the “smoking gun” rather than working with teams to avoid the smoking gun in the first place
  • Procurement – the current RFP processes rely on being prescriptive and transferring most of the risk to the vendors
    • Vendors bid to win and then use the Change Request process which often drives final costs to be two-to-three times the original bid price
  • HR – existing HR policies are primarily based on hiring to skill rather than hiring to behaviour and compensation policies are reward individual rather than team achievement
    • People are called  resources, assets and capital as if they are interchangeable like furniture and computers
    • Competition is valued over contribution to value creation
  • Executive level – see this “agile thing” as just an IT team level thing that will somehow increase the productivity of these groups but has no bearing on how their level of the organization

It is interesting to me that organizations are willing to invest in having their people learn about more agile ways of thinking and working, while they somehow believe that outside of these teams (usually within IT), that it’s OK to keep doing what they’ve always done.

The people who show up for these classes do want to do things differently because they genuinely want to make a difference. They recognize the folly of continuing to use outmoded ways of thinking that rely on prescription in an increasingly chaotic and complex world.

Yet here they are. In a class that will validate what they already have come to know about why things don’t work. Where they will learn some new ways of thinking and some new ways of working that offer the possibility of handling the complexity and chaos they know their organizations face.  

And now they have to go back to organizations that, outside of the teams that these people belong to, want to keep doing what they have always done.

The IT industry and those in the agile space have tended to focus on the team-level with their educational thrusts. There is nothing wrong with that. However, it does leave the part of  every organization that can actually make the real difference in meeting the complexity and chaos challenges to pretend that agile is a IT-team thingy. It isn’t. It’s an everyone in the organizational thingy – and that starts at the top.

Are you a leader in an organization where your teams are learning about and/or starting to use agile approaches? Do you  recognize the crucial role you will play in how successful or not these teams will be? Do you realize that in order for them to make a difference, that you will also need to make a difference by eliminating challenges such as those above?

In our course on Adaptive Leadership we refer to that part of leadership your need to be the CSR (Chief S**t Remover). Whatever impedes your teams' ability to help you achieve organizational and business agility needs to be removed. As a leader are you up to being a CSR?

If you’d like to talk strategic intent, adaptive strategy, back-casting over forecasting, outcomes over outputs, any of the agilities, or pretty much anything you think I may be able to help you with in making a difference in your world, here is my availability during the conference:

  • Saturday the 28th from 1:30 to 4:30
  • Sunday the 29th from 3:00 to 5:00
  • Monday the 30th from 9:00 to 12:00

You can also connect with me at:

Posted by Lawrence Cooper on: October 26, 2017 10:49 AM | Permalink | Comments (3)

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)

Agile NASA software? Are you Crazy?

Going to the 2017 PMI Global Conference in Chicago?  

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

NASA JSC Engineering

Isn't NASA the epitome of the double-cursed WATERFALL technique?

Wrong NASA was agile before agile was a common term.  As a matter of fact, One of the 17 original authors of the agile manifesto -- Jim Highsmith used to work at NASA.   The question that NASA asked itself was: “How can we, the space ops community, adopt state-of-the-art software development practices, achieve greater productivity and lower cost, and maintain safe and effective flight operations?”

NASA Ames, together with my old “home” JSC (Houston) and JPL are developing “Mission Control Technologies (MCT) software in an integrated agile environment --- with modifications necessary because of human life and safety factors (in a *very* harsh environment).

Traditional requirements processes and documentation was replaced with a team design process which included the customer, design experts and paper prototypes. (Sorry Systems Engineering).  Iterations were delivered to the customers every three weeks with a full release every three month (Sound like NASA-Agile now?) 

Nightly builds were made available to facilitate customer feedback on the team’s progress.  This effort replaces the traditional intensive NASA documentation and reviews with ongoing interactions.  Technical documentation is maintained on a team Wiki which everyone has access to and can contribute to.

Why do this? 

To shorten the delivery cycle, break large software development efforts into smaller more easily manageable pieces. To facilitate direct interaction between the developers and the users.  And to produce a download daily so users always have the means to access the latest version of the code.

Replaced Predictions with Actuals.

Progress is measured by the state of the code, rather than estimations and presentations.  For the MCT this takes three forms.  First, the nightly build, second are the iterations (every three weeks) typically installed in a Mission Control test facility.  And after four iterations the software is released for operational mission control certification.

Manageable Deliveries

With a longer delivery cycle, the more the code, the greater the complexity and the larger number of tests that must be conducted.  A longer cycle means more time from specification of function to delivery.  The greater the time from specification to use, the greater the room for error between user expectation and the software product.  Using a shorter cycle reduces the number of new features and possible regressions.  Agile may not reduce the total number of tests, but it distributes them over time, making it a more manageable effort.

Development Team / Customer Interaction

With a short delivery cycle, the availability of working code for evaluation and feedback, makes it possible to have closely coupled interactions between the development team and the customer.  The developer-customer interaction is very useful to verify new features as they are rolled out.

Fast Response to Change

The shorter development cycle allows the team to better respond to changes.  The software is rolled out in stages, the users respond then the development team can act on this feedback. 


Next time: NASA Agile: Delivery Cycles. 

Reference: American Inst. of Aeronautics and Astronautics; Reston, VA, United States; Agile Development Methods for Space Operations Jay Trimble Nasa Ames Research Center Mountain View CA and Chris Webster University of California Santa Cruz, Nasa Ames Research Center, Mountain View, CA

Posted by David Maynard on: October 18, 2017 02:00 PM | Permalink | Comments (13)

"If you must play, decide on three things at the start: the rules of the game, the stakes and the quitting time."

- Chinese Proverb