It’s a scenario that gets played over and over again in software shops: the person designated as the analyst for a project, sometimes the CTO, sometimes also the project manager, heads into the birthing hut at the start of the project, and doesn’t come out until the spec is born. This analogy hurts in so many ways.
It comes as a surprise to many people when I suggest that the requirements analyst (or whoever has the role of ensuring the requirements are captured, regardless of their title) is not the author of the requirements. I don’t come by that declaration lightly – I have been the designated analyst and tried to give birth to that tome myself, and from all my travels in a wide range of teams, the default assumption is usually that the analyst writes the spec. The result in most cases is very similar to that birthing hut analogy: the analyst hides away and struggles dearly with the task of capturing the requirements (and there is rarely any epidural or nitrous oxide to take the edge off), while the rest of the team waits expectantly outside. They are cooling their heels, or working on something that may end up being irrelevant in the end. When the spec comes out, nobody dares note that it is an ugly baby: they will make do with what they have, and the project will struggle along. Half of all the defects throughout the project will be the result of missing or otherwise flawed requirements, but few will make that connection.
To suggest the analyst is the author of the spec is like saying the project manager writes the code on a project. It might work for the smallest of projects or simple little prototypes, but certainly does not scale. Thinking in these terms is just as bad for everyone else on the team as it is for the analyst: their expectation is that they stay on the outside, and only receive the finished product. I once had a corporate lawyer ask me how she could possibly have any interest or role in the requirements stage of a project. I asked what she did, she replied that she was in charge of ensuring the company was up to date with tax issues worldwide. I asked how she got involved with projects, and she noted that there is usually a frantic call in the eleventh hour of a project, and she has to rush in to help clean up the mess. It didn’t take much discussion to convince her there might be a better way.
The analyst’s job is to coordinate the entire team, to drive a deep collaboration, out of which the team has arrived at a common understanding of what needs to be built. At most, the analyst may at times act as a scribe, capturing the elements of the discussions that are held, the different forms of analysis and elicitation that are components of that common understanding. First and foremost, though, the analyst brings an understanding of the structure of a well crafted set of requirements, and deploys the range of tools as a mentor, bringing expertise from all stakeholder communities together as required for each piece of the system.
She’ll bring the business representatives together with the product champions to understand why this product is being built at all, to put some structure around the boundaries of the project, to hold their collective feet to the fire and quantify what success means to all parties. Out of this context, she will pull together representatives from all external stakeholder communities and gather information from as wide a range of sources as makes sense. More than just asking what they want, she’ll drive discussions down the path of identifying the goals they want to achieve, but will also look at competitive products, defect reports, and will also solicit an understanding of what is possible or even feasible with given technology.
She will then make sure that everyone has an appropriate perspective into the needs of the system, using whatever means is appropriate. She will ensure that the essential data relationships are understood, that the user interface has been clarified, that the objects with states are well understood. She’ll make sure that the tax lawyers or the people managing SOX compliance get their say at this early stage. She’ll look at the team structure and ensure that all this information is expressed in enough detail to ensure that the product can be implemented with minimal risk.
Wrangling the team into the right discussions is the focus, rather than actually writing the specs. Think people-person over wordsmith. Giving birth is the wrong analogy, this is more akin to raising a child. While no trivial task in itself, it is far more collaborative and inclusive.
Take advantage of special member promotions, everyday discounts, quick access to saved content, and more! Join Today.