Principles of Shaping a Project
I stumbled upon book on shaping up a project by Basecamp and found the techniques mentioned there interesting. I thought of keeping a summary of the ideas as blog post so that I can keep referring to it.
Shaping up a project
When we shape the work, we need to do it at the right level of abstraction: not too vague and not too concrete. Product managers often err on one of these two extremes:
-
When design leaders go straight to wireframes or high-fidelity mockups, they define too much detail too early.This leaves designers no room for creativity.Over-specifying the design also leads to estimation errors.
-
On the other end of the spectrum, projects that are too vague don’t work either. When a project is defined in a few words, nobody knows what it means.
Properties of a Shaped Project
-
Work in the shaping stage is rough. Everyone can tell by looking at it that it’s unfinished. They can see the open spaces where their contributions will go.Work that’s too fine will commit everyone to the worng details. Designers and Programmers need room to apply their own creativity.
-
Despite being rough and unfinished, shaped work has been thought through. All the main elements of the solution are there at the macro level and they connect together.
-
Shaped work indicates what not to do. It tells the team where to stop. There’s a specific appetite—the amount of time the team is allowed to spend on the project. Completing the project within that fixed amount of time requires limiting the scope and leaving specific things out.
Who Should Shape
-
Shaping is creative and integrative. It requires combining interface ideas with technical possibilities with business priorities.
-
Shaping is primarily design work. The shaped concept is an interaction design viewed from the user’s perspective. It defines what the feature does, how it works, and where it fits into existing flows.
-
It’s also strategic work. Setting the appetite and coming up with a solution requires you to be critical about the problem. What are we trying to solve? Why does it matter? What counts as success? Which customers are affected? What is the cost of doing this instead of something else?
Steps to Shaping Up
Set Boundaries
The first step to shaping up is setting boundaries and what we are tyring to do. The best way to start with is setting up the appetite by asking the question of is it really valuable to spend time on this otherwise we can commit resources or have long discussions about potential solutions that will lead nowhere.
I have mostly worked on two weeks cycle which sometimes get changed to one week cycle which I have felt is very constrained.In this book they mention about using six weeks cycle and they usually set their appetites in two sizes:
-
Small Batch: This is a project that a team of one designer and one or two programmers can build in one or two weeks. We batch these together into a six week cycle.
-
Big Batch: This project takes the same-size team a full six-weeks.
Fixed time Variable scope
An appetite is completely different from an estimate. Estimates start with a design and end with a number. Appetites start with a number and end with a design. We use the appetite as a creative constraint on the design process.This principle, called “fixed time, variable scope,” is key to successfully defining and shipping projects. This principle can be applied to each stage of the process right from shaping projects to building and shipping them because
the appetite constrains what kind of a solution we design during the shaping process
Good is relative
We can only judge what is a “good” solution in the context of how much time we want to spend and how important it is.
….to be continued