Maximizing Software Process ROI: How to make your excel chart go green

DJ de Villiers

DJ de Villiers

Let's face it--the reason there is a market for software process is because software developers are stoopid (that's more encapsulated than stupid). Too often, we hear of projects that have been playing tiddlywinks for several months or that are being restarted for the third time or finished without archiving the source code. Methodology experts will tell you that having a process will solve these problems because all the developers automatically know what to do next. It's a fool-proof path to success: buy a process (and all the related tools), squeeze 10 days of training into a 2-hour presentation and perfect code will suddenly start to appear, the customer will offer the team a bonus and everybody in the project will find their love life improving. The major obstacle is that the selection of available processes represents Benjamin Buford Blue's shrimp recipes.

The shrewd and discerning IT manager will by now have realized that this article is aimed at him (have you ever met a lady IT manager?) This article answers the most burning questions in the minds of our readers: "which process to choose?", "how to maximize ROI?" and "why did Fred get the corner office?"

Answer 1

To answer the first question, one has to consider the industry's record of success and failure with different processes. Applying the Scott Adams scientific research approach to a representative sampling of real-world projects produces the following results.

Entering this raw data into Excel and creating a pivot chart reveals the secret answer to the first question: there is no statistical relationship between process and success. In layman's terms, no matter which process you choose, your project still may or may not fail. We can only conclude that the real problem lies in the way the process is applied. Considering that it is people who apply the process, the problem must be (as usual) human error. Process vendors have convincing evidence that software developers do not need their brains once they have a process, e.g. filling in templates automatically increases project success rates. This insight leads us into answering the second question.

Answer 2

To reiterate the conclusions made above,

Using basic mathematical deduction covered in most high schools, we brilliantly deduce that software developers SHOULD NOT use their brains once they have a process. This fact can be used to the advantage of the thrifty. To maximize ROI, we want to minimize the cost of adopting a process. Here are several strategies that have been proven in practice:

  1. Minimize cost of the process by purchasing several books covering the topic. To avoid the additional expense of reading, simply put them on display near the work area so people can absorb them as they walk by to the coffee.
  2. Minimize cost of training by sending one team member to a half-day marketing seminar and having him/her scatter the unlabelled demo CD's on other people's desks.
    3. Minimize cost of tools by not using tools. You may have heard the phrase "a fool with a tool is still a fool" from a training vendor, but keep in mind that tools developers are more productive using tools from 1972, and they get better job satisfaction out of manual debugging. Offset the trivial remaining costs by selling off the now not-needed brains of team members to medical research labs. You'd need to strike a balance between the volume and pricing of programmer brains vs. project manager brains.

Conclusion

This article has presented irrefutable evidence that people are the root cause of software project failure. The wise IT manager will acknowledge this fact and place a higher emphasis on good process than on good people. A trend to watch out for is "process enactment". Several leading tool vendors are looking into executing process automatically, which means in the future we may not need people involved in software development at all!

Because our answer to question 1 was enlightening although not entirely useful, we decided to conclude by briefly explaining why we prefer the waterfall process above any other.

Easy to manage. Some famous guy once said "the planning is nothing; the plan is everything". A detailed Gantt chart with intricate intertask dependencies and a critical path is the most important deliverable early in the project. Once the plan has been emailed to the team, they own it and will work seamlessly together to follow the plan. When the percentage complete has been updated for every task, executives obtain uncanny insight into what is really going on in the cubicles.

Highly predictable. Important project stakeholders such as the customer and the budget holder get the information they need right at the beginning of the project. Customers get to approve a list of requirements and the budget holder gets detailed estimates. Those pieces of paper are as certain as the promise of gold on banknotes. These stakeholders have the security they need, no matter what happens, which causes considerably less stress. Furthermore, forcing people to write things down is a remarkably effective way of ensuring they are following the plan and predicting their future performance.

Natural way of working. Psychologists will tell you that any creative human activity consists of figuring out what to do, deciding how to do it, doing it and then reflecting on whether it was done well. It makes perfect sense to follow the same thought process for any creative activity, especially when it involves hundreds of people in different countries speaking different languages. Grady Booch said "software development is a team sport" so individuals should not get ahead of themselves and start thinking about how to do things before the entire team has agreed on what need to be done.

Better change control. Because the development team is not allowed to be distracted after receiving the requirements, they can focus on what they are good at and work undisturbed by pesky users. Any project manager will tell you that if you allow any form of communication between developers and users, you lose control of the project. Successful projects consistently deliver the specified requirements on time, regardless of whether the system solves the original problem.

Heightened excitement. Roller coasters, bungee jumping, and cocaine exist because we all enoy a rush. When scores of developers have been churning out chunkcs of code for months on end, nothing can beat the thrill of putting it all together to see if it works just hours before shipping it to the customer. The team revels in the tingling excitement because they know if it doesn't work heads will roll, and the idea of pulling it off at the last minute no matter what the odds is an irresistible urge. Maybe one day Hollywood will produce a move about a software project team that pulled it off despite everything.