The Project Canvas – Defining Your Project Visually

Defining a project accurately is critical to its success. Sometime this isn’t an easy task, particularly at the beginning: small deviations at the start can have exponential negative effects later on. This post presents a tool to help you visualize your project: The Project Canvas. Download the canvas and read more about how to use it.

by Jim Kalbach

---

** UPDATE **

As of 27.7.2012 the Project Canvas is out of beta.

The links in this post now point to v1.0 of the canvas. 

——

Defining a project in its earliest stages is likehitting a golf ball: if the face of your club is slightly tilted , you’ll end up slicing the ball as it travels down the green. Likewise, small miscalculations at the beginning of projects can have massive consequences down the road.

Part of the problem is that the logic of a project definition is invisible. You can’t “see“ project goals or risks, for instance. Sure, you can write them down as text. But long documents – if they get read at all – tend to get lost in the shuffle as the project proceeds.

What’s more, a written description of project elements doesn’t expose relationships between them. The big picture can fade quickly as work and deadlines pile up.

I’d like to present a tool to help you get a quick, but broad definition of a project in a single overview. It’s called the Project Canvas. You can download it here:

Download the Project Canvas v1.0 (PDF)

You can use it freely, but note that this is a beta version. Please send feedback directly to james.kalbach@useeds.de for improvements.

Figure 1: The Project Canvas (by Jim Kalbach)

This approach is directly inspired by Alexander Osterwalder’s Business Model Canvas. Like project definitions, business models also have an invisible logic. To expose relationships between the elements of a business model, Osterwalder developed a canvas to visualize 9 most-important dimensions.

In the Project Canvas° I’ve focused on 10 aspects of projects most relevant to design-related projects, explained below. For the sake of keeping the canvas simple, I’ve not included further potential elements, like “assumptions” and “critical success factors.” Budgeting and resource concerns are also steps that come later and are not included here.

Elements of the Project Canvas

First, there is a group of elements that make up the start and end of the project, located at the top and bottom of the canvas with grey boxes:

• Project – Name the project in the grey box in the upper left.
• Motivation – In 1-2 sentences, describe the overall intent of the project and what caused the sponsors to decide to initiate the project. Here’s an example: “metrics may show that conversion rates are continually slipping, and analysis of the problem shows that the check-out process is too long. This project intends to address this problem.”
• Project End – At the bottom of the Project Canvas is a place to indicate when the project is over. It may be a launch date or it may be a decision by stakeholders to accept the outcome (such as with agile processes).

The detailed elements of the Project Canvas° are the 10 boxes in the center:

• Users – I believe users stand at the center of attention in every project. Accordingly, we’ve put “Users” in the center of the canvas. At a minimum, list here the main target groups relevant to the project. This can be at a high level, such as “readers” and “advertisers” for a media portal. You may want to be even more granular in detail. For instance, you can list personas you’ve developed here, as well.
• User Benefits – List the concrete benefits that users will have when the project is successfully completed. What will they gain from it? This can include things like “faster check-out times” or “more control over their own content” and so forth.
• Goals – To the left of users is a region for project goals. You can also map success metrics to each goal in this box. Include subheaders in this box to distinguish different types of information.
• Participants – On the far left is a list of project participants. This should include all people involved in the project in some way. We tend to have several lists of participants by type, such as “core team,” ”stakeholders” and “interested parties.” Include individual names as much as possible. Optional: in the lower half of this box you can show dependencies. For instance, if prototypers are depended on getting content from a client, that should be made explicit.
• Activities – To the right of “Users” is a list of key activities. These are the methods and approaches you’ll be employing on the project. Examples include “User research,” “Persona development,” “Concept design,” “Wireframing,” “Creation of detailed mock-ups” and “User testing,” to name just a few design-related activities.
• Deliverables – List the documents that will be delivered. This doesn’t need to include internal working documents, like spreadsheets and analysis documents. It should only include things stakeholders or other teams will see, as well as assets that appear in a product or service that customers may see.
• Risks – This is a list of potential future events that can have a negative impact on the project. For instance, recruiting users for testing may be a risk for target groups that are difficult to get to: in this case the impact would be slippage in testing timelines or a reduced sample size. You can also list how you might mitigate known risks here.
• Milestones – List the key dates and events that frame the overall timeline of the project. This doesn’t need to be a detailed project plan. It should include things like “workshop with senior management,” “user testing sessions” and a launch date.
• Constraints – Time and money are always constraints, and you need not list them here. Resources are also a typical constraint, so only list exceptional resource constraints. The focus should be on overarching limitations on work products and processes. For design, this may be something like: “the designs must comply with the CI guidelines.” Include technology and platform constraints here as well. For instance, if a website needs to work on an iPad and smartphone, you’ll want to know about it from the very beginning.
• Scope – Finally, define the scope of the project. List the features and functions that are in consideration on the project. Also list what is NOT in scope here, if known. Information in this box is helpful in fighting scope creep later on in the project.

Download the Project Canvas v1.0 (PDF)

How To Use the Project Canvas°

There are several uses of the project canvas:

1. Briefings – Print out the Project Canvas and bring it to briefing meetings. It serves as a great checklist of questions to ask. Your notes will also be concise and captured in a single overview by jotting the answers you get directly on the canvas.
2. Kick-off Workshops – Make a large poster of the Project Canvas for kickoff meetings. Use sticky notes to fill it out collectively as a team. This guides the discussion and keeps the meeting focused.
3. Project Reference – Hang the completed Project Canvas in the office or project rooms for quick reference. This helps keep the defining elements in sight at all times.

The Project Canvas is primarly an offline document, meaning it’s most effectively used with sticky notes or by writing directly on it in a printed form. The PDF file, however, is editable (e.g., using Illustrator), so you can capture the elements digitally as well.

Download the Project Canvas v1.0 (PDF)

Try the Project Canvas. Again, please keep in mind that it’s still a beta version. I’d like your feedback on how to improve it. Email james.kalbach@useeds.de directly with your comments.

Tagged: business model canvas, project canvas, project definition

Posted in: English