Tuesday, April 15, 2008
Throughout my career, sometimes without realizing it, I played many roles in the IT world. Most of the time I dealt with the multiple roles as just a combined series of tasks that had to be done on small low risk projects. But as my career in the IT field grew, so did my responsibilities and the complexity of the projects I worked on. Sometimes I was the project manager, other times the system architect and other times the developer or tester. It depended on that difficult balance of resources, effort, money, time and quality. When I was told I was the “Project Manager” (PM), I quickly figured out that it involved more than just managing the project. Sometimes it involved me doing the tasks. This slowly became a common problem throughout my career, trying to determine the roles on in the software development lifecycle and who would fill those roles. Didn’t have a body to do the work? I would fill that role. Eventually I became a manager of consultants, auditor of software development projects and seller of IT solutions to clients. So what?
Well, now that I am a Project Management Processional (PMP®) and a Certified Business Analysis Professional (CBAP™) I am deeply involved in transferring my knowledge in both these areas to others in the industry, I have put quite a bit of thought into this historical issue of mine – wearing the multiple hats. Many class participants have also brought up the problem of wearing the multiple hats. In particular, I have found challenges when both the PM and Business Analyst (BA) hat is worn on a single individual. From my experiences, the PM role typically wins out because of the pressures of reacting to project fires, but it is the BA role that can prevent you from falling into the fires in the first place. So, if you are a PM who also plays the BA role, have you considered:
- Clearly defining each role and communicating the tasks by role at first– not by person – to ensure all tasks have been clearly defined and effort estimated (if you don’t ask for the time or money you won’t get it)?
- What the business analysis tasks are in your project plan (throughout the lifecycle) – even if you plan to do them? Allowing time for traceability?
- That a PM focuses on the work and what has to be done to deliver what is expected and the BA focuses on the product or solution and ensures it meets stakeholder expectations once it is delivered?
- That both the PM and BA need to be concerned about tradeoffs throughout the project among the project factors of cost, schedule, quality and scope (both work and product)?
- A BA must communicate requirement risks to the PM. Have you communicated those to yourself – well, I know I am trying to catch a laugh here, but seriously, have you considered these risks in your risk management process and considered different approaches to mitigate requirement risks?
So if you feel you are in this situation, I recommend that you get familiar not only with the Project Management processes (http://www.pmi.org/) but also check out http://www.theiiba.org/ for their next version of the Business Analysis Body of Knowledge (BABOK™). Get familiar with the BA role and Business Analysis work – at least it won’t catch you off-guard!
Article written by: Gina Schwalm, PMP, CBAP, Business Analysis Curricula Practice Owner, TEKsystems Partner via Lighthouse Consulting Partners
A most interesting post Gina. Obviously this vexing problem is common across all kinds of projects. Your comments are interesting and important in that being disciplined in the "switching of hats" is required to avoid conflict. For conflict avoidance, I revert to my process road map. I specialze in mentoring project teams and engineering process for development teams. Whether I select a Unified Process or an Agile Process, I find that I'm never conflicted or lost if I refer to the process. This isn't so much a focus on the prescriptive side of process, but the milestone, or sub-milestone we are focused on in that particular iteration. If I have planned our iteration well, then the whole team, including me in my dual role as business analyst and requirements specifier, should be focused on the iterations goal.
Posted by Joe Butson on Thursday, May 15, 2008
Reply to this Comment »
Please keep your comments relevant to this blog entry. Email addresses are never displayed, but they are required to confirm your comments.