When Delivering Measurable Business Value is not the key to success of a software project


It is a no-brainer that if your software project delivers “measurable business value” it is deemed as successful. But, is the converse true – that is, if no measurable business value is generated the software project is a failure? The projects which I classify as ROI project, it is definitely true. However, there are 4 other classes of projects (7th-Habit, O-Ring, Hype-Cycle & Build-to-Flip) for which this need not be true. The danger of misclassification is to doom a project to be failure even before you have started.

So, let us look at the 5 classes of software projects and what makes each of them successful. I have also added how agile methodologies can aid the success.

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.

7th-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.

Udayan Banerjee on Google+
About these ads
Comments
5 Responses to “When Delivering Measurable Business Value is not the key to success of a software project”
  1. Shoaib Ahmed says:

    ভালো লিখেছেন. মনে হয় প্রথমবার কোনো ব্লগ এ বাংলায় কমেন্ট করলাম :-)

  2. Dan George says:

    The O-ring project characterization struck a chord with me. Software engineering has yet to develop a means to describe software component functionality in a larger system. It seems that we cannot say very much about the components until we’ve made them and then they speak for themselves. Realizing a software component is must less expensive then realize a hardware component but the cost is still significant. Can it be proven fundamentally impossible to substantially improve our ability to describe without having to actually make a functioning component? I’m working on standardizing my use of the UML explicitly for that purpose. It would be good to know if I’m wasting my time.

    BYW, does Agile reject the use of models? If the idea is to code and re-code as fast as possible then probably modeling just postpones coding. If the idea is to limit the amount of complexity per cycle then modeling might be an accelerator. Models help expose complexity.

Trackbacks
Check out what others are saying...
  1. [...] Is agile suitable for all type of projects? There are certain categories of project where it may not be suitable – When Delivering Measurable Business Value is not the key to success of a software project [...]



Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

Join 986 other followers

%d bloggers like this: