Project Definition: How to start at the beginning

In Design Decisions I outlined the 4 types of decisions I focus on in design projects - project definition, research planning, design analysis and concept development. This post focuses on project definition decisions - the earliest project conversations that can set projects up for long-term success.

When does a design project start? Sometimes it's not clear. A casual conversation about an issue leads to an impromptu whiteboard session. This leads to further conversations and brainstorms and maybe review meetings. Over the course of several interactions various stakeholders and team members look at each other and nod in general agreement about something that should be created or something that needs to change. It's like a snowball rolling along, gradually gaining mass and momentum. It's sneaking up on you... suddenly you realize you have a full-fledged project on your hands.

Many project stakeholders may be involved in these initial conversations. Rarely are all the stakeholders present for all the conversations. The project definition grows over time and each stakeholder constructs their own model of the emerging project definition which is influenced by the conversations they've been a part of and their own personal motivations and desires. Before actual work starts there may be multiple project definitions floating around in the minds of multiple stakeholders.

Projects that begin like this (almost all projects suffer from this to some degree) are at risk for difficulties later when the actual work happening doesn't fit the project definition in the mind of an important stakeholder. When projects aren't well defined from the beginning many problems can arise.

Teams focus on the wrong problems

Projects that gather momentum naturally aren't always the right things for teams to work on. Organizations might choose different projects to work on or probelms to focus on if they considered all possible projects and not only the ones that naturally gain momentum.

Scope creep

Difficulties arise when criteria are introduced late in the game. Teams can be stretched to the breaking point trying to accommodate new requirements that weren’t planned for from the beginning. Adding new activities that weren’t accounted for at the beginning increases likelihood that schedules are missed.

Teams feel disenfranchised

When outside stakeholders bring new requirements to the table that affect the course of the project the team will feel a loss of agency, ownership and control. This can cause the team to disengage near the end of the project when critical work remains to be done.

How to define a project

A little discipline at the start of a design project can go a long way towards alleviating these difficulties. There are many ways to define a project – I use a simple model to ensure I have coverage of key aspects of work to be completed. Different organizations may require additional or more detailed defining topics but I think it's important that any project definition include the following:

• Goals or requirements

• Activities

• Deliverables

Goals or requirements

What are we trying to accomplish with this project? What would success look like? What do we want to be different about the world when we’re done?

By definition, all the goals and requirements cannot be known at the beginning of a design or innovation project. Through design research and analysis many requirements will emerge during the project. While the team cannot have a complete knowledge of goals and requirements at the outset - team members and stakeholders always have some notion of what the project is about from the beginning and these ideas should be captured.

Activities

What Activities will the team engage in over the course of the project? Will there be regular stakeholder check-ins? Travel for user research? What is the timeline for the project?

Addressing questions about the activities of a project is an important part of expectation setting. It also allows the team to weigh in on timelines required to tackle the defined activities. For example, frequent stakeholder check-ins can be time consuming for the project team if there is much preparation required for those sessions. This prep-time cuts into time available to work on the actual project and can make overall timelines unrealistic if not considered from the beginning.

Deliverables

What concrete work product is the team driving towards? Who is the audience for the deliverables and how are the deliverables expected to be used?

Knowing expectations about deliverables is important for several reasons. For one it helps the team ensure they have the right people with the right expertise to get the job done. Also, understanding expectations of deliverables plays a large role in discussion of timelines - high fidelity prototypes will likely take longer to develop than lower fidelity prototypes or a simple slide presentation for instance. I like to consider the audience for the deliverables just like a user of any product I am designing - who is the audience for our deliverables and what are they meant to accomplish with our project output? How can we best support that user? Understanding deliverables as a product with a user helps the deliverables stay focused and efficient.

Capture, discuss and commit

During early project conversations it is important to capture a defining issue when it arises. When I recognize a potential defining topic arise during conversation I like to grab a post-it note and sharpie to capture the thought. I want to make sure I understand the thought by playing it back to the author and also make sure they feel heard and understood. When a critical mass of defining topics are collected it’s important to socialize and discuss them.

This discussion is ongoing - it is not to be "completed" before all other work on the project begins. The earlier the conversations start however, the more likely a team is to avoid the pitfalls of poor project definition. The conversation should be revisited as and when important new topics arise or an existing goal becomes clearer or better understood. The goal of the conversation is to agree – and maintain agreement – on which topics are solid commitments for the team, which are nice to haves and which are not on the table for now. With this conversation the team has clear marching orders for the project.

It's useful to capture all topics for discussion - even if in the end the team will not be expected to satisfy all these requirements. Having the discipline to capture and discuss all the possible requirements that arise minimizes the chance of later stage scope change. Teams need to decide what is out of scope as much as they decide what is in scope.

Project definitions evolve

It's not linear - the project definition will change over time. Design project teams learn over the course of a design project. This learning may suggest new requirements to be considered, new activities to be undertaken or new types of deliverables to be made. It's key to keep track of new defining issues as they arise and keep the team and stakeholders up-to-date.

Start on the right foot

Recognizing when a new project is emerging is key to giving the project a chance at eventual success. Design projects can and should be rewarding, challenging and fun. Too often the challenges that arise are not about the design problems to be addressed but rather internal political and process challenges that are impediments to the ultimate value of the project output. Projects loaded with this type of stress and anxiety are not likely to succeed and it is in the very first moments of the project that the seeds of these conflicts arise. Diligence and discipline on project definition is an important first step in eventual project success.

Ambiguity to clarity - an example of an evolving defining topic

At IDEO I worked on a food packaging project. The client came with several goals and requirements. The example below shows how an ambiguous goal became more clear and actionable for the team over a series of conversations.

During the initial conversations a client stakeholder shared with us that they thought an important goal was to create a “Brand Experience.” Brand and Experience are two of the most ambiguous words in the English language and here we were using them together to describe a goal for out project. I captured it on a Post-it note.

I like to keep the defining topics of the project top-of-mind and easily accessible during the course of the project. This way when the topic comes up the team can easily discuss, refine and potentially change the project definition. This “Brand Experience” defining topic came up frequently during prototype reviews and we gradually added more clarity to this area of the project definition.

During one brainstorm and idea came up that our client particularly liked because they felt it would be “memorable and differentiated” - when they said this I captured it on a post-it because it sounded like an important goal we should strive for. We added it to our understanding of the “Brand Experience” defining topic.

During a later prototype review another comment stood out as significant and was added to our understanding of the “Brand Experience” goal.  Our client said: “We really want people to seek out our product over our competitors because of the packaging we’re creating here.”

Maintaining diligence and paying attention to the emerging project definition even into the later phases of prototype development helped us turn a vague project goal into a more actionable and potentially measurable criterion.