Project Management

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
Dan Furlong
David Maynard
Marjorie Anderson
Fabio Rigamonti
Emily Luijbregts
Priya Patra
Karthik Ramamurthy
Stephanie Jaeger
Moritz Sprenger
Kimberly Whitby
Laura Schofield
David Davis
Drew Craig
Lorelie Kaid
Kiron Bondale
Heather McLarnon
Brantlee Underhill
Michelle Brown

Past Contributors:

Deepa Bhide
Chris DiBella
Nic Jain
Karen Chovan
Jack Duggal
Catalin Dogaru
Te Wu
Jamie Champagne
Esra Tepeli
Randall Englund
Kristy Tan Neckowicz
Sandra MacGillivray
Gina Abudi
Sarah Mersereau
Lawrence Cooper
Bruce Gay
Michel Thiry
Heather van Wyk
Barbara Trautlein
Steve Salisbury
Yves Cavarec
Benjamin C. Anyacho
Nadia Vincent
Carlos Javier Pampliega García
Norma Lynch
Michelle Stronach
Sydni Neptune
Laura Samsó
Marcos Arias
Cheryl Lee
Kristin Jones
Jeannette Cabanis-Brewin
Annmarie Curley

Recent Posts

The PMI Virtual Experience Series Delivers You a Roadmap to Success

Striving for Inclusivity? Agile Can Help!

What Our Attendees Asked: Questions About Everything from Pure Agile to Waterfall (and Hybrid!)

Presentation Recap: Make It Safe to Think Different

Presentation Recap: Conversational Intelligence Software Will Boost Meeting Productivity

Viewing Posts by Marcos Arias

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)

Another Project Management Communication War Story


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??? 

Posted by Marcos Arias on: September 29, 2014 01:28 PM | Permalink | Comments (9)

Getting Excited for PMI Congress

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 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.  

Posted by Marcos Arias on: September 16, 2014 08:01 PM | Permalink | Comments (1)

"Wise men talk because they have something to say; fools, because they have to say something."

- Plato