Charlie was a Business Analyst. He pissed off the Project Manager of the project he was working on. Read his story and see what he did wrong. Was he the only one to blame?
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 he decided to bring 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 Project Manager needs timely information from the BA.
Top-notch Business Analysts:
- 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 Business Analysists 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.
- Project Managers need to give firm estimates and implementation dates.
- Successful Project Managers 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?
Want to learn more?
Below is a selection of resources that I personally feel are relevant to this blog post, and will allow you to get more in-depth knowledge. I do earn a commission if you purchase any of these, and for that I am grateful. Thank you. (Important Disclosure)
Also – read “A look at “A Navigator to Business Analysis”“
Yes, maybe the BA should have informed the PM, but the PM should probably have made it clear to the BA from the start what the budget was. And if taking a couple of extra colleagues along to an initial requirements meeting blew the budget then the budget is ridiculously inadequate. PMs have an obsession with budgets and dates and not enough focus on quality. If anything, the BA’s main crime here is not fighting his corner strongly enough.
Excellent input Dominic. This blog post is also been discussed quite a bit on LinkedIn, and the general feeling is, indeed, that the budget was not flexible enough, but also that communication is a to-way thing. There should have been better communication not just from the BA -> PM, but also the other way round (as you allude to).
Well, as usual, communication is a key, and just like BA should have talked to PM about involving other resources, PM should have discussed with BA if his expertise will be enough and whether or not other resources might be needed. After all, it is PMs responsibility to make proper cost and labor estimates and this work should not be performed in a vacuum.
I understand how awkward it is to go back and ask for more money once the budget is approved, but on the other hand, it’s better to spend more where it is needed and actually finish the project, rather than create something that doesn’t work well because we desperately try to stay within budget and lack the expertise to properly establish functional requirements and design the right solution. So, as inconvenient as this BA’s actions might be for PM and the client, he might have just saved the project….
Galina – good insight. So you feel that Charlie’s action might have actually led to a better outcome. What do you feel about the idea that, if Charlie hadn’t taken this course of action, the outcome wouldn’t have been as good, but would have been … acceptable?