Business Analysis: Is it a Bottleneck in Your Project?
How often is a project manager, architect or developer waiting on the Business Analyst to complete a requirements document, finish a model, or finalise a process. As all business analysts (BA’s) know it takes time to identify and talk with all stakeholders, elicit requirements, analyse them, then document and review them. And as good business analysts we all want them perfect and very detailed with no ambiguity. But how do you produce such well defined, clear, concise, non ambiguous and detailed requirements in projects where expectations are greater, deadlines are getting shorter and budgets are tighter. As the time given for gathering and documenting requirements decreases, so too does the detail and quality of the documented requirements. We all know how long creating those amazing models takes.
I have worked in a number of organizations and on many projects, and it is common in project teams to have only one person acting as the business analysis on requirements, while there is a team of developers making the code changes or developing the software from scratch. After all – often only one requirements document may be being produced so why put more than one person on it.
Getting good quality detailed requirements is critical to a project and a good business analyst is required to produce them. But why not put two or three or maybe even more business analysts on a project or function. When was the last time you worked on a project where business analysts outnumbered developers? So why not have more people working on one of the most critical phases of a project? Some of the advantages are shared knowledge, collaboration, peer reviews, a greater range of ideas and possible solutions, and reduced timeline if more resources are available. And any cons can be overcome with good project and document management techniques and tools, even egos can be overcome. But often a company’s business analyst’s resource is stretched and putting more than one on a project or function is just not possible.
So if we can’t apply more people to the problem of reducing the requirements timeline then how else can we do it? Well we see more and more talk about agile development methods where business representatives talk directly to the developers cutting out much of the need for BA’s. This can work in the right situation and in the right environment, but many companies and projects have found agile causes more problems with overruns and quality issues when not fully embraced and understood.
I have seen a project work where multiple BA resources worked on the requirements and specialised in particular areas. The requirements were not completely detailed up front but the business vision was, and high level requirements were documented to a level that allowed estimation to be performed. Then as each iterative development phase started on each business area the BA responsible would verbally present his or her concept to the development team in detail, with mock screen shots or story boards, models of the process, and associated business rules. Allowing the developers and testers to see the complete picture as well as the detail is important and allowing them to ask questions and seek clarification on issues instantly speeds up the process of transferring information. If anything does change then an efficient and quick change management process is very important.
The process of documenting requirements is often a lengthy one that produces many large documents. I know I have written many large requirements documents full of detailed requirements, Use Cases and diagrams in my time. On the positive more time gives our requirements more detail and clarity, unfortunately this can often lead to more time spent on changes and change control.
So is a large requirements document or many Use Case documents the best way or best practice. Well the answer is it depends. It depends on the organization and their development process and rules, and if the whole team is located together. Some organizations still have a very rigid waterfall development framework, strict financial models, that requires formal reviews by a large number of stakeholders before the next phase progresses. They rely on large detailed requirements documents and accurate cost estimates. The costs are a large part of this process and it is easy to understand all these controls in a large organisation, but it does mean the requirements process of capturing, analysing, documenting and reviewing requirements takes a long time. We see more and more press about agile development methods and many companies want to take advantage of these without understanding how their whole development framework needs to change.
So what we want is a way of speeding up the requirements process without losing any of the detail or the communication to stakeholders that allows them to confirm the requirement and therefore deliverables are correct.
Vision documents are excellent at capturing the stakeholders’ vision and needs of what is to be delivered, and Use Cases and User Stories are effective ways of communicating how someone will interact with a system and how it will respond, as well as capturing the all important alternate and exception conditions. The quality of service requirements are also important as they give us the parameters by which the system must operate under. Other supplementary specification documents capture report and interface requirements. So it is important we capture all of these things and convey them for approval to the stakeholders and developers. It is how we do this that can change and speed up the process.
I know if I have to stand up in a room and present requirements or Use Cases to a group of people I really want to know and understand what I am talking about so I can not only present it well I can also answer questions on them. So if I have to present requirements to stakeholders or developers and a view of the proposed system then I also want to know I have captured all the detail and understand it well. People also seem more open to asking questions when there is someone there to answer them. You also have the advantage of seeing if people are confused or lost when you’re explaining something that allows you to rephrase or simplify what you’re saying.
I have found that by talking to stakeholders and developers you are able to convey more information and understanding than from just a written document, in a much shorter time frame. But it is important that everyone hears the same information and gets the same picture. So conveying requirements verbally to developers is seen as answer to speed up the development process as we see in agile development, especially if you are always available for developers to confirm details with. As with anything there are risks but there are ways to mitigate them.
So in my experience a middle ground is important. We need to capture the business’s vision in a document because it will be referenced a lot and it is an important we capture it in detail and clarity.
With requirements and Use Cases capturing a high level view is important but much of the detail can be conveyed verbally. We need to capture enough detail to ensure we have identified everything and have enough detail to perform a preliminary estimate. And detailed use cases are important for critical or high risk parts of an application. And working closely with developers, architects, and testers is important. After all it’s about the solution and not just the requirements.
Don’t forget to leave your comments below.
Ross Wilson is a Principal Consultant with Equinox Limited in Auckland, New Zealand, specialising in requirements management. He has been working in IT for 27 years and has a wealth of varied project experience in a number of different industries. For the last 14 years, he has focused on business analysis, project management, and team leadership. Ross can be contacted at [email protected]
As business analysts we have a wealth of knowledge, information and experience to tap into. There are many different books on eliciting, documenting and managing requirements for a business wanting a new capability or a new product or system. There are numerous web sites that have articles and information for business analysts, plus many blogs discussing ideas and issues facing business analysts. There are many different techniques to use and methodologies to follow. And for projects where there are hundreds of requirements from many different stake holders we have Excel spreadsheets, and requirements management tools to assist with controlling and managing the requirements. So with all this to help us why do things still go wrong?