One area most agile methods are completely silent on is project chartering. Below is a lightweight you can use to fill this gap and get your project headed in the right direction long before the first line of code every gets written.

10 questions to ask at the start of your next project

It starts out so hopefully. As you begin the project, you and your team are all on the same page. Or so it seems. Then you start actually building, and you realize that you all had something different in mind. Has it happened to you?

How many of your projects start off like this: You and your team get together at the start of your project thinking you are all on the same page?

And when you start building something, you realize you were thinking something completely different.

This happens all the time on projects: assuming there is consensus when none exists.

While good teams can roll with these punches and adapt as they go, it’s a form of waste that can hurt or kill the unwary before they even get out of the gate.

To nip this problem in the bud, when I was at ThoughtWorks we created a lightweight project chartering tool called “The Agile Inception Deck: 10 questions and exercises you’d be crazy not to ask before starting your project.”

These questions serve two goals: alignment and expectation setting.

Alignment is about making sure you and everyone else are on the same page with regard to why we are here, what we’re trying to do, and how are we going to get there. Basic stuff.

Expectation setting, on the other hand is about you communicating clearly with your team and stakeholders what it is going to take to make this project a success. You are defining the rules of engagement.

Yes we can build that for you. No it shouldn’t be too difficult. Here is what it is going to take….

You need to have that conversation early and make sure your customers know what you’ll need to best serve them. Don’t assume. Be explicit and ask.

How do you know what your customers really need? A good place to start is to ask them:

1. Why Are We Here?

You can’t build a great product if you don’t know why you are building it in the first place. Asking why gives you and the team the context you need to make all those smart decisions while executing.

For example, say you were hired by a construction company to create an online road-closure system for mapping which roads were closed by date on a given construction site.

An obvious question that would help you and the team build the solution is asking “why?” Why is the company spending shareholder capital on this project in the first place?

Is it about safety? Is it a regulatory requirement? Or is it to act as a traffic broker for the efficient movement of material and goods on the construction site?

Knowing and understanding the number-one driver behind your project is going to give you the insight to make those balanced trade-offs that inevitably come up during delivery. You can’t do that if you don’t know why.

2. Create an Elevator Pitch

Projects can be a lot of things to a lot of people. This exercise is about making sure they are not.

A good elevator pitch tells people what your product is, who it’s for, and why it’s special in about the time it takes to take a ride in an elevator.

Creating a good one can be harder than you think. But once you get it, it feels great. You can quickly distill a big abstract concept (which is how most projects start) into something tight, real, and concrete.

3. Design a Product Box

Thinking hard about your product from your customer’s point of view is always cool. Not only does building a product box get you in the head of your customer, it’s a great team-building exercise, as you are formally given permission to draw and color at work.

You don’t have to come up with anything elaborate or complex. Just ask yourself:

1. What are the top three reasons people are going to buy this product?
2. And if there was one slogan that captured the spirit of this thing, what would it be?

4. Create a NOT List

Saying yes is easy. It’s saying no that is hard. The NOT list starts to put some stakes in the ground and to set expectations around what you are not going to be doing as part of this project.

Saying what you are not going to do is powerful. It eliminates a lot of up-front waste by letting the team focus on the stuff that is clearly IN while ignoring everything that is OUT. It is from the IN column that all of your high-level user stories will flow.

Also, it’s not uncommon to have a lot of things that could be in scope but for whatever reason (usually time and money) aren’t. Better to resolve these now than to leave them till later.

This is really a “big rock” scoping exercise. All you are saying here is: “If we move these big rocks as part of this project we are going to be OK.”

5. Meet Your Neighbors

I once almost lost a project because I didn’t appreciate that your project community is always bigger than you think. It’s easy to think it’s all about you and your core team. But the reality is that most projects require more than just the day-to-day people on the project to be a success (especially in big companies).

This exercise is about getting you and the team thinking ahead of time about who you are going to want to meet and establish relationships with before going live. Not only is this courteous, it lets them prepare for your arrival and be there when you need them.

6. Show the Solution

You pick your architecture when you pick your team so you’d better make sure everyone is on board with your solution before you begin.

This exercise is about telegraphing your punches. If you are counting on solving this project using a certain set of tools or architecture, better to let them know up front. You’d hate to be caught off guard because of some corporate standard.

This is also your opportunity to come clean if you don’t have all the answers (that’s OK too!) Let them know.

7. Ask What Keeps Us Up at Night

There are a thousand things that could wrong on our projects. Some we can handle. Others we can’t. This exercise is about making sure we identify the risks that are worth worrying about and not sweat the ones that aren’t.

For example, you can’t do much to prevent the economy collapsing, or your customer getting promoted to VP of Engineering. So don’t sweat it.

Having full-time dedicated team members, however, is something you can manage and is worth fighting for.

This is your chance to call out the craziness before the project begins and fight for what you are going to need to make this project a success. You may not get everything you ask for, but it never hurts to ask.

8. Size It Up

This exercise is about answering the question: is it bigger than a breadbox? We can’t say exactly how many days it’s going to take to do this project up front. But we can say whether it’s a 3-, 6-, or 9-month’er.

To do this exercise you’ll need to do some high-level story planning and estimation. The NOT list will serve you well here. And you will need to come up with some high-level numbers to at least give your stakeholders some idea of how big this thing is and what they are looking at.

The point here isn’t precision. It’s to determine whether this project is even remotely feasible with the resources you’ve got.

9. Be Clear on What’s Going to Give

All projects have levers like time, money, scope, and quality. Better know going in which of these is most important, and which ones can flex.

For some projects it is all about money. For others it’s all about the date.

You need to have this conversation up front so you’ll know, when push comes to shove, whether you are going to be able to flex on scope (preferred) or whether you’ve got wiggle room around the date.

The other thing you’ll want to discuss is: what is the one thing that would really knock this project out of the park? Is it ease of use? Simplicity? Speed? Flexibility? Safety? Write those things down and make sure they are on everyone’s radar before you start out. These high-level aspirations can be your guideposts when things get dark.

10. Show What It’s Going to Take

This exercise is about the two questions burning on every stakeholder’s mind: how long is this going to take and how much is it going to cost?

If this is a pre-sold piece of work, your budget may have already been set. In this case all you need to do is some simple table napkin math to see if this project is feasible given the cards you’ve been dealt.

This is also your chance to show what kind of team it’s going to take to pull this off. Here you can set expectations around team size, skill set, and the mix of cross functional skills necessary to make this happen.

It’s About Getting the Right People on the Bus

Doing an inception deck for your project isn’t magic. It’s simply a matter of getting the right people in a room, asking them the tough questions, and then sharing the results with your stakeholders and everyone else on the team.

It can take anywhere from a couple days to one or two weeks to complete and is usually good for 3-6 months of planning. But it’s an invaluable tool for setting up-front expectations on your project, and for reminding people what you and your project are all about.

So before starting your next Agile project, make sure you ask the tough questions up front and get everyone aligned going in. You’ll look like a pro and it will set your project up for success long before that first line of code ever gets written.