Understanding the Frustration of a Project Manager


So there he was.

Charlie had been assigned as lead BA on a project with an external client. “Cool” he thought, but still felt a bit nervous. There were others in his department that had been in the game longer, and he was still reeling from having the proverbial  “slap in the face” in an earlier project that had turned slightly pear-shaped.

As such, Charlie decided to ask some of his colleagues for help. They were most forthcoming and decided to hook in other expertise. “All fine,” he thought, “the more experience available in this, the better.” 

Charlie drew up an elicitation plan and scheduled several high-level interviews with the various stakeholders from the upper echelon of the company.

On the agreed upon day, he headed on down to the client. He was joined by another BA (with a different skill-set), and the lead designer. Charlie was confident that, together, they would be able to get a deep understanding of the business objectives, business drivers, and expectations of the client. 

The interviews went extremely well. Because there were the three of them, each with a different background, and understanding, the notes gathered during these sessions were richer, than if Charlie had been on his own. Charlie was really chuffed. “This knowledge and understanding gathered today will be really valuable, not just for understanding the client and their expectations, but also when holding the lower-level elicitation workshops.” Charlie thought to himself. It was all good…

Until he got back. In his enthusiasm, Charlie had not actually thought about telling the Project Manager that there would be three people involved. The PM was furious. The two extra people meant that the man-hours used had just increased by a factor of 3. The project had already gone over budget. Charlie tried to explain that this meant better requirements had been gathered, and that it was going to help in the future, but this didn’t really help. The PM ended up having to have a very uncomfortable meeting with the client, and the project ended up coming in way over budget.

This story was inspired by a post on the ProjectTimes site titled A Business Analyst’s Best Friend: The Project Manager The key points from that post are:

  • The PM wants timely information from the BA.
  • Top-notch BAs
    • keep the PM informed.
    • ask for help when they need it
    • stay connected to other BAs
    • build great relationships with stakeholders,
    • build trust and ease users into changes.
  • Top-notch BAs have a broad vision. They can focus on the detailed requirements, but they understand how their piece of work fits into the larger project and organization at large.
  • PMs need to given firm estimates and implementation dates.
  • Successful PMs deliver projects on time and within budget.

Looking at Charlie’s story, you can see that he did do some things right. He asked for help, he focused on detailed requirements, and he worked hard to see how they fitted into the customer’s larger goals, and objectives.

At the same time, Charlie made some big mistakes. He didn’t keep the PM properly informed. And the consequences of this were quite serious.

What are your thoughts on this? Did Charlie really screw up royally? Or was he actually doing the right thing?

    1. Dominic Miller 11/08/2014
      • markjowen 11/08/2014
    2. Galina 13/08/2014
      • markjowen 13/08/2014

    Add Your Comment