Managing Software Development Efficiently

One definition of insanity is doing the same thing over and over yet expecting a different result. Our own form of IT insanity is that we continue to use software development approaches that are tired, worn out and destined for failure.

You’ve probably heard of “Chaos ’98,” the Standish Group study that found that 75 percent of software projects fail because they are late, over budget or poor quality, or all of the above. For projects valued at more than $10 million, the failure statistic becomes 100 percent. The West Yarmouth, Mass.-based Standish Group came up with four conditions that it says will improve the likelihood of project success:

• Executive management support and user involvement.
• Clear statement of vision, objectives and requirements.
• Proper planning, realistic expectations and frequent milestones.
• Competent project management and focused staff.

In my experience, CIOs do a pretty good job at getting the right level of executive management support and user involvement. You would love to have more, but most projects have steering committees and a project sponsor fighting the good fight. Fulfillment of the rest of the criteria is spotty. That is why so many CIOs have too many projects going on, many being done the wrong way, many not worth doing at all.

Projects go astray in many ways. Often they are in need of a purpose. One of my clients in my coaching practice walked into a new CIO job and took inventory of the IT projects in progress. The majority lacked well-defined objectives. That’s the response of a team with no clear mandate.

This happens so easily in IT. Your business partners have a great idea, for instance, and want to get moving on it. But you wait too long to respond to their requests because you’re tied up with other work. When the pressure builds, you delegate the project to an already busy director or project manager and hope for the best. That person delegates it in turn to one of her busy analysts, who then works with his business counterparts to read the minds of the senior executives who came up with this brainstorm. To break out of the cycle, my client challenged his direct reports to define the value and objectives of their initiatives. His employees and their senior business partners quickly instigated valuable direction-setting conversations.

Other times the project mandates are clear, but CIOs try to tackle the project by applying a waterfall development approach—a slow, step-by-step process in which no task is begun until the previous one has been completed. You know you’re dealing with a waterfall project when you see a discovery period of three to six months and more than a year elapses before any software is delivered. The Standish Group indicators for projects with a high likelihood of success comprise a six-month duration from start to finish, no more than six people devoted to the project and less than $750,000 funding committed.

Many of my clients get trapped into the waterfall approach by default—they don’t know how to compress development cycle times. Others adopt the waterfall approach against their better judgment because they purchase software packages that are not easily broken into digestible bites, either because of software design or pricing. One of my clients had every intention of splitting her ERP effort into smaller deliverables only to discover that the benefits were two years away because of the software package’s dependencies. (To add salt to the wound, she had to pay for the entire product up front.)

Finally, many IT projects suffer from inadequate resources. I don’t mean money; most of my clients say they have more project money than they can spend well. Their constraint is the lack of qualified project managers. CIOs’ project agendas are bulging. They try to fill internal leadership voids with consultants or contractors—but those must be managed with the very leadership resources that needed supplementing.

In short, many CIOs have set up a cycle of project failure. While everybody agrees that there is a problem in software development, the path out of the mire isn’t as obvious as the Standish Group researchers believe. Software project insanity is deeply embedded in our companies and IT groups—our cultures, belief systems and skill sets. CIOs need practical action plans and assistance to transform development approaches. Let me share a few gems that my clients and I have discovered over the years.

Develop conviction. The cycle of software failure is not just one issue out of many on which a CIO must focus; it is the issue. It blocks you from delivering value to your organization and extracts huge costs. Convince yourself by examining your track record with software projects. If you’re like most CIOs, you’ll see the problem. But until you develop an “I’m mad as hell and I’m not going to take it anymore” mentality, you are not ready to move forward.

Share the crisis with other senior executives. It’s not just your crisis; it’s the organization’s problem, and it needs the attention and cooperation of everyone. What’s shocking is that most of you have not shared this issue with your business partners. There is no upside to letting them think the delivery problems are unique to your organization. Unless you engage your colleagues’ energy, you will be unable to mobilize support for the necessary changes in policy, process, skills and resources.

Redefine your job. Your business is not simply IT; it is innovation. You help your company develop hypotheses about where IT can make a difference. You and your business partners then conduct a series of experiments to reduce risks and discover the future. Most of these will fail to some extent, but that’s OK—an imperfect product will evolve and generate value as it is refined.

Set new rules. New governance guidelines for IT are needed. Just as investment managers view a financial portfolio as a whole, an IT investment board should manage its project portfolio against predefined targets for capital allocation, return and risk. The value of IT investments should be estimated by commitments from business executives to deliver value. Project funding should come in stages—say, $750,000 at a time—and future funding should be predicated on proving benefits and mitigating risks. Project stages should be sliced into six-month increments. Your staff should monitor projects from concept to the realization of value.

Know your leadership limits. Count the number of competent project managers in your organization, in and out of IS, and approve projects up to but not beyond that capacity. Require that your direct reports oversee all major projects. Work for adequate staffing so that senior people are available to help business executives think through their hypotheses and approaches.

Lean on your legacy systems. Stop trashing your legacy systems, infrastructure and processes. They’re your most valuable nonhuman assets and will take you further than you think. Dell Computer leveraged its legacy systems on the way to 40 percent per annum growth during the ’90s. We all want the latest and greatest for critical projects. But the implementation cost and time spent learning the new systems can be huge.

Tap into project techniques. There are proven methodologies out there that can help you improve project predictability and quality and, if applied correctly, reduce the cycle time of development. Those approaches are geared for today’s business conditions and technology. One great source of information is the Carnegie Mellon Software Engineering Institute website, www.sei.cmu.edu.

The Vanguard Group, which spends 40 percent of its operating budget on IT, has said that its most important lesson on how to improve the success rate of IT projects is to take time at the start to think things through. Follow that example, and put your findings in front of your leadership team so that you can start to reverse the cycle of software project failure.