In this article I discuss my experiences of the circumstances and reasons that lead to a business analyst joining a project some time after an upgrade or extension project was started. The project has usually stalled to some degree as a result of the technical team being unable to continue with certainty. They will have found unclear, ill-defined and contradictory business requirements emerging from their reverse engineering of the existing application, and will not be in a position to sort out the real, and current, business requirements.
In tackling this situation as a late start on an existing team, I outline my 3-pronged approach: (1) building my understanding of the organisation, (2) learning more about the project’s history and origins, and (3) delving into the existing solution so that I understand what is being offered to users, and how they are actually using it.
I round off by putting forward the outcomes that I look for from each of these approaches.
One of the things that you will find, when working in the role of senior, or consulting business analyst, is that you are often brought on to an upgrade or extension project some time after the project has kicked off. The usual reason for this is the management team running the project held the view that the project was a mostly technical endeavour, and the value of the analyst was deemed to be too low to warrant a full time someone in the role. The call was made to let our developers do their own analysis.
This scenario will play out for a couple of months, by which time our developers are usually expressing their concerns loudly to the project manager. Our developers will have come to realise that they have been given the unhappy task of reverse engineering the business intent of the application from the code. This is a challenge because of:
- Sprawling complexity.
- Poor conceptual integrity.
- Loss of organisational knowledge.
As a consequence of new and changing business demands, applications all tend to grow over time, often organically. The additional features requested by the business sees modules added, or existing modules changed in some way, with the development team of the time ‘hacking’ the changes in wherever necessary. The codebase balloons. Existing code is seldom refactored, and obsolete code-blocks are hardly ever removed.
It may take months or years, but eventually the application becomes a large, nebulous thing that challenges understanding and stymies fast, reverse-engineering type analysis.
Poor Conceptual Integrity
According to Fred Brooks;
“Conceptual integrity in turn dictates that the design must proceed from one mind, or from a very small number of agreeing resonant minds“.
Back in the office, it is likely that as time progressed multiple development teams will have worked on the application. This leads to the conceptual integrity of the application being undermined, which in turn obscures the intention of functionality. Symptoms of this problem include:
- our developers uncovering conflicting and ambiguous business rules in the code;
- questions like ‘is this a bug, or was this intentional’ and ‘did the business really want to have it work in this way, or did the previous team take a shortcut/not understand the technology’ being asked;
- and discovering that business rules have been dispersed throughout the application’s layers, from rules in stored procedures, to validations in the user interface, and everything in between.
Coupled with sprawling complexity, the loss of conceptual integrity makes the task of reverse engineering the business intent from the code a very challenging task indeed. Our developers will make a best attempt, but they may run into the third problem: who do we ask?
Loss of Organisational Knowledge
The problem of staff turnover is not restricted to development teams. It affects the organisation at large. People come and go all the time for any number of reasons. Given a few years, it is not uncommon to find that key business stakeholders, those who were responsible for stating the principles and business rules that underpin the application, have left, taking with them the rationale for many of the original design decisions.
Faced with a mountain of questions, our development team will turn to the business for clarity, but in many cases they will be unable to find a business stakeholder that can answer their questions. It is usually at this point that the team call a timeout, and request that a business analyst be brought on to the project.
This is where you step into the breech.
Engaging with the Project
So, how do you get going on a project that has been running for a month or two? I use a three-pronged approach:
- Understand the organisation;
- Understand the history;
- Understand the application.
This is not a prioritised, or ordered list. You are not going to start at the top, and work down. Instead you will find that you are often working on these items simultaneously. The point is to fully immerse yourself in the project, and to soak up as much as possible as quickly as possible. You are riding the learning curve to the max!
Understand the Organisation
Off the bat you need to get to know your team. Your solution architect (or technical lead) is going to be able to provide you with a lot of information about the problems that the team are running into, and the questions that they have. Get these down into a coherent format, and review them with your team. This is the basis of your to-do list.
Identify the business areas are affected by the change as these will set your business area scope. Agree this scope with the PM. You don’t have time to waste on working in business areas that are not important to building your knowledge of the application, so setting clear boundaries within the organisation is an imperative.
Building your view of the organisational structure. Once again, spend time with your PM and work on fleshing out an organisational hierarchy. Mine the company email system for contact details and add these into your organogram.
Importantly, get a feel for the company politics that is in play. Get very clear about how you should be approaching the business in your search for clarity. Identify who is able to make decisions about conflicting business rules. Understanding the hierarchy will also help you avoid the trap of stepping on toes in your quest for knowledge.
Using the outcomes from this prong of your approach you should be able to build:
- An organogram, or organisational hierarchy;
- A stakeholder matrix, with a start to formulating your communication plan;
- A business area scope statement.
Understanding the Origin of the Project
You need to get on top of the drivers as quickly as possible, and you have to be clear in your mind about the reasons that brought the project to come into being.
Again, I suggest starting by spending a session or two with your project manager. They will have been the primary contact with the business up until you joined, and they are likely to have valuable knowledge around the business drivers. Ask them for the Project Brief and the Business Case. Review these documents. Make sure you are asking questions when you come across something you don’t understand.
See if you can get time with the project sponsor. Although the project sponsor is often quite removed from the details of the project, they are crucial to your mandate. When they push you in the direction of a business stakeholder you are able to approach that stakeholder with their backing. This is very powerful, and you can leverage this to achieve quick results.
This prong of your approach should lead to the following outcomes:
- developing your relationship with your PM;
- initiating a relationship with your project sponsor;
- defining your terms of reference.
Understand the Application
An easy way to get up to speed on the application is to get on to a training session. The organisation may have a formal training programme, or you may have to approach a senior user for informal training. There is a lot of know-how locked up in the application, so the sooner you get to grips with the application the better. Spend some time just running through the application from end-to-end. Don’t just open up, and look at screens. See if you can complete tasks or processes. Use the application as intended so that you fully appreciate what is getting done when you work through the various features presented by the application.
If you can get your hands on one, read the manual. Many organisations will have taken the time to put together a user manual, and this can be a rich source of information for you. Often the manual will have a section that introduces the application, and you can mine these introductions for all sorts of valuable rationale that justifies the existence, and outlines the expected benefits delivered by the application. These justifications are often written early on, so you can use them as a sounding-board to make sure that proposed changes are still within the original gambit – or you can set about defining a new context.
This prong should lead to the following outcomes:
- An understanding of how to use the application;
- A start to developing a definition of the application’s business rules;
- A functional decomposition diagram or diagrams for the application.
This is an unsaid activity that you will be doing throughout your engagement with the project, but it is of utmost importance that you communicate frequently when starting up.
Be sure to share your learnings with your development team constantly – strive to keep them in the loop. Build their confidence in you.
Let your project manager know of your progress. Ask them for help when you run into headwinds. See if you can help them out with any of their documentation by applying what you have learned.
There is no one-size-fits-all approach to starting up late on a project. You will have to feel your way around initially, and you will have to craft an approach that is appropriate to your particular set of circumstances.
Plan to explore the problem along the three dimensions that I have laid out above. Keep your initial engagements short and frequent, rather than long-winded and infrequent. You will absorb much more if you are interacting with your stakeholders for short periods of time, a lot of the time.
Be sure to keep your team informed of the progress you are making. These guys are going to have to work on your specifications later on, but they have done a lot of work already. You don’t want to blindside them with sudden about-turns that undermines what they have already achieved.
Most of all, remember that the only correct answer early on is ‘It depends’. Be honest when you come across gaps in your understanding. Fix these gaps quickly, and then go back and ask your questions again. Soon enough you will be on top of the problem, and you will be well on your way to delivering a great new solution!