Having developed an understanding of what we will have to do, we now need to determine how we will go about delivering this.
As part of this, we will be looking at ways of working and governance, but also creating estimates and a plan to drive delivery – often to provide cost and timings to a client in the form of a statement of work.
While this playbook will naturally seem linear, the items in this chapter should not be seen as sequential, but rather parallel / iterative. Ways of working, team shape and plan are intrinsically linked and thus will influence each other.
Knowing what to deliver is all fine and good, but delivering well is just as important. By defining ways of working and having a plan and delivery approach, we are not only ‘doing the right thing’ - we are doing it ‘in the right way’.
Another consideration: stakeholders will need some indication of ‘what, when and how much’ in order to make a decision on whether and how to proceed.
The goal is to setup solid foundations to decide on whether to proceed, and how to kick off delivery in the best possible way.
We expect many of the items defined here to change over time. However, by having an agreed starting point we can go about subsequent change in a controlled and directed manner.
What values should we adopt?
We identify values (both ours as the supplier, and the client’s) and assess fit (and what changes should be made, if feasible). These will shape our ways of working, or, in some cases determine whether we believe we can be successful at all.
Expect to make changes and amendments to ways of working or the wider engagement as you start collaborating and ‘true’ values come to light, or the context changes.
How will we work?
We define the working practices, principles and tools we will be using that are most suitable for this specific initiative, based on the type of opportunity, capabilities, values and constraints.
We consider the overall process (from ideation to go-to-market, operation and decommissioning) as well as the more nitty gritty details of day-to-day work:
- Agility vs linear methodologies
- Continuous Delivery
- Colocation vs distributed teams
- Collaboration and communication
- Ceremonies and delivery cadence
- Project funding
- Quality assurance, regulatory concerns etc.
We generally keep this relatively light (in our experience, more complex models tend to be promptly ignored the moment delivery starts). We focus on facilitating day-to-day delivery, clear decision making and a clear escalation paths.
Expect ways of working to initially be a ‘best laid plan’, with a view to adapt these as the context and team evolves. Ensure that as you evolve you are still set up for success.
Are we in control of things that will trip us up?
We review risks, assumptions and dependencies and put mitigation strategies in place.
What is the effort to bring each deliverable into the hands of our users?
We estimate each deliverable in terms of effort. This serves as an input into subsequent ROI-based (re)prioritisation exercises, solution option choices, planning and roadmapping activities.
There is a lot to be said about the right and wrong way to estimate – enough to fill another (play)book.
The most important thing to appreciate and communicate is that estimates provided during inception are indicative: they are sufficiently detailed to allow solid decision making but should be expected to be refined during delivery.
Our experience has also shown that neither longer upfront planning nor more granular estimation increase estimation accuracy (in fact, they often do the opposite). Instead, we openly recognise the level of level of uncertainty we are subject to, and factor it into our estimates. For example, early planning stages tend to come with more uncertainty than later planning stages; greenfield projects tend to come with more uncertainty (particularly when the team, concept, context and domain are totally new to everyone) than brownfield projects (though brownfield projects may come with more dependency-related risks).
As our project progresses and we gain more insights, we tend to refine our estimates. This ensures that we have more certainty about when and how we will deliver imminent work, while having a hazier understanding of how we’ll do this for work much further in the future.
What is the most appropriate team shape for delivery?
We define (options for) team size, composition and distribution which feed into the various planning scenarios.
How long will it take and when do I get what?
As well as potential team shapes we create a feature / delivery roadmap(s) and plan(s), taking into account the chosen solution, prioritisation (now considering value and cost), risk and dependencies.
What is the best way forward?
Based on the opportunity and the context we’ve learned during the inception, we propose a way to proceed. This is the culmination of all the work that was done to date, and in many cases summarises the functional and technical solution, and the delivery approach, together with some kind of rationale or justification. It may also be a recommendation to pivot to a discovery (especially in cases of a curtailed inception) or to not proceed.
If we have run our inception well, we will have been sufficiently close to all decision-makers – so this recommendation should not come as a surprise. In many cases, we provide it in the form of a playback; in others, more formal feedback may be required. This is often then used as input into a business case or board presentation.
I want to know what to do next.
We define and communicate immediate next steps. Remember, right after the inception we ‘Wrap-up’ and collectively decide whether to proceed with the initiative (or not).