Skip to main content

Author: Sergey Korban

Business Analyst and Project Manager In Tandem for Success

Fotolia_30981361_XSI’ve been working in project management and business analysis domains for many years. The projects I’ve been engaged in cover regulatory compliance, business process improvements, software development, ERP implementation and ITIL adherence just to name a few.

Heated discussions about relationships between a project manager (PM) and a business analyst (BA) are often focused on their non-aligning sides rather than on their mutual efforts to ensure project success.


I tend to think about PMs and BAs working together in projects as two hands carrying a baby. Here is my view on the PM-BA tandem and how it comes together to make a project successful. 

How It Works

I’ve been involved in multiple projects for the last two decades. The projects were of different scales and nature. However, there is one common element in all of them: a project manager and a business analyst were the two sides of the same coin. Their skills and joined efforts made a project successful and delivered good value to the business. I would like to demonstrate how a PM and a BA can work on a project, and explore each project phase in more detail. Please note that project phases and the documentation involved follow PRINCE2®.

Project Start Up

PM and BA work with project stakeholders throughout the entire project life cycle. Before the project starts, a PM deals with business stakeholders to identify the business need at a high level. The outcome of this interaction is a project initiation document. This document outlines the business need, the impact of the current state on the business, the desired target state, project complexity, estimated project duration and expected benefits.


 PM-BA: Collaboration Model

Project Initiation

The PM engages the BA to help with project scoping and defining the business need, the expected project outcome (deliverables) and the project acceptance criteria.

While the PM works on drafting a project plan, the BA develops a BA plan outlining BA deliverables, communication patterns with stakeholders, requirements management approach and estimation of effort. The BA agrees the BA plan and requirements management plan with the PM.

Once the plans are agreed upon, the BA works closely with the project stakeholders to clarify the business need, specifying high level business requirements, conducting stakeholder analysis, identifying risks, assumptions and constraints, and tolerances to a solution. The BA determines solution scope, high-level requirements, solution approach, and reusable and new components to be used in the final solution. The BA works closely with the PM to align solution scope with project scope. The BA informs the PM about all identified and potential risks.

The PM maintains the risk register and develops mitigation strategies for the identified risks.

The joined efforts result in two key documents: the project vision and solution vision. The former contains the problem statement, desired outcome statement, acceptance criteria for deliverables, stakeholder analysis, business context, assumptions, constraints and scoping definitions (in scope/out of scope).

The latter describes the problem statement, solution statement, provides a solution overview, stakeholder summary (RASCI), determines “to be” capabilities and business context, and defines what is in and what is out of solution scope.

These two documents support the business case document in medium and large projects, supporting the project sponsor’s decision making on whether to go ahead with the project.

The PM and BA work jointly on developing a WBS to ensure the solution can be assembled in a way that is cost efficient and adheres to the project timeline and resource constraints.

Project Execution

This phase requires even more close collaboration between PM and BA. They work together in requirements workshops to prioritize and validate requirements. They conduct workshops with vendors of components to the solution (where applicable).

Changes to solution scope lead to changes in project scope so the PM applies change management process to ensure that only justified changes will be accepted. The PM maintains the change request register throughout the project.

The BA’s reporting on progress in turn supports the PM’s reporting on project progress to the project sponsor and other interested parties.

The PM supports the BA in communicating with solution architects, software developers and other engaged third parties with regards to solution validation activities. The same is true when it comes to user acceptance testing. The PM’s support is invaluable here. The duo works hard to ensure that solution acceptance criteria will be met within the predefined tolerances. The BA facilitates solution implementation to ensure a smooth transition to the “business as usual” mode.

Project Closure

With the project deliverables accepted by the business, the PM works on closing the project. The BA facilitates project closure by providing feedback for the post-implementation review. The BA reports on how well the solution met the business requirements. They jointly work on the lessons learned log to ensure that all valuable information has been captured for further use in future projects.

The BA hands over artifacts such as business requirements, functional requirements, use cases, non-functional requirements and solution technical specification to the business. These artifacts form a basis for business documentation on how to use the solution.

When the project has been formally closed, the BA files all approved BA artifacts in a central repository.

Pain Point

From observing how different PMs tackle their projects over the years, I would like to highlight some things that can trigger a blaming attitude.

A bossy attitude towards a BA, a lack of understanding of the business domain, skipping important project background where the rotation of PMs takes place, “managing” customer expectations without involving the BA, expectations of having the final solution requirements identified by the BA after a single requirements elicitation iteration with project stakeholders—all these elements create a foundation of blame for not delivering on time and under budget.


The complexity of modern projects has increased to a great degree. Changes to business processes are coupled with changes to business applications, IT infrastructure, and interfaces with the company’s environment. The PMs and BAs are required to be more productive in projects of different nature. My experience gained from over 35 projects confirms that to deal with the changing demands and to make projects successful, the BA and PM should work in tandem pushing towards the finish line.

Shared responsibilities, mutual respect and support combined with a collaborative attitude pave the way to project success.

Don’t forget to leave your comments below.

Sergey Korban has been in the IT industry for over 25 years and has hands on experience in business analysis, project management and software development management. He is passionate about making businesses more effective. You can find more of his articles on the Aotea Studios blog  

Can Strategy Maps be Used in Business Analysis?

After attending a management workshop on strategic themes in an IT organisation, I started thinking about the potential uses for strategy maps. These maps help capture the management team’s thinking in a non-restricted manner and they facilitate effective communication amongst stakeholders.

The core value of the strategy map is that it shows value that is to be created within an organisation, and how different layers within the organisation are interconnected. It also helps to see both the drivers of change and the impact it’s going to create.

Business Analyst View

Can strategy maps be used in business analysis? The answer is yes. The map concept can be “re-used” with a few modifications to its layout. I created five perspectives and added five business objectives on the top. The reason for this is that each initiative within an organisation aims to satisfy business objectives. At the same time, each initiative is a source of change. An understanding of the direction of change and its impact on different layers within the organisation from different perspectives is the core goal of business analysis.

The 5×5 map illustrates cause and effect relationships between objectives and problem/opportunity layers. It facilitates communication with decision makers within the organisation by means of a vivid picture of constraints and limitations within each layer. It also allows you to see the effects of external or internal changes on the current state.

My practice shows that a lack of visibility across all layers at once heavily limits the ability of top management to see pain points and make a sound decision about resolving the problem.

Have a look at an example map:


Map Structure

The map has a simple structure. Five key business objectives are located at the top. They are Grow Revenues, Manage Risks, Increase Efficiency, Maintain Compliance and Enhance Customer Value. The perspectives of analysis are Governance & Standards, Customer, Vendor, Partner & Community, Business Functions & Interfaces, Internal Stakeholders, and Enabling IT Services. The map is just a single page, so a holistic picture can be presented to the decision makers. Another benefit of the map is that it provides a framework for managing programmes of change across different business departments within the organisation. Selecting an element within a layer will allow you to describe practically any scenario where a change is required.

Strategy map as a Communication Tool

The map can be used as an effective communication tool allowing you to tell a story of the required capabilities, proposed changes, expected benefits and achievement of business objectives. The map uses the language of the executives and it keeps them on a single page illustrating the business objectives and organisational layers simultaneously. The map facilitates  understanding of complexity of change and the required effort (money and human resources) to implement the change and helps assess organisational readiness to changes.

Lessons Learned

Each organisation evolves every day. It is not really visible from one day to the next but it sill takes place. It means that changes made yesterday have impact on today’s state and thus relationships between components of the map evolve too.

The map can be used to see the progress of changes at a high level. It can also be used to understand what new changes may be required to attain the desired objectives under the changing conditions in the organisational environment. The advantage for the executives is that operational details do not take up their attention, and they can focus on what is working, what is not, and why. The map helps identify new dependencies as projects move from stage to stage. My view is that the 5×5 map is a tool for understanding and managing change.

Practical Application

Let’s have a look at how the 5×5 map can be applied to real situations. Let’s take for example the Maintain Compliance objective and the Sarbanes Oxley Act of 2002 (SOX) as an external force driving a change within an organisation. Three sections in the SOX, namely 302, 404 and 409 are of  interest.

Section 302 requires CEOs and CFOs of public companies to certify the information in the company’s quarterly and annual reports along with the company’s internal controls.

Section 404 requires a clear responsibility of management for establishing and maintaining an internal control system and procedures for regular financial reporting. The section also requires an assessment of the effectiveness of the established control system and procedures.

Section 409 states that material changes in the financial condition of the organisation must be disclosed to the public.

All these requirements rely on the control systems and processes. Bearing in mind that no organisation can function without an information infrastructure (business applications and telecommunications), the control systems and processes should be interwoven with the information infrastructure. Without these controls in place the organisation won’t be able to track physical operations and reflect them in the financial postings that are a source of financial reporting.

Let’s go through the layers and perspectives to analyse what should be considered within the organisation to satisfy the SOX 302, 404 and 409 requirements.

Governance & Standards

From this perspective, we need to examine policies, procedures, corporate standards determining the responsibilities of management and employees, the limits of delegated authority given to key managers, the ethics controls established to ensure that all actions are taken in favour of the organisation and its environment. These key guiding documents outline the internal control system and describe specific controls, and where they are to be used.

This layer is important as it gives an overview of all business rules applied to business processes and embedded into the enabling IT services. 

          Customer, Vendor, Partner & Community

The Customer & Community perspectives both refer to the public and shareholders. The organisation deals with them differently depending on elements within the layer. We need to look at the services provided to customers and communications with customers and community to ensure that the organisation uses the information. This excludes potential complaints and claims of misleading which may lead to a breach of compliance. It means that we need to see if the communicated information is obtained from reliable sources of actual transactions, and who has access to the information.

The Vendor & Partner perspectives are used to look at the transparency of relationships between the organisation and its external parties (supply chain), monitoring and reconciliation of all physical and financial transactions and fair provision of goods and services.

            Business Functions & Interfaces

The Business Functions perspective enables us to analyse the organisational value chain, as well as how functions are shared across the organisation. It facilitates a better understanding of  organisational structure, business processes within each business department and how they complement each other. Using the information obtained from the Governance & Standards perspectives, we can verify the established controls and rules, check their efficiency, reveal potential weaknesses and thus propose the required changes.

The Interfaces perspective comes in handy for analysing departmental boundaries, how the business information is passed on, what transformation of business data takes place within the processes and what IT enabling services are used within the business processes.

As the organisation operates in its environment, this perspective gives us an opportunity to analyse how the organisation cooperates with its environment, what communication channels are and whether they are manual or automated, what rules are applied to the flowing information, etc.

            Internal Stakeholders

Any policies and rules apply to people within the organisation so this perspective is focused on personnel, designated roles, skills, levels of competency and understanding of requirements imposed by the organisation itself and its external environment. This perspective facilitates an understanding of stakeholders’ perception of organisational culture, as well as how culture facilitates acceptance of internal controls and willingness to enforce them on a daily basis.

            IT Services

The last perspective is useful for the analysis of enabling IT services which include business applications, communication means and IT infrastructure. They can be analysed in terms of:

  • criticality to the business
  • ability to protect and control access to sensitive information
  • levels of compliance with regulatory requirements
  • potential impact on financial reporting
  • availability and business continuity measures
  • disaster recovery measures
  • scheduled service resiliency testing
  • backups
  • physical access controls
  • audit trails


The 5×5 map describes the drivers of change, the direction of change, what problem/opportunity layers should be considered when a change is to be made in order to achieve a business objective, what the constraints and limitations within each layer are, and what changes will be required to each layer. It is a useful analysis and communication tool for business analysts.

Don’t forget to leave your comments below.

Sergey Korban has been in the IT industry for over 25 years and has hands on experience in business analysis, project management and software development management. He is passionate about making businesses more effective. You can find more of his articles on the Aotea Studios blog (

How to Impress Executives with Your Presentations

Business analysts and project managers need to be able to present their work, such as findings of completed analysis, proposed changes to business processes and/or underlying systems, or project status. If you Google “executive presentations”, you’ll get a lot of links but quite often these resources are focused on how to prepare or behave during the presentation. There is another aspect I’d like to propose – what should be in the presentation and how the content should be organized. This article lists the important considerations in preparing an executive presentation from my experience.

Initiating the Project

Try to limit the summary or overview to ONE slide
Executives rarely have time to go into a lot of detail for a project, so my approach is to summarize the project on exactly one slide. This slide should provide an overview of the key points at a glance. As this may be the only slide that you are given time to present so it needs to succinct and direct. By concentrating on this single slide you are forced to focus on presenting only the essential information. Short sentences, rather than bullet points, are more appropriate, especially if the handout will be referred to later, or passed on to others who were not in attendance. You can still go into detail during the rest of the presentation as needed, or as time permits.

Use metaphors

The human mind loves metaphors, especially curious ones. I use the metaphor of a highway with distances between towns to prepare the executives for a phased approach to moving from the current state with its pain points to the painless target state. You should use whatever is appropriate for your executives or project.

Give direction

To get the executives’ attention, I use the strategy of transition from one state to another as a foundation of my one slide presentation. I outline the key pain points, align the transition strategy with the enterprise’s business objectives and draw the future state. Executives should be able to relate to this approach.

Announce stop points

Depending on the nature of the message; I divide the whole route into several segments with stop-points and call them phases. The stop-points are gates which will be used to assess the results of the completed phase before making the decision to move further forward (also known as go/no-go decision points). I describe what will be done during a particular phase and how long it is expected to take, at what cost, what risks are known, what changes are envisioned, and then highlight the expected achievements to keep everyone’s spirits up.

Deal with risks

The picture can’t be completely idyllic however! There are no actions without risk, so it’s best to identify the initial risks upfront. The executives will usually add a few more through their discussions and questions, and I make sure to write them down. I also let them know that the identification and mitigation of risks is a major process and will continue throughout the project.

Show costs vs. savings

Any trip costs money. I use this idea to keep executives in the comfort zone. When giving cost estimates I think it’s important to mention savings and/or benefits even if they are only potential. The key point here is that you have given thought to that business aspect of the project. Just remember that any initial cost estimate, even though the emphasis is on “estimate”, will be recorded and unfortunately never forgotten.

Close with a summary

At the end of the presentation I quickly summarize the key phases and key achievements, the projected costs, expected potential savings, changes to the existing state and what the target state looks like.

Here is an example layout that could be used for an executive presentation:



Reporting project progress

After the project has started, you will be required to report its progress, as needed or as identified as part of the project plan. These progress reports are usually presented to various formats and to different audiences, but often include presentations for the executive team. In addition to the normal progress report elements of budget and schedule I have noticed that there is a missing piece of information that should be provided by BAs for these presentations. Very seldom are the executives told how the business goals of the project are being met by business requirements in the course of the project effort.

The executives can derive some information from the Project Status report: the results which have been achieved (or not achieved, as the case may be) during the current phase, the costs incurred to date, the activities planned for the next phase, as well as resourcing issues, identified risks, outstanding issues and so on. However, this is detailed information which may be commonly presented but may not be optimal for executive decisions that are needed.

A good approach can be borrowed from the ERP world. There, all system capabilities are translated into the terminology of business needs and goals, thus greatly simplifying executive decision making. The factsheets from well-known vendors are full of descriptions of what their system does but not how exactly it operates. How can this approach be applied to the BA realm?

When doing business analysis work, a BA produces different artifacts, such as the Project Vision. This document outlines the high-level business requirements and expected outcomes. These requirements reflect the executive view of the solution and can be used to validate the high-level business requirements and summary capabilities of the solution being delivered.

Each phase of the project from now on can be reported on in terms of coverage of the solution capabilities by the determined business, functional and non-functional requirements, as long as these remain at a high level. Too much detail tends to make executives lose interest (unless they are very detailed oriented and not functioning as an executive).

What are the benefits of this approach for the executives?

Firstly, the executives deal with a much less complex context of the project. Secondly, the decision making is supported by assessing the top level of capabilities expressed in the business language. Finally, progress on the project is easily tracked through a proxy of the capabilities.

Both business analysts and project managers will benefit from this approach. The project team as a whole will be better able to communicate the results of their efforts on the project clearly and effectively. They will also find it easier to address questions in a more business focused manner, without getting bogged down by the details of functional requirements, changes to software, and especially non-functional requirements.


The key to executive presentations is to include only the information, and in the most appropriate method, which is crucial for executive decision making while avoiding diving into details unless it’s specifically requested.

Sergey Korban is the Business Analysis Expert at Aotea Studios, publisher of visual learning and reference materials for business analysts.

How to Handle Tight Deadlines as a Business Analyst

BA_Nov30_FeaturePicWhen you are assigned a complex project that has a short timeframe (as often happens), it can be nerve wracking – I know this from experience. It’s like driving a racing car – you have to push close to the limits but any error can throw you completely off the track.

The first thing that I do when I get a project like that is considering the reasons for the deadline. You can end up with a tight deadline for a variety of reasons. The deadline may be mandated by the management. It can be determined by interdependencies between projects. It can be defined by market compliance rules. In other cases it’s estimated using the work breakdown structure for the project but ends up being too short because of wrong assumptions.

So how can you as a business analyst make sure that circumstances don’t control you and your team, and you deliver your project successfully? Keep in mind that sometimes you can be successful even if you don’t meet the original deadline!

Here is a visual summary of deadline causes and ways of handling them:


Let’s look into the ways of handling deadlines in more detail.

Manage the Manager

Management sometimes sets up deadlines with a good “buffer” to allow themselves time for decision making at the end of the project, or because they don’t expect to get results on time and want to push things along by moving the deadline forward. This can be best mitigated by having good communication with the management.

However, what can you do if your manager does set an unreasonably short deadline? Find the tolerance level of your project sponsor (management) and of the key stakeholders who can influence the sponsor. Talk to end users to understand the severity of not delivering on time. There can be scope for negotiation.

Shuffle Dependencies

If your deadline is constrained by dependencies, you can talk to project managers of the upstream and downstream projects to get a better understanding of the interconnections. You might be able to find a way to reorganise things and either get what your project needs delivered earlier, or move the deadline for your own project.

Be Smart About Compliance Deadlines

If you’re working on a compliance project, it may have a firm deadline established by the market bodies. In this case find out if there is a transition period. It is usually provided because market participants have differing levels of compliance and don’t have the same resources available to make the transition. You can also evaluate the impact of breaching the deadline (such as fines for non-compliance), and prioritise the parts of the project which would have the highest financial impact if they are overdue.

Double Check Estimates

When it comes to deadlines defined by estimation, it’s a good idea to double check the estimates. Ask what facts and assumptions were taken into account when the task was initially estimated.

Watch Out For Changes

Once the project starts, you have to watch out for changes in the project environment. Changes will affect project completion time, so work with the team and stakeholders to update the WBS and the schedule.

Organising Work On Projects with Fixed Deadlines

After you’ve applied the practices above and you are sure that you’ve done everything you can to negotiate a reasonable deadline for your project, the next phase is organising your work in the best possible way to meet the deadline.

I’ve found that the following practices help me complete projects on time:

  • Determine the business context which will be affected by the change to status quo
  • Define the scope of the solution required to satisfy the identified business need
  • Plan short iterations to verify the project direction
  • Align the solution with the existing business processes and IT infrastructure

Each of these practices is discussed in more detail below.

Determine Business Context

Completing this step successfully often determines the success or failure of the project.

Many organizations that operate in a competitive environment have well defined and standardized processes. Many others don’t however, so be prepared to discover them. Explore the business processes which may be affected by the new solution. Learn which systems are used by the business within these processes. Embedding new solutions into these business landscapes should be considered thoroughly to reduce resistance to changes and exclude redundancy in project management, solution delivery and transition to the new state. If done right, it also gives a business analyst an opportunity to find ways to add value to the business.

The rationale for the project should be identified by the project manager, while the business analyst should identify business drivers and actual business needs.

Define Solution Scope

This is the exciting part of the project, but defining solution scope has never been an easy task. Short timeframes and technological changes which may occur during your project make it even more challenging.

In general, to cope with this task the project team needs a solid foundation to build on – well documented processes and good infrastructure. Knowing and using best industry practices can often point you towards defining a sustainable solution and save exploration and research time.

When it comes to defining solution scope, my approach is to use only the “must” requirements for the “initial” solution, and prioritise the remaining “should” requirements into subsequent phased releases (“final” solution).

You must work closely with the solution architect and play an active role in exploring available options. Often the overlap between business analysis and system architecture saves a lot of time – I have saved up to a third of project time by ensuring that the architect could use my documents as a useful starting point in producing a detailed design of the solution.

Plan Short Iterations

I’m still on the fence with regards to the Agile method. Its value is clear in software development (at least for certain kinds of projects) but when it comes to business analysis, I’m not so sure. However, short iterations are one useful technique in Agile which can reduce project time. Use them to get a summary of the completed and outstanding tasks, evaluate changes to the project scope, and identify feasible shortcuts.

Project manager and business analyst need to present a unified front in dealing with business stakeholders. Face to face communication is essential to make short iterations work for analysing the current situation, required changes and making decisions on the next steps. Informal communication style helps too – really, there’s just no time for strict formalities if you want to get things done. It’s very important for the project manager to arrange a “green corridor” for access to authorities and clear the way for the team to focus on delivering rather than struggling with bureaucracy.

As a business analyst, you also have to do your share to deliver results quickly by being professional and active in all your activities (industry research, compliance requirements and so on). Make sure that communication is well maintained between everyone involved in the project.

Align Business and IT Infrastructure

Most of the time new solutions are embedded into the existing environment. It’s a good idea to make maximum use of the existing components and processes to make the introduction of the new solution less intrusive and to minimise the number of temporary patches and business interruptions.

I try to present the solution in terms of interacting services to achieve this. I transform business references to applications and systems into services and show how they could interact. This approach allows me to show the business users how all pieces of the business, including external parties and outsourced services, come together and how the new solution will improve overall efficiency.


Whenever you get a project with a short deadline, don’t forget that there are two major considerations: what can be done to change the deadline, and what is the best way to organise your work to meet the deadline.

The practices presented in this article should help you address each of these considerations.

Don’t Forget to Leave Your Comments Below

Sergey Korban is the Business Analysis Expert at Aotea Studios, publisher of innovative visual learning resources for business analysts. We think business analysis should be easy to learn! We deliver practical knowledge visually, with a minimum of text, because that’s an efficient way to learn. Find out more at

  • 1
  • 2