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
Dan Furlong
Marjorie Anderson
Emily Luijbregts
Priya Patra
David Maynard
Fabio Rigamonti
Moritz Sprenger
Karthik Ramamurthy
Andrew Craig
David Davis
Kimberly Whitby
Lorelie Kaid
Laura Schofield
Stephanie Jaeger
LORI WILSON
Kiron Bondale

Past Contributers:

Deepa Bhide
Nic Jain
Karen Chovan
Jack Duggal
Catalin Dogaru
Kristy Tan Neckowicz
Sandra MacGillivray
Gina Abudi
Sarah Mersereau
Lawrence Cooper
Yves Cavarec
Nadia Vincent
Carlos Javier Pampliega García
Michelle Stronach
Laura Samsó
Marcos Arias
Cheryl Lee
Kristin Jones

Recent Posts

Crowd Sourced Inspiration

My parting thoughts on PMI's 50th anniversary Global Conference

My impressions from day one of "Ask an Expert" at #PMIcon19

Ask The Experts -- at the global conference

What Does an Invitation to the ‘Ask the Expert’ Panel Mean to Me? #PMIcon19 #Inspiration

Serious Gamification, the power of 3Ps in an Agile world, RPA, and TED Talks at #PMIEMEA19 Day 3

What a last day at the PMI EMEA Congress 2019. The last two days have been packed and I am somewhat exhausted due to information overload. But there is still room for another full day of promising sessions and hopefully inspiring TED Talks.


After a very large and strong coffee I was energized for the morning session with Erik Agudelo. Erik provided some insights on his research on transformation projects: “50% of large organisational transformation projects fail. One reason is poor collaboration between small and medium sized projects in a company that are not visible to large and well-structured projects. The smaller unstructured and invisible projects can undermine, diminish, and oppose large-scale change initiatives”. These results led him to develop serious training and coaching games to better simulate the challenges of project collaboration.

 Thank you Erik for all the practical examples and the fun and interactive session. You transfer passion for what you do, and this really engaged the audience.


I will remember the second session for a very long time and will certainly address the key take-aways in my own organisation. Nicholas Clemens is training governmental officials to be able to manage multi-billion dollar projects.

 

“PMI can take credit for one of the most important element in supporting the profession: developing a worldwide acknowledged standardised vocabulary for project, programme, and portfolio management.” Nicholas now urges PMI to standardise terminology for agile practices beyond the small task group level. Agile will and does transform the way organisations manage the 3Ps. During his session he checked how the four prominent agile methodologies cover the 4 levels of organisational governance (Scrum@Scale ®; Large-Scaled Scrum (LeSS®); Scaled Agile Framework (SAFe®); Disciplined Agile (DA)).

A top take-away of that very interesting session: Check on what level you operate and tailor your approach within the 3Ps, apply focused agile processes where best suited, and avoid the baggage (overhead).

 

At lunch I met Miranda, a project manager from the states with a very difficult but rewarding challenge: To develop a PMO for a university online library. Great to hear that she will visit my home town Hamburg for a conference next month.


The third session raised the highest amount of questions from the audience, as it is something that affects all project managers: Robotic Automation of Project Processes and its effect on the PMO. Robert Allen and Rhys Lancaster provided a good testimony on how they have transformed their customer facing PMO. “We have made the decision to invest in a really flexible platform, on which we are able to quickly and without much coding effort automate processes through effective machine learning.” However, they pointed out three very important pre-requisites: You need to have structured and quality data, you need to have very mature processes, and the more repetitive they are, the more value you can create by automating them.


And finally: TED Talks!

The three talks I were able to attend were astonishing. They inspired me to change the perspective, become realistic about the world we live and work in, accept this world, and from this new stance: Make the world better for me and everyone around me one step at a time. Nothing is impossible: Mark Pollock’s story is incredible - he became paralysed and now is fighting together with his wife to cure paralysation within his lifetime. Accepting the circumstances and being realistic about the probability of success he fights a new fight everyday – and is again enjoying life.


All in all, it was a great experience. I have a learned so much from fellow project managers and speakers. I will go back to work with a long bucket list of things I need to address.

Thanks to Kristin, Emily, Stephanie, and Karthik for their correspondence and support during the three days.

I will hopefully see you all soon.

Posted by Moritz Sprenger on: May 16, 2019 07:30 AM | Permalink | Comments (7)

Think-Feel-Act, Design Thinking, Governance, AI in PM, and the importance of Sponsorship at #PMIEMEA19 - Day 1

What a first day at the PMI EMEA Congress 2019. A single blog post won’t suffice to cover all the learnings of one day. I chose to pick out some of the key points that stuck in my head of each session I attended – so here it is:

“Most of people define themselves through what we actually do: I am a Project Manager, I am a Fire Fighter, I am a School Teacher. Also, most organisations define themselves through what they sell, and not what customer values.” Jamil Qureshi told the story of a Fire Fighter, who, given the question what he did for a living, said: “I let the future take place, I build communities”. He believes that if he saves a family or a house from a fire, that family can live happy lives and the house will remain to exist. The firefighter defines himself through what he thinks and feels, rather than what he actually does, namely fighting fire.

 

Jamil made an important point: It is all about perspective. We are drawn to our most dominant thoughts and feelings. If we change the way we think and feel about something, we can change the way we act.

 

 

Denis Vukosav is a passionate project manager from the banking industry. That industry may not be known specifically for their ability to deploy Design Thinking and Agile methods in their projects, but Denis is challenging this: “When Design Thinking and Agile methods merge, you can combine best of both worlds. Design Thinking devotes an entire process step to developing customer empathy, which is often minimized within the agile framework for the benefits of speed.” You can make your projects become more successful by incorporating the needs of the customer with design thinking early on in your projects.

 

Denis continues to investigate how Design Thinking will enrich project management processes and will talk again at the global Congress in September. 

 

Michael Knapp presented his research findings from a study on the importance of governance in 3P (Portfolio, Programme, Project Management) in managing innovation in organisations. “One common mistake management and project managers often do is confusing governance and management. Management is about the execution of tasks and processes. Governance is about decision-making.  Today, we have good standards and processes defined for the execution, and research shows, there are very little standards and processes on Governance in organisations.” The lack of maturity and metrics in governance can often lead to barriers to manage innovation effectively. If a project manager experiences the following barriers, there is a high chance that these symptoms are the result of a lack of governance maturity: Under-funding, culture clashes, sclerosis, politics and poor alignment, lack of strategy and vision, and lack of executive commitment.

 

“The best thing you can do as a project manager working in innovation is to grab management and sponsors and drag them down to the shop floor where the action takes place basis”, said Michael. This will make them start to rethink their commitment.

 

 

What will the future of work look like for a project manager? The next session I attended was organized as a panel discussion formed by three industry leaders in their field of expertise (project management). Hilary Baker from Airbus, Jim Robinson from the Ministry of Defence UK, and Dieter Butz from Bosch.

 

“Knowledge management, empathy, and anticipation are probably the key competences that distinguishes a good project manager from any future AI-driven tool in the profession”, says Hilary. Jim adds, that: “Hard project management skills such as scheduling, risk management, planning, and reporting the right information may become less manual, but need to be understood by a PM”. “Role perceptions will constantly change, and we need to change with the changing needs of the organisation to stay competitive, as an organisation, and as an individual”, concludes Dieter.

 

The gist of the talk for me: Now is the time to rethink standard role models in a project in order to shape the profession in 2030. AI will support, but cannot compete with the human intuition, passion, and creativity of a project manager.

 

 

Olivier Lazar, one of the very few people in the world holding each PMI certification, made an inspiring talk about the role and the need of the sponsor in a project.

 

“41% of projects fail because there is a lack of sponsorship”. Especially in Change Management the role of the sponsor is inevitable. The project manager does not have the credibility to effectively sponsor change and convince negative influential stakeholders.

 

Furthermore, he stresses a vital point: “The project charter is a contract between the organisation, the sponsor, and the project manager. It is the accountability of the sponsor to write and own the project charter”. This is sometimes forgotten. Olivier reminds us that the Initiation Process Group of the PMBOK 6th is owned by the Sponsor.

 

The sponsor is a tool to the project, a good project manager applies this tool effectively in their projects.

 

 

Now I am looking forward to a great 2nd day.

 

Don't forget to follow my fellow Community Correspondents for updates during PMI EMEA 2019: Emily, Stephanie, and Karthik.

Follow me on Twitter or LinkedIn we will be covering the sessions live so you don’t miss a thing!

Posted by Moritz Sprenger on: May 14, 2019 03:38 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 (7)

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.  

Dave

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

Who's coming to Chicago?

I can’t believe it’s been a year since I had the privilege of attending PMI Global Congress 2016 in San Diego as part of the Ask the Experts cadre. I once again have been afforded the privilege of attending, this time in Chicago from October 28-30, 2017!

The Ask the Experts sessions are designed for attendees like you to have access to your peers in the profession who may have been there, done that, but also more than likely have a few scars to show for it. The point to scars is that while they may hurt at the time of the injury, you tend not to forget their lessons, well most of them anyway.

In the lead up to this year’s event I thought I’d provide a little insight for attendees for who I am (besides the scars side of it), where I came from, where I’ve been, where I’m going, and what drives me. In so doing, I’m hoping that it will resonate with a few of you who will be attending, and that’ll cause you to want to come share a bit about yourself with me. And while doing that, feel free to off-load some of your challenges with me and I’ll see if I can offer some insights that you might find helpful.

So who is Larry anyway?

I was born on a dark and stormy night in the middle of the north Atlantic (closer to reality than you may believe as my house was less than 50 feet from the ocean) on March 5, 1958, in a very small town in Newfoundland, Canada.  I graduated with a B.Sc. in Computer Science in 1977. I started university at 16 and graduated at 19 – it wasn’t because I was that smart, it’s because we only went to grade 11 back then.  Another factoid – the year I started my B.Sc., 1974, was also the year the first graduating class in Computer Science were finishing their degrees at my university! When I turned fifty, my then 5-year old looked up and said (instead of Happy Birthday) “daddy, you’re old!”  So I just saved you the trouble – I’ve been told that already.

I did my entire B.Sc. on punched cards – the PC did not come along until a couple of years after I finished my degree. What’s interesting is that in my first job with the provincial government I did everything – requirements, analysis, design (such as it was), developing, testing and deployments. Sounds a lot like the self-organizing, cross-functional teams in Scrum, doesn’t it? (if one person can be a team, but you get the idea – you had to have multiple competencies).

Starting in the late 1980’s and 1990’s and into the 2000’s I watched the IT industry turn these competencies into roles, and eventually into entire org structures – honestly I never got that, so I mostly ignored It. I was lucky enough to be in small enough size places to get away with ignoring the trend.

Along the way I also picked up an M.A in Public Administration and 20+ industry certifications on project management, Agile and ITIL. That degree is when I had to learn how to write – I was a lousy English student. Then again, I was a lousy software developer too, so lucky for me I learned how to write. So I was clearly not a NASA scientist calibre fellow like David Maynard, another of our gang of experts. But I do have talents – we all do.

We all have those moments that we feel define us in some way. Mine was a little more than a moment – more like three years to be exact.

In the early 1990’s I worked as the Operations Manager for Ice Forecasting Services at Environment Canada in Ottawa as we faced an enormous challenge.

The gist of it is that we would be replacing aircraft that flew around the Arctic and “iceberg alley” off my childhood home of Newfoundland, taking radar images of the ice floes and bergs, with a satellite that would provide full imagery for all of Canada in a single day – 7.5 GB of new data/day in an era when our largest disc drive was 424mb. That was  a lotta data!

This meant a wire-up replacement – networks, all hardware (mini computes, the workstations, etc.), and all of our software. Oh, and we had roughly three years in which to do all of it.

Some things that were pretty obvious pretty quickly:

  • Doing things the way we’d always done was not going to work (e.g. taking twelve to eighteen months to build each application)
  • As our existing technology was no good, we had to figure out possible options, and quickly
  • As our tech was no good, and we couldn’t do what we’d always done, then we’d have to learn new skills and new ways of doing things

Necessity as they say is the mother of invention. We went to see the vendors for hardware and some of the software options that might fit. For example, we wanted four-foot wide screens to display the imagery. The response was, “you guys are about ten years too early” (we heard that a lot).

We decided to go object-oriented for any software we had to build – and none of us knew not an iota of how to code in it. We decided to assemble two small development teams that would remain intact with all the tools they needed. We set targets for having useful things delivered every three to four months. 

We decided to look at what capabilities were common across our applications and build those before we did any application development - we called them Global Services; This was 1992 and a good ten years before Service-Oriented Architecture was a thing. Eighteen months after we had made the decision, the Object Management Group came out with the CORBA Specification and called some of what we had done Common Facilities. Who knew? Once the services were built, we able to rebuild our applications at a rate one per team every 3-5 months.

And in the midst of all that, we also managed to implement automated event and incident management, as well as automated capacity management – also ten years or so before ITIL really became a thing on this side of the pond.  We had to – we only had three system administrators and over 30 servers and a dozen high-end workstations to manage that had limited capacity in a 24x7 operation.

It was the most influential three years in my professional career.

Near the end of the projects we had started, I was asked by Auerbach Publishers in NY to write a couple of chapters for the 1996 edition of their Manager’s Handbook of Local Area Networks (the book talked about almost everything but!) on the design approaches we had used (never did find out how they found me).  That was my introduction to writing beyond project documents.

I left the government after nearly eighteen years in 1995 and went over the private sector as a consultant which I have mostly done since (except for a two year stint as an employee at a telcom company 1999-2001)

My time at Ice had a tremendous influence on everything I did afterwards, especially in how I viewed the project and the software development worlds:

  • Establish the big picture early and then work backwards to figure out where to start
  • Never rely on the past too much to guide how you look at the future
  • Set small goals
  • Assemble small teams, equip them well, and provide whatever support they need to do well
  • Experiment and adjust quickly
  • Always deliver something of value in short increments

(My new friend David from the 2016 congress used a similar approach at NASA before we did it).

As a result of what I learned during that period, I ended up leading teams that applied the same design principles to business process as we did for software design, taking an outcomes-based approach to figure out what we needed to do based on where we wanted to go, creating an  incremental release strategy for what became the world’s largest web-enabled supply chain, and fell almost naturally into an agile way of working before the Manifesto for Agile Software Development was released in 2001 (truth be told, I never came across the Manifesto until 2009).

All of that led me to doing more writing as part of a book series I have labeled The Agility Series (www.TheAgilitySeries.com). You can read more about the series here. The newest book I am working on is called Cultural Agility: Changing our Stories . In fact I’ll be meeting one of my contributing authors to this book for the first time during the conference. Can’t wait!

Besides writing, I am a strategic portfolio executive and trainer, with a decided emphasis on organizational adaptability and agility in all its forms. I am also involved with www.NFPPC.org where we are trying to distill all of the industry frameworks, standards, and methodologies down to their essential WHATs. Why would we do that? Because so many of them overlap with one another and at times create as much confusion as they do clarity. And with all the talk about Agile it would be kind of nice to know which parts of what we already know still has value in helping us do things in a more agile way.

Why do I still work? Besides the obvious reason of having a 15-year old who won’t be leaving home for a while and then has university ahead, it’s because I genuinely like what I do. It’s fun. I have changed careers multiple times within the IT/PM profession over the years. Sometimes out of necessity. Sometimes for fun. I find the more I know, the more I realize how much I really don’t know. It’s fun learning new things and meeting new people and feeling like I am still making a difference.

The feeling of making a difference is a very human emotion. Everyone wants to make a difference and everyone does so in their own way. There also no one way to do that successfully.

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

Oh, and as much as you think we may be able to help you make a difference, I am guessing that by the end of the conference some of you will help us see things differently and change how we make a difference.

So, let’s meet up in Chicago and make a difference together!

             

Posted by Lawrence Cooper on: September 06, 2017 06:41 PM | Permalink | Comments (8)
ADVERTISEMENTS

"I have not failed. I've just found 10,000 ways that won't work."

- Thomas Edison

ADVERTISEMENT

Sponsors