Necessary and Sufficient

When was the last time you did a Proof-of-Concept (POC) ? Not sure - well let me pose another question...When was the last time you embarked on a technical project/task that had a considerable degree of risk in it?

IMHO one of the primary responsibilities of the project stakeholder is to mitigate the risk associated with the technical components of the business. Let's think about that for a minute. What risks are there, and how do you mitigate them? Well apart from the obvious and well documented issues like high availability, application scalability, disaster recovery, data loss, security breaches, project overrun, etc one risk that impacts on the engineering team is the occasional, or often, reliance on 3rd parties for significant components of your technical offering.

Sure, your engineering team might by LAMP/.Net/RoR domain experts and are very comfortable working in an agile environment with AJAX-y interfaces and all the bells and whistles of modern "web 2.0" applications, but as time-to-market is important and in a world where open APIs and SaaS are becoming more prevalent, invariably you'll eventually want to integrate with other service providers.

Building in this dependency on an outside party inherently poses a risk that you want to assess before making a commitment to go that route. In some cases the risk is easily assessed by reviewing the subjective feedback and experience of others. In other cases the risk is harder to quantify. e.g does the operating system and firmware of smart phone W from telco X enable you to do feature Y using language Z ? A java/brew/symbian domain expert may know the capabilities of the language/platform but it's unlikely that they will be familiar with the latest offering from Nokia or Apple, and the restrictions (if any) placed on the phones by a given carrier.

Regardless of the domain expertise you think you have in-house, it's often prudent to commit to a POC to mitigate the risks introduced. When you think about it, the POC is really the first step in any project that involved dependency on unproven technical components. If it's not, then be aware that the risk you are exposed to is carried much later in the development cycle and therefore becomes more expensive, or impossible, or mitigate late in the cycle.

When asked about assigned tasks as the delivery deadline approaches, I've heard more than one developer reply with the mantra "You can have it done right, or you can have it done right now". What they are telling you is that the quality of the technical work they are doing is going to be greatly diminished if the time window they have to complete it is not sufficient.

If you think about it, the same logic applies to business decisions. Those making the decisions can weight up the risk associated with a bad decision and take a view as to how much thought process needs to go into the decision process. If the risk is minimal, because the work done to effect the decision made is easily reversible and not destructive to the product's or company's established goodwill, then a quick decision is warranted.

If the ramifications of the decision are significant and not easily reversible then more time and effort can be afforded to the decision making process. It may be necessary to expend resources to test the waters with a new feature, or prototype an application, or consult outside specialist help. Whatever it is you need to do to gather more information and reduce the risk you should do it - but don't let the process drag on for ages. Any company or manager can be decisive and make decisions and form opinions quickly but the companies that beat the crowd are, more often than not, the firms that ultimately make the "right" decisions more often. Of course, if you can do that quickly you're already one step ahead. After all, you won't know you've made a bad decision until you've actually made a decision and moved forward with it!