Cast a Wider Net to Get the Best Software Requirements
In his recent article "What You See Depends Upon Where You Look," Steve at theBigRocks.com describes how change agents, depending on where they look, can often get different views on whether there is support for their initiatives.
For example, asking individual direct customers whether they support a project to change the billing procedure may yield different results compared with asking the sales team. Both of these scenarios might yield different results from holding a focus group, where customers are interviewed in a group.
It’s important to find a strategic path that takes into account valid individual views and concerns as well as considering the bigger picture. This is certainly true, and while reading Steve’s article, it struck me that there is a direct parallel relevance for those carrying out business analysis on projects, too. The stakeholder landscape on projects can be extremely complicated, with dispersed stakeholder groups potentially spread all over the world. In fact, sometimes there might be a few political landmines too, which are best avoided.
As well as having different attitudes toward the project or change that is being pursued, stakeholders will have different views about what should be included in the scope of the project. They are also likely to have differing views about what requirements need to be included, the priority of those requirements, and perhaps even which solutions would be acceptable.
This reinforces the need to cast the net wide early on in projects to understand which stakeholders are involved with, or impacted by, the proposed change. Stakeholder analysis and management is important, and it’s important to have an adequate communication plan to keep stakeholders in the loop. Peter Checkland’s CATWOE technique can be extremely useful here. Of particular importance is understanding each stakeholder’s worldview. What does the project mean for him?
However, we can extend Steve’s analogy even further. What we see—and what we’re able to analyze—will also depend on which requirement elicitation techniques we use.
There’s often a temptation to jump straight to workshops or interviews as these can yield fast results—and if we’re not careful, they can become a comfortable default option. Other techniques like document analysis, observation, and activity sampling might provide us with additional insight that helps us really understand what the business needs.
There’s nothing like spending time with front-line staff to really understand how a process or business system works. This provides an excellent chance to look for improvement opportunities. Clearly, requirements elicited this way still need to undergo analysis and prioritization before they are considered valid.
Remember—to help assure project quality, cast the net wider for stakeholders and requirements!
