Two Business Analysts are not Necessarily Better than One
More is better right? Especially if you can afford the luxury of having more and paying for more.
Two pizzas are always better than one. More cake – or any dessert for that matter. More lobster, more steak, more money, more cars, more speed, more knowledge…
In many cases – at least on the surface and in general – more is better. Unless your a crazy cat lady. One more cat might be the one that gets you locked up or evicted. But I don’t like cats much anyway.
What about business analysts on a project. Two business analysts on the same project just means more work gets done faster, right? Business analysts out there… is this true? Do you agree? Have you ever been on a project where you were one of two or more business analysts on the same project? Save your thoughts and tell me about it at the end… would really like to hear your experience and especially why there was more than one of you on the same project.
I did have two business analysts on two projects and it wasn’t all that I expected it to be. It actually caused more problems than it solved or avoided so by choice alone I would never do it again unless it was forced on me. And it essentially was those two times. Let’s discuss reasons why this could be bad – and the list does include things that happened to me and my projects when I had multiple business analysts working together or whatever you might call it (against each other ? ) as well as things I have witnessed on other projects….
Customer concerns over who’s really in charge.
Ok, the project manager is in charge. But on many projects, the business analyst is often a primary point of contact for the point person the customer side – especially once the real project starts post kickoff. Management and oversight and primary communication and status comes from the project manager, but in the trenches type information and communication may likely come from the business analyst. With two business analysts, the customer could be concerned or confused over who the main business analyst contact is. I didn’t really experience this, because on both of my situations it was obvious – and discussed early on – which one was senior and which one was junior… which leads to my next potential problem and I did experience this one…
One senior, one junior.
On day one of the project, our PMO director – who was present for the project kickoff session – explained that one business analyst was senior and one was junior and learning from the other. Ugh. This was a horrible thing to admit upfront. The junior business analyst was fully competent and also the one who was always 100% available to the project. The other – more senior business analyst – was stretched too thin across three busy projects at the time including mine. But that doesn’t matter to the client… what they heard was one was good and one was just learning… or that’s what they took from it. From that point on they questioned everything the junior business analyst said or did and insisted the other, more senior business analyst, also review it. What they weren’t told was that he wasn’t that available to do it. Thank you my dear PMO director. He caused me several headaches, and this was one of the biggest ones.
Customer concerned over cost.
Likewise, cost becomes a concern and this is one that I experienced. We stayed on budget because I knew upfront that I had two business analysts and strategically worked the cost and effort into the timeline. But the customer was constantly concerned about costs on the project for one of the two engagements. Thankfully, I was able to show them often and in detail that we were doing fine so by halfway through the project that wasn’t such a problem, but it did take several months to get to that customer comfort level with my management of the BA costs.
Fails on certain or overlapping tasks. This can be an issue as well if tasks aren’t well delegated and the assignment line is blurred. It didn’t happen to me but I watched tasks get dropped on other project managers’ projects in an organization that somewhat frequently assigned two business analysts to the same project. Task assignment and management is key here between the business analysts – so communication between the two BA’s must remain high to keep tasks on track and well covered.
One business analyst gets pulled from the project.
Love this one. Management, for some reason, assigns you two business analysts – mostly for one to learn from the other in most situations – and then because you have an “extra” business analyst who has been built into the schedule, they take them for a new project. And which one they take depends on the new project. If it’s more important or a higher visibility project than yours, they take the senior business analyst. And likewise, if it’s a smaller project and they feel this more junior business analyst is up for it, then they will take him. Either way, your project may be heavily affected if you had enough tasks to go around. Suddenly, you’re left with a big gap in your schedule – either one business analyst who is now way overloaded on tasks or many unassigned tasks that have to be spread across the entire team (or maybe you need another business analyst). The best you can do – especially if you have some tenure or pull in the organization – is fight to get a similar resource added because if you have to slide project deliverables out for this reason your customer is not going to be happy about it. We all know that the likely scenario is that you’re going to have to make do with what you have and both cut corners and move out some deadlines – time to negotiate a little with the client to keep them from being too upset. Think of some reasons to give them to make them maintain confidence and satisfaction levels… look for some pluses to push on them… it won’t be easy so be creative.
Summary / call for input
Two of a good thing is not always a better thing or even a good thing. So that’s my list – what’s yours? Have you ever had or been more than one business analyst on the same project? What happened? Conflicts over tasks? One reviews everything the other did? Did you team up on the tasks and project as a whole or attack entirely separate areas of the project? If you’ve done both, then which was was more effective. Please share and discus.