More often than not, an I.T project will begin with a
customer asking for an I.T solution. It may be fixing a newfound problem,
re-engineering their existing system, or quite simply helping them with a wacky
way of spending their cash (which is the case most of the time ;)). Be it
whatever, the journey then starts. The first stop over will be into the minds
of the customer – more appropriately into the users who will be using the
designed solution so as to understand the exact requirements.
As a business Analyst, my role is to be that imaginary fly
who can effortlessly cross into the minds of the users and extract out their
wishful thinking, deduce what is realistically possible and try and plant a new
image into their mind after consultation with my dreaded developers who will
eventually code out the designed solution. If this does not happen as intended, then what comes out can be anything between a total disaster to horrifyingly obscene! Lest you think I am exaggerating,
check out this video for a more realistic analogy of how things can go wrong -
(Video thanks to http://email-collection.blogspot.in/2009/05/software-development-life-cycle-sdlc.html)
The whole process of ‘extracting’ the user’s thoughts on the
desired solution and replacing it with ‘a new thought’ is an intriguing process. In my organization, we call it – The Inception. A fancy name (they
came up with this much before the movie was out! )
Recently I went through this process with an interesting
customer from the entertainment industry. Thanks to the fantastic team I was part of, the entire process was a lovely learning curve. Thought I'll take some time off to reflect on the whole episode.
What went well –
The suspecting and doubting customers on day one quickly
warmed up to the concept of inception when they were asked to play some games (can't emphasise enough on the importance of Innovation games) and activities. As the clock ticked, a
lot of things seemed to go well.
- Elevator pitch – An exercise where all of us in the room wrote down what we thought of the solution in the shortest possible way (in a small card) – akin to explaining the solution to a stranger in the space of an elevator journey as it takes off from the ground floor to the topmost floor. This not only broke the ice but also helped all of us come on the same page.
- Time Machine – The intent was to travel forward in time with the customers, in the process noting down all that they wanted to see at various points. It’s more like laying out the roadmap of their journey by asking them to dream a picture perfect way of what they want from the solution. We drew the line for the next two years, splitting it on a half yearly basis. So beginning FY2013, H1 2014, H2 2014, H1 2015, H2 2015. This sort of gives the BIG picture view of things.
- Creating the personas – To every system, there will be users. We tried giving life to all the different users who would be using the proposed system. Coming up with all the things that will make life easy for the users and also of things that the users will hate if we messed up. The idea was to come up with what the ideal user would want from the system.
- Business Model Canvas – With each of the personas, we listed down all that they’ll practically want to do with the system. Every activity that the user will be engaged in from sunrise to sunset was listed and put down, more like the journey of the user. Thus laying down all the features the system will require. Now I am simplifying this a little too much but essentially what we did is to see how the solution caters to the personas, especially in trying to entice the customer to use this more and also uncovering what will irk them too. A better video explanation below -
- Prioritization – Once we had the complete list of features which the different users, we came up with the bare minimum or the most necessary of the lot; just so that we were not burning up cash without reason.
- Transparent estimation – Usually, at least as far as I know, once the requirements for a system is gathered, the next process is a whole black box where the I.T company claims to make use of complex systems to come up with a magical cost figure. But here, with each of the features laid out, the developers argued and agreed over the complexity of each of the features and came up with a final number that indicated the sum total of all the feature complexity - also called as story points. A good explanation on Agile estimation in the video here
- Shooting with a Premonition – With the complexity number against each feature, the developers dug deep into their guts and convictions to come up with a number, which estimated how much time the numbers translated to. The fact that we were honest in assigning the numbers and equally honest in admitting that this number in ‘Man hours’ or ‘people time’ was only an informed guess earned us brownie points. Now we don't really say time, rather we call it as the velocity or as the no: of story points which the developers can cross in a given time (usually an iteration). But obviously, it boils down to a time figure.
- Collaborative Approach – Making the whole exercise of extracting what they want and telling what they’ll realistically get into a collaborative exercise where there were equal participation from business users, developers, managers, decision makers, business analysts helped. It sort of translated to a shared mission and goal rather than a one sided approach or a purely transactional one.
- Visual Appeal - what also helped is the fact that we employed visual tools. All the exercises we did where all evident by means of charts/stickys/ post-its hanging all around the room. The walls of the room went from plain white to all sorts of colours by the end of the exercise. I have no doubts that also helped in a big way.
Too good to happen –
At the end of all this, what perhaps helped make the whole
event a ‘completely smooth’ one was the fact that the numbers we came up with
fit the customer's pockets perfectly (it almost magically came just within their pre set
budget!). Most of the time it is after the requirements phase that the nasty
street fights begin – trade offs of features or time or quality or of ‘n’ number
of things come up. But I suspect even if the numbers had crossed the Lakshman
rekha, the clients brought into the whole process and were willing to stretch
since they saw the value they were getting for their money
So in summary, a requirement gathering exercise which went
exceedingly well without any frictions. Obviously not a common phenomenon, but
one every B.A will highly desire :)
