Shaping

AKA Project Roadmapping, AKA Solutions Design

The phase in a project between requirements gathering and beginning the work. The art of examining constraints and resources in order to design a solution to a problem. Term is inspired by the Basecamp book, Shape Up.

Shaping involves identifying risks and rabbit holes. Rabbit holes are unanswered questions that could cause trip ups in development. Reducing unknowns and therefore risks is the primary value add of shaping.

Shaping involves setting the appetite for the solution. How much time and resources are you willing to invest in the solution? This is a more useful question than asking for a estimate, and focusing on "how long it might take."

Shaping is still early enough to walk away from a project. It's simply a time to explore ideas.

Shaping should also define no-gos. Anything specifically excluded from the concept. Functionality or use cases we intentionally aren't convering. Defining these contours increases legibility for both sides.

Factors to consider for project-wide shaping

• What are the hard requirements for this project?
• Which requirements are flexible (and thus, not requirements)?
• What are the constraints of this project?
• What is ongoing support plan for this project?
• What do we need to do to guarantee the security of the application?
• What 3rd party integrations will this project involve?
• What are the risks involved with this project?
• Do we require any data form internal or 3rd party sources? How will we get that data into the new system?

Questions to help with shaping features

• Where in the system does the new thing fit?
• How do you get to it?
• What are the key components or interactions?
• Where does it take you?

Questions to help identify rabbit holes:

• Does this require technical we've never done before?
• Are we making assumptions about how parts fit together?
• Is there a hard decision we should settle in advance since it doesn't trip up the team?

Shaping Artifacts

• Fat Marker Sketches. Shaping is typically too early to start fleshing out a full UI. Instead, use some kind of rough visualization to explain ideas.
• Roadmapping Documents Documents including the information above, outling the key features of the application. Can also include estimated costs and price.
• Solutions Architecture documents & graphs. For project wide shaping, you may also include documentation outling what the technical resources will be.