So, why did simulation enable the discovery of this insight? The main people involved in this project were the same over the two years. The insight was not the result of adding a new person. I was invited to participate in this project because the program manager believed that a simulation approach would help this stalled project. I trained and mentored the team in the approach and the tool we used.
However, and this is significant, I did not have any detailed prior knowledge about either the application this team was developing or the service they wanted to cross sell. I had a 50,000 foot view of the department, but that was all. Additionally, on the day of this “Aha” moment, I did not know about the two year history which I learned about afterwards. I emphasize my lack of prior knowledge in this domain because I will shortly challenge a widely held assumption about business analysts (BA).
Let’s go back to the SME’s “Aha” moment. The SME discovered a new way to connect the cross selling opportunity on his own. You could argue that the SME had all the facts already and you would be right. However, the way those facts were organized, as industry standard textual system requirement specifications, had not help the SME to connect the dots.
On the other hand, the new approach enabled the SME to quickly see those very same facts in a new light. The simulation itself facilitated the “Aha” moment by visually connecting previously unconnected or wrongly connected facts. So, this is why I’m challenging the assumption that BAs must be domain SMEs to be effective.
Recommendations
Cross-functional BA teams organized into centers of excellence are more effective in documenting requirements than SMEs documenting requirements. The IAG study states, “The idea of a center of excellence for business requirements is gaining momentum particularly for larger companies with a need to deal with complex projects. In the absence of this structure it is harder to manage the requisite competency base of the corporation, and optimize the use of elite analysts across the enterprise.”
The ability to move across the enterprise works because subject matter expertise is not a statistically significant predictor of project success for business objective types 3-7. However, having superior competency in BA domain skills is statistically significant. In other words, a BA must have a certain level of requirements development domain skill to be successful. Higher levels of skill are needed as the risk type of the project increases.
To manage risk, companies should develop or bring in elite analysts to succeed in higher risk project types. Failure to use rightly skilled BAs will result in high failure rates. The center of excellence approach can provide skilled resources to assess the risk of a project using the scale above and to supply elite analysts to engage in higher risk projects.
One of the burning organizational questions in many companies is “Do BAs report to the business or to IT?” Once the decision to form a center of excellence is made, the IAG findings are clear – the center of excellence should report to both the business and IT. An organization with a jointly owned center of excellence significantly outperforms an organization where requirements are the responsibility of only one group no matter which one it is.
BAs can rely on subject matter expertise for only projects with the least risky types of business objectives. However, projects seldom have only one business objective. Rate the relative importance of each relevant objective to determine the overall project risk and determine which skill level the BAs should have. If the optimal expertise is not available in-house, consider getting outside resources.
Ideally, in-house BAs should be organized into a cross functional center of excellence that is jointly owned by the business and IT. The center of excellence should focus on improving the skill level of in-house BAs by training and hiring.
The rewards for using rightly skilled BAs are high: over $2 million per project. It is an understatement to say that you could reap significant financial benefits by rethinking how your company discovers and documents requirements.
Brian Cook was a Senior Software and Systems Architect for Zurich Insurance for six years and prior to that an Information Architect, Information Modeler and trainer for Perot Systems for four years. Currently, Brian is President of Cook Enterprise Corporation whose primary mission is to help clients discover, document, simulate and validate processes, scope and requirements visually so they are understandable to non-technical people. A description of the Building Requirements Consensus Methodology can be found at Brian’s website: www.building-requirements-consensus.com.
“If a picture is worth a thousand words, a simulation is worth a thousand pictures.”