The Business Analyst role in most organizations I have worked with is passive and reactive by design. Analysts are given a feature description and tasked with defining the requirements for the same. The analyst then goes off to perform a set of activities and tasks like elicitation, model creation and requirements definition. Eventually, they create a requirements document that gets reviewed, approved and handed off to the development team for further action.
In almost every situation, the development team will push back stating that there is too much scope to deliver within the constraints of the time and resources they have been provided. The document will get kicked back and the analyst will get involved again to prioritize the requirements to be delivered by the development team. Some items may be cut from scope (this happens very rarely, if ever;) while others will be pushed back for future releases. This process will iterate a couple of times before everyone agrees to a scope for the release and moves forward.
The analyst is treated as a semi-skilled resource to flesh out the details of a product concept initially (dreamed up by someone “higher up the food chain”), and react to the development teams needs for scope control later in the process. However, they are not permitted to perform vital tasks around product definition and scope control proactively. Analysts are not permitted (or, at the very least, strongly discouraged) to ask basic questions around the need for requested features, suitability of requested features to solve the business problem at hand, quantification of the business problems that the solution will address. In short, they are almost totally forbidden from really understanding the problems being addressed by a solution and its suitability for the same.
Prohibiting analysts from performing these kinds of higher level tasks deprives the organization of significant benefits to be gained from these key areas.
- Ensuring that business objectives are understood by everyone involved with the project. This is the single most important factor driving scope control and feature prioritization. Without this understanding, prioritization is just a well-educated guess on the part of everyone involved with the project. My experience observing this kind of guesswork in action is that it is no better than a random walk through the feature listing. In other words, it is not very effective.
- Ensuring that the designed feature set will satisfy the business objectives. This is a key failing with many efforts and the risk is particularly high for long term projects. As business conditions change over time, the features being delivered must constantly be reassessed for suitability to current realities. The simple reality is that for the most part, no one is doing that now. This sounds like an incendiary statement. But look around your own organizations and see if you can positively identify the person or group that is tasked with doing this systematically on all your projects. I wager that you will be both surprised and depressed by what you find out. There is no reason that the analyst should not be this person.
- Reducing the number of features. Studies have consistently shown than 2 out of 3 features that are delivered are seldom or never used. If analysts are not empowered to make significant scope changes beyond reprioritization, chances are these changes will never be made. Building useless features is a tremendous waste of time and resources. It ultimately manifests itself as failed and canceled projects. Feature removal in a systematic and sensible way that supports the overall business objectives is simply not possible without empowerment of your analysts.
- Driving feature prioritization proactively instead of reactively. By empowering analysts to identify key features needed to satisfy business objectives up front during envisioning, the development team can staff appropriately. Additional scope control becomes the exception (or a purely tactical decision) and not the norm as is common with the bottom up prioritization driven solely by development constraints that happens today.
- Budgeting properly to satisfy business needs. By letting analysts drive feature selection, a true picture of effort will emerge. Projects can then be funded realistically based on what is actually needed. In today’s world, budgets are allocated largely based on guesswork and T-shirt sizing during planning. These may or may not reflect reality as no one is actually tying features to business objectives during these exercises. Once money is allocated, it is extremely difficult to get additional funding for projects that were under scoped at the outset, typically resulting in a crippled product no one wants. At the other end of the spectrum, projects with excess budget spend the money they are allotted regardless of business value. The net result is waste through acts of commission and omission.
If a lot of what you are reading sounds awfully similar to what you would expect a Product Manager to be doing, you are correct. Business Analysts are the closest thing most organizations will ever get to Product Managers for their in-house development projects. It makes sense to empower them to take the final step towards product management, in the real sense of the term. They are extremely valuable resources who should be tasked with delivering real, measurable value to companies instead of artificially crippling the role based on outdated thinking. This unfathomable reluctance to empower analysts is costing billions of dollars in lost productivity gains annually. If they are smart enough to work on the details of what you are building, chances are they can figure out the “what should we building anyway” quite easily.
Successful projects are the result of two things – building the thing right and building the right thing. Analysts are only tasked with building the thing right. If they are empowered, they can ensure that the right thing is being built.
