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

RSS

View Posts By:

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

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.

What I've learnt at #PMIcon17

 

 

 

 

 

 

 

It's been a week since #PMIcon17 started and it's been a time to reflect on a few things that were really visible to me during the conference that I think is valuable to share with the wider community.

  1. Volunteering: A really valuable way to connect with others and give back to the community is through Volunteering. Either with your local chapter or with other professional organisations.
  2. Talent Management: It's vitally important to understand your own worth in your organisation and also as a Project Manager. Make sure that you understand what you're worth and also where you can still develop as a Project Manager.
  3. Innovation: Be innovative, be a 'bar raiser', 'thought provoker', 'change maker' and be this not just for one day, but constantly. Analyse what you're doing and what you can do better. What can your organisation do better? Are you thinking about how Project Management could be better?
  4. Collaboration: As Project Managers we can be stronger within the community if we collaborate together to give more knowledge to each other. Are you collaborating enough?
  5. Generational Project Management: Project Managers seem to have a longer more valuable shelf life than other industries and roles. During the conference, there was a great combination of younger Project Managers just starting their career with other more seasoned Project Managers who had so much knowledge and information to share. As an organisation and industry we need to be aware of this and work on sharing this knowledge together.

Personally, I felt that the Conference not only highlighted the opportunities that we have as Project Managers to learn and develop as stronger Project Managers but also showing the possibilities that are available in the PM world to contribute and grow.

What next?

Where will I be going from now? I'll be continuing to connect with everyone that I met to make sure that we can continue collaborating and sharing knowledge. I'll also be making sure that my 'contribution' to the Project Management industry remains involved, active and giving back just as much as I have been learning!

What will your contribution be? How can we collaborate together?

Posted by Emily Luijbregts on: November 04, 2017 10:24 AM | Permalink | Comments (7)

#PMIcon17 - A round up.

I've finally arrived back in the Netherlands and it's been a whirlwind few days! I consider the "Ask the Expert" sessions to really be so beneficial to the wider community as well as the individuals involved. I wanted to provide a summary of the main things that really struck me over the weekend and some final thoughts about the conference.

Key elements:

This years session really had a few stand out areas of conversation:

  • Career advice: A lot of people wanted to talk to us for career advice as well as knowing where to go next or issues that they had in their career
  • Growth plans/ development: This was a really hot topic for a lot of people. They were struggling to know how to establish a development plan and knowing what they really wanted from their career.
  • Transitioning to a Scrum Master/working in an agile environment: This came from several people who weren't sure where to start or where to go in their agile career. There seems to be a gap between when you have your training and when you really start using agile in your daily career.

Key areas of advice given:

  • Your value: Spend some time understanding who you are, what talents you have and more importantly, what you want to do in your career. Then make any move that you want to make
  • Investigate! Research your local job market, look at the area that you're in and see what's available and open to you. Reach out to some recruiters in your area and see what's available.
  • PMI Chapters: Look at your local PMI Chapter and see what they can do to help. Network with your other Project Management colleagues and see what opportunities you can get from them.
  • Talk to your HR: Ask them what's available for you at your company and tell them what/ where you want to go.

Looking forward at your career and path is the most important thing that you can do for your professional development. You need to understand and analyse within yourself what you want to do and what's important for you. 

Did you attend #PMIcon17 and did you enjoy it? Did you come to the Ask the Expert area? 

Posted by Emily Luijbregts on: November 01, 2017 05:15 PM | Permalink | Comments (7)

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)

So Hard to Communicate

I saw this potshots comic today and liked it, so I'm sharing it.

Why do many people (myself included) find it so hard to communicate?  I actually find it pretty easy to broadcast (as you can see from my posts), but true interactive communication is difficult.  I'm not sure if it's the risk of exposing my feelings, if its a disconnect of values with the person I'm communicating with, if it's my attitude, or if I just don't add anything of value to the person I'm communicating with.  Or is could be I'm just overthinking everything :)

Regardless, I frequently challenge my own ability to communicate.  Granted, I thought I was a good communicator until I had children, but I found that what I thought I communicated clearly, was not received clearly.

My path to green for this is to keep on trying,  Use active listening and watch for body language signs, paraphrasing back what the person said, and accept that I don't have to respond to everything said to me.  I can acknowledge with a smile or the nodding of my head.

Anybody else find communication more difficult that it should be?

Get your most burning project management questions answered in “Ask the Experts” at PMI Global Conference.  Sign up for a specific time at: http://www.signupgenius.com/go/4090c44a9ad23a7fb6-askthe5 or just stop by.

Times Dave is scheduled for:

Saturday October 28:  3:00PM -  4:30 PM

Sunday October 29: 10:00  11:50 AM, 3:00 5:00 PM

Monday October 30:  1:00 – 2:30 PM

David L. Davis PMP, PgMP, PBA

Senior Project Manager OhioHealth

dldavispmp@gmail.com

Posted by David Davis on: October 16, 2017 09:13 AM | Permalink | Comments (10)

PM War Stories - Communications Confusion over words

I wanted to share a recent event that is in line with our communication war stories topic. Over the last couple of days, my team has been trying to work a project and secure some critical data that is hard to get. Our different teams were tripping over each other trying to understand what we were doing. Here is our situation: My company qualifies customers for services on estimated guesses. After the customer is installed and using the services, my company now gets real data and knows how well a customer can use a service and what additional services and speeds for which a customer can qualify. What we needed was the original qualification (the promise given to the customer), not what the actual data after the install says. We were using words like original loop qual, loop qual at point of sale, service promise, estimated loop qual, and calculated qualification. Impact: This part of the project was in confusion and getting no where. Subsequent analysis dependent upon this data downstream could not proceed. This data was on the critical path. If the wrong data is pulled, we come up with the wrong conclusions or have to restart the data pull. Then, the project gets delayed or is implemented poorly. Next steps and results: We had to get everyone on the phone and clear up the confusion immediately. Next, we had to clearly define what the actual ask is for that data. Last, we memorialized that definition so that there was no more confusion. Sounded like a lot of work, but it was absolutely necessary. Did we do it right? Was there something else we should have done?
Posted by Marcos Arias on: October 23, 2014 02:55 PM | Permalink | Comments (5)
ADVERTISEMENTS

"When I have a kid, I wanna put him in one of those strollers for twins, then run around the mall looking frantic."

- Steven Wright

ADVERTISEMENT

Sponsors