Quantifying scope creep by code analysis

I gave StatSVN a whirl after Alistair recommended it a while back. It's a nifty tool that analyzes Subversion repositories and returns aggregated statistics and graphs. All very interesting and great stuff for a left-brain dominant stats obsessive like me. However, it was recently very useful in helping me convince a client that their change control requirements were maybe going too far.

The project had been going for well over a year by this point. It was an intranet-based bespoke CRM application for a large multinational consultancy. We had gone through a specification process up-front, and had spent what I thought was a decent amount of time doing so - the package included a functional specification and key page wireframes that amounted to nearly 100 pages. We did four iterations of that package and spent six months doing it - I was hoping that once that was signed off, it would be relatively straightforward to build, test and launch.

However, between specification signoff and delivery of the application for user acceptance testing, a few things changed. The person leading the project on the client's side left the firm, and what was a pretty tight, unilateral decision-making team was replaced by a committee of people, all of whom wanted to put their own stamp on the thing. Over the following year, we went through another 5 batches of change control - suddenly there were lots of people asking for small tweaks, which when added together turned into pretty major rewrites. The problem was that each individual change was in itself quite small, and therefore it was difficult to quantify the overall scope of the changes. Also, as a small company, if you have a client that wants to make changes to things, and they are willing to pay for them, it is very difficult to convince them to draw a line in the sand and get the damn thing launched.

So I had a play with StatSVN and looked at a few figures. The initial version of the application contained about 32,000 lines of code. In the most recent version, there were over 8,000 lines of code that had been added or changed. That's over 25% of the original specified application that had changed. The scores of small incremental changes had changed over a quarter of the application's codebase.

While I think we all knew what was going on, being able to quantify the additional changes, no matter how crudely, really focussed everyone's minds. Presented with these figures in black and white, the client decided that they would stop fiddling with it and launch the thing immediately. They still have a list of "would be nice to have" issues, but we'll see how important they are after six month's of real-world use.

© 2018 Associative Trails Ltd. 4m@