When I think about software projects, my memory goes back to the large ones I worked on when I was a developer. These projects lasted for many months and usually had teams that were divided into sub-teams that worked on specific areas of functionality. They typically created major systems for the customer. But was that the normal life of a software developer? Not really. Years were spent on production support handling change requests, while the many small projects we completed are now only vague memories.
Recently, for some research I am doing on function points, I worked with a database of over 2000 recently completed software projects. As a byproduct of that research, I was able to come up with a portrait of the “average normal” Business IT project that I would like to share.
- The normal project is not new development. In fact, only 16% of recently completed IT projects in the database were new development.
- 75% were either major or minor enhancements.
- Median project duration from the beginning of analysis until implementation was 7 months.
- Median effort was 22 person months (or 3520 hours at 160 hours per person month)
- Average staff (team size) just over 3 FTE people.
- Average size – 160 unadjusted function points.
While there is nothing earth shattering in these numbers, I saw a disconnect between the typical, relatively small project and massive lifecycle methodologies and process sets, such as CMMI, that are designed for BIG projects. These processes and methods usually make some effort to be scalable; but the time and effort required to understand and scale them appropriately is a significant endeavor all by itself!
Perhaps what makes Agile so attractive to developers is that it focuses on the issues they have to deal with. A team of 3 or 4 people is not concerned with producing an official requirements document and may function very well with informal processes for change control and configuration management. But they are concerned with getting feedback from their customer and producing workable software and find vexing activities that seem peripheral to their work.
As anyone who has worked on a big project that lacked effective structure can attest, large project methodologies and process sets will always be needed. (Terms such as failure, cancelled, and death-march come to mind when structural rigor is absent). The answers to questions like “what is normal?” and “what processes/methods are right for us?” will differ depending on the goals and type of work performed. If the bulk of your business IT work is done on small projects, it makes sense to match process improvement strategies to the work you are performing and the priorities of your project team. One size does not fit all!