I am very passionate about the work that the Business Analyst (BA) does – I should be, I’ve been one for long enough. The role of the BA is critical to the success of any project. If the delivered system code keeps falling over, it can be fixed. If the system infrastructure is creaking, you can always throw another server at the farm. However, if you don’t capture the business requirements correctly, or if your BA team is inexperienced, or even if you just misunderstand them, you get complicated and costly problems.
I thought I’d walk through some of the pitfalls that can befall a BA work stream, having recently discussed a scenario I have seen before with an industry colleague. They work on a high profile, financial services project that is losing its way. The project appears to have been running for a considerable length of time and still appears to be at the requirements capture stage, with little in terms of artefacts and deliverables to show for it.
Stay within the project scope
BAs are incredibly inquisitive creatures. A good BA will uncover a thread, start pulling at it, keep pulling at it, trace it, follow it, absorb any information that thread unearths, consider and gain understanding of that information and will continue to doggedly do this until a satisfactory conclusion has been drawn. This is a wonderful approach to BA work and if your team are doing this then you have a winning set of BAs – a star team.
The only problem with this approach is that the BA’s understanding of a satisfactory conclusion does not necessarily meet the criteria laid down in your project scope. Working on out-of-scope items is a real killer for projects. Taking our unguided BAs, the work they do could very quickly become a week or two’s effort outside your project scope before the PM is aware and understands the issue. If you’ve got five BAs working on the project, then that two weeks easily becomes three months of combined lost effort, which few projects can afford to lose.
Work closely with the business
On site, I expect to see empty seats at BA’s desks, with the team out talking to the business, eliciting requirements, chasing down information, walking through use cases, reviewing wireframes and generally becoming an ever-present force in and around the business. There are times when this intelligence has to be shaped, ordered, tweaked and presented. However, even when that has been done, the business still needs to be walked through these presentations (unless you are lucky enough that your client actually reads your emails). Empty seats are thus a good sign of a healthy BA Stream – embrace it – don’t be afraid of it. If you see your BA team at desks all the time, then it’s time to question what is happening.
Share the vision – gaining business buy-In
This is a problem that arises when the BA stream begin to engage with the business. The business people you need to talk to are too busy to take time out to speak to you. This isn’t always the case as the business community have a vested interest in the delivery of a project/system that will make their life easier. However, this can be an indication of a communication problem from the stakeholders, where the vision has not been explained sufficiently to the business teams. This problem is common after the requirements capture phases of the project but it isn’t always limited to just that phase.
To tackle this and drive the project forward, a lot of diplomacy is required and you need to be able to manage the business community effectively. Sharing the project vision is often useful as staff in middle and back office roles are often overlooked by senior managers. Arrange convenient times to share this vision and try to get the team on side that way.
If this fails however, the problem must be resolved quickly lest weeks go by without BAs being able to secure sufficient time with the business. Everything is impacted, not just the BAs, and adopting the “can’t you be getting on with something else” approach to keep your team “busy” will often just exasperate the BA and compound the problem. Engage with your project and programme managers, talk to the project stakeholders and use soft power such as vision sharing to gain buy-in from the wider business community.
A roadmap for the BA delivery process
Those who have worked in Extraction, Transformation and Load (ETL) projects in the past will appreciate the distinct steps of:
- E Extract the data
- T Translate, make sense of, understand, format that data
- L Load that data to the required place
This is a simple roadmap that BAs should follow in their project activities. Development teams, testing teams and business colleagues need to be fed with information in order to work. For a BA, ETL becomes:
- E Capture/Elicit the requirements/problems/issues from the business
- T Assimilate the information, preparing it and formatting it accordingly
- L Present this information in a timely fashion to their consumers
A pitfall for BA work streams is to fall into the “analysis paralysis” trap. Through a lack of clear direction, the team loops endlessly through the E & T of the roadmap. This may be great for the BAs, satisfying their inquisitive nature, giving them an understanding of things both in and out of your scoping document. However, it is of no use at all to the project as a whole. The rest of the process requires clear, concise and accurate documentation in order to deliver the project. If your BAs don’t have a clear direction on what is to be produced and when, they may lose their way and spend months working very hard, only to produce very little. A Requirements Traceability Matrix (http://bit.ly/1OQe4Cg) is critical to prioritising, executing and monitoring the BA work stream’s activities. Fail to create and maintain it at your peril!
Timely and effective delivery of BA documentation
The nature of BA work is that it involves the elicitation and assimilation of large amounts of information, and understanding these requirements is critical to the success of any project. Information gathered can be used to foresee potential issues in the Target Object Model and also to identify those areas of the “As Is” state ( http://bit.ly/1OQe5Gj ) – problems perhaps even the current business/operations departments have not fully recognised.
But what use is it to the project to elicit that information, make that analysis, identify those issues and problems in the BA’s mind, if no documentation; no deliverable is produced?
For a project to succeed, the BA stream must document, document, document. The intelligence and information elicited needs to be stored somewhere where it can be seen and presented in a format that allows it to be easily consumed by the various people that need it. These include:
- Your business colleagues who need the confidence that you understand what they need
- Your development team who need to translate the requirements into code
- Your test team who need to understand how to test the business cases
- Your project manager who needs to know that risks are mitigated
- Your programme manager who wants to be assured that costs are controlled
Retention of project and requirements knowledge
It goes without saying that BAs are needed in the early phases of the project. Their role is critical to the supply of accurate information to the development and test teams further into the development lifecycle. However, there is a strong desire to release them once this phase of the project has been completed. This is a waste of hard earned and costly information.
Often when the development team are working from the functional specifications, issues and problems arise that need the BA to iron out. If the BA has been released, it is then very difficult to understand the reasons for the decisions made by the BA. Retaining an element of the BA team is crucial during the build phases.
The BA and testing teams should also be very closely aligned. Bringing testers in early on the project and partnering them with designated BAs ensures a smooth transition into integration testing and UAT.
So don’t be too keen to lose your BAs. They have an accumulated knowledge and an intimacy with the Target Object Model that is not necessarily present in your development and testing teams. I’ve taken those post-contract calls from harassed programme managers to come back to projects and sometimes I have been available. But not always…
Book a free consultation on managing business analysts now:
