CUT COSTS, NOT PROJECTS (Part 2 of 2)

March 2009

In our last Critical Knowledge, we challenged the tendency of IT departments to respond to budget reductions by reducing the number of projects and amount of software functionality returned to the business. Instead, IT needs to take a more business-like approach. This means examining the processes that go into building software and making those processes as efficient and effective as possible so that the cost of all projects is reduced. In business, managing the cost of processes is a critical tool for improving ROI. Is there a quick, “good-enough” way to understand which software development processes (requirements, design, coding, testing, etc.) are costing too much? The answer is yes, and we will outline it here.

Start by recognizing that software development, as currently practiced, is a highly wasteful and inefficient effort. Consider the following facts:

• The average programmer spends only 47 days a year coding new functionality
• 80% of defects are due to errors in the specification of the requirements
• 50% or more of most project resources are expended on rework

IT does not typically measure and manage process costs. Instead, we manage project costs, which are not the same thing. However, a first-cut assessment of process cost drivers can be accomplished by taking resource expenditure data from project management and doing some analysis on it. It is a four-step analysis:

1. Determine which processes (analysis, design, coding, testing, other) each resource falls under or participates in.

2. Track the participation of each resource across the phases of the project.

3. Compare the expected and actual participation of each resource (or skill) in each project phase.

4. Unexpected or extended participation in a project phase is a clear indicator of extended or repeated processes. These are cost drivers to be attacked.

We can express this analysis graphically. A typical project has multiple phases with certain work to be performed in each phase. Resources are engaged, and they utilize whatever standard (or ad hoc) processes are needed to accomplish the work.

However, if we look at the actual expenditure of resources as the project progresses, we see the following distribution:

As this diagram clearly shows, when specific skills and resources reappear in project phases where they were not expected, then the processes those skills represent need examination to understand why so that corrective action can be taken.

It is essential that IT understands the cost drivers for software development in order to reduce those costs.  We do not help ourselves or our business customers when our knee-jerk response to budget reductions is to reduce software deliveries.  This type of analysis is a good starting point and is available from existing data in most IT organizations.

Note:  A more extensive treatment of this topic is available in a series of Webinars that can be found at critical-logic.com.

Got feedback?
We’d love to hear from you. Send us a note if you would like further information on a specific topic or if you have any questions.

Past Issues
IRNID

Why IT Budgets are Like Government Entitlements

Stop Scratching at the Surface of Software Quality

The Elephant in the Room

Guess the Project Cost

Is "IT" really this difficult?

Manage the project, not MS Project

The Mythical 4-Month Project

AGILE, INCREMENTAL, WATERFALL: Is there a quality difference?

Automating Test Execution: What You Need to Know.

Check out our videos
Webinar: Why are IT projects so hard (and what can I do about it)?

TMX Product Family Video

TMX 3-Minute Overview