Change can come from anywhere within an organization, including the lowest ranks. However, significant change and fast change can not occur without the complete commitment and involvement of management at the highest levels.

Software development processes have changed dramatically over the past 3 years (and are still changing). The cumbersome processes of the '80s and '90s are giving way to lean and agile development methods. This change was not instigated by the IEEE, the SEI, or the DOD. It was demanded by the consumer market.

How much process does a software development organization need? The least necessary to get the job done well. ...and no more!

In an-ad hoc software development organization, where should the introduction of process start?
First introduce Requirements, then Development Plans, then Change Control, then Test Plans. When these have been introduced successfully everything else will follow.

How long does it take a team to develop a software project? Usually, longer than you think. Fred Brooks* stated over 25 years ago that programmers are notorious optimists. This is still true today.

Great software development teams are made up of ordinary people. It is the leader (the software manager) who either makes or breaks a great team. With rare exceptions, all developers want to be members of a successful team.

You are crossing Fifth Avenue in New York City during lunch time. Being a reasonably careful person, you first search out a pedestrian crossing. You then wait until the green "WALK" light comes on, and then, remembering that traffic lights are considered by New York drivers to be no more than a recommendation, you look left then right then left again.

Satisfied that all is clear you safely cross Fifth Avenue to the other side. While you are involved in this exploit, a friend of yours, without hesitating, races across Fifth Avenue and surprisingly makes it safely to the other side. He then proceeds to taunt you for wasting time with all the precautions that you took. You may be tempted for a brief moment to wonder if he is right.

The parallel in software is that occasionally you may rush through a software project without using any orderly development methods, and you may be lucky enough to succeed. However, in most cases, like the person rushing across Fifth Avenue, you will be hit by a bus!

We all know that occasionally people are lucky. But, as a professional engineering manager, you cannot base your project development plan on sheer luck. The business case for developing a software project is based on the fact that there is a reasonable chance for success. If, in throwing care to the wind, you can promise no more than a poor gamble, then it makes little business sense to develop your project. An orderly development process is like an insurance policy; it greatly reduces risk, but for a price. The recent history of software development has demonstrated time and time again that this price is well worth paying.