At EdgeCase, we’ve been in the business of building software for our clients for many years. In that time, we’ve come to realize two truisms about virtually every project:
Our response has been to develop a project inception process that we use when we first engage a client. In this article, I’ll describe to you what it is that we do, why we do it, and some of the lessons we’ve learned along the way.
The goal of the inception is to educate both the client and us. We frequently find that clients come to us believing they fully understand the vision for the product to be built. And while they are undoubtedly better prepared for the project than us initially, we’ve found that the questions asked during the inception help them uncover issues not previously considered.
Even in cases where the client is confident in their understanding of what they want, the act of going through an inception is valuable for us. In a typical project, we start with many unknowns - domain terms, requirements, stakeholders, constraints, etc. The inception offers us the perfect opportunity to sprint up the learning curve before we need to start applying that knowledge on practical problems.
Before stating what an inception is, let me clear up something it is not - an Iteration Zero. Google for that phrase and you’ll find definitions with subtle differences, but most of them describe an initial iteration where the focus is developing project infrastructure and tools rather than user features. At EdgeCase, we have tried this approach but found it lacking. We typically work in two week iterations. Our experience has been that we don’t need anywhere close to two weeks for these steps - especially given the rapid evolution of things like automated git-based deployment solutions (e.g. heroku), authentication libraries (e.g. omniauth), and other frameworks and tools that make it a snap to get a project’s technical core in place. We want and expect to be delivering real customer value in our first iteration, but we need to make sure we’re delivering the right value and working on the right set of things first before we start.
Our inceptions are made up of three days of intense effort. The first day is all about capturing the vision for the product. Some of the key exercises used to do this are:
On the second day of the inception, we begin the process of defining a Minimally Viable Product (MVP). If you’ve not read Eric Ries’s The Lean Startup, an MVP consists of the minimum set of features you can build which allow you to learn rapidly whether or not you are building the right thing. We frequently are able to show customers that we can deliver real value with a smaller feature set than they originally planned. This set of features is articulated through a process that consists of:
Throughout the first and second day, we use a scratch pad area (stickies on a wall) to capture thoughts and issues we need to circle back on later. Some of these will be unknowns (technical or otherwise) uncovered during the course of the first two days that need rapid investigation. On the third day, we reserve the first half of the day for our team to work independently from the client on closing some of these questions. A couple hours spiking a technical solution is often just enough to understand whether or not an approach is feasible.
The remaining part of the third day is essentially close-out. We talk about what we learned from the spikes, consider acceptance criteria for key user stories, and discuss project management issues (e.g. roles, meetings, tools, etc.) that will be relevant if the project moves forward beyond the inception.
After three days of this, I guarantee you that everyone involved is exhausted but in possession of a much better understanding of what is to be built and how the project will be run.
We’re happy to run inceptions either in our office or at the client site. Which is best is largely a function of the client. If they are capable of being present and focused on the incepetion, then holding it at their location may offer a tremendous opportunity for us to get visibility to the deployment environment and talk to real users who can verify or refute the characteristics baked into the persona exercise.
However, not every client has the discipline to stay in the inception and block out the distractions while on site. In such cases, it’s better to have the inception back at our office where they can fully engage in the discussions.
Getting the right people in the room for an inception is the single most important factor in determining whether or not it will succeed. Miss out on an important stakeholder and you risk having wasted your time when that person later challenges decisions made in their absence. Have too many people in the room and you make it too easy for someone to mentally check out and not fully contribute.
We aim to have two people from EdgeCase - someone with project management skills and someone with development skills - and two to three key client stakeholders. The client participants need to:
The last of those is especially critical. You’ll find clients who believe themselves to be so busy that they can’t possibly spend two to three days of uninterrupted time in the inception. This is a red flag for the project. A business owner who can’t spend the time neccesary to start a project off on the right foot is likely to be one who has trouble committing time later when real-time decisions and customer feedback are required.
Here a few tips we’ve learned along the way to make your inceptions run smoother:
Like anything, running an inception is a continual learning experience. Every time we’ve participated in one, we’ve walked away with one or more new “aha” realizations that make the next one better. In a sense, the discovery of what makes a for a good inception is much like what makes for a good product idea - being humble and being prepared to constantly learn and improve. To quote Francis Bacon:
If a man begins with certainties, he shall end in doubts, but if he is content to begin with doubts, he shall end in certainties.
We are not yet to the point where we can say we have “ended in certainties”, but our insight on starting projects off on the right foot has most certainly grown. The payoff has been better projects that follow on from those inceptions.
I hope you’ve found this overview of the inception process helpful. Please send us feedback on what’s working well for you and over time, we’ll all begin to erase our doubts.
If you want to learn more about the inception process, here are two good resources to consult: