Involving Innovation in Requirement Capture

Nothing kills innovation quite like the words, “That’s all very well but let’s be realistic here!”
Nothing kills a project quite like unrealistic expectations and requirement creep.

So does this represent an impossible dichotomy that acts to prevent us from building the innovative new applications that all engineering businesses need to stay on top of their game? Well, a lot of the time yes it does. It can seem as though the choices are either to take a risk, bite off more than you can chew and deal with escalating costs, requirement creep and late delivery in order to get ahead of the market or, like a tortoise peeking out and sensing impending danger, tuck your head back under the shell of your technical comfort zone and hope you can hold out for a little longer in a rapidly changing ecosystem.

Of the two options I can understand why the second may seem more attractive but the reality is that the longer that carries on, the further and further behind the rest of the world you get and the more risk you’ll need to take in order to re-establish yourself later on. But hey, no-one wants that kind of risk on their watch right? Leave it to the next person.

I’ve recently adopted a different view though. I think you can have both and that key to the whole thing is the ability to clearly differentiate between ideas and commitments when talking to customers about their needs.

Over the last few weeks I have been involved in a series of customer workshops in a sort of combined role of business analyst and system architect. It’s clear from the brief we’ve been given that the customer is very keen to see innovation in any solution they will end up buying but at the same time, delivery timescales are very short. At one point during the discussion I was talking to some of the users about some of the cutting edge things the solution we were proposing could deliver when I heard the fateful words, “That’s all very well but let’s be realistic here!”

Talk about throwing a bucket of cold water over proceedings!

The comment actually really irritated me. The reason for this was that we had clearly been talking about possibilities, exploring ideas to see if there was any mileage in them. I was trying to figure out what excited them, what was important to them and how new features might impact on the way they currently work. In that moment I realised that while most of the room knew and understood what was going on, it was clear that many didn’t. Worse than that, the ones that didn’t seemed to believe I was committing to features in the end solution. A situation ripe for confusion later on!

Later on as I sat back down after the discussion I started to mull over what had happened in that moment. Why had some of them not realised that we had been in ‘exploration’ mode? After all, the whole point of the workshop was to poke at the limits of the requirements and find out where they were. One thing was for sure, no-one was going to dare to suggest new ideas now. Suddenly the project had nothing exciting in it anymore.

It occurred to me that while I had been speaking, my mind had been jumping between several different modes and I couldn’t even remember at what points I had switched from one to another. No surprise then that I hadn’t brought everyone in the room along with me. If they had snoozed even for a moment (the view from the top floor meeting room was quite impressive too) or they didn’t understand some of the deeper techie stuff we’d been discussing, they could quite easily have been left behind.

As a long time geeky kind of a chap, I began to think about these different modes as a set of states in a finite state machine. I thought about how the conversation had traversed these various states and what those states might be. I came up with three and popped them into a note on my iPhone.

Stages of Requirement Capture

Stages of Requirement Capture

What’s possible?
What’s important?
What’s feasible?

When thinking about what’s possible you’re thinking innovatively.

“Technology is now at this point here and our systems currently look like this but imagine if…”

This is the ‘opening up’ part of the discussion whereas the others are the ‘nailing down’ parts. When thinking about what’s important we take the ideas and concepts discussed in the ‘what’s possible’ phase and start to focus in on the ones that make the most difference to the customer. Having figured out what’s important we then need to look at our constraints and build a project around what’s feasible. This is where we finally nail down the project scope.

It seems to me that if you want to create something great then a discussion like this must include all of these things. By dwelling on what’s feasible you close yourself off to innovation or what the users might really need. By dwelling on what’s possible you can lose track of what’s important and by dwelling on what’s important you can become too bogged down in the status quo and shut yourself off from new ideas that could offer real benefits to the customer.

The trick then has to be in finding a way to let other participants know where the discussion is at any particular moment in time. The next challenge for me is to find a way in which to do that. Perhaps some kind of discussion board divided into three areas could be used and ideas written on sticky notes placed on it. Perhaps a simple diagram showing the three states and a sticky movable arrow that can be pointed at the one describing where the conversation currently is. Something to explore I think. Please feel free to let me know if you have any ideas!

So how does this help with keeping your technology business alive and on the cutting edge? Well I believe that this creates a framework that allows us to engage in new thinking without the fear that it will get out of control because everybody involved knows whether the discussion is about something exploratory or not and that it doesn’t matter if the ideas may seem a little trivial at the time because the subsequent phases of the discussion will filter these into what is important and finally what is feasible. Good innovation will make it through all of these filters and what you hopefully end up with something that combines the best of the established with the best of the new.

  1. Beautiful write up! I think I had a similar experience during requirement gathering with customers at least twice, probably more. Things get spoken out, are written down, and there is still a lot of room for (mis)interpretation or wrong expectations. I strongly believe that things needs to be communicated multiple times, in different ways, to get it soaked in.
    As for innovation: I think the killer for it is if there are already too much constrains at the beginning (budget, what it shall do, time): the more ‘out of the box’ thinking is allowed, then I think the more innovative things will be. Another way is to challenge ‘this is how things have to be done’ thinking. Apple vs. Nokia is a good example in my view.

    • Hi Erich, thanks for stopping by it’s much appreciated. It’s funny isn’t that the assumption is always that things will be cheaper, quicker and less risky if we stick with the old and don’t think about new ways of working. I mean, who says? Of course there are also people who for their own reasons really don’t want to be helped. I’ve got some notes on that too, perhaps a future post 🙂

      • Hi Jon,
        Yes, I have seen this (too many times) too. As organizations get ‘mature’, the are unable to think in new ways or taking risks. On the other side: that’s the ground where startups and new companies can grow :-).

      • Yep and that’s how we get our mojo back 🙂

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: