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? |
Another Project Management Communication War Story
| All, 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??? |
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 roles...one 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. |
