Software development – not by PERT alone

I have great respect for software developers. Because software is abstract, invisible and runs at extreme speeds, the people who are good at building it have to possess a particular talent at visualization and a willingness to use complex tools.

When software developers become project managers (PMs), they tend to rely on software tools to monitor, control and report on projects, just as non-technical PMs do. The problems that technologists have in management have to do with inexperience in people interaction, including conflict, collaboration and just plain old ability to listen well. If you’re a technologist in management, you can find more ideas on what to do about this in my book Get Out of the Way.

For the rest of PMs, there are lots of good tools,such as PERT and Gantt charts, but simply having good tools will not make your project succeed. Software development projects frequently fail to produce results that the customer or end-user wants. Why?

Here are three factors that contribute to the unruliness of software development projects:

1. Estimating the effort and time required to complete a task is difficult. Even when reasonable-looking requirements and specifications of a software package are provided, understanding the difficulty of development may require architecting multiple layers and investigating interactions with a complex environment. Since requirements are generally high-level items, and design has to be done at multiple levels, it is difficult to break down the work into “pebble-sized” tasks and then to keep to a schedule with those tasks.

2. Designing an algorithm often takes experimentation. Engineering a software system requires trying out some things to see if they work, or testing multiple possible ways to implement something to find one with reasonable performance, for example. This aspect of software engineering is so prevalent that Fred Brooks in The Mythical Man-Month advised us to “plan to throw one away.” He meant that at the completion of a complex software implementation (such as an operating system), the designers have learned so much that it is often best to start over and re-implement everything.

3. Assuring that a software implementation functions properly under all conditions may take as long as the design phase. In fact, you may never be able to prove proper functioning, because testing all combinations of conditions is impossible. At best, using test-automation tools and good intuition about where to look for errors, a software team can reduce the number of bugs at the time of a software release, but almost never to zero.

Scheduling a software project is made more difficult by the fact that additional tasks are always discovered during implementation. This is so prevalent that I learned long ago always to ask “What remains to be done?” in addition to “What have you completed?” You can count on the list of tasks to be done growing during the project.

One of the best countermeasures to all of these problems is to use Agile development methods. Iterative development with regular demonstrations of working software having incrementally greater functionality will help reduce uncertainty and increase the ability of a development team to adapt to a changing world. It also shortens the time between the initial charter of the project and the point where the customer says, “but that’s not what I wanted.”

Even Agile will not save all projects. If you’d like to learn more about why not, join me for a free webinar, Why Agile Won’t Fix All Your Problems, or simply download the slides here
.
And good luck. The world needs software, so we all have to keep on trying to deliver it the best we can.