Development methodologies

At Optima we work with all sorts of corporations ranging from the very large to the very small. Small businesses typically have no specific development style requirements only the need to produce the solution on time and to a tight budget. Larger corporations often have huge overheads associated with their chosen methodologies - but they will still have tight budgets and time-lines.

We work with all of our clients in a way that suits them best and we never try to impose a working style - although we may advise alternatives.

Our experience shows that regardless of company size the methodologies adopted fall into one of two categories; Waterfall and Agile

Waterfall

Most large companies that we deal with operate a "Waterfall" style of project management. This means that the whole process is very heavily dependant on documentation, administration and a large number of people who are not directly connected with producing the result. In addition the Business and Developer are kept apart leading to errors in understanding and functionality missing.

Overall costs tend to be high and often the project will overrun on a number of markers. Assuming however that things run to completion the eventual solution is usually well documented and supported but future changes/enhancements tend to be expensive and time consuming to implement.

This waterfall approach is often applied to large, complex projects which require a high degree of mental agility just to understand all of the ramifications. We see a consequential problem of describing such a complex process or set of processes in documentation. Trying to encompass the whole picture up-front and getting it right is doomed to failure and in any event will take much time and budget.

Senior management are often happier with this approach as all aspects of the implementation are closely controlled and costs can at least be monitored to the penny but error levels, functionality mismatches and bugs occur at a similar level to more pragmatic methodologies.

The Waterfall approach is very rigid and often very costly but can be visualised as shown in the diagram.

The project cost line typically rises steadily over a medium to long period of time until implementation when the solution starts to deliver the business benefit.

Assuming that this benefit can be represented in pure monetary terms a net profit will be realised sometime thereafter. This profit may take many months or even years before its effect is truly seen by the business.

Sometimes the arrival of a net profit never occurs before the solution is decommissioned in favour of a new approach or the business adopts new practices as a result of say a reorganisation.

Agile

A methodology we have adopted with great success over recent years is one called Agile which is derived from the extreme programming groups and has been written about at length. This approach has been slow to be adopted by many large corporations as it sits outside of their normal comfort zone.

With Agile programming we break down a large project into a number of small, tangible sub-projects each of which can be easily visualised and comprehended. Each sub-project is worked on in turn with an eventual longer term goal always in mind. These smaller tasks each have a time line to be implemented in and importantly each provide tangible benefit to the business.

Over time these smaller projects are worked on and delivered in such a way as to demonstrate actual progress and profit back to the business.

Since each sub-project is smaller and easier to identify with, the project team can be smaller and more specialised so as to meet the immediate need. The developers will typically work alongside the eventual user group to ensure that what is delivered is actually required.

A typical project cost/profit model is shown below.

Our experience shows that a total solution can be delivered more quickly and that project profitability is realised much faster.

In addition, should/when the business requirements change the Agile approach allows such change to be implemented quickly. In the case of financial administration systems where the requirements are very dynamic we have seen the impact of such changes as being almost insignificant to the overall project cost and delivery timescales.

An added advantage is that due to the involvement of the users in the development from day one, buy-in by them is greatly improved and rework due to misunderstandings during the design phase reduced dramatically.

Documentation can be produced as the system is developed which combined with test harnesses that are developed with the code as it is written reduces the project development time even further.

Our experience shows that one week of agile programming can equate to several months of an equivalent Waterfall build.

In a recent build for one of our major clients we reduced the process time from over one hour to just a few minutes, reduced staff training to use the system from in excess of six months to less than one day and provided the first phase of this system to the business within four weeks of starting. Prior to our involvement no progress had been made due to the quoted expense of providing a similar system on a waterfall methodology.

In this particular case and by utilising APL programming styles carefully we found that after a short period of time the users (none of whom were programmers) were able to view this code and be able to point out where logic mistakes had been made! This ultimately made for an immensely powerful combination of business knowledge and programming experience. This is very hard to achieve in many other environments.

We estimate that the result of using this Agile approach has saved our clients hundreds of thousands of pounds and in one case probably millions of pounds over the time the system has been in production.

Back to top