When a project doesn’t run according to plan, a common reaction is to assign more project managers to create “better” plans in the belief that their combined clairvoyant abilities will somehow make the future more knowable. In a similar fashion, letting loose a posse of business analysts when faced with unexpected hurdles or unknowns seems to be fairly standard behaviour. Perhaps this makes sense as, after all, surely more analysis equals better results – right? Well, while there are some very important questions to answer at the start of an endeavour (see below) I don’t agree that the business analyst is the person best-placed to ask them, nor that the standard approach of creating reams of documentation is a particularly worthwhile activity.

My main objection is that it just doesn’t make sense to put somebody between those asking for a product (the customers) and those providing a product (the development team). Not only does this represent a potential layer of miscommunication, if we accept that part of the remit of all professionals is to anticipate what will be required and not to merely react to scattergun suggestions then surely the most qualified person to get involved is the one who will actually do the work, e.g. the developer, bricklayer, or engineer, and certainly not the analyst. As Lewis Carroll writes in Through the Looking Glass, “it’s a poor sort of memory that only works backwards”. And so the development team should be drawing on experience of previous initiatives to create a working prototype (before asking, at any level of detail, what people think they actually need), using the resultant model as a straw man to facilitate further discussion and targeted evolution. Think about this from the point of view of your customers. They have their own jobs to do and aren’t likely to welcome endless meetings to discuss functionality (that might or might not be delivered) with somebody who won’t even be building it, only to have to repeat the process later on in the project when the development team come a-knocking because they can’t understand the requirements.

My second issue relates to the breadth and timing of documentation. As Eli Pariser writes in the Filter Bubble, “we tend to convert ‘lots of pages of data’ into ‘likely to be true'”. And so it is that professionally-produced up-front requirements documentation perpetuates the “illusion of understanding”. In the first place, even if we could create a perfect description of our requirements it would be too detailed for anyone to make any sense of. As Nate Silver tells us in the Signal and the Noise, “the instinctual shortcut that we take when we have ‘too much information’ is to engage with it selectively, picking the parts we like and ignoring the remainder”. Thus the developer will merely pick the most interesting bits to develop rather than the most important parts. Secondly, it is an oft-repeated fact within project circles that over half of what gets asked for never gets delivered, and half of what is delivered is never used. Therefore, it’s unlikely that anyone in the dev team will even look at requirements documents. Certainly in 20 years of (mostly successful) system implementations I’ve rarely cast more than a sideways glance at such a beast as it’s generally full of nonsense that will never make it into the final solution.

So what is my approach when given free reign to run an initiative? Quite simply it is to get the developers spending up to a week with key people in order to understand only high-level requirements and then to get the team straight on to prototyping the most important functions. In this way, we neither commit the wholly avoidable sin of wasting our customers’ time nor stymie progress with a load of unnecessary and/or unimportant requirements. As Dave Trott writes in Predatory Thinking, “less important points don’t add to the communication, they detract from the most important point”. But what of the beleaguered business analyst, torn from the usual role of up-front fact-gathering? Well, as I see requirements emerging naturally as the project progresses via a cycle of constant business prioritisation and continual rapid delivery of complete slices of functionality, it would seem that I dislike documentation and that this major aspect of the BA’s role is redundant. Not so! It’s just a question of timing and focus. We must still document our product, but only after functions have actually been delivered. This is the time to call upon our erstwhile analyst to create a targeted “after the fact” detailed requirements document, explaining only those features that are in the final solution. Not only does this focused approach reduce customer irritation and dramatically shorten project start-up, it also frees up time for the analyst to better employ their skills and knowledge of the business by undertaking other activities such as the production of training materials, running training courses, creating test scripts (that match up with the after-the-fact requirements), coordinating product roll-out and, most importantly, designing business processes around any technical solution. It does seem a waste of talent spending the majority of their time detailing every nut and bolt of a possible solution when nobody will even know all of the answers until, well, the end of the project.

In Being Wrong: Adventures in the Margin of Error, Kathryn Schulz writes “if anything can rival for sheer drama the demise of a belief that we have adamantly espoused, it is the demise of a belief so fundamental to our lives that we have never even registered its existence”. Well, PRINCE2 and your ilk – I reject you from a position of knowledge: your “real” business analyst is better than you think.

HOME