Projects will always have their ups and downs, and curve balls thrown in for good measure. For me, the Inception Deck helps stop some of these curve balls before the project begins, and is also a useful tool for the project on an ongoing basis.
One of the key factors in a successful project delivery is ensuring that everyone understands the goal they are trying to achieve, and is bought into it. Easy right? As with most things in IT there is no perfect way to start a project, and it will always depend on the people involved about how best to achieve this mythical perfect start to a project. One method that I have found works well is the Inception Deck, as authored by Jonathan Rasmusson in Agile Samurai. This outlines an approach to an initial kick off meeting where you ensure that everyone understands the aims of the project, and helps you have some of the traditionally difficult conversations right at the beginning to prevent them having to take place in the midst of things going wrong later on. It also results in a useful artefact of an ‘Inception Deck’ which can be referenced throughout the project to ensure that things have not gone off track, and as a useful onboarding tool for new starters.
So you’ve been given a project, and you want to run an Inception Deck meeting…
How do you ensure that the meeting is a success?
As with all meetings, it is important to get the ‘right’ people in the room. For a traditional Inception meeting this would be everyone in the project team (PO, BA, developers, testers), and then ideally the key senior stakeholders i.e. the ones who will be making the decisions. Your PO will be representing the stakeholders who will actually be using the system.
Have the meeting at the ‘right’ time. Some initial analysis should have taken place in advance of scheduling in this meeting. You should have a basic understanding of what you are wanting to do and why (you do not need to understand everything, this is not a Waterfall project). The meeting should take place before any actual development has taken place i.e. no code should have been written yet. This is an important point as it may be that you decide based on the output of the Inception Deck that it is not appropriate to continue the project.
Keep the meeting a sensible length of time. This doesn’t need to be a three day workshop, as some initial analysis should have taken place in advance to understand the whats, whys etc. for the project. In my experience an hour is long enough to go through the points below, but obviously this may vary depending on how many people are involved/whether they have been part of an Inception meeting before/how much initial investigation has taken place.
So how do I run an Inception meeting?
The running of the meeting as with everything is going to depend on the people in the room. This could be an informal conversation around a whiteboard going through the below questions in an order that works for you, or it may need to be a more formal agenda where people can only discuss the item at hand. The key with these exercises is to get everyone involved so that everyone is invested in the project. This should not be a meeting where you just talk at the group. As per Jonathan Rasmusson in Agile Samurai I follow the below format:
Why are we here
The aim of this section is to get everyone on the same page. Introduce the opportunity/problem. Then collectively come up with a summary of why you are here i.e. what problem/opportunity are you trying to solve/take advantage of. The key here is to keep the description short and sweet. The idea being anyone could pitch the summary of what the project is about in the length of time of an elevator ride or about 30 seconds to 1 minute. I would be targeting three sentences as a maximum.
Make a Product Box
You can just draw this up on the whiteboard, see diagram below for rough format:
Any items which you cannot agree whether they are in scope/out of scope should be put in unresolved and should be investigated outside the Inception meeting. You should allocate owners of these items to ensure that they investigate/liaise with stakeholders to resolve them.
Dependencies/Meet the Neighbours
Now get everyone to write down who you will need to work with to get this project up and running. This could be teams, or individual people, or stakeholder groups. These should then be documented and used as a basis for stakeholder management. For large organisations in particular, it is essential to understand this from the beginning. There is no point progressing a project which has a dependency on a team who wouldn’t have availability for the next six months.
Either create, or go through an existing draft of a high level plan for what you want to implement – you need to have this before you can understand dependencies/how big a piece of work it is. I have always had a draft design from a Solutions/Technical Architect in advance of the meeting, but it depends how you want to work.
Risks/Up at night
Get everyone to write down on post-it notes what it is about this project that is worrying them/they think they will worry about as the project progresses. As the name suggests these should be the type of worries that will keep you up at night. You should be considering where is this project likely to go wrong? What can we do to prevent these from the start? Are these worth worrying about?
Once everyone has completed their list they should be categorised into the following:
Not worth it (i.e. should not keep us up at night)
Please note, that the ‘not worth it’ is not in anyway a way of belittling someone’s worry. This is simply a categorisation based on whether there is something that we can actively do about the worry. For example, an external organisation creating a similar product, there is nothing that you will be able to do about this, so would be put into the ‘not worth it’ category.
Size it up
Based on the high level plan you should collectively come up with an estimate for how long this is going to take. Before everyone panics, this is very much an estimate, and should not be used as any form of promise for timescales. It should also be a high level estimate – is this a couple of weeks/months/years’ worth of work?
What is going to give?
This is why it is essential to have the high level stakeholder involved in the Inception meeting. At this stage (before anything has gone wrong) you should get them to prioritise the following:
Do not let them have some equal, the point is that they pick now the order of importance. This should make the conversation easier if something has gone wrong, as you will know what the likely course of action will be e.g. you reduce the scope, or increase the size of the delivery team.
What is it going to take?
Collectively come up with the following:
- What roles are required – are they available within the team/company? Do we have enough people in each role?
- What skill set is required – is this available within the team/company?
Who is making the prioritisation decisions?
Make this decision now, and pick a named person or agree a definite process. You do not want to be doing this mid-way through a project when you have built up a long list of requirements with multiple stakeholders all arguing as to why theirs is the most important.
Congratulations! You have now completed your first Inception meeting. You now have lots of post-it notes, so what’s next?
How does this all tie in with running the project?
There are many benefits to the Inception Deck that you have created that go along with the project, and for this reason it can continue to be reviewed throughout the project lifecycle.
- You have the perfect start for an onboarding process, any new starters can be pointed at this deck as a quick intro to your project. Likewise all of your team should be in a position in a couple of sentences to explain to any visiting stakeholders what you are up to
- It can be used as a useful reference point when refining the backlog – does the user story help us meet the benefits we are hoping to achieve? If the answer is no, then you shouldn’t be doing it! Have you inadvertently picked up some work from the ‘not list’?
- Dependencies gives you a great starting point for your stakeholder management for the project. You should be considering how you are going to keep in contact with all of these people/teams/groups.
- The ‘up at night’ section is a starting point for a basic risk register. Ideally this would be progressed, and owners assigned to each of the risks to mitigate them
- When the seemingly inevitable situation occurs when the project has fallen behind schedule – you’ve already had the difficult “what’s going to give” conversation. So it should be easier to have the conversation with your senior stakeholders about what is going to change (I can’t promise that it will make the conversation pleasant though!).
- Someone trying to sneak some work into the Sprint? Trying to move something out of the ‘Not List’? Refer them to the change process agreed!
Projects will always have their ups and downs, and curve balls thrown in for good measure. For me, the Inception Deck helps stop some of these curve balls before the project begins, and is also a useful tool for the project on an ongoing basis. It ensures that before you really start your project that everyone involved has a clear understanding of what you are trying to do, and why, where there is flexibility in the project, and what it is likely to take.
As with everything Agile it is important that you have the buy-in of your team members with this process, so make sure you explain the benefits that you are hoping to achieve when proposing this meeting. For those who have the time, I do recommend reading Jonathan Rasmusson’s Agile Samurai, but hopefully the above gives you a quick overview of what is entailed and some useful ‘how to’ guidance. All that is really left to say is that you should give it a go, and good luck with your first Inception!