Sometimes Business analysts tease Project Managers, we joke that we are more important than they are. In a meeting with a group of BAs last week I was reminded of how much we need PMs!!
Analysis paralysis! We joke about it but it is a real problem. Most BAs can get stuck in details whether they like to admit it or not. We love to analyze and we get into so much detail that we forget that we have to actually get something done. I am reminded of a Calculus professor in college – the absent minded professor who would forget that our class hour was over because he was so enjoying calculating derivatives on the blackboard. We model and we define terms and we "what if" and we get completely lost in our fascinating world of ideas. We need someone to pull us back up out of the weeds and force us to take that first step in the direction of the finish line.
Not only do we get lost in details, we can't stay within scope. Everyone always blames the business people for scope creep but let's be honest, BAs wander outside the scope of the project as much as anyone. We start thinking about how we could help fix another business area or we get an idea for how we could help the business sell more products or offer a new product or . . . . Where does it end?? It ends when our Project Manager reminds us that we need to stay focused on the requirements inside our scope and we should get just the details that we absolutely need to move forward. We tend to be perfectionists but we usually don't have time to get every single requirement perfectly so we need to prioritize, get the most important details and move forward. Get something done.
So I say to all of you Project Managers – thank you and keep doing what you do best: keep us on track and focused, reminding us that although we can't do everything perfectly, we are doing a very good job!
5 Comments
Point well taken, but what if our duties include both project management and business analysis? I find I have to set deadlines and scope for myself in order to get things done on time. But it definitely would be easier with someone else taking care of that stuff.
While it is good to have project managers to take care of this, one thing that I always tell people is to time-box themselves. Usually, we all scope box, but time boxing is the key. On large teams a project manager may not have visibility into who is slow (or paralyzed). In such big projects the PM is usually too busy managing the outward relationship. So, comes in the Iteration Manager on who’s typically responsible to manage an iteration and to ensure that the team keeps marching ahead.
Barbara, I agree with you about scope creep and BAs being sometimes the cause of it
– no offense to other BAs out there. I know I have been guilty of it many times, then was brought back to reality. I like to imagine things and sometimes I get stuck in my "what if" as you said. And it is much easier for the two hats to be different people instead of one person as in the case of Tom. Tom, I salute you!!!! You are not the only one though, and before the BA role was recognized, many project managers were doing just that. And even sometimes without the techniques, they were able to get some decent requirements and sometimes to a good level of detail. However, I believe that also contributed to lots of project failure (hope not in your case). Having one person decide when how much detail is needed and when it's enough detail is very scary. There is no accountability! How do you know it's enough if you already set the date of when you should finish? I hope no one has developped a double personality because of this delimma. You will basically have to stop yourself and have one side of you wanting to dig deeper and the other side saying: "when are you going to be done?" or "no that's too much, you can stop now."
LOL Barbara. I have written a few posts myself on why ONLY NOT to blame the project manager for a project failure. The PM depends on the BA a lot. I think the problem arises that most BAs come from the technology side of things – and as any developer can attest (no – i do not think they will admit to it), they tend to be perfectionists. What I mean is they cannot let working things be – they have to go back and redo it to make it better. This approach has its pros and cons depending on the situation. But take a BA with business experience, and you are not likely to see the above scenario. This is my theory. If someone can validate it, it will be great. The reason I can say this is I am BA, who has never professionally coded – but come from the business side of things. I understand the project constraints and know that it will never be 100% perfect. But if a requirement meets 80-90% of the needs, lets code. We will improve on it in future iterations. Tom, for medium to large projects I really think the two roles must be performed by different people. There is just not enough time in the day to do both these roles. I have written a post on this as well – "do you need a project manager and a business analyst?"
Having risen thru the ranks as a BA to Project Manager and now as a Program Director, I know that the BA and PM need each other.
Simply, the two main resons why projects fail (as identified by numerous studies) is because of poor requirements and poor scope handling. The BA is the main person on a team responsible for requirements and the PM is the main person responsible for scope management. Without them both on a project, you are building a foundation on a house of cards.
I recently inteviewed with a COO, who was a former CIO, of a Fortune 50 company who told me that he wanted to eliminate BAs and PMs from smaller software development projects. His justification was simple; he wanted to cut costs. BAs ad PMs on every project is expensive. But, he nevered considered the cost of re-work is much more expensive – it’s the Cost of Poor Quality.
Keep using this CoPQ arguement and drumming into the minds of your managers. It is the basis of modern quality theory. Quality is free – the cost of poor quality is inspections that developers do and QA does, re-work in the form of recoding and bug-fixes, and the iterative code-test-debug-retest cycyle.
Tom, for all projects, the two roles must be performed by different people. The only reason it is not is for cost. But, the risk of outright project failure or small amounts of rework is not being considered by your management. They have this concept “there is never enough time to do it right the first time, but plenty of time to fix after screwing it up”. The modern quality principle is “Do it right the first time”!
The best way to do it right the first time is to have the best team together – a BA and a PM have to be on all (but the smallest and simplest) teams. Their respective roles are vital and should not be combined.