Here’s the conundrum that line managers of business analysts face: business partners/clients/customers want a business analysis service that provides both a strategic partner and a faster-than-light order-taker. Many BAs begin their professional lives in order-taker roles. Over time, they develop their skills and chance upon a situation where their insight, experience and knowledge enable them to contribute at the level of strategic partner. After the head rush and deep sense of professional fulfillment from receiving the first “Your contribution as our strategic partner delivered results far beyond our expectations” comment, few business analysts will be content returning to the role of an order-taker. A good manager understands that the BA as strategic partner vs. order-taker isn’t an either/or question, but is a question of organizational maturity.
Regarding organizational maturity, we need to remember the late 1980s when Watts Humphrey first published his Capability Maturity Model (CMM) as a paper, then as a book, Managing the Software Process. The 1989 model defined five levels that were points on a continuum:
- Initial (chaotic, ad hoc, individual heroics) - the starting point for use of a new or undocumented repeat process.
- Repeatable - the process is at least documented sufficiently such that repeating the same steps may be attempted.
- Defined - the process is defined/confirmed as a standard business process, and decomposed to levels 0, 1 and 2 (the latter being work Instructions).
- Managed - the process is quantitatively managed in accordance with agreed-upon metrics.
- Optimizing - process management includes a deliberate process of optimization/improvement.
According to the Software Engineering Institute, which sponsored the development of the Capability Maturity Model, "Predictability, effectiveness, and control of an organization's software processes are believed to improve as the organization moves up these five levels. While not rigorous, the empirical evidence to date supports this belief." That was the perception back in the late 1980s. Fast forward to 2012. We now have a variety of rapid iteration software development methodologies that have the intent of optimizing the software development process but, well, let’s be honest, are often misused to avoid doing the hard work up front of defining goals and success criteria.
As a result, we have this notion of “quick hits.” A quick hit is often a solution to a problem that everyone wants solved yesterday. Getting any form of relief to the problem is so urgently demanded that people adopt a just-get-it-done attitude and throw money at it. Quite often the quick hit is a short-term success, not because the effort in the spotlight and a few individuals’ careers are riding on a good outcome, but because the business analyst defined the problem so well that the solution’s objectives were highly constrained so that the requirements could be met with a minimum of design, which would mean that development was low risk so functionality could go into production like an arrow to the target.
While the quick hit model for projects delivers immediate gratification, anyone taking the long view realizes that the success of a quick hit is often counter-intuitive. Sure, the quick hit solution was speedy, and it met the letter of technical requirements but it isn’t extensible and it has few “-ilities,” namely, scalability, reliability, compatibility, manageability (four of the many “non-functional,” requirements for readers who aren’t business analysts).
Moreover, the more emphasis placed on quick hits, the less focus there is on strategic planning and understanding the big picture, that is, the business model and business architecture view of the business’s needs. People who are rewarded for putting out fires with quick hits are not receiving incentive for thinking about the long-term ramifications, nor do they feel at liberty to think strategically.
In 2010, Alexander and Osterwalder and Yves Pigneur published their handbook for visionaries, game changers, challengers and empowered business analysts called Business Model Generation. When there is no business model, an organization is low on the capability maturity model; development is chaotic, quick hits are the norm rather than the exception, and innovation is haphazard at best.
In 2011, Robert Strohmayer identified the business architect at the top of the list of the six hottest jobs in IT (“The 6 Hottest New Jobs in IT”, Infoworld, June 2011). Strohmayer quotes Alex Cullen, a VP at Forrester Research and the Research Director for Enterprise, Business, Application and Development and Technical Architectures, "Business architecture is about making sure the whole business holds together . . . it's a role built around business planning, pointing out opportunities to utilize IT more effectively." Simply put, business architecture model is a blueprint of the enterprise that provides a common understanding of the enterprise and is used to align strategic objectives and tactical demands.
When business analysis is being done well, the practice of creating and maintaining the business model and the business architecture is as deeply ingrained in the organizational practices as the tradition of the quarterly all-hands meeting. Not having the business model and the business architecture model as references would be unthinkable. After all, how will an organization know what it is doing and how things will affect it in the long term?
When business analysis is being done well, the organization values having the solution to a problem defined along the dimensions of the users, the interface, the capabilities that the users and the business will have, the data, the controls, the environment that the solution will deployed into, and the quality (those “-ilities”). If you want to know more about these seven dimensions, take a look at Discover to Deliver, just published by Ellen Gottesdiener and Mary Gorman. Discover to Deliver articulates a methodology based on rapid iteration for ensuring that what gets built has long-term value and can be linked directly to an organization’s strategic goals.
When business analysis is being done well, business customers see their business analyst as a strategic partner, and they see an empowered business analyst who knows the business’s 5-year roadmap, not just their program portfolio, not just a project pipeline and not just the project in front of their nose. In our experience, business analysts who work in organizations that are not mature in the CMM sense are only as good as the managers who protect them. No business analyst who consistently takes initiative, challenges the conventional perspective, raises uncomfortable issues and brings transformational (disruptive) ideas to the table will survive without at least one manager watching their back and providing them with information about the political climate and budget sensitivities.
When business analysis is being done well, executives see the product managers as entrepreneurs, the enterprise architects as intrapreneurs, and everyone sees senior business analysts as brilliant strategic partners.
Don't forget to leave your comments below.