Monday, November 1, 2010

The curse of the fast(er) delivery

During the recent years different agile concepts have been introduced into many organizations, in order to minimize the time from a projects inception to the first delivery.

There is nothing wrong with that, as we all wish to deliver working software to our customers as fast as possible, and this blog post should not be seen as an attack on any of these methodologies. It is however an attack on some project managers, and others, rather loose interpretation of some of the concepts of multiple release projects.

In the organization where I work there is a goal of a nine month period from project inception to the first release.

Here we come to one of the points where the concepts release and business delivery are put into play, and these are used to tweak the a view on the project, to satisfy managers and perhaps the business leaders, because we will deliver "something" within that nine month deadline.

Let's just clarify the concepts, at least how I interpret them.

- Business Deliverable - a logical entity in the project containing related functionality, which could stand alone, should it be release to the customers. How much benefit it will give is a whole other discussion which I will not go into here, perhaps in another post...
 - Release - the implementation of one or more Business Deliverables into the "real world"

Now, what I suspect the management meant when they set up the nine month deadline, what they meant was that they would like to have a release within nine months. However, the fact of the matter is, as projects go along and they get more complex than anyone had imagined, we start to talk about doing a Business Deliverable within the nine month deadline. - and hey presto, we have now bought ourselves more time, because we have something to deliver within nine months but it might not make sense business wise, so we will save it for a later Release.

Thus we still have the same 12 - 16 month delivery period for something that actually gives value to our customers, but we have satisfied the management because we have lived up to the nine month deadline as well.

My point here is, that if we take a look at the situation from the customers or business representatives side, we have done absolutely nothing to improve the delivery time of actual working software.

As a Business Analyst I would like to cut through the concepts of business delivery and releases, the arbitrary deadlines put up by managers, and instead focus on the business needs.
If what the business wants takes 12 months to deliver, and it does not make sense to split it into release, so be it! But lets not kid ourselves that we have delivered faster because we had a business delivery done after 6 months, the business gained no value from it.

Don't get me wrong. Business Deliverables is a great project management tool, to ensure that you focus on the right part of the solution and can prioritize, but do not think that a business deliverable without a release is something that gives value to the business. Even if it is the business that have decided to wait until several business deliverables can be joined in one release.

To me what matters when setting goals for projects delivery times must be business value - When can we create value for the business! The rest is just manipulation...