Tuesday, 11 January 2011 13:36

Ups and Downs of a Business Analyst / Project Manager's Journey

Written by 
Rate this item
(0 votes)

Blash_Blog_jan11Today my job title is Project Manager but over the years I have gone from Systems Analyst to Project Manager to Vice President, while in reality nothing seems to have really changed.

After starting my professional career as a high school math teacher, I was hired into the training department for an insurance company.  Having helped my husband with the "automation" of his sales reporting, I was quickly moved into the role of analyst/designer/programmer of a new system to support Insurance Agents.  Over the years my title changed from a Systems Analyst, to a Data Analyst, to a Quality Analyst - depending on the role the software development project required.

Within a few years it became apparent that if I wanted to "move up" in an organization that I would have to take on additional management responsibility, while still being able to utilize my analysis skills on assignments.  Depending on the size of the project, I might be lucky and the project would warrant an analyst as well as a project manager resource.  Otherwise the task assigned would determine the role I would play.  As software development was replaced by packaged software implementations, the analyst role was slowly eliminated.  My choice now was either to take the technical route of a DBA or take on a management role.

Even though I spent many years working on technology-based projects in IT departments within insurance, health care, defense contractor, consumer goods and gaming organizations, I realized that I preferred working with people rather than machines.  I also realized that the technical positions were limited in career paths options, whereas the non-technical IT positions were stepping stones to higher management.

After a few years of climbing the corporate ladder, within a number of organizations, I found myself as a Vice-President of IT with the responsibility of opening a new resort/casino property.  On any single day I would spend my time as an analyst, a project manager, or a member of the executive team.  I discovered through this experience that I would prefer the work of the BA and/or PM rather than the politics required of an executive.  As a result of having reached what many would consider the "top" of a career path, I chose to return to the role of a practitioner, mentoring and training future business analysts and project managers.

BA and PM Roles

Even though the role of a BA has regained acceptance in many companies thanks to organizations such as The IIBA, with the limited resources available today, the BA is often a dual role played by the PM.  This is especially evident on projects with aggressive schedules and limited resources.  When the Statement of Work (SOW) or Scope is being developed, who is responsible for completing the task?  Or maybe a better question -- What role is assigned to the person doing the work - the BA or PM? 

Obviously analytical skills are critical to both roles and this combination has been recognized in Version 4 of the PMBOK through new processes -- Collect Requirements and Identify Stakeholders -- and the expansion of the process Define Scope.  The Stakeholder Register and the Requirements Traceability Matrix are new deliverables that are also the result of the recognition of the Business Analyst role on a project.

With the initial version of the BABOK many discussions, which at times became very heated, were held between BAs and PMs regarding the common processes that were included in both the PMBOK and the BABOK.  These included stakeholder analysis, risk assessment, and planning of activities and communications.  Confusion regarding the planning activities was clarified in version 2.0 to refer only to the planning of BA activities and communications.  The similarity in the processes between the PMBOK and the BABOK is often only able to be resolved at the individual project and/or resource level.

Even though there is an overlap of the two roles as defined in the PMBOK and BABOK, there are a few personal qualities that differentiate the BA and the PM:

  1. The Project Manager aligns closer to typical management positions with the responsibility of managing and tracking the various tasks and resources assigned to the project. Business Analysts are more akin to Independent Contractors, working across organizational boundaries as well as up and down organizational hierarchies.
  2. The Business Analyst is responsible for "drilling down" to elicit detail requirements, while the Project Manager is responsible for staying at a higher level and concentrating on answering questions such as: "What percentage of the work is complete" or "How much longer will it take to complete?" The BA's work is never complete (possibly why the term "analysis paralysis" may have caused the demise of the Systems Analyst of the past) - while the PM continues to try and move the effort forward.
  3. The Business Analyst is often more people-oriented, being more concerned with the requirements of the business stakeholders. The Project Manager is more task-oriented, making sure that the project is completed within the time and budget constraints. The dilemma has always been though, "Is the project a success when it comes in under budget and ahead of schedule but does not meet the expectation of the stakeholders?" And who is really responsible for the ultimate success of a project?

Given these various similarities and differences in the same role, I personally believe that my experience has given me the ability to take on projects as a PM and/or BA that require thinking "outside of the box" and adding tasks and items that are not typically included in the standard project and deliverable templates.  Understanding customer expectations and being able to easily adapt to those require the analysis skills of the BA as well as the management skills of a PM.

Next Step in the Journey

Regardless of the title on a business card, or the management level of a position, the skills acquired through the journey provide the building blocks required to meet the expectations of future assignments.  Maybe progressing "up" the proverbial career path is not as important as doing the job that you consider enjoyable and yet challenging.

Don't forget to leave your comments below.

Read 3197 times Last modified on Tuesday, 27 March 2012 13:46
More in this category: « The Facilitator’s Voice

Comments  

 
0 # Ganesh Ram Anand 2011-01-11 15:37
Hi Blash, Thought provoking article. Even though many articles had been written trying to differentiate the role of BA and PM, this article is unique. Few of my questions to you and would be great if you could post your reply comments which will definitely help others as well. 1. As many organizations are considering cost as major factor, the BA's are considered as overheads and often end up doing the QA tasks in the projects? How do you think we can overcome this scenario? 2. How flexible we should be in a project given the consideration we should not be worrying about the business card title? 3. 100% agreed that we should take up additional responsibility to move up the management role. But, I am not sure what kind of responsibility one should be taking? How to define that? What additional responsibility you can take as a BA if you are working in a enhancement / support project? 4. What
Reply | Reply with quote | Quote
 
 
0 # Cathy Brunsting 2011-01-12 05:47
In my organization (Geneca) we consider the the BA and PM roles to be distinct but both essential to the success of the project. The BA is accountable for ensuring that we are delivering the right solution (meeting the expecations of the stakeholders) while the PM is accountable for ensuring that we are delivering the project right (all team members are meeting their committments). We also consider the Architect to be essential to project success - accountable for ensuring that the development team is delivering the correct technical solution. I believe that no project can be considered successful if it does not meet the expectations of the stakeholders, regardless of when the project is delivered. This includes their expectations in regards to how the solution works, as well as time and budget expectations. With key team members accountable for different aspects of the project, you can build a strong project leadership team who working together insure that the project is successful on all levels. In regards to GRV's comments - I think that having BAs participate in QA (or UAT) activities is not necessarily a bad thing. On smaller projects, this can part of the over all accountability for ensuring that we are delivering a project that meets the stakeholders expectations. On larger projects, I believe that dedicated QA personnel are essential to ensure that a quality product is delivered, but still believe that the BA should play a significant role is supporting the QA process to ensure that the solution is as expected. Ulti mately the entire team is responsible for ensuring that they are delivering the best possible solution within the time and budget constraints of the project.
Reply | Reply with quote | Quote
 
 
0 # Ganesh Ram Anand 2011-01-12 20:31
Hi Cathy, Thanks for your comments. It's insightful. Ho wever, I am still not sure how a business analyst should be utilized in the case of production support and maintenance projects? Can you throw some light on this? Others, please contribute as well.
Reply | Reply with quote | Quote
 
 
0 # Bennett Mendes 2011-01-13 02:34
Production support is generally the domain of the Technical staff ie. make sure the systems are humming smoothly. If anything goes wrong, it's generally a technical person required to fix. Now, having said that, when something goes into production, there may be feedback from the user community that certain features are not panning out in the real business world. I've seen this happen many times and the ball gets thrown back into the BA court. Sometimes this may take months or even a year to emerge. WRT to maintenance projects, the BA has to be involved as long as there is a business component. There may be a meeting of techies and management debating an issue and the BA stays quiet most of the meeting, then chimes in with a key nugget of info that alerts everyone to re-think their direction. So, to summarize, only if a project is 100% technical (i.e. no business issues), is a BA not warranted.
Reply | Reply with quote | Quote
 
 
0 # gretablash 2011-02-06 10:25
I am not sure if a project that is 100% technical does not need a BA. If the project is technical. the BA should be the BA that represents the technical area requesting the project. Was that position not called a "systems analyst" in the past? I am often asked if a PM is needed on a 100% technical project. Maybe the reason most IT projects fail is because they have neither a PM nor a BA involved.
Reply | Reply with quote | Quote
 

Add comment