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

 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.

 

---

Big Freaking Requirements Documents !

The typical requirements document is a long, sprawling piece of literature. Within it, one might find a title page, table of contents, change history, complex headers and footers, legalese, confidentiality notices, and, if you're lucky, maybe even requirements. It's length is probably due to the fact that it tries to be everything to everybody. But the problem is that the document isn't read entirely by any single person, except perhaps by the analyst who wrote it in the first place.

And parts of these documents are only relevant to certain people. High-level overview stuff is great for managers, but developers could care less about the project's "vision"; and testers only require certain parts themselves. (Though one might argue that they should read this stuff, in order to provide context for the job at hand).

In theory, having all of the requirements in one document makes everything easier to find, as well, and to see how all the pieces fit together. In practice, however, the document becomes difficult to manage as it grows over time, and these linkages fall apart.

 

The question that I always seem to ask myself when take a peek at a customer's requirements document template for the first time is, "why must us humans unnecessarily complicate our lives like this?"

One of the core reasons, I believe, is that managers still want to put their monogrammed gold pen's ink on something tangible, sign on the dotted line, and have everything recorded so that somebody (namely the BAs that report to them) can be held accountable in case something goes wrong... which will happen, because nobody understood, or questioned the contents of the document in the first place.

Luckily, from where I sit, I believe that the typical printed requirements document is nearing its death. And the good news is that this eventuality is closer than most people think. Yes, for some companies this dream will be further away than for others, but Blueprint has actually witnessed this happening at some of the more progressive companies that we've worked with (thus restoring my faith in humanity).

Tools for the Business Analyst, like ours, help to take requirements and break them down into managable deliverables, suitable for consumption by various stakeholders with different needs, while *still* maintaining cohesiveness.

 

---

Tools for the Business Analyst? Better Late than Never

In the 90's the Standish Group with their "CHAOS Report" quantified the alarming rate of project failure in the software development industry and the associated costs businesses incurred as a result. It also identified poor requirements as a primary contributing factor. Over the last twenty plus years, the CHAOS Report has consistently told us that the project failure rate has not dramatically improved and poor requirements continue to play a leading role.
RM or Requirements Management was a term coined to cover the entire problem set at the time and a push was underway to convince development organizations to stop relying on office automation tools (Word, Excel, PowerPoint, Email) to document and communicate their project's requirements throughout the SDLC. Solutions such as DOORs, RequisitePro, and CaliberRM were introduced to the market as RM repositories. Textual requirements were typed directly into these tools instead of a Word document and they could be used to track each requirement's priority, status, due date, risk factors, etc. Edit histories were automatically recorded and trace relationships could be established and maintained between requirements for more meaningful analysis of both requirements coverage and the impact of proposed change. The focus moved from the document to the individual requirements themselves.
However, this early RM approach assumed the correct requirements were entered into the repository to begin with and that was a false assumption. As the old adage goes "garbage in, garbage out". It doesn't matter how well you version, baseline, trace requirements to each other. If the starting requirements are incorrect, incomplete or missing altogether then the team will surely encounter some unpleasant and very costly surprises further down the line.
RD or Requirements Definition was born of the acknowledgement that requirements had to be discovered and defined properly before they could be managed forward through the SDLC. As you might expect, solutions appeared in the marketplace to help facilitate the accurate definition of requirements: DefineIT, SteelTrace, and Profesy (later renamed "Requirements Center").
Additionally, there was focus placed on the visualization, prototyping, simulation of requirements to enable true validation that requirements are correct, complete, and aesthetic concerns, important to the business users, were not left to developers to figure out. Again, solutions like Apptero, Simunication, and others appeared on the scene.
Today the industry knows this collective space as RDM: Requirements Definition & Management and it includes visualization/simulation. However, the desired goal is not a collection of standalone products each addressing their own specialty but rather, a single integrated solution that addresses all of the challenges analysts face day to day, effectively becoming their workbench.
Developers have had their IDEs and integrated source code repositories for decades. Likewise, QA has had their test management and execution platforms for years. Finally, emphasis has been placed on the intrinsic importance of requirements and getting them right and the BA community will get the attention they deserve in the way of holistic solutions catering to their needs as a defined profession. It seems we're the last in line but better late than never.

 

---

Subject Matter Expertise - Take Your Medicine Wisely!

We've all seen the drug ads with the picture-perfect family playing Frisbee with the dog on the beach and the narrator telling us how your symptoms can be wiped away and usher in the dawn of a whole new healthy and contented lifestyle. Then the narrator becomes monotone as he reads at warp speed through a long list of pre-existing conditions that exempt you from taking the drug. Yes these drugs can be very beneficial but only under certain circumstances and in certain situations. If you take the drug outside of these circumstances it could actually cause more harm than good. I have a similar answer for people who ask if it's good for a business analyst to have subject matter expertise. In certain situations it can be a great asset, but in others it could actually be harmful.

The case "for" having subject matter expertise is pretty straight forward. The analyst doesn't have to be educated about the domain and can leverage his or her experience in the area and previous lessons-learned to the project's advantage.

There are occasions where it can actually work against the project's best interests. More than once I've seen subject matter experts who cut short the analysis that should be performed because they "think" they know the answer based on previous experience. Sometimes they're right - but many times they're wrong. In some of these situations I've also seen others on the project hesitate to challenge because the subject matter expert is supposed to be - well, the expert.

For a skilled and inquisitive business analyst to enter a project without subject matter expertise can actually be a benefit. Non subject matter business analysts have an open license to ask the so-called "stupid questions" and people have this expectation. These types of questions routinely uncover hidden issues that could have been disastrous later in the project. I've also noticed people can be more with this type of business analyst - possibly because they assume the business analyst knows less about the subject than they do so there's an element of feeling less threatened coupled with an natural inclination to help along "new comers" to the subject.

So should you actually try to steer clear of business analysts with subject matter expertise? Well, like the drug example, it depends. Before considering subject matter expertise, there are far more important skills a business analyst should have like being able to truly listen, facilitate, negotiate, and to have real analytical skills and modeling skills. To this I'll also throw in diplomacy and political savvy. Because vast majority of people I speak with agree with this, and after some discussion also agree that subject matter experience is lower in importance, what I find puzzling is why most ads for Business Analysts list subject matter expertise as the most important aspect of what they're looking for. Here's a sampling of ad headlines I just took from some online boards:

• Seeking strong BA with digital media and online content experience.
• Looking for Business Analyst with HR and Recruitment experience.
• Looking for Business Analyst with Vendor Management experience.
• Excellent Opportunity for ERP Business Analyst.
• Business Analyst - Investment Banking.

Perhaps as the profession continues to mature the key characteristics of what makes a good business analyst will become better known and sought after.

So if you're going to take subject matter expertise, here's my prescription:

• Before considering taking Subject Matter Expertise you should already have: listening, facilitating, negotiating, diplomacy skills, analytical skills, modeling skills and political savvy.
• Only take Subject Matter Expertise in combination with humility, true listening, and the liberal asking of ‘stupid' questions.
• Use the effects of subject matter expertise to probe more deeply, as a source of additional questions, and to help validate what you discover.
• Never rely on preconceived notions - do your analysis, and leverage your subject matter expertise to do better analysis.

 

---