Skip to main content

Author: Ross Wilson

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]

The Importance of Collaboration with Business Experts

importance1As 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?

I was thinking about this the other day while riding my mountain bike through the forest. I enjoy mountain biking and I have an average bike capable of doing what I need of it. My requirements were simple when I started and have not changed much, I needed something that would go off road in a local forest area which had purpose built tracks and I was not into jumping so something basic but strong would do. I went to a local bike shop that had a range of bikes and I was then asked a lot of technical questions about the type of riding, brakes and suspension needs I had. Mountain biking is a very technical sport and although the bikes don’t look that different they range in price and specification greatly. As the store assistant was the expert I asked for his advice and then made my decision based on price and features. As usual I ended up spending a little more than I had intended.

So what has that got to do with business analysis? Well, in the bike shop the assistant was seeking requirements and was also the expert. He knew the products and could advise based on his expertise and experience. He knew the questions to ask and explained the terminology to me as he described the different bikes’ specifications. So, as business analysts we know how to elicit (ask the right questions), document (write the requirements down clearly and concisely) and manage requirements (store them and apply other attributes to them). But we are not always experts in the industry, or area of business, or product we are dealing with. So we rely on experts from the business, not only for requirements, but also for information and advice. If we have incomplete or incorrect requirements, do we as business analysts really know that this is the case, if we are not the experts in that area? And do the experts from the business really understand what the requirements are meant to convey and really understand how important they are?

In many instances we gather requirements and then get the business to review and sign off on them. But this is often after only a single pass over the requirements and may not be to an adequate level of detail. It is important that we involve business people in a more collaborative approach and expand and dig deeper into the requirements as we get closer to developing them. Having a key subject matter expert from the business working closely with the business analyst to help detail the requirements can stop issues with terminology and terms, and make the requirements more easily understood by the business. I have worked in a few different industries and have found each one has its own language full of acronyms and technical terms. It is important that this language is used in the requirements. Even if we know the subject area well, it can still be good to involve someone from the business to work with in detailing the requirements. After all they are the users not you, and the user experience and interaction with applications is so important.

I have also seen places where the business is only involved up front and then, as requirements are developed, the direction of the solution may change in isolation from the business. This may cause many problems further down the track when the business sees the solution as part of user testing or worse at implementation time. The agile way of developing does encourage greater closeness and collaboration between the business and developers. Thus, the inevitable changes can be discussed and agreed with the business as they are being developed. Even if you’re not using an agile approach, close collaboration between the business analyst and the business is very important, as is continuing that communication and collaboration through the development and testing phases.

No matter what technique or methodology is being used, the tools you have available, the industry you work in, it is more about people. Finding experienced and knowledgeable business people to work with and learn from is important. The can help with ensuring the right language is used, and agreement on requirements is reached. They also will play a part in developing the solution. Finding that expert or group of experts to help make the right decisions is truly worthwhile, even if you end up spending a little more time working on requirements.

Don’t forget to leave your comments below

Ross Wilson is a Principal Consultant with Equinox Limited in Auckland, New Zealand, specialising in business analysis, and training. He has been working in IT for 25 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, training, project management, and team leadership. Ross can be contacted at [email protected].