Many techniques of developing and implementing Internet technologies came from the traditional world of software development. This includes version control, application development methodologies, project documentation and project management just to name a few.
However, in the compressed life-cycle of Internet and Web development many time-tested, proven and accept techniques were modified for convenience and in some cases completely dismantled as they were seen as road blocks to rapid development. One of the most critical items that was dismantled and rebuilt in a newer sleeker way was the change control management aspect of project management.
In the traditional world of software development, once the project business case was completed, a technical analyst would prepare the technical development specifications. These would then be signed-off by the appropriate members of management and development would begin. As the project moved on, new ideas and concepts would of course be put forward as project changes. These “change requests” would be documented, and a proper cost justification made.
The cost justification would not only include the additional time to program the changes, but would account for the time delay in the project to implement these features and where appropriate, the cost of tossing out potentially obsolete code. Once these costs were captured, they would be compared to value proposition of the change (the ROI) and included in the “change control document”. This document would require reviewing and sign-off by all those who initially signed-off on the project plan. If the change was truly beneficial and delivering true value now (as opposed to in the next release), it would be approved and the project plan adjusted accordingly. This entire process can normally be managed in two to four weeks.
Now along comes the Internet and the Web. Developers stop looking at development cycles of 12 to18 months and started facing a short development cycle of three to six months. Management can no longer afford to take the time (two to four weeks) to prepare and review “change control documents”. Instead, many companies opted for a more relaxed approached. They empowered an individual (usually the product manager) to make these decisions on their own. In essence creating a product dictator.
The result of this decision is what I like to refer to as “Seat of Your Pants Project Management”. To justify their existence, dictators frequently want to implement new or modify product specification purely on a gut feel basis. Of course, since they are accountable to those that granted them power to get the project done on time, and without the proper paper work (change control documentation), delays in the project deliverables can not be justified, as a result all dictated changes and modifications must be done without adjusting the project plan.
The reality is that it is impossible to make even the smallest changes to a project without impacting the project itself. And as one more change after another is implemented the project’s milestone dates come and go and before long, the project is significantly behind schedule.
Management then starts trying to figure out whom to blame for the delays and the finger pointing starts. The dictator blames the development team with statements “I only gave them a few minor changes” and development team responds with “those little changes forced us to toss out X amount of code and set us back 4 weeks.”
So who is to blame for this mess? Once again, without the paperwork to backup what was done, the blame ultimately falls on the development team. After all, they were the ones who agreed to make the changes and who missed the deadlines.
What is a development team to do? There is no quick fix other then get back to the basics of managing the project. Document all change requests, put best guess estimated time to implements and any other impacts including project delays. Have the dictator sign-off on each change. With the process formalized in this manner, you can still avoid the delays of the traditional change control management process, but at the same time protect yourselves from undeserved blame and put accountability back into the development cycle.
Finally remember to remind all those dictators who just want one more little change done before final release, that “Great works of art are never finished, only abandoned.” – Leonardo DaVinci.
K’necht is a Toronto-based consultant specializing in the business side of the Internet and a frequent speaker at technology conferences. He can be reached at alan@knechtology.com
