Plan
PLAN HOW TO DELIVER
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.
Why
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.
What good looks like
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.
Activities
VALUES
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.
Recommended tools and techniques
I want to structure information, find patterns and make the consumption of a larger amount of information easier
An affinity map is a diagram which groups items that belong together. It’s helpful when we ask a team to provide their thoughts, which we then group by relationship / category. We use affinity maps to gather success criteria from all stakeholders and distil themes which are then reflected in our team charters and ways of working.
WAYS OF WORKING AND GOVERNANCE
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
Governance
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.
Recommended tools and techniques
I want to know how we work together
We use lightweight team charters to remind ourselves of the standards and principles we agree to work towards. We use these as a baseline against which we review the team health, optimise our ‘performance’, and also use these when onboarding people.
Note that a Team Charter is not a training or coaching manual. It simply outlines principles and constraints, as well as key ceremonies.
I want to know who is responsible for what
A RACI can help a team initially define boundaries between roles. If applied in a lightweight fashion it can be used to facilitate interactions by clearly outlining responsibilities.
While RACI matrices are often a bureaucratic overhead, the insights gained during their initial creation can be of benefit.
I want to understand who I am dealing with
Any successful delivery is based on interactions with people. These people have different roles, interests, agendas; they may be empowered or just there to execute or inform. A stakeholder onion maps stakeholders by degree of closeness, while a stakeholder matrix arranges them on dimensions such as influence vs. interest.
I want to make decisions in the most objective and consistent way
Decision-Making Frameworks are a way to formalise the criteria by which decisions are made, and ensure these are made with strategic goals and outcomes in mind.
We use them for all aspects of decisions, whether they relate to investment, feature design, prioritisation or technology choices.
Do note that such models do not take into account the nuanced contextual factors that are sometimes at play. We need to be careful not to make bad choices by applying inappropriate models.
I want to understand and align on what is important
Alignment on values and principles is vital, as it determines not only ways of working but also the decisions and compromises we make. Project sliders allow stakeholders to indicate the relative importance of a number of dimensions. This helps teams to align, and also defines a decisionmaking framework.
RISKS, ASSUMPTIONS, DEPENDENCIES
Are we in control of things that will trip us up?
We review risks, assumptions and dependencies and put mitigation strategies in place.
Recommended tools and techniques
I want to make sure we are all aware, all on the same page and are ready to manage outstanding concerns
We find that key failure points of projects are often down to misalignment and unmanaged risks. Documenting assumptions, decisions made, issues to be resolved and risks allows us to identify, communicate and manage these items in a controlled manner from day one.
While ultimately we hold these artefacts in an easy to share / collaborative digital format, during workshops we reserve white-board space for these. They are constantly updated as fresh information arises.
It’s vital to recognise that we need to start populating these artefacts on day one, and continue to add / update / manage them throughout the entire initiative (i.e. not just the inception).
I want to map dependencies that impact my delivery
A tree or network identifying individual dependencies, their relationships (x depends on y), their status and ownership.
Estimate
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.
Recommended tools and techniques
I want to summarise requirements
Where we gather requirements during an inception, they should be user-centric and at Epic level. It’s too early to go down to implementation level at this stage. We generally stay at feature / epic level during inception, only moving to a ranked backlog (Requirements Hierarchy) for prioritisation later in the inception.
I want to know how much effort individual deliverables require.
TEAM SHAPE
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.
DELIVERY PLAN AND ROADMAP
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.
Recommended tools and techniques
I want to know by when can I expect which outcome, feature or deliverable.
We are big fans of roadmaps (as opposed to plans). Roadmaps are outcome and value focused, and give stakeholders what they need: an indication on how we get to where they want to be. There’s a focus on when value is to be delivered, in a visual format that is easy to update and digest.
Individual teams can then take this roadmap and formulate ‘tactical’ plans to structure their own team profile and delivery approach.
Delivery plan
I want to know when I need to do what.
We focus on value-based delivery rather than tracking work. For this reason we prefer roadmaps to outline and track the overall ‘plan’ and progress, and only use plans as a tactical means to tightly control individual aspects of delivery (as and when required).
This reduces overheads and allows us to create plans that have at least some chance of remaining stable and helpful, rather than being a document that simply shows that things change all the time.
RECOMMENDATION
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.
Next steps
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).
Recommended tools and techniques
Pro tips
Maintain and communicate agility as a concept: inception outcomes are based on knowledge available at that point in time, but scope, solution design, plans and estimates will change as more information comes to light during delivery.
This is not a shortfall of the inception process; assuming that such change can be controlled or made more definitive is a fallacy.
We find that aligning values and beneficial ways of working is one of the key success factors for delivery. Be cautious if values or ways of working conflict in the early stages, and make an honest assessment of whether the gap and misalignment can ever be bridged.
Value alignment needs to be constantly monitored and worked on. Especially as it’s only once we really start collaborating that true values will surface.
Avoid overly heavy governance models. A massive RACI matrix or team structure can be an indicator of this. While governance is important, it must facilitate, guide and ensure consistency in critical areas without hampering teams’ autonomy.
Another key success factor is managing risk and dependencies, closely and continuously. In fact, much of an inception is about mitigating risks. Be aware that logs alone do nothing– it’s how you use them to manage and action items in practice that makes the difference.
As the initiative proceeds, expect changes to many things you may have taken for granted. That’s fine, as long as those changes do not go against the original vision and goals (without subsequent realignment having happened).
Last updated