What exactly is a double-black-diamond project?
The name comes from ski trail markings, where a single black diamond indicates (at least in the U.S.) an "advanced" trail, while two black diamonds indicate "expert."
In reality, the difference between single- and double- black trails is that a strong skier can typically waltz onto a single diamond slope and have confidence that it may be interesting or challenging, but it will have a predictable outcome.
The double black trails, on the other hand, can feature hidden obstacles, cliffs, terrain features that vary with the snow conditions, and even areas which may be practically unskiable depending on conditions. (E.g., the cliffs in the background of this image are the double-black "Palisades" at Sugar Bowl.)
In software development, a double-black-diamond project is one where the outcome is in question from the beginning, not because of resource issues (e.g., too few developers or too little time), but because some fundamental unknowns are involved. Something new is being created, and it is sufficiently unique as to make it unclear whether it is even possible to succeed, or exactly what "success" will look like.
These unknowns might involve integration to an unknown external system, performance of problematic features like voice recognition, custom hardware, etc. If these challenges seem feasible enough, or success seems valuable enough, to make the software project worth a try (ultimately an investor decision), but the sheer implementation risk (as opposed to business risk) is clear from the start, you've got a double-black-diamond slope in front of you.
I will be writing a number of posts on these double-black-diamond software projects, and I plan to cover
- typical elements ("signposts") indicating a double-black project
- why, as a developer, you might ever want to get involved in such a project when there are lots of other opportunities
- gearing up: the skills, knowledge, and/or people to bring with you
- the art of keeping project sponsors properly informed (the subtle part is the definition of properly)
- how to handle risk and predict outcomes (as much as possible)
- maneuvers and techniques to gain leverage and minimize the odds of failures or surprises
- managing the definition of "project success" (and why it's essential to do so, even as a coder)