The Inception team
Last updated
Last updated
An Inception team must be a multi-disciplinary team that generally consists of 3 groups:
inception core team who leads the inception
Inception team who closely contribute and make decisions
wider stakeholder who provide input and are taken along for buy-in
At the minimum, your team will need representatives from delivery, product and technology to cover the various areas an inception touches on. The core team must be experienced in their field and in running inceptions!
This section on Types of inceptions provides examples of actual team shapes.
The team shape looks slightly different for an in-house vs. client-supplier scenario where the supplier runs the inception:
In this situation the entire inception team are from one organisation which usually allows for a leaner team shape.
Where a supplier runs the inception we generally find that certain roles in the inception team are either taken or doubled-up with both supplier and client counterparts. To ensure robust outcomes from the inception, the core team should always be from the supplier, even if delivery, product or technical roles are added by the client.
At the minimum, your team will need representatives from delivery, product and technology to cover the various areas an Inception touches on. In the world of consulting we live in, these are usually provided by the supplier.
Expect the average Inception to require the following roles:
Engagement manager: Focus: the overall engagement, risks and constraints
Delivery Lead: Focus:governance,dependencies,ways of working.
Product Lead / Business Analyst: Focus: objectives, requirements, business processes and capabilities.
UX / CX Designer, Researcher: Focus: bringing in the voice of the users.
Tech Lead / Software Engineer: Focus: technical capabilities, constraints and related technical and non-functional requirements.
DevOps Lead: Focus: operational capabilities, constraints and infrastructure requirements, and non-functional requirements.
QA: Focus: quality assurance approach and regulatory requirements.
Misc specialists: Focus: as required by initiative (e.g. data science).
Generally one representative per role, although we have run inceptions where a single individual covered multiple roles. During bigger inceptions, we’ve often had multiple individuals cover a discipline (usually for BA/ Product, Dev or DevOps). Our Types of inceptions shows some examples.
We tend to have at least one seasoned ‘inceptionist’ – in fact, often a Delivery Lead + Business Analyst pair. They facilitate planning by taking inputs from all other disciplines. Ideally, the entire team is involved in planning the inception.
Running an inception is the responsibility of the entire team, with a dedicated facilitators for each activity. We find that organically often one individual becomes the ‘overall’ leader or ‘MC’. This is often a delivery lead or product consultant, but it can be anyone, really, if they have experience in running inceptions and client engagements.
It’s particularly important that this person is able to facilitate and be clear about when they’re facilitating vs contributing. As a facilitator, it is crucial to not bring in bias, as this erodes the trust the attendees will have on the impartiality of the facilitation. All voices should be equal.
Facilitators can of course contribute but only when they are explicit about stepping out of their facilitation role, and into the role of a contributor. This is one of the most commonly overlooked aspects of successful inceptions, which can erode trust from a very early point in an engagement.
By default, we assume that the entire team will be present in all sessions. However, as an inception progresses and discussions become more focused and in-depth there can be a benefit in splitting into dedicated specialist teams, as long as we keep sharing relevant knowledge across teams.
In addition to the core and inception teams we must consider the following roles (in a client-supplier scenario these are provided by the client)
Senior decision maker / Sponsor: Focus: makes the final calls – their necks are on the line, they are interested in the ultimate outcome, and they pay for it all!
Project Management / Project Support: Focus: providing information about delivery capabilities, ways of working, dependent initiatives and governance requirements.Areinterestedinmonitoring and controlling change in the initiative.
Product (Sales / Marketing / Product): Focus: own the deliverables and need to delivervalue.Understand the problem domain and will make feature specific decisions.
Operations: Focus: will operate the product and have related requirements. Know the existing domain.
Technology (Architects / Software Engineers): Focus: knowledge of client’s technical capabilities. Interested in appropriate solution from technical perspective. Will provide constraints and requirements and knowledge of existing and dependent systems.
Infrastructure / Sys Admins / DevOps: Focus: knowledge of infrastructure capabilities and current domain. Interested in appropriate solution from an infrastructure and operability perspective.
Brand / Compliance: Focus: provide requirements specific to their domain.
Misc. Subject Matter Experts: Focus: providing information and / or controlling resources in their area of concern.
Users: Focus: Will changes according to the initiative, but these are the people we’ll develop the solution for. Ultimately it must be of value to them. The most important group of all, however they’re often only represented via proxy. Should include internal users (e.g. support) as well as external users (e.g. paying customers).
We ask our clients to support scheduling and making their people available.
Inceptions work best when participants are interested and focused. Good planning and communication ensures they have the mindspace to participate, understand why they are participating, what is expected of them and what value they will derive from this exercise.
We share the agenda and expected outcomes of each session prior to the inception, so that expectations of participants can be managed and they can bring or refer to other participants as necessary. We communicate what preparation we expect them to do, but are mindful that stakeholders may be busy and that siloed preparation may not provide much value in any case. Generally, we avoid too much upfront preparation as it tends to be biased.
By default we opt for a wide range of participants, especially in the early stages, but balance this with more focused activities (often run in parallel) as the inception progresses and we get more granular. We support this with a mix of all-hands sessions vs. smaller break-outs.
When doing so, we are mindful to avoid working in silos: we want cross-pollination and information sharing to occur between departments and disciplines as much as possible.
