If I were to ask you four simple questions about the project you are working on right now, they would be easy to answer, right?
- What are you doing?
- Who is it for?
- How are you going to achieve it?
- Why are you doing it?
It's not always as easy as it sounds is it.
So it should come as no surprise that being able to concisely articulate the purpose, audience, vision and goals of a project is crucial. Without these pillars, everything we put into our work suffers from a distinct lack of foundation; risking collapse under even the slightest interrogative gust of wind. If digital agencies and organisations alike were more vigorous in ensuring every project was bound to them, they would likely see many more successful outcomes.
It was with this in mind that I’ve recently been experimenting with a Project Canvas as a means of making these details as explicit as possible at the start of a project.
Existing solutions I’ve used previously always felt to have lacked the appropriate focus: Either too lofty in scale or scope to be practical (Stand up Business Model Canvas) or too granular and managerial to convey a higher purpose (See, well… every other project canvas).
I was interested in something that could help provide a strategically-minded UX Design team with a few critical pieces of information, as quickly and painlessly as possible. Something that would help address the following:
- A consolidated and concise brief.
Nothing is worse than trying to work from someone else's understanding of the brief. A cacophony of disparate, overlapping, ambiguous kick-off meetings with Account Managers, Product Owners, Project Managers, Creative Directors, all giving their own nuanced (and in many instances, completely alternate) focus on the undertaking at hand. - Aligning the team and baselining knowledge.
It’s painfully easy to fall into the trap of making assumptions about pre-existing knowledge when onboarding new team members and stakeholders onto a project. Getting everyone on the same page quickly, with a common, shared and definitive point of reference can help refocus direction when required. - A repeatable approach to scope and plan discovery activities.
The only thing you know for certain at the start of a project is that you know absolutely nothing. So a simple and transparent way to understand the lay of the land is essential. Having the confidence to ask (and make a plan on how to answer) pertinent and practical questions can make all the difference. - A strategic purpose to the work.
The most important aspect of any project is the meaning behind it. Without a motivation that provides objective rationale to otherwise subjective design decisions, everything can be made instantly malleable by the fickle and transient whims of high ranking Swoop-n-Poopers.
It's worth pointing out that Project Canvases are by no means a revolutionary approach. There are already an over-abundance of similar tools and techniques readily available. 2015 has almost certainly hit peak canvas, with colleagues around the office glazing over merely at mention of the format.
It nevertheless retains some strong benefits:
- It’s summative, avoiding unnecessary detail. As a single sheet with constrained proportions it can provide a useful 'at a glance' overview.
- It’s visible and tangible. Unlike a written document, hidden away on a project folder or Basecamp, it’s easy to print or write on a wall for all to see.
- It’s relational. When done well, it helps make relationships between information explicit, by virtue of where it is placed spacially and its proximity to neighbouring information.
The Project Canvas
Layout
The draft canvas I've been experimenting with is laid out so that the rows are tailored to differing levels of strategic detail (the 'Altitude'), and columns to the focus of the information required (the 'Pillars').
Altitude
The three rows from top to bottom provide an appropriate level of detail for the various stakeholders and team members who will be engaged on the project. The intention being that c-suite bigwigs, project sponsors, account managers and anyone removed from the day-to-day specifics of the project can quickly scan across the top of the canvas to gain a strategic overview. Similarly, project managers, data analysts and tech partners seeking detail on the practical mechanics can focus on the bottom instead.
Pillars
The four columns from left to right cover the crucial questions any project should ultimately address, namely:
- What are we doing?
- Who is it for?
- How will we achieve it?
- Why are we doing it?
1. What (Proposition, Challenges, Scope)
Proposition
What customer/audience/user needs are we satisfying?
This is the projects ultimate raison d'être, and one unfortunately all too often overlooked. When completing this it can be quite useful to do so as an individual exercise, by asking all participants to write what they believe the proposition to be, and then sharing with the group to discuss and hopefully reconcile (another day if necessary).
Challenges
What issues do we need to overcome or resolve?
Are there any specific technical, business or user issues or insights that should be shared? Remember that organisational politics and culture are often overlooked or ignored despite being big hurdles that have enormous impact on project success. This line of questioning needs to be delicately handled.
Scope
What are the boundaries of our remit for this work?
Where does the project start and end? The points of crossover with other teams or disciplines are often gaps assumptions fall into. These need to be made explicit.
2. Who (Audience, Stakeholders, Team)
Audience
Who are the target user groups?
Specifically identifying a primary audience is invaluable to focus efforts and deprioritise peripheral needs. Briefly discuss their core goals and any existing sources of evidence which support these insights, as too often they are anecdotal assumptions missing proper follow-up validation.
Stakeholders
Who are the business sponsors accountable for budget and success?
A responsibility assignment technique such as RACI (indicating who is Responsible, Accountable, Consulted or Informed) is useful here to understand the nuances of everyones role, particularly on larger projects that have a complex mix of stakeholders. Ensure you identify the project sponsor. They're the one ultimately paying your salary, patting you on the back or pulling the plug.
Team
Who are people and partners directly responsible for delivery?
List out everyone directly working on the production of the project. Identify the primary contact from the various parties involved, such as the Product Owner and agency point(s) of contact.
3. How (Vision, Approach, Activities)
Vision
How are we going to realise the proposition?
This is very often expressed as the brief itself in the first instance, but all too often projects are lacking an articulation of the higher purpose, or Proposition, behind it. Building an intranet, Migrating to a new CMS, Designing an app. Redesigning a website. Building an eCommerce area. These are all executions of varying levels of ambition, without any real elaboration on the purpose behind them.
It's important to get this down into a single concise statement wherever possible. Similar to the Proposition, it can be useful to complete as both an individual then a group exercise to flush out any issues with misalignment. It doesn’t need to be resolved here and now, but the sooner the better. You obviously don't want this changing half way through.
Approach
How are we going to approach the project?
Be clear on the methodology. Identify any key milestones and the tempo of demos, playbacks or presentations with the rest of the team or key stakeholders. Tempo injects confidence in those interacting with the process. Also don’t forget to flag any specific location or environment needs that would otherwise all too easily be assumed as inconsequential ’business as usual’.
Activities
What are the specific activities we will conduct?
Activities are things that happen to satisfy an Outcome or Goal (see below), so these need to be considered in tandem. If an Activity doesn’t directly seem to contribute to an Outcome or Goal, it's almost certainly not worth doing. This can also help avoid superfluous and distracting requests for your precious time further down the line.
4. Why (Goals, Outcomes, Metrics)
Goals
Why will this benefit the organisation?
These should be the core business objectives of the project (such as acquisition, retention, etc). If you can’t measure it, how will you know if the project has been a success? Setting objectives which are SMART is useful, so aim to make every goal Specific, Measurable, Achievable, Relevant and Time-bound.
Outcomes
What practical impact will this have on ourselves, our team and our organisation?
It’s important to focus on outcomes rather than outputs, so listing out deliverables here won't cut the mustard. These are more varied softer and fuzzier objectives not covered by the measurable business Goals, which can range from individual professional ambitions to team up-skilling. What will change for the better from before? These can serve as very powerful motivations.
Metrics
How will the goals be measured?
Setting targets against which the Goals will be benchmarked and tracked (e.g. increase conversion by 10%) can provide much needed evidence for sceptical c-suite exec's and critical stakeholders. However, it's likely to take time and plenty of collaboration with data analysts and others to reach consensus on what is worth measuring.
The Project Canvas is a living document, so it’s never ultimately set in stone. It can and should be modified throughout the course of the project as and when necessary. It’s intended to be made visible in the halls and on the walls of working areas, reviewed, recapped and remixed in however many slide decks and marketing materials as necessary to demonstrate a focused and aligned team.
The ultimate aim of the Canvas is to impart clarity on all who touch the project in even the slightest way. The litmus test of its success therefore would be that anyone involved has the capability and confidence to clearly and concisely communicate an ‘elevator pitch’ covering the high level What, Who, How, and Why to anyone unfamiliar with the project.
Project canvas on Miro
Miro has changed the way we work. It seemed logical to convert our much-loved Project Canvas template into an open-source board on Miro. See our Tiny Lesson on how we use our Miro project canvas.
Feedback
If you try out the Project Canvas we'd love to hear from you about how it went and how you think it could be improved.