Incepting Inception

by Colin Gemmell

At 1partCarbon all our projects start with an inception, sitting down with the client to find out what they need. Continual improvement is very important to us, and when starting a new internal project (more on that soon) it seemed like the perfect opportunity to look at how we could better our inception process.

How to find value

The key focus for all inceptions is to find where the most value lies in the project, providing maximum value early. For this inspiration, I looked back at previous conference talks and workshops I had attended and tried to distil this into a very short two hour slot.

I started by getting the team to define the problems they wanted to solve simply by listing them on a whiteboard. This brought an initial focus to inception that worked well as the team could always refer back to them. Once the key problem was understood I moved the team on to look at who we where solving that problem for.

Knowing who you are solving a problem for is just as important as knowing what the problem is. Who you are solving a problem for can inform what has priority, validate if a solution actual solves a problem for a user and help the team identify with who they are creating the application for. Although I would have like to create fully fledge personas, due to the time constraints we simply listed the foreseen stakeholders and proceeded to rank them in order of who would benefit most by solving the key problem. By identifying the people who would gain most from the project along with ranking the individual problems they faced we had a starting point to generate stories.

From here everyone focused on contributing stories that solved the top priority problem for the most important stakeholder. I got the team to write as many stories as possible that would solve the top priority problem for the user with the most need. From there we categorised and ranked these story in terms of priority and value they would offer and in a short space of time a plan was was created for development.

What was learned?

The exercises used certainly helped the team define where the value lay and gave us enough material for at least the first few iterations. But what was key was that this was done in a very short space of time and can serve as a template for a longer more in depth inception process.

The biggest missing part was not clearly explaining what each exercise involved and what the desired outcomes were before hand. I guess you could call this fundamental, but I often taken it for granted that other people have the same understanding as myself and this is something I need improve for next time.

What next?

There will be more sessions like this continually revisiting where the value lies within the project and running more of these sessions to keep improving our inceptions. UX and design theory still holds a lot of techniques I would like to explore such as journey mapping, personas and hypotheses that I hope will bring more value to our inception process, further refining our process and finding more ways to deliver the maximum value for clients and internal projects in the shortest time possible.

Colin Gemmell

Colin Gemmell

Colin Gemmell is Web/Application Developer. He has gained a wide range of experience in his time as a developer working on everything from enterprise applications to small promotional web-sites. Spends most of his time writing Ruby and Javascript and evangalising Go to anyone who will listen.