Skip to main content

Author: Jenny Quillian

The Cost of Missing Stakeholders

Business Case:  Lessons from software implementation which put head office directives before stakeholder needs.



This business lesson was learned at a US non-government organization (NGO) operating refugee camps and support services in East Africa.  A few months prior to my arrival the NGO selected an accounting system to be implemented at all local offices.  Instructions and software were sent out from the US head office, and my predecessor had been gamely trying to implement the new system but falling behind a little each month.  We crossed paths in Nairobi as I was inbound to Mwanza, a dusty town on the shores of Lake Victoria.  He was clearly stressed and anxious to be going home.  What was I heading into?

NGO’s operate on private donor funding and from US government grants.  Money was provided in US dollars and was spent in local shillings.  Financial reports are provided in US dollars to the head office and for donor reporting, and in shillings for local authorities.  Multi-currency accounting was not the cause of their current issue, but added complexity to the implementation.

The software was installed but a backlog of configuration work and data migration had been created and this was consuming the efforts of the finance office.  Production of the donor reports were months behind and the NGO was at risk of losing or disrupting the funding to aid the thousands of refugees in their camps. Payments to local suppliers and workers were also in arrears as time had been consumed by the software change.

The new accounting system was rolled out by the head office to support a strategy for global standardization of accounting and reporting from their international offices.  The implementation strategy could be called “out with the old and in with the new”.   Use of the old system was abruptly ceased while the new software was installed, and production of the monthly donor reports would be resumed from the new system once the install and data migration was complete.   There was no local planning for the initial rollout.

The approach of this paper is to use this business case to illustrate the benefits of applying business analysis tools and techniques to all software projects, regardless of size or location.


Planning– identify stakeholders and business analysis approach. 

Always look for all the stakeholders.   The NGO head office is a stakeholder in the Mwanza project, and they communicated a business need to achieve global accounting standardization.  The funding donors are also stakeholders in the project.  The rollout strategy was based on an assumption that the new accounting system was the number one priority for this local office – but donor funds are the life blood of non-profit organizations and any hint of not being able to account for how the money is being spent can cause delays or withdrawals of support.  The number one business need for this Finance office was the timely and accurate production of donor reports.

Local workers and suppliers are also stakeholders in the accounting system. Timely reimbursement for labor and materials is needed to maintain the supply of both to run the refugee camps.

It is easy to overlook the need for business analysis in small projects, but this case illustrates the risk of implementing software without some basic analysis of scope and flows.  A simple context diagram and stakeholder map would have provided a better perspective for implementation planning.




Requirements – identify all the functional and non-functional requirements.

The requirements given to the local office were:

  1. Install new software
  2. Migrate historical data
  3. Recreate reports


Recognition of additional stakeholders leads to the additional requirements –

  • Maintain accurate and timely reporting to donors.
  • Avoid disruption to the delivery of monthly donor reports
  • Ensure consistency in donor reports
  • Maintain payments to local vendors and workers
  • Avoid delays of vendor and worker payments


Strategy – identify the business need, address that need, and align the change strategy within the enterprise.

The business need which dictated the implementation strategy was to achieve global accounting standardization.  The missing business need was to maintain continuity of operations during the software change.  A new strategy was required that gave equal priority to both needs.

Under the new strategy all work was stopped on the software configuration and data migration until the monthly reports and daily operations were up to date, then these were maintained in parallel during conversion and testing until a clean cutoff was possible.  This was achieved within 3 months and there was no disruption to the NGO’s funding or local operations.


Create a Context Diagram at the start of the business analysis process then share this early and often with your known stakeholders to help identify what might be missing.




Identification of all stakeholders is key to successful requirements. Timely identification of all the stakeholders at the start of the project avoids delays and rework when new requirements are identified while development or delivery is in progress.

What Use Case to Use?

The Use Case is a standard tool in the BA toolkit, and like most tools they come in different shapes and sizes for different jobs.

During Business Analysis Planning it is important to identify the appropriate use case format for the project needs.  At the high end we have a multi-page highly regulated requirements template. The base model is a single actor and basic flow.  Between these is the textbook version with complex flows. This article looks at these use case formats and design influences to consider during your Business Analysis Planning.   

Use Case Formats

  • Simple Flow Use Case
  • Complex Flows Use Case
  • Highly Prescribed Use Case

Simple Flow use cases describe the interaction of a single actor along one basic flow.  This format can be used as the starting point for a more complex effort, as a placeholder for planning purposes, or as the final deliverable for a simple project.  This format is similar to a user story, with post conditions instead of benefits. 

Complex Flow use cases include alternate flows, triggers, business rules, post and exit conditions. The degree of complexity should be determined by the stakeholder needs and perspectives.  For business users the documentation must be readable so that they can follow and agree that you have captured their needs correctly.  For the architects and developers, the details must be specific enough to translate into units of development.  For the testing teams the documentation must provide clear inputs and outputs of success so that they can formulate test cases. 

Highly Prescribed use cases have a multi-page template with approved instructions to complete each section.   There are projects which require such discipline,  but I have also worked on projects where the template became the end rather than the means,  and the degree of detail slowed down the project and produced wasteful documentation.  

Design Factors

Use Case formats will be influenced by:

  • Funding model
  • Requirements complexity
  • Rate of change
  • Regulatory environment
  • Project methodology
  • Project phase
  • Build or Buy


Funding Model

Organizational funding models may impose a need for provide for detailed requirements well in advance of the project development phase, in order to compete for funding.  A use case that identifies all potential steps, alternate flows, business rules and usage estimates can be useful to assist with cost estimates.  Tight funding oversight models will ask for more detailed documentation than open models.

Requirements Complexity

Retail web pages for major sellers can be large and complex because of the product offerings, but the system requirements themselves are repetitive and reusable and changes easily delivered with a user story or simple use case.

A new system with complex requirements needs more detailed documentation than an informational web page.   A new system with many business rules needs detailed documentation and requirements tracing to ensure proper coverage.  Integrated systems need a degree of rigor ad traceability to ensure that front end changes do not break upstream or downstream systems such as integrated re-order or delivery systems. 

Rate of Change

The retail web pages are repetitive but require rapid changes to meet demand and marketing plans. The requirements documentation cannot stand in the way of rapid delivery. 

From another perspective, detailed requirements documentation that can be reviewed in the change management process can help slow down a rush delivery and prevent embarrassing releases.

Regulatory Environment

Systems that are governed by external regulations need detailed requirements documentation that can be read and understood by multiple stakeholders so that all affected parties are able to understand and approve the inputs and outputs of the system to be delivered.  Systems that collect personal information must be able to demonstrate that the correct information is being captured and the appropriate security will be in place to protect this information from misuse.

Project Methodology

Waterfall projects tend to require detailed requirements. Agile projects prefer minimal documentation, user stories, and simple use cases if any.  

Project Phase

Documentation detail may expand or contract during the project phases.  As discussed above, projects may require detailed requirements documentation for early feasibility and cost analysis exercise, but they may then drop down to user stories for the development and delivery.  Other projects may require only simple use cases to outline a concept, and then expand on the use case flows and details during the requirements phase.

Build or Buy

If the project includes a build or buy decision, then a simple use case format that can be transferrable to a matrix of acceptance and evaluation criteria will be most useful when comparing solution options. 


Use Cases are a valuable business analysis tool that come in multiple flavors.  As part of the Business Analysis Planning step the Business Analyst should identify the degree of rigor and detail that the project and the stakeholders require and select the appropriate use case format(s) to use during the project.

The Remote BA

The purpose of this article is to offer suggestions to the Business Analysts working remotely from your team and your stakeholders.

This article is an extension to my previous article which encourages the Active BA.  With today’s technology and your initiative it is possible to remain a strong and active BA without the face to face engagements which used to dig into requirements and resolve issues. 

My key suggestions are below. I encourage readers to add comments below with their own ideas.

  • Use all the technology available to you.
  • Be proactive at reaching out to your team and stakeholders.
  • Enhance your online meetings with online presence and visual aids.

Long distance teams are quite common in today’s IT projects, and there are a number of offerings for team collaboration.  Use them all.  If the dev team has a Slack channel,  then join it and monitor it every day.  If the PMs are using  Microsoft Teams then sign on and learn that too.  You may need to install multiple web and video conferencing tools because one stakeholder group uses Go To Meeting and another uses Amazon Chime.  Become proficient in both so that you are a proactive attendee.

Proficiency in communication tools is essential to 1) keep up the flow of ideas, discussions and feedback, and 2) maintain the soft skill of Presence when conducting meetings.

The role of Business Analyst is to provide the bridge between business and technology teams.  Much of this occurs during hallway chats and office drop-ins.  You pass the PM’s desk and stop to say Hi.  They have a small issue that you help with by reaching out to the stakeholder immediately with a quick question. It is essential to replace these informal communications by being comfortable with all tools to the extent you can casually reach out across the ether. Replace the office walk-by with a brief daily update to each of your contacts in whatever mode they are working in.  Keep the bridge together by proactively reaching out to teams and stakeholders.


Conducting successful requirements sessions over collaboration tools starts with the same basics as your on-site meetings – Preparation and Presence.

Preparation was covered in my earlier article, The Active BA.  The concept applies to on-site and n-line meetings.  The soft skill of Presence requires new approaches for on-line meetings.

BATimes May6 1 2020

Rule #1 – use a web camera.  Maintaining the illusion of face to face communication is essential to make the remote connection and prevent audience drift.  Use the tool function to keep the attendees visible during all screen shares.   

Rule #2 – use visual aids as much as possible.  Use screen shares with a powerpoint or other visual display to keep focus on today’s agenda and current topic. If the purpose of the meeting is just a daily catch up,  then a screen of just faces is fine,  but if the purpose of the meeting is to provide deliverables – answers, ideas, input – then do not allow your audience to talk to a blank screen.

Speak with strength when talking to your audience.  The screen is now your stage and your role is still “Powerful BA”.   Carry the same confidence that you use in a meeting room.  If you like to walk the room while presenting in meetings, then get Bluetooth connectors and step back from your desk.  Set up a white board in your home office.  Practice and film your presentations for play back and review.

If the meeting is a daily stand-up – then feel free to stand up. 

One final observation – check the background clutter in your home office or whatever room you are working from.  Remove all distracting items.  Align the camera to display your certificates and not your personal photos.

The Active BA

The purpose of this article is to encourage Business Analysts to be active in your role.

On some teams the BA is a project management support role rather than a leader.  While PMs always need our assistance, all projects benefit from having a strong BA with a focus on delivering the business needs.  I extend the concept to include proactive and reactive

  • Be Active. Don’t be a passive member of the project team. Be active in meetings, in proposing ideas, and contributing to the discussions
  • Be ProActive. Create and present a business analysis plan and BA methodologies to the project team
  • Be ReActive. Be ready to react quickly when new information, technology or needs are introduced

Be Active

Be active in meetings, in proposing ideas, and contributing to the discussions.

Project meetings can be a lot of fun.  The exchange of ideas among technology experts can be uplifting and inspirational.  Requirements gathering meetings can also be lively and productive as stakeholders share their knowledge and ideas.  But sometimes meeting can be dull and they can be frustrating, especially when participants go off track or monopolize the discussion.   Whatever the situation, the active BA is leading or contributing to the discussion.  There are two techniques that can help – Preparation and Presence. 

Preparation means know your subject. 

Within the project team we are the conduit between the technology teams and the business they are supporting.  We can bring to the project team an understanding of the user needs and of management’s expectations of how the technology product / output will benefit their organization.   It is not necessary to be a Subject Matter Expert in the technology or in the user’s business domain, but you should have sufficient knowledge of both to be an effective liaison between the customer and the development team.  Stay current with the technologies of your architecture and your business. Be active in offering your ideas.  It is especially important to offer your thoughts in project meetings on requirements that are implied in discussions.  Clarify early and often.

The BA Times article Mind Maps for Business Analysis shows how to use the 5W Mind Map to present requirements and anchor team members during project meetings. 

Before the first requirements gathering session make sure that you have some understanding of the organization and business of your stakeholders.  In large organizations it may be necessary to create your own org chart to place the stakeholders and at least recognize where there may be differing expectations.  Talk to a few individuals to get a sense of direction.  Think of this as you would a vacation trip to a new country, where research and talking to others who have been there helps get the best out of your days once there.


For all requirements meetings ensure that you have a powerpoint or other visual display to keep focus on today’s agenda and current topic, with an appendix readily at hand of all requirements and decisions previously confirmed.   To run a good meeting, be prepared with 1) visual clues and 2) the ability to steer discussion back to the subject of your choice.  The latter requires presence.

Presence means having the ability to focus the audience on you and your line of discussion. 

There are many tricks and tips for controlling meetings. Agendas, time boxed discussions and parking lots all help, but even with these a facilitator with no Presence can lose an audience. 

Entertainers have presence.  They move around the stage and engage their audience.  Elton John played a piano, but he jumped around that piano to keep the audience eyes on him.  When it’s time to focus the audience, stand up and move around as you speak.  Use hand movements and point to the presentation as needed.  Write comments on the wall boards while you continue the dialog.  When you have made your point and want member discussion, sit down and allow the focus to move back to them.

Speak with strength when talking to your audience.  I have an accent which goes down well with my local audience, but that alone would not keep their attention if I mumbled.  The meeting room is your stage and your role is “Powerful BA”.  

Another lesson from the entertainment business is practice.  Strong speaking skills can be developed with practice.  If your organization has a BA work group, then use this to present a topic to your peers. If you are part of a local IIBA Chapter then volunteer to make a presentation. 

Be ProActive

Create and present a business analysis plan and BA methodologies to the project team.

The proactive BA starts with a business analysis plan and BA methodologies, then presents the plan to the project team during a kick off meeting so that they understand and support it.  The plan should include roles and responsibilities with regard to requirements analysis,  In a great project team, and especially in scrum teams, there is a degree of  this analysis conducted by technical members. The business analysis plan will set boundaries for the team to understand who is responsible for getting requirements to a level of specificity so that can be ingested by the developers.  

BA Jan15 20 1

The BA operates in a continuous change environment, so continuous learning is an essential part of the Active BA career.  Learning should include development of BA skills as well as staying current with technology.  One of my recent projects was migrating apps to AWS cloud, so I spent time learning the vocabulary and cloud concepts to increase my effectiveness in the team.  See BA Times article Add BA value to your AWS cloud Project.

Be ReActive

The third branch of the active BA is to be reactive to change.  Be prepared and act quickly when new information, technology, or needs are introduced.  Reaction times are faster for the active BA with preparation and continuous learning in place, and the ability to ignore sunk costs.

Sunk Costs is an Economic principle that costs already incurred have no part in decisions on future expenditure.  For a BA this means that time and effort spent to date sometimes have to be wiped out when requirements change mid-project.  Forget the hours spent defining the module that will now be outsourced.  Let Finance worry about the dollars and cents of wasted time. The BA should immediately pivot to new requirements and how this change affects existing requirements.

The same assessment applies to the backlog and deliverables on Agile projects, but with regular adjustments from sprint feedback, and strategy changes can still occur during a delivery phase that wipe out existing work.  An Agile BA is Active, Proactive and Reactive.

Mind Maps for Business Analysis

The purpose of this article is to demonstrate the use and benefits of Mind Maps for business analysis.

The 5W mind map uses the journalists’ five questions (Who, What, Where, When, Why) plus How to provide a template for a business analysis guide that can be used through the project lifecycle.

This technique is the first action I take for every new project, giving me a project overview that is then used as a check list and visual reminder during the course of the project. I use a free download version, but there are many mind mapping tools available and the paid versions offer more sophistication for presentations and integration with other project tools. (The mind map tools provide the ability to embellish your view with markers, images, colors and labels, but beware of drowning your big picture in a pool of emoji’s).

The diagram below shows the 6 major topics, and the initial round of sub-topics for each. The choice of sub-topic may vary with your project or your own area of responsibility.

BA Oct17 1


The mind map will grow and change during the course of the project and can be used under each of the BABOK knowledge areas as follows:

  • Business Analysis Planning and Monitoring
    • At the start of each project, create a new mind map to organize and coordinate plans for the analysis tasks
    • Add information from the project proposal to each topic
    • Use the mind map tool to expand the sub topics as knowledge is gathered
  • Strategy Analysis
    • Identify stakeholders and project partners under Who
    • Record the high level business case under Why
  • Elicitation and Collaboration
    • As requirements are gathered, add the high level business requirements and business rules under the What topic
    • Record sizing and usage estimates against Who, How or What
  • Requirements Lifecycle Management
    • Use the mind map during the course of the project to maintain focus on the high level requirements and to reinforce relationships between and justifications for requirements
    • Use to analyze proposed changes
    • Print out the mind map and pin to your wall or the project war room for all to see, especially during team discussions when members need to be anchored
    • Refer to the mind map when developing presentations to stakeholders and project teams to maintain consistency over long projects
    • Update the mind map during the course of the project, maintaining version numbers
  • Requirements Analysis and Design Definition
    • Validate the requirements against the other project topics
  • Solution Evaluation
    • Identify key aspects of the solutions and delivery methods under How
    • Record implementation locations and delivery sites under Where



Each topic provides an opportunity for the BA to start shallow and take deep dives. Add all findings as you go – but do not hesitate to remove or edit as new facts or requirements are discovered.

Who – Stakeholders and Project Partners

The key stakeholders of the proposed system should be identified in the project proposal, but stakeholders are also uncovered during the life of the project. An example is downstream consumers of the product or data being delivered. User estimates can be noted against active and downstream users.

Making a note of the executive sponsors and influencers serves as a flag to follow up when there is an organization change or an executive mind shift. How will that affect your requirements? The BA should be aware of other partners such as Finance, delivery team, and the planned support team as potential influencers of the system requirements.

BA Oct17 2

What – Requirements and Business Rules

Detailed requirements and user stories should be left out of the mind map, but they should map back from your requirements management tool to the mind map. The requirements in the What topic serve as a guide and constraint on the detailed requirements. There should be sufficient information so that the mind map is a stand-alone overview for when you are faced with an executive in the elevator asking what this project is about.

Where – Locations

The Where may prove to be not significant for a particular project, but including this in your initial template provides the opportunity to consider first then ignore – rather than ignoring first. Will the infrastructure be hosted in a public cloud or in-house servers? Will there be international users? Will the support be local or outsourced. The requirements must cover these variables. The delivery variables

When – Project Timelines

Making a note of the high level project timelines at minimum completes the overview of the project, but this branch may also include requirements analysis plans, sprint plans, and/or key business event dates.

How – Solutions and Methods

The Business Analyst is not responsible for technical solutions or project methodologies, but these may have an impact on requirements, and therefore the BA should be aware early of technical decisions such as COTS or Build, In-house or Outsourced, Agile or Waterfall. Record just enough information to show how the technical project decisions support the requirements. Sizing estimates should be recorded here because the technical solution should be compatible with the expected traffic and data volume on the system.

Why–Business Case

Recording the high level justification for the project provides another guideline reference for the business analysis work, and red flags during requirements analysis.


The following section lists benefits from using mind maps for project and requirements management. In addition, I find them just fun to use. I was hooked on mind maps from the day our new Director introduced himself to the team through a colorful and informative mind map of his resume and interests.

  1. Generate discussion and ideas. The loose structure of the visual and the flexibility of the software work together to open minds and to overcome reluctance to offer ideas and changes.
  2. Multiple perspectives. The mind map shows horizontal and vertical perspectives. The drill-down design allows viewers to see big pictures and their underlying details in a single view. Discussions can go down rabbit holes into the detail but the presenter has a tool to bring them back to the shared big picture.
  3. Highlight relationships. The central positioning of the major topics in the 5W template provide the horizontal perspective, and makes the viewer think about the relationships between topics. How does the project methodology impact the requirements delivery? Do the requirements match the business case? Do the requirements reflect all locations and stakeholders?
  4. Easy to recall. Mind maps create a visual representation of your project, and the picture really can be worth a thousand words. Visuals are easier for memory retention than pages of words.
  5. Enable change. Today’s software development environment is short and agile. The BA operates in an environment driven by change, disruption and transformation. The 5W mind map enables free thinking within defined boundaries, and also provides an impact map to assess shifts and changes.


The 5W mind map is a useful tool for requirements planning and management. The starting topics of Who, What, Where, When, Why and How provide a check list when collecting requirements and a reference during the life of the project.

The attached file presents an example of a 5W mind map for a hypothetical project to provide digital signage at local swimming pools.