Technical Design

You still need the Proof Of Concept

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.


Time to Deliver

Often there can be a disconnect between what management thinks will happen and what actually does happen in the development cycle due to many common scenarios. These include:

  • management bringing forward the real deadline in order to build in a buffer for overrun;
  • management not understanding the required effort to do certain things (a communication failure between technical and non-technical folks);
  • engineers adopting the ask-for-clarification-when-I-get-to-that-part approach (this is often an unfortunate byproduct of agile development methodologies);
  • a project stakeholder not being available for timely feedback when clarification of some component of the task is required by the engineering team
  • engineers giving time estimates that do not include time for adequate testing, and/or are based on an incorrect appreciation of the scope of the work (another communication failure); and
  • the ubiquitous scope creep.

If not dealt with correctly these factors can add considerable pressure to the engineers in the trenches doing the technical work and greatly inhibit your ability to deliver on time.

To maximize your chance of meeting the deadline:

  • tell the engineers what the real deadline is (if known), and advise them of the desired deadline for "code-complete", with the subsequent time being used for review/testing/patching.
  • ensure that the developer understands the task at hand. The days of writing detailed specifications are long gone, but there's no excuse to not provide a basic verbal briefing followed up by a bullet-point summary email or wiki page so the decision process is documented and the task scope is clear to all
  • prioritize the sub-elements of the task, and have the engineer do them in priority order. If the deadline is hard then you have the option of dropping the non-essential components of the task. If the deadline is flexible you can decide whether it's best to push it back whilst the remaining features are done, or ship without them.

If this all sounds like Project Management 101 then that's good, but there are many cases where the basic survival principles are ignored by technical managers. And ignored at their peril !


The Decision Making Process - pt1

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!