While more and more clients and teams ‘get it’, we sometimes get questioned when we propose an Inception. Here is how we respond:
{% hint style="success" %} I like the idea of this ‘Inception’. Just remind me, how do I explain it to my colleagues? An Inception is a lightweight pre-delivery phase during which we align on what we want to achieve; on expected outcomes and on scope. We look at people, process and technology, risks, dependencies and constraints. This allows us to de-risk and hit the ground running when we start delivering for you." {% endhint %}
{% hint style="success" %} This sounds expensive. Is it worth it? The cost of an Inception is outweighed multiple times when we consider the risk of doing the wrong thing, or not being able to do it at all. {% endhint %}
{% hint style="success" %} We have ambitious deadlines – is it really worth spending time just talking about what we want to do? The length of a good Inception is relative to the size of the challenge; compared with the overall initiative duration they are short and lightweight. The effort we spend initially is paid off by the issues we prevent down the line, where cost of change is higher. {% endhint %}
{% hint style="success" %} Isn’t that like waterfall? Why don’t we start delivering in Sprints right away? Inceptions allow us to set the scene and shape the delivery, not define it at its lowest level - doing so at this stage would reduce subsequent agility. {% endhint %}
{% hint style="success" %} Is this really needed? Our stakeholders are very busy. Successful initiatives require stakeholder support, alignment and input. Senior stakeholder engagement is vital to communicate strategic direction and the importance of the initiative. {% endhint %}
{% hint style="success" %} Fortunately we have done requirements elicitation already, I can share the business requirements doc with you so we can get right into solution design. An Inception is not about detailed analysis, scoping or solution design, it is about shaping delivery. Having requirements is great and we will certainly build on them, but requirements alone give us only a tiny part of what we align on during an Inception (e.g.. ways of working, technology, dependencies). {% endhint %}
{% hint style="success" %} We don’t need all those people involved, it would just add noise. The initiative sponsor and programme director can tell you everything. Inceptions are exactly the tool to handle such noise, and build trusted and mutually beneficial relationships. Based on our experience, broad input, governed by clear decision-making structures is what makes initiatives successful. {% endhint %}
{% hint style="success" %} That’s great. Then we’ll have all the answers and all details we need to delive. Due to their intrinsic lean and agile nature (remember, this is not waterfall on steroids) Inception deliverables are high level. They allow us to align and de-risk but don’t replace detailed analysis and design (which we do as and when required during delivery to reduce ‘waste). {% endhint %}