Writing an Inception Deck

Question

I am reading the book "The Agile Samurai" and it talks about Inception Decks and Elevator Pitches. I am wondering how to apply it.

For example, an Inception Deck is to clarify:

• why are we doing the project
• what the project is

...which I suppose should correspond with what the stakeholder wants, but what if the stakeholder answers with "what do you think??

I like very concrete things. My system will do this and that, and won't do this and that. But then the stakeholder says "what do you think?" and I tell him and he says... ummmmm not quite but never gets concrete and precise on what does he want

Is there a way to get things concrete and clear? Any strategy to talk with vague people?

Answer 1

Implement Iterative Analysis Through Collaborative Dialogue

[Is there a constructive] strategy to talk with vague people?

Note: The way you structured your original question may get it closed as "opinion-based," but with a little editing I think the core of your question as quoted above is quite relevant to chartering and managing any project. The original question could just benefit from a little editing to make it less of an opinion poll and more likely to garner a (potentially) canonical set of answers.

As your question is tagged agile, it's definitely worth considering iterative clarification techniques such as the Five Why's. The central notion here is that you're already receiving validated learning from your initial presentation in whatever format, whether it's a pitch deck, a lengthy strategic roadmap, or some notes on the back of a napkin. The problem you're describing is that the feedback isn't yet detailed enough to be actionable, so you can't address the real underlying questions or adjust your planning. Iterative questions can help.

Ultimately, any effective agile approach is built on collaboration and communication. In cases like this one, you need to facilitate the dialogue in order to identify the root cause of the disconnect or clarify real requirements.

A Worked Example

Consider the contrived example below. In this example, the Q&A is inverted from the problem you describe as the clarifying questions are coming from a key stakeholder rather than from the product or project manager. However, the example still illustrates the technique quite effectively.

1. Product Manager: I think we should kick of a new program to sell embiggened widgets to Lilliputian factories.

   Business Stakeholder: I don't get it. Why is that a good idea?

2. Product Manager: Well, the Lilliputian factories need the parts, but their equipment is too small to manufacture the embiggened widgets themselves.

   Business Stakeholder: Okay, but Lilliputians are small, and so are the machines they build. Why is there a market opportunity with this program?

3. Product Manager: We'd have a first-mover advantage with the entire manufacturing industry of Lilliput.

   Business Stakeholder: Well, our current die stamps are all designed to ensmallen widgets. Why do you think we can switch to embiggening?

4. Product Manager: We already have a cross-functional team of machinists with the tools to cast new dies, and we could have the production line up and running in less than 90 days.

   Business Stakeholder: That sounds fine so far as it goes, but why do you think we have the people power or budget to do this right now?

5. Product Manager: We were 25% under budget last quarter, so we already have the estimated cash required on hand. And since our teams are cross-functional, we don't need any additional people because our teams already have excess capacity right now because our regular production lines are running so smoothly.

   Business Stakeholder: That all sounds good, but the steering committee has been shooting down new ideas recently. I'm not sure I want to be the sponsor of this new program.

How to Leverage Validated Learning from This Analysis

I bolded the last sentence because that's really the X in this X/Y conversation. In this example, the underlying issues that needs to be addressed to get backing for the project are:

1. Convincing the steering committee rather than the stakeholder that this is a good program to support.
2. Solving for the stakeholder's concerns about the personal impact of sponsorship on their career or within the company's politics if the steering committee turns down the proposal.
3. Finding a different sponsor if this particular person can't or won't sponsor it in front of the steering committee.

By iteratively refining the question through open-ended or targeted questions, you should be able to eventually get sufficient information about whatever the real concerns are. You can then use any or all of the answers as inputs to refine or adjust the proposal enough to build the necessary level of consensus.

Answer 2

Requirements are the foundation that you will use to design, and then build a solution for whatever business needs or goals are to be accomplished.

An Inception Deck is nothing more than a requirements elicitation technique that you can use at the begging of your project. A set of activities to engage stakeholders and draw out details about the project.

Ideally, requirements need to be complete, but in most cases they are not. Simply because when people have an idea or a need to meet, they can't imagine everything in details about it, or anticipate every potential issue or outcome.

So as part of business analysis activity, requirements are elicited using various techniques. To take something from a very broad idea or project statement, to something more detailed, and more focused, that can then be used to build a solution and set proper expectations going forward.

But using a technique like the Inception Deck doesn't mean that you've suddenly cast a magic spell on stakeholders and all of a sudden they know what they want, they know how to define it, and to clearly and precisely express their needs. That's not going to happen.

In fact, in practice it was observed that people are better at recognizing something that they don't want, as opposed to defining something they do want.

So because of this, any requirements elicitation, no matter if at the beginning of the project or otherwise, will have to be done in multiple passes, iteratively, and incrementally, in collaboration and communication with stakeholders.

And for example, one technique that helps even more in bringing focus onto the final solution you need to build is prototyping => you refine some of the need to have enough details to build a solution that you then put in front of the stakeholders and use it to elicit more information. Rinse and repeat until you get the final product out, or at least something that is good enough to use that requires no more iterations while you spend your time focusing on other ideas.

So it's fine if people say "I don't know", or "what do you think?", or "not quite what I imagined", because it means another iteration to refine the idea or the need, and to design a better solution for it. And if this continues for many iterations then that's fine too, because it allows you to identify a potential risk for your project from the get go. If there is so much back and forth when defining the project charter, then maybe there wasn't a strong need to begin with, and maybe there is no point in continuing with this project.