Can you hear me now ? Helping Business find their voice.

 digg it |   delicious |   StumbleUpon |  reddit 

In an ideal world, excellent requirements result from a thoughtful, well-informed discussion between business stakeholders and professionals who provide the services and systems required to keep the business running and make it grow. Naturally, the conversation might require translation between the two sides, to ensure common understanding of business goals and technical details. Fortunately, there is the Business Analyst, whose role precisely addresses this difficulty.

So it's all good, right? Every company with a BA team produces excellent requirements arising from ideal collaboration between business and IT, right? Of course not, and I need not tell you that. What may surprise you is the extent to which business involvement varies across companies in the requirements definition process. In just the last two months, I have visited two customers who represent two extremes in how (or even whether) business should be involved in the process of defining IT requirements:
• Company A has a number of business issues, not the least of which is an ongoing loss of marketshare. In this company the LOB owners have a modest role in the definition or prioritization of IT requirements. On an annual basis, IT teams identify projects and technologies that are of interest to them, and then present the list of candidate projects to the business owners for their prioritization and approval. Once projects are approved, IT teams return to their labs, scope out their projects, decompose the scope into requirements, and build out the system. (In practice, these activities are rarely done in this order, and are sometimes done in parallel, but that is another discussion.) Meanwhile, business owners must figure out how the proposed system will help them achieve their business objectives. Whether they can or not, they are still going to receive the deliverable. The good news is that it will probably be on time, as their IT department takes great pride in its history of meeting project timelines. The bad news is that it may not provide any business value. As you can imagine, this is not working out well for this company. When I asked how this state of affairs arose, the customer blamed history and culture. "We're a technology-driven business. Business stakeholders aren't expected to be technologists, and tend to defer to IT on these questions. But we can't keep going this way. IT can't be expected to know what our customers want or need." Company A has asked us to help business find their voice in the requirements definition process.
• Company B has no in-house IT development staff. Instead, they assign BA's with specific domain expertise to various lines of business. BA's take requests (usually highly urgent ones) from LOB owners, package them into large specification documents, and contract with offshore vendors who complete the work. BA's at this company do very little requirements elicitation or elaboration, and focus mainly on completing specification document templates. The perception is that the requirements are fully described in the business case that justifies the request. Indeed, many of their "business cases" do read like specification documents. Business cases often include curiously specific requests like "We need a screen on the customer accounts page that looks like this..." without documenting the business need behind the request. LOB owners are dissatisfied with the length of time it takes to complete a project, and often submit a NEW! URGENT! request before their previous project has been completed. As you can imagine, their projects have a higher-than-expected failure rate in terms of returning targeted business value. BA's are frustrated by having to create such detailed documents without knowing the full story behind the requirement. They could provide significantly more value to the company than they do today. This company has asked us to help them structure the requirements conversation such that LOB owners can focus on high-value business initiatives rather than technical minutiae, and BA's can flesh out those initiatives into clear and complete requirements.

The good news is that, even for these extreme cases, the solution is the same. Requirements should depend on the business problem they are meant to solve. A company seeking to gain a handle on its requirements definition process needs to start at the topmost node in the hierarchy of business objectives. If the mapping has not been established and documented between a given project's scope and overall Business Objectives, the BA may have to return to the PM team and/or LOB owners for that mapping, and ask them to validate whether the project is in alignment with where the business is headed. Once this is in place, requirements can then be decomposed from general statements to the required level of specificity, be it to the point of writing textual requirements, use cases, screens, or an integrated model including all of these. The role of the BA is to drive this process and ensure that each requirement supports business goals.

I describe these companies as extremes on a spectrum, with Company A shutting their business stakeholders out of the requirements discussion, and Company B allowing business to thoroughly dominate the requirements and implementation discussion without active involvement from BA's or IT entities. In reality, these are manifestations of the same problem: a focus on the technology to-be-delivered, rather than on providing value for the customer.

In the case of Company A, this means that the requirements discussion can no longer begin with IT deciding which interesting things they'd like to develop in 2010. Rather, business stakeholders must define the path to regaining recently lost market share, then lay out a step-by-step plan for traversing that path. This plan will become a strategy document, against which projects and to-be-developed technologies will be weighed to ensure they support the strategy. In the event that projects in planning or development phases cannot be reconciled with the strategy, they should be scrapped. Company A will have some difficult and painful choices to make, but the alternative (continuing to lose market share) is not sustainable.

Business stakeholders in Company B already have such a strategy in place, but have not carefully mapped their initiatives to the strategy. And it is easy to see why: without an IT department that owns the design and implementation of the solution, their business people have adopted an affinity for the technical side of the requirements discussion, rather than driving business value. BA's will have to work hard to redirect business attention away from the implementation of a request, and towards the desired business objective. As with Company A, this will not be easy, but the benefit will be felt across roles:
• Business will receive valuable and relevant project deliverables.
• BA's will provide value by decomposing requirements from the business strategy into requirements statements, use cases, and (perhaps, but not necessarily) new or revised screens on the customer portal. In addition, their job satisfaction will likely improve, as their focus will turn more towards requirements themselves, and the information that goes into good specifications, rather than filling out templates.
• Offshore consultants will have much better artifacts to plan, carry out, and validate the business value of their work.
How well have you structured your company's requirements definition process? Symptoms of a flawed RD process include:
• One or another of these two examples strikes a familiar chord. (Or, Heaven help you, both of them do.)
• Features are often removed from and re-added to project deliverables.
• Projects do not deliver the intended business value.
• Projects are often late and/or over budget due to rework.
• IT teams find themselves providing similar or related services for multiple business units, but are unable to merge the projects.
• You laughed nervously at the Dilbert cartoon and thought, "That sounds familiar."

If any of these are true for you, your company might need some help in creating an RD process that provides the greatest amount of business value, and allows Business Stakeholders, Business Analysts, Development, Quality Assurance, Project Management, and other parties to focus on what they do best.