Skip to main content

Author: Tom McIntire

Inheriting Projects

Working in a corporate environment we are often asked to drop tasks and projects that we are currently involved in, so that our efforts can be concentrated on other initiatives within the organization that needs our attention.

We often need to transition these tasks to other individuals in the same or similar role as our own.

“One of the hardest things for someone working in Business Analytics is letting go of a project they are working on or transferring it to another Business Analyst.”

You have already put in significant time, effort, and energy to bring the project and stakeholders together and now you are being asked to transition it to another person. The first thing that comes to mind is a younger version of myself that says “I don’t wanna share! This is my toy!”. I was an only child, so I didn’t have to share a lot when I was younger, but when I did it was an effort for my mother to get me to do so. Thank you, mom, for teaching me this important life lesson early on, so that it is easier for me to share as an adult.

“It is perfectly acceptable to share our work with others when we need assistance.”

I have been on both sides of the coin (giving and receiving). It can be strenuous for both parties for different reasons, but the analyst receiving the project from another will have to perform more work initially in order to be brought up to speed on the project. Many times, you may not even know which questions to ask or what information you need as you have not been associated with the project in any role.

“Working in the field of Business Analytics, one needs to remain flexible and open to change.”

I have devised the below checklist to assist with the transition process from one Business Analyst to another. The checklist is meant as a guide or a talking point when creating your very own Transition Checklist. The Business Analyst should be thinking about the potential answers to each of the items during the initial transition of the project. Each project is different and working in the Business Analysis field, we need to be committed to change. Therefore, each Transition Checklist may be different. The checklist below is created from the aspect of the analyst(s) receiving an active project, however, the analyst(s) transitioning the work to another should be proactive and communicate as many of the touch points listed below as applicable to the project.



  • Verify the tasks, goals, deliverables, and roles in the phase(s) owned by your team
  • Identify what methodology is currently being used: Waterfall, Agile, Agile-Waterfall Hybrid
  • Identify the project goals and scope
  • Are the correct resources on the project or are there resources missing?
  • Determine if it is possible for the previous analyst to stay on the project as a mentor for a short time period
  • Conduct a meeting to introduce yourself to the new project team. Make sure to cover the following:
  • Review established expectations
  • Review established ground rules
  • Review key decisions made prior to your assignment
  • Review Stakeholder roles and responsibilities for accuracy
  • Inform group of what they can expect from you moving forward
  • What is the current communication style?
  • Is there a communication plan?
  • Where is the project documentation stored?

Analytical Services:

  • Meet with the current analyst on the project and complete a knowledge transfer
  • Walkthrough of the requirements and project scope
  • Review the current BA Plan and complete any updates needed
  • Obtain written approval of updates from key Stakeholders
  • What are the deliverables (completed and outstanding)?
  • Project milestones
  • Change Requests
  • Requirements
  • What is the current phase of the project?

Project Details:

  • Meet with the Project Manager to cover the project timeline
  • What are the key milestones that will need to be completed and the dates?
  • Record the impact/risk of the transition of Business Analysts on the project
  • What is the current health check of the project: At Risk, Poor, On Schedule, Ahead of Schedule
  • What are the dependencies or relationships with other projects?
  • How many Project Managers are currently assigned to the project?
  • How many Project Managers have been transitioned off of the project?

Solution Details:

  • What are the Known Production Problems that are to be resolved as part of the project?
  • What are the details of the Release Schedule?
  • Who are the Third Party Vendors involved in scope, requirements, testing, or implementation?
  • What are the defects associated with the project?
  • What are the identified constraints?

It’s Beginning to Look a Lot Like Collaboration!

Collaboration is one of the most difficult actions we complete in the Business Analysis world.

Working with stakeholders can sometimes feel like a grueling task after weeks of meetings leading up to requirement approvals from stakeholders. I have discussed this topic in previous article I’ve written, but today I’d like to discuss collaboration among other Business Analysts when working on a project that involves multiple authors or writers of the same set of requirements.

In my experience as a business analyst the majority of the work I have completed involves a single business analyst assigned to a project, however, there are some projects that I have worked on that are just too large for a single business analyst to be involved and there are often 2-3 other business analysts working together to meet the project goals. This process can just as complicated as working with other stakeholders on a project. Opinions are many and voiced often. Temperatures run high at times. In the end, strong collaboration surpasses these complications and the end goal is achieved.

Below are some methods or techniques that I have followed over the years to help guide this process:

Plan, Do, Review, and Improve

The four phases of this technique – used to coordinate and publish complete and consistent requirements – are detailed below.

  Phase  Description
   1    Plan  The architect or group of authors plan the work to be done once the high-level requirements (HLRs) have been defined.
Planning includes the following:

  • Determining and agreeing upon the HLRs for the project.
  • Assigning HLRs or sections to the various requirement authors.
  • Determining the structure in which to write the requirements.
  • Determining a timetable to complete the various sections of the requirements.
   2    Do  The authors create all functional requirements that lie within the HLRs or sections assigned to them.
   3    Review The requirement authors review each other’s work. They read through the requirements as if the subject matter were new, asking open-ended questions such as “How does this functional requirement connect to the scope?” and “Why is this requirement important to the scope of the project?”
   4    Improve Consider and implement the suggestions and comments received from the other requirement authors. Requirements should be improved through editing content, grammar, and requirement structure.
Note: The Architect will be accountable for ensuring updates are made accordingly.


Requirements Workshops

Requirement Workshops can be very effective for gathering requirements. They are more structured than brainstorming sessions, and participants collaborate to document requirements. A workshop is an effective technique when there is more than one analyst working on gathering and documenting requirements through facilitation and documentation.

Through these sessions both business unit and development subject matter experts (SMEs) collaborate to define and review the business requirements for a system. This allows the two parties to resolve any differences of opinion regarding the design.

More information on Requirement Workshops may be found within the IIBA BABOK V3.0 Guide.


The architect of a project is responsible for the Requirements Architecture as a whole. He or she will own the role of owner of the requirements.
Responsibilities include:

  • Determine completeness of the requirements.
  • Determine consistency of the requirements.
  • Determine the requirements align with the scope of the project.
  • Determine the structure of the requirements adhere to the guidelines that your company has set for requirements writing and documenting.
  • Coordinate with the other requirements authors.

Additional Techniques

Additional techniques for collaborative writing can be found in a number of ways:

  • Printed and online publications specializing in Business Analysis.
  • Online academic or scholarly articles from leading business universities.
  • Industry leading conferences such as ones through the IIBA.
  • Industry leading webinars from sources such as the IIBA and Bob the BA.

Functional Decomposition: What Have You Done for Me Lately?

Oh no! Functional decomposition!

It sounds like an evil villain from an elementary school play like tooth decay or gingivitis. Actually, functional decomposition is a BA’s favorite tool. If you haven’t heard of it then you are in for a treat. If you have heard of it, don’t worry there is a still a great lesson to be learned in the following article.

Functional decomposition, according to the BABOK, “Helps manage complexity and reduce uncertainty by breaking down processes, systems, functional areas, or deliverables into their simpler constituent parts and allowing each part to be analyzed independently” (BABOK, 2016).

You may be asking yourself, “What does this mean for me?” Functional decomposition is used to break down a complex process in order to capture all the needed requirements for a project. If you use the tool properly you will be able to break down all the functional areas in order to provide more complete project estimates and requirements.

I have used functional decomposition throughout most of my career as a BA, but sometime in the past few years I stopped using it as I had access to various project management and requirement documenting tools that assisted with the process of gathering requirements and project estimation. The problem is that there wasn’t a real functional decomposition occurring and my projects suffered for it.


It wasn’t until a year ago, after speaking with Bob Prentiss ( through a seminar that I realized what was missing from my routine and could increase the accuracy of my estimates for my projects as well as assisting in avoiding missing requirements. Bob unlocked this part of my brain that had been shut off temporarily almost like a code word in a spy novel to unlock hidden abilities in an agent or in my case hidden potential.

Using something similar to the following diagram you can take your main project and break it down into its functional areas or your requirements.

mcintire 101717Notice how the project is broken out into its various functions? Then each function in turn may have sub functions. I prefer to label my items using either color codes or in the example shown number codes. This way I can see how my requirements will flow through my requirements documentation and aides in traceability. I know that I have a Function 1 and that function has Sub Function 1.1 and Sub Function 1.2 helping me in documenting all requirements and aiding me in preventing missed requirements.

The lesson to be learned is to not forget about the available techniques and tools at your disposal when working on a project. We can easily get side tracked by timelines or stakeholders requesting for updates and immediate results that we forget to slow down and use every appropriate tool or technique at our disposal. We need to take time to plan out our requirements in order to provide a better end product. We should be saying to ourselves “Functional decomposition: What haven’t you done for me lately?”

Facilitation Rules to Live By

Ground rules are essential for any meeting. It can determine the success or failure of a meeting.

As a Business Analyst, we are constantly organizing and facilitating meetings of various sizes to progress through the SDM (System Development Methodology) for a project. It is important that all project stakeholders understand what to expect from subsequent meetings in order to be prepared. Ground rules are generally discussed during the kickoff meeting, documented (and stored in a shared location?), and then displayed moving forward.

Are ground rules needed for every meeting? Not necessarily. It is safe to say that ground rules aren’t needed if you are having a one-on-one with someone you know, who is someone you have worked with in the past, and he/she knows your facilitation methods. One-off meetings are another scenario where ground rules may not be needed. Use a gut check and determine if ground rules need to be created prior to the meeting. If the meeting is with unfamiliar faces, then an established set of ground rules will allow the meeting to progress smoothly without disrespecting each other’s views on the topic.

But where do we start?

The Buy In

Prior to establishing the set of ground rules, it is important to get Management buy in. Communication is needed between the Business Analyst and Management in order to discuss the purpose of ground rules. The support from managers who are responsible for each project stakeholder will help enforce rules if there are rule violations. The managers can support you in a time of need when something needs to be escalated to them at some point during a project’s life cycle. Make it clear to the managers that the ground rules will provide a structure to the meetings, encourage participation, and support the company core values.


Advancement in technology has aided the modern workplace with mobility, employee efficiency and collaboration, and increased security. People are working smarter rather than harder than their previous counterparts. This is great for the employee as well as the employer. Employees can work remotely from the office setting to complete their work through video conferencing or teleconferencing.

However, there are times when technology may get in the way. Especially in an environment associated with a meeting. We have all been in the position of a facilitator when we attempt to actively engage each participant. Meanwhile each participant in the meeting is on his/her laptop performing tasks not associated with the meeting topic, or on their cell phones browsing social media apps, or they are eying the lunch special at their favorite restaurant. Communication is a two-way street and when participants are not actively listening then the purpose of the meeting is lost.

To correct this, the facilitator must set ground rules in advance of the meeting. The rule can be simple: Phones and laptops may be brought, but must remain off or closed unless needed. Ultimately, the facilitator and scribe should really be the only meeting attendees using devices during this time.


Safe Zones

How many times have you been in a meeting and arguments are occurring over a topic or a meeting participant has a highly negative opinion of an idea? People are often categorized as extroverts and introverts. Extroverts enjoy meetings because they are used as a pathway for their voice to be heard. Introverts dislike meetings because they are noisy and their ideas are often misunderstood or ignored. Creating a “Safe Zone” avoids one person domineering a meeting and allows for free flow thinking and idea generating.

The purpose of any meeting, especially initial research sessions and requirement gathering sessions for projects, is to convey your thoughts and ideas to a group. The group in turn asks questions and then more ideas are generated. Essentially brainstorming ideas and solutions together. People must respect each other’s ideas and opinions. Clarifying questions are welcome, but judgmental questions are not allowed. Interruptions must be avoided when someone is speaking and actively listen to the speaker in order to fully comprehend what is expressed by the speaker.

Staying on Topic and Be on Time

Time is valuable. Respect the meeting time and arrive to the meeting on time. I prefer to allow everyone to leave a meeting at least 5 minutes early to allow the participants time to get to their next meeting. If someone arrives late to a meeting, then leaving early is no longer an option and in most cases the meeting has already started. This causes disruption and valuable time is lost.

If you are the facilitator create an agenda and stick to the allotted times for the topics. Assign a time keeper in every meeting. Avoid stealing time from each speaker and to make sure all topics are discussed.

Open It Up for Discussion

As the facilitator, you set the ground rules, however, it is easier to enforce the rules when everyone agrees to do so. Open the rules up for discussion. This is an important step for reoccurring meetings, but may be necessary for a single meeting as well. It is probable that others may have their own rule they would like added or need clarification on the rules already defined. If the stakeholders feel they have more of a buy in to the process it is much easier as the facilitator to hold everyone accountable.

Document and Display the Rules

Documenting the ground rules is important. It reminds meeting attendees what is expected of them. There may be times where someone will forget the ground rules and he/she may need a place of reference. Ground Rules can be documented on the agenda, in a central repository, displayed on a white board in the room, in the email invitation, or even displayed on a giant sized Post-It note in the room. The rules should be visible to act as a reminder to those participating in the meeting.

Enforcing the Rules

As the facilitator, you don’t need to become the “ruled police” to enforce the rules. Everyone is responsible for their own actions. Since everyone has agreed to the rules, it is necessary to have a unanimous group mentality to make sure the rules are not violated. As a facilitator, you will need to be conscious when a violation is occurring and you may even need to intervene. If the frequency of the violation is low (once or twice during a meeting) then there may not be an issue, but if the frequency increases then enforcement must occur. The action taken may be as simple as restating the rules. Remind everyone of the “Safe Zone”. If a violation is frequently occurring or very distracting, then a direct one-on-one discussion may be necessary. Private discussions may be difficult and stressful, but remember it is important that everyone feels respected and safe to discuss ideas freely.

In the end, ground rules create efficient meetings and respectful environments where it is possible that quiet voices can be heard and share their ideas and it harnesses the strong voices to become active listeners.

Pet Rats and Change Controls

A stigma has often been associated with change controls or change requests in regards to requirements of a project.

There is this aura around the words “change control” that gets a negative reaction from stakeholders and BA’s alike. It usually means there is added work to the project. Which, in turn, means the requirements will have to go through the approval process again. If you have read my previous article, then you already know my love/hate relationship with the stakeholder approval process.

Even so, I like to think of change controls as the misunderstood animal of a project’s lifecycle. Take rats for instance. They are often represented in the film industry as disgusting creatures that eat garbage from dumpsters and live in the sewers. They are also blamed for spreading the bubonic plague even though they were simply a host for the disease-carrying fleas. No one ever thinks about the “goodness” in rats. I prefer to think of rats in the light of Master Splinter from Teenage Mutant Ninja Turtles. They are quite affectionate and rarely bite people. They are extremely intelligent and can perform tricks if trained properly; similar to a dog. If you take care of them well enough they will love you always.

One look at my daughter’s pet rat jumping from a chair into her arms 5 feet away after being coached to do it changed the way I view rats forever. One word. Adorable.

Now. I don’t think that I will ever call a change control “adorable”, but like rats, they are often misunderstood. Yes, they create more work for all parties involved. Yes, we have to go through the approval process one more time. However, they provide a better end solution or product. They are often necessary to express clarifications or add a missing piece to the solution. Just because a change control is needed doesn’t mean someone made a mistake or didn’t do their job. On the contrary, we need a change control because someone is doing their job. Someone noticed something missing or incorrect and requested to have it fixed.
In order to reduce or even eliminate all together the stigma surrounding change requests we, as BA’s, need to educate ourselves and our stakeholders. What is a change control? What does it mean for me? Is it good or bad?


What is a change control?

According to the BABOK, a change control is “controlling changes to requirements and designs so that the impact of requested changes is understood and agreed-to before the changes are made.” (BABOK, 2015)
In essence, it doesn’t mean that someone missed a requirement. Although, this may happen. No one is perfect; therefore, no project team is perfect. Requirements may get missed or a better solution may be presented that affects the requirements. The change control documents these changes within the requirements.

What does it mean for me?

As a BA, we are change agents. In my opinion, the term change agent should be in every job description for any BA role. So, if we are change agents why are we so afraid of change controls? I think, often times, we look at the negative associated with change. At least, initially. I know from my past experience I would view the need for a change control on requirements as something that I missed or something I got wrong, which means I failed. I’ve learned that we need to accept change. There are things that are out of our control and we need to be flexible to make changes that benefit the project. Remember, you are not alone. You are part of a project team. The requirements were created together with everyone’s input considered. We are all accountable, so to not accept the change needed may negatively impact the project as a whole.

Does this mean we just accept any change control?


Each request will need to be evaluated for benefit and impact on the project. If the benefit is high and the impact is low, then it may be a no brainer to create the change control. If the request is somewhere in the middle more analysis is needed to identify the cost, benefit, duration, and resourcing before creating the change control.

Are change controls good or bad?

Change controls are not characteristically good or bad. They are a necessary cog in the project lifecycle. Without change controls, we risk introducing a solution that is not complete or not what the stakeholders requested. If there is a better solution or a clarification needed to the requirements it is the BA’s job to document, it. We need to stop looking at change controls as “bad” and look at them as sometimes “needed” in order to fulfill our duties as a BA.

In the end, you will be thankful that change controls are made because it will avoid rework later in the project lifecycle, internal audits against projects, poor customer experiences, and provide better customer solutions.

After all, if you had a pet rat, wouldn’t you want it to show you affection and know all the tricks?

BABOK®: v3: A Guide to the Business Analysis Body of Knowledge (2015). pg. 443. Toronto: International Institute of Business Analysis.