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 firstname.lastname@example.org.