The Business Analyst and Project Manager are team players on a project. As is common the Business Analyst and Project Manager sometimes have conflicting approaches during a project.
Having frequently taken up dual roles of a project manager and Business analyst during the course of my career, I have gained some insight on the dos and don’ts for a business analyst to work effectively with a Project Manager
The following are the 10 recommended Tips:
TIP 1 – Collaborative Stakeholder Analysis
Key to your success as a Business Analyst on any project is identifying your key stakeholders and having a good understanding of their interests and levels of influence. From my experience this is a task best done in collaboration with your Project Manager to ensure you speak the same language when it comes to managing your stakeholders. Imagine a situation where you haven’t captured the requirements a highly influential stakeholder already identified by your Project Manager. This could in turn result in unwanted reworks on the project, increased costs and project delays.
TIP 2 – Synchronization of your Business Analysis Plan with the Project Schedule
It is good to ensure that the activity dates of your Business Analysis Plan are incorporated or synchronized with the Project Manager’s Project Schedule. Nothing is worse than discovering that the period of time the project manager has allocated for your Business Analysis Activities is insufficient.
TIP 3 – Usually not all requirements can be captured up front.
Many Business Analysts discover that as much as the intention may be to capture all requirements up front before the execution phase, there are actually few cases where this is possible. During execution it is common that stakeholders bring up forgotten requirements. The good news is that usually the Project Manager will define the Acceptance criteria with the client. The acceptance criteria is an agreement of what the product or service should constitute for it to be accepted by the client. The Acceptance criteria are usually part of the signed off project charter. Other Project Managers may use the agile approach where prioritized requirements are implemented in phases. In summary A BA must accept the fact that in most cases not all requirements will be captured up front.
TIP 4 – Non Functional Requirements vs. Project Scope
As Business Analysts we also capture non-functional requirements i.e. the expected efficiency level of a system. It is good to liaise with your Project Manager on what is out of scope for the Project. It is common that non-functional requirements requested by stakeholders are sometimes not feasible due to budget and time constraints. In summary you need to be on the same page with your project manager on what is out of scope. This is to avoid complicating the management of your stakeholder expectations
TIP 5 – Help to minimize Scope Creep
As business analysts we know that stakeholders may request additional requirements during the course of the project. As Business analysts a new requirement is accepted or rejected depending on whether it can be directly linked to the Business Need. However Business Analysts need to remember that project manager aims to minimize new additions to the project scope (Scope Creep) that will require the adjustment of the Project budget and Schedule. In most cases stakeholders are not willing to incur the increased cost or time required for inclusion of new requirements.
TIP 6 – All changes to requirements undergo impact analysis
Whilst carrying out the Requirements Management & Communications process the business analyst must ensure that changes to requirements go through the Impact Analysis process managed by the Project Manager. This is to ensure that the Impact that a change in requirement will have on the Project Schedule, Project Cost or product quality is assessed before the requirement change is formally approved.
TIP 7 – Collaborative Prioritization of Requirements
Prioritization of requirements is a standard task that we carry out as Business Analysts under Requirements Analysis. However it is common to reach a road block where stakeholders wish to classify all their requirements as high priority. This is usually due to the fear that non high priority requirements will be excluded in the project scope. With this in minded it is recommend that prioritization of requirements is done with the involvement of the project manager to assist in management of your stakeholders.
TIP 8 – Synchronize the list of prioritized requirements with the vendor selection criteria
Selection of vendors is procurement management task that critically requires the input of the Business Analyst. Selection of vendors is usually based on each vendor being evaluated against the vendor selection criteria defined by the project manager. It is crucial that Business Analyst ensures that the vendor selection criteria is synchronized with the list prioritized requirements.
TIP 9 – Transition Requirements can sometimes be implemented as post GO LIVE tasks
Business analysts also capture transition requirements i.e. the required training of users. For a Business Analyst a project is complete when all the categories of requirements i.e. transition requirements have been implemented. However what is sometimes experienced is the Project Manager wishes to separate the implementation of transition requirements from the Project Scope and treat transition requirements as post GO Live tasks. This is usually the case when Project has a non-negotiable constraint on the GO Live Date.
TIP 10 –Factor in Project Manager’s constraints and assumptions when the defining the solution scope.
The Business Analysts defines the solution scope under the process of enterprise analysis. It is critical that the Business Analysts gains the input of the project manager on constraints and assumptions before defining the solution scope.
To work effectively with Project Manager a Business Analyst has to be able to understand aspects of stakeholder analysis , Project Schedule , Project Scope , Managing scope change , vendor selection criteria and project constraints from the eyes of a project manager.