Wednesday, April 17, 2013

Trading Opportunity for Reduced Risk

Make no mistake about it, deliverables slow down your team, product and organization. Depending what the deliverable is and why it's done, this may or may not be a bad thing. Chances are, however, that your 'deliverables' are a product & organizational smell.

Deliverables can mean a lot of things;  it definitely rocks the edge of a rabbit hole. In the context of Product, teams and organizations, it generally refers to artifacts whose purpose is to mitigate risk or facilitate communication. With them, you're trading opportunity for reduced risk.

Roadmaps, Wireframes, Business Cases...Oh My!

So the tasks in the above header fit squarely in project management. They are about mitigating risk and internal communication; they do not involve customers and do not deliver value to them. The smell of these generally mean that trust is lacking in the organization and you're paying opportunity costs. Taking a page right out of Maslow, these assume that people are not trusted with mistakes, are not fully informed and do not identify with the same managerial objectives.

The goal of roadmaps, wireframes and business cases (and others) is to help spread trust, information and objectives; however, are they really they best way to do this? Can trust simply be implicit? Can a 'roadmap' be in a form that does not drag the team and organization? What if we entirely skipped wireframes and went from concept to prototype?

Even if it can be agreed that deliverable artifacts such as roadmaps, wireframes and business cases are just a drag on the team or are just about mitigating risks - is that so bad...? Well depending on when they are presented - yes it is.

Communication or Priming?

Besides being a waste of time (time is a powerful competitive advantage and should NOT be squandered) a big problem associated with deliverables is how they invite groupthink and Parkinson's law of triviality. This often leads to an end result which is unfocused, organic and probably late. The problem here is that they curtail creativity and set preconceived notions into someone's mind. This is an easy one to test. When an initiative starts, show a wireframe, explain the problem space and ask everyone how they would solve the problem space.  You'll likely find that everyone will start to think about the solution in the same way; in a way that is similar to the wire frame. This is also known as priming.

Now, next time, start off by explaining a problem space, then ask everyone how they would solve the problem. It's almost guaranteed that everyone will have a different way of solving it. Of course, eventually something has to be written down or shared, to facilitate some consensus. When this is done, it should serve as a historial record - NOT as a perquisite to effort.

Trading Opportunity for Reduced Risk

Business cases also trade opportunity for reduced risk. It could be argued that before an endeavor starts a business case must be made to 'approve' it. Well, what happens if in the course of operationalizing this business case, other opportunities are discovered? Does that mean that the team forgoes the opportunity for the sake of executing the business case? What if during early on in executing the business case, it becomes clear that the assumptions (which is, after all, the only thing business cases are) that made up the business case are wrong? Does the team stop? If they do, did they fail? 

Documents Don't Solve Problems

Deliverables should be thought more of as artifacts - breadcrumbs that show where a product is going: not before it goes there. When an artifact is presented / delivered before an initiative starts, it reduces your options and closes doors. Sometimes this may be necessary in order to focus individuals and bring structure where none exists. Just keep in mind though, that you're trading opportunity for reduced risk.