How we built a project classification framework in 6 weeks

(While still running all our client projects)

By Alexandra McIntosh (Product Person)

The best results always happen when everyone’s on the same page. Over the past few years, we’ve found where teams tend to be least aligned is in agreeing which stage a project is in the product development process.

While it seems obvious, it often isn’t.

The missing ingredients tends to be a shared mindset and approach. Some people want to converge, others want to divert.

“Are we building this thing right now, or are we just trying to figure out if it’s a good idea?” — said every team member ever

Questions like this create uncertainty and noise. If you can answer them up front, projects run much smoother.

To align teams, we’ve created and published a project framework to identify where in the product development process you are. These are the steps we took to to achieve this.


Week 1 — Studio retrospective on process and first iteration of the project framework

A studio wide retro on our process sparked a conversation around the lack of clarity around how to approach specific projects. Some of the questions slowing us down were:

  • Are we prototyping or building the site?
  • Are we running usability testing or are we only testing the concept?
  • What documentation do we need for this type of project?
  • How do we make money from this thing?
  • How do we onboard team members half-way to a project?
Studio retro on process

The retro led to lots of hallway conversations about how solve this. Those involved were quick to put pen to paper to articulate their solution. This is where we landed at the end of the week:

Process Framework — Iteration number 1

The sketch is a framework which describes projects based on:

  • Scope of the project (from Iterative to Step Change)
  • Definition of solution (from Tangible to Vision)

Week 2 — Fleshing out the framework and sense checking it with the team

This week we moved on to build out each of the project types in an off-site. For each project we looked at:

  • Outcome — what the project owner really needs at the end of this page
  • Mindset — the team should adopt when approaching the project
  • Toolkit — exercises, templates, methods, products appropriate at this stage
  • Approach — the steps we would likely take to reach the outcome
Mindset and approach for Top Right (Step Change + Tangible)
Tool Kit and Outcome for Top Right (Step Change + Tangible)

We built out mindset, tools, approach and outcome for the four project types which surfaced the differences in our thinking and sparked a few healthy discussions.

Some dot voting helped us reach consensus as to the mindset, approach and tools to apply to each. A little synthesis after the offsite and we were ready to pressure test the framework with the studio at Friday book club.

Would the team place our live projects in the same place we had?

Sense checking the framework at our Friday Book Club with the studio. “Where would you place this project? Ready, set go! After silently voting, coloured stickers per project were placed in the quadrants to show were everyone thought they belonged. .

Thankfully, the majority did.


Week 3 — Aligning on the need to ‘go live’ and adding some science to our classification system

The framework made sense. The next step — getting it live. First, an exercises to check everyone was on the same page as to why it needed to be live (as opposed to in google drive or our internal wiki). The top reasons for being external facing were:

  • It makes it feel more real, solid and necessary to follow
  • So we can have open and honest conversations with clients about where they are

Good to see we were aligned, Carry on.

Time to flesh out criteria to help classify a project in order to add depth to the one liners to describe the needs of a project owner per quadrant.

  • Have an idea, and need to build a case to prove its viability?= Step Change + Vision
  • Have a case for something, but need to bring it to life? = Step Change + Tangible
  • Have something to work from, but see opportunities to grow? Iteration + Vision
  • Worked out what has to happen, just need someone to do it? Iteration + Tangible

How? Post-its on the wall for each quadrant of what might be on the project owners to-do-list.

Project checklist session — Our favourite in the bottom left “we did outgrow the status quo” (thanks Jo)

We saved the refining the criteria for the following week.


Week 4 — Refining project checklist and sketching product solutions

The week started creating criteria to vet the project checklist criteria (meta). Our thoughts were around five per quadrant (five feels like a nice, solid number)

Our vetting checklist:

  • Binary — each item could be answered with a ‘Yes’ or ‘No’ (it’s hard work to avoid the maybes)
  • Applies to only that quadrant — this was hard, especially between ‘Step Change + Vision’ and ‘Iteration + vision’
  • Literal — not metaphorical/figurative. We wanted to remove room for creative interpretation.
  • Each quadrant covers user, business and tech — at least one item per quadrant
Culling our project classification checklist

Week four wrapped up with a co-design session to explore what the project framework might look like.

Studio sketching day — get amongst it.

A few in the backlog:

  • Team structure and roles (coming to the project framework soon)
  • Timeline and cost (coming to the project framework soon)
  • Chatbot to assess which project type to run (thanks Liam)
  • Custom project plan with timeline, tasks, outputs and team
  • Build your own project toolkit

Week 5 — Building the content model, some co-design and the epic visuals

Theme of the week = super quick.

We were adamant to get it live before end of the year to avoid losing momentum.

Our MVP included team roles per project. But on the list of things to do is workshops with leads and teams to define these, which isn’t locked in till next year. Team roles were culled and we worked with what we had. You’ll see those next year.

Week 5 — final sprint

Our main design challenge, were the axes necessary? Yes — Testing showed the matrix is a heuristic, helping with decision making by forcing a choice between the scope of project (x axis) and definition of solution (y-axis). This surfaces the difficult conversations early.

We took an object orientated UX approach, first defining all the objects in the content model.

Creating the content structure

Once the content model was sorted, we moved on to co-design, working through the relationships between objects. Then, in the same day started on visuals — an evolution of the MF palette from a lighter to a dark UI, and the addition of a few new colours and some iconography. We wrapped up the day settling on a construction theme for project names: Architect, Engineer, Renovator & Handy Man — Thanks Mon.

The next day we set up our content model in Contentful in the morning and moved onto dev set up in the afternoon. By end of day we had the main page of the project framework done.

We spent the rest of the week designing and building the project pages.


Week 6 — Get it live

The final week started with a co-design to smash out the icons for the project toolkits. We put on a timer for 1 minute per tool and picked the best to run with. In under an hour we’d decided on all our icons. No time to muck around.

Icon sketching — fidelity not welcome

We got the rest of the content in Contentful — a headless CMS allowing flexibility in design, with its focus on structuring and delivering content via an API (so no restrictive front end templates)

Then finished the build — using Jekyll to build a static site along with Codeship and Github for Continuous Integration and finally deployment to Amazon S3. We pushed the site live in under 1 week.

Then wrote this medium post.

Check it out ->

Show your support

Clapping shows how much you appreciated Mentally Friendly’s story.