Can you think of an instance where a software project had to completed on schedule and the measure of ROI was of secondary importance? When a piece of software is part of a larger initiative the ROI becomes less important and the fallout of any delay may far outweigh the investment on the software.

Latest trend in agile and lean methodologies is to weigh every feature in the scale of “measurable business value” before acting on it. This approach, for some type of projects, may be redundant or even counter productive. In my opinion, software projects can be classified into 5 types - ROI, 7th-Habit, O-Ring, Hype-Cycle & Build-to-Flip.

Let's look at the characteristic of each type of projects and what makes each of them successful. I have also added how agile methodologies can aid the success. The danger of misclassification is to doom a project to be failure even before you have started.

ROI Projects

There is a class of software projects where delivering business value is the key. The measure of value need to be quantifiable and can typically be:

• Cost saving
• Revenue generation
• Customer satisfaction
• Cycle-time reduction

If I spend “X” dollars I will get “Y” benefit = measurable value delivered to business.

Approval Process: Follow a variant of the following 4-step process:

1. Identify and quantify business benefit
2. Translate into software requirement
3. Estimate – time and money required
4. Obtain approval based on cost benefit analysis – the analysis may be absolute or relative to other projects

Pitfall: To get the project approved, the benefit may be (consciously or unconsciously) overstated. Alternately cost may be understated or impact of critical technical challenges not fully understood.

How agile can help:

Fail early – This is where use of agile methodology can be of great help. Used properly, it can identify, early in the project lifecycle, if the projected cost-benefit analysis is realistic. If it is not then the project can be allowed to fail early thereby saving considerable expense and heartache.

Incremental value – If the project is such that it will be feasible to make phased releases either to a small community of users or with subset of business critical features, then adopting agile methodology will allow value to be realized even before the completion of the project.

7^th-Habit Projects

The seventh habit (see 7 Habits of Highly Effective People by Stephen R. Covey) is “Sharpening the Saw” or about renewal.

These are already running applications and have to be re-written for one of the following reasons:

• Technology obsolescence – either hardware or software
• Problem of maintainability – lack of people or unwieldy code base
• Integration challenge

The applications would have been in use for a long period of time. Though the UI may be archaic, most users will be reluctant to switch to anything different. For such project, value will be intangible and it will be difficult to quantify. The renewed version of the product will normally will need to replicate the functionality of the existing application with some enhancements thrown in.

In the airline industry, majority of the ticketing runs on IBM mainframe and the application is developed using TPF which is a second generation language. IBM has declared that support for TPF is going to be withdrawn and it is to be replaced by z/TPF.

Approval Process: Ask the following questions:

1. Can we afford to do it?
2. Can we afford NOT to do it?
3. Is there any alternate way of satisfying the business need?
4. Is this application still relevant?

Pitfall: The project will be deemed successful only if users find the version at least as reliable and useful as the old system. The biggest risk is to miss out on the key feature, functionality or usability issue. This may happen when key users are unwilling to spend enough time or knowledge of specific feature is lost and is only available as code.

How agile can help: One of the challenges in using agile methodology for such project is the reluctance of users to contribute time and effort. If no major enhancements are planned then the developers are expected to study the existing system and derive the requirement. However, if the user interface is being revamped, then iterative refinement with constant user feedback can make or break the project.

O-Ring Projects

On January 28, 1986, when Space Shuttle Challenger broke apart 73 seconds into its flight, leading to the deaths of its seven crew members. Disintegration of the entire vehicle began after an O-ring seal in its right solid rocket booster (SRB) failed at liftoff. It had lost its elasticity because of the unusually cold outside temperature.

Sometimes, software becomes an O-Ring in a large infrastructure project or new product release. In such cases, quality and on-time-completion becomes so much more important than any other parameter. 100% budget overrun may be an acceptable tradeoff to either prevent a bug or to avoid short delay.

When you are planning to open a new terminal building in an airport like Heathrow Terminal 5, software will be a small (cost wise) but important component in it. However, it will be at least as critical as any other component or equipment. The complete software has to be ready in time and has to function flawlessly. Even few days delay may lead to revenue loss in excess of the cost of the software. Also, any quality problem can damage the image of the organization.

Approval Process: Since such project will be a component of a larger project, there will be no separate approval process. However, following questions need to be asked:

1. What to make – what to buy?
2. How much to automate?
3. Is the scope too ambitious?
4. How much premium can be paid to reduce risk?

Pitfall: The biggest pitfall is to underestimate the complexity and technical challenge especially integration challenge. Many of these will surface only towards the end of the project when the deadline pressure will be at its peak.

How agile can help: Since, such project require a big bang release, what value agile can bring is not immediately obvious. However, for such project early mitigation of technical risk may be critical. Tackling them in an agile manner early in the project lifecycle can greatly increase the chances of success.

Hype-Cycle Projects

Hype-cycle is a term promoted by Gartner to provide pointers to how new technology adoption happens. Every technology goes through a “Peak of Inflated Expectations” where everybody jumps into the bandwagon. People want to cash in on the early mover advantage and time becomes of essence.

For such software projects, “being there” as quickly as possible is major driver. Though, cost and quality cannot be ignored, but they take a back seat.

With the release of iPhone from Apple, it became important for organization to release an iPhone application to the market. Scenario one is when you want to be the first and be perceived as the leader. Scenario two is when your competitor has already released such an application and you need to follow suit lest you be perceived as a laggard organization. It is the same story with Facebook applications.

The story of Cloud Computing or SOA is little different – there you are afraid that you may be missing out on something important. Therefore you want to try it out. In all these instances it is difficult to quantify measurable business value which is realistic. It is important to be there as quickly as possible.

Approval Process: Ideally such projects need to be driven by an evangelist. It will be a discretionary spending and money may either come from technology budget or marketing budget. The decision making is unlikely to be logical and based on figures – it will be a right-brain decision.

Pitfall: Normally, chances of failure for such projects will always be high. However, not responding to changing scenario fast enough can lower the chance of success to almost zero.

How agile can help: Since the area is new, the requirement needs to emerge and change during the course of the project. For such projects, it is difficult to envisage any methodology other than Agile.

Build-to-Flip Projects

The term build-to-flip was coined by Jim Collins, the co-author of Build to Last. If you have an innovative idea, you start a company, create a prototype, get VC funding and build your idea to a level where you have sufficient user base to sell the whole venture. Significant percentages of such ventures are purely software projects. Alternately, software would be a major component in the development effort.

Build-to-flip projects have some similarity with hype-cycle project but have its own unique characteristics. The innovator will start with an idea but in most cases it will not be fully formed. Whole plan needs to be flexible and the product needs to morph based on the feedback, likes and dislikes of the early adopters. The innovator needs to be sensitive to unintended usage of the idea. In addition, the early adopters will also become the beta testers. Quality may not be the most critical factor. Twitter, for example, used to crash quiet frequently in the initial days. That did not prevent it from being one of the biggest successes of recent times. Rolling the right features out as soon as possible may be the key to success.

Approval Process: You need an idea which can grow big. You need to sell the concept to a funding agency, probably a VC. If you succeed then you are on.

Pitfall: Not everybody is Steve Jobs – you may not be able to create an iPod or an iPhone in the first attempt. You will need to iterate and listen to early adopters. Not doing so quickly enough is a sure road to failure.

How agile can help: Not only will agile development is mandatory, agile deployment is also critical. Option of continuous deployment is also worth examining – here is a nice example.

Read the original blog entry...