Today 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 and now with the new PMI-PBA certification from the Project Management Institute, 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 the 4th, and expanded even more in the 5th edition of the PMBOK® Guide through new processes — Collect Requirements and Identify Stakeholders — and the expansion of the process Define Scope. The Stakeholder Register, Requirements Management Plan 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® Guide 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® Guide 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® Guide 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 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 a 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.