The key message from this week was simple but easy to overlook. When a project starts it starts and when it ends it ends. Time is fixed and the way you allocate it across the different stages of a project will determine the quality of what you produce. Proper preparation prevents a poor final project.
One thing that stood out was the reminder that the middle of a project tends to get messy. It is easy to front load the early stages with enthusiasm and then rush the middle when things get complicated. That middle section deserves just as much attention as the beginning and the end, arguably more.
A good project starts with clarity. A well defined problem statement gives the whole team a shared understanding of what needs to be done and why. Beyond that, knowing your team, understanding who is in it and what each person brings, is just as important as knowing the problem itself.
From there a good project needs a clear goal. What does success look like, and importantly that question needs two answers. What does success look like for us as a team, and what does it look like for the user. Those two things are not always the same.
Scope and constraints need to be established early. What is the budget, what is the timeline, what technology is available and what can realistically be achieved within those limits. Scope creep is a real risk on any project and being aware of it from the start is the best way to avoid it quietly derailing the work.
Finally a good project defines its key metrics upfront. How will we know when we have succeeded? How will we measure that success? Without answers to those questions it is very difficult to evaluate whether what you have produced has actually done what it was supposed to do.
Stakeholders also need to be mapped and understood. The framework introduced was a simple hierarchy of core, important and helpful. Not every stakeholder gets an equal say and knowing who sits where helps manage expectations and prioritise whose input shapes the work most directly.
Two frameworks were introduced this week as tools for structuring design thinking.
The Double Diamond maps the design process across four stages. Discover, define, develop and deliver. Discovery is about going wide, exploring the problem space and gathering signals. Define is about closing the net, using what you have found to frame the problem clearly. This is a process of exclusion as much as inclusion. Develop is ideation, going wide again to generate multiple potential responses to the defined problem. Delivery is implementation, refining the final solution based on real world feedback. The double diamond is useful because it makes the difference between divergence and convergence visible and helps teams understand which mode they should be in at any given point.
The Stanford Design Thinking framework covers similar ground across five stages. Empathise, define, ideate, prototype and test. Empathise is about learning deeply about the audience. Define is about sharpening the key questions that need to be answered. Ideate is brainstorming solutions. Prototype is building representations of one or more ideas. Test is about putting those ideas in front of real people and gathering feedback. The two frameworks complement each other well and both were useful reference points throughout this project.
