Using a Project Canvas to define the what, who, how and why.
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?
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:
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:
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').
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.
The four columns from left to right cover the crucial questions any project should ultimately address, namely:
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).
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.
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.
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.
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.
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.
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.
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’.
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.
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.
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.
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.
If you're interested in more details regarding how to facilitate a Project Canvas session, you can find an extended version of this article on my website.
If you try out the Project Canvas I'd love to hear from you about how it went and how you think it could be improved.