Forget Change Management - it undermines your chances of success. All changes should be free!

When you commit yourself to delivering a certain set of requirements ("requirement specification", "statement of work" or whatever you call it) by a certain deadline you automatically create a need of ways to manage change – because change brings risk and disorder, and it risks ruining your time-plans that you have spent so much time figuring out. It risks ruining the architecture that your designers & architects spent so much time thinking through, and it risks turning those already completed programming & testing efforts into waste because a feature is made obsolete.

What's even worse, if you're the project manager then you're likely to be the lucky person stuck with the bill and you have to work out who's going to pay: your company or the customer?
It can be a nerve-wrecking job to be the one that have to make that call to the customer and explain that "this recent request will end up costing 5.000 EUR more and it will delay the project with 3 weeks". And if your requirement specification is the least bit vague or ambiguous at this point, you might end up in an irritated argument or negotiation with the customer about him considering the feature part of the “original scope”, whereas you consider it a Change Request. Not really an optimal situation. But under such circumstances of course you will require a clear way of managing these ugly changes.

So what can you do to minimize these risky aspects of software project management? The traditional way to go is to become even more thorough the next time during Requirements Analysis. I.e. you put even more focus on planning and on trying to figure out even more of the details up front. You have longer pre-studies. You do bigger and more detailed design up front. This way you'll be able to give yourself a better picture of the project before you sign off the requirements and set any deadline. In essence, you build your walls higher and thicker around you. You strengthen the foundation for your Change Management Process and thereby make your project less likely to be exposed to Change and the risks they bring.

With the above reasoning change is something ugly that you want to avoid. But wait. Is change really a bad thing?

I argue that change is great. Change is fantastic.

Screw Change Management processes and the administration they bring! Yes, I said it. In fact, I think we need to give the customer all changes for free, always!

Change means the customer has gotten a different or stronger opinion than he had before, and if I don't adapt to it then the customer will be less happy than otherwise. And what is our number 1 objective? …No, silly, not to make money. Our number 1 objective is to make the customer happy - because happy customers are returning customers. And as a consequence we will make money.

The problem here is much larger than the Change Management process alone. The problem is in the entire traditional approach to software project management and software development.

With a traditional methodology you will definately need Change Management - no doubt about it. There are many great project managers and companies out there, I'm sure, who are working with traditional methods and who are excellent at Change Management.

But I think remarkably many of those never thought twice about the software development methodology they adopted. They just chose one that everyone else was using (for that reason: because everyone else was using it) instead of adopting a software development methodology that maximizes their chances of success. At the end of the day, if you're not NASA and you're not working against the FDA with tons of beurocracy and laws to adhere to, then you're much better off using an Agile development methodology.

You have to accept that you can’t foretell the future. It would be very nice if you could, but you can’t. Sorry. And consequently; change is inevitable – you can’t wish it away. You also have to realize that the customer doesn’t know what he wants – he discovers that as he goes along. Consequently; change is inevitable. Furthermore, you have to realize that developers don’t know how to build the software up front – they discover that as they go along Yes, consequently; change is inevitable.

You can sit there and sob and dislike it all you want, but it doesn’t change the facts.

This is important, and a huge difference to traditional assumptions, so I’ll recap:

1. Unforeseeable sh*t happens that will affect your plans.
2. The customer doesn’t know what he wants – he discovers that as he goes along.
3. The developers don’t know how to build it – they discover that as they go along.

Most people will agree that the above is true. So, why do we rely on dusty old project management methodologies that assume the exact opposite??

The first thing you need to do is to stop committing to both scope and deadline up front. Commit to date rather than scope. This is sometimes called “date-driven development”. You achieve it by putting the requested features in one single list that is prioritized by the customer. Allow changes to priorities, as much and as often as the customer likes. But make sure the priorities are always kept unique for each item in the list and that the priorities are strictly followed, i.e. work is carried out in strict order of priority. As a consequence of adopting this approach there will be no such thing as an “original scope” – because that would imply that there was a “before” and an “after” some event (e.g. a “change”). “Feature creeping” is no longer a bad thing. As long as the customer sticks to the one single prioritized list of features he can have as many features “creep” in as he wants; he can replace all the items with others from one day to another. As long as the customer is happier in the end. With this approach there is no such thing as a “scope change” anymore: the scope instead is something that evolves over time by continuous readjustment .

Secondly, you need to stop making detailed plans. Plan for God’s sake, don’t misunderstand me, but just don’t overdo it. Forget about figuring out what exactly will be done, by who, when, before or after what, two-three months or more away from now. Try to ask yourself; are you creating the time-plan the way you WISH things will happen or as you KNOW they will happen? I’m guessing most of the time the answer will be that it’s the former. The effort spent on creating silly wishful-thinking time-plans is much better spent on something more constructive in terms of bringing the team closer to the end goal (a happy customer) – like getting coffee for the developers. Note that I am not telling you NOT to plan. I am just telling you that all plans are wrong and rarely survive more than one minute in contact with reality. So just minimize the amount of time you spend making them.

Thirdly, start involving the customer. Do it early on. And make sure you have as short feedback loops as you can. With a traditional approach, presenting the product to the customer is often scary because you fear there will be changes, and those changes can be ugly. But you have to remember that those changes are a necessity for the customer to become maximally happy. The problem is not the feedback, the problem is when you have a long lead-time between points of customer involvement (and consequently risk having put in a lot of effort into something that is wrong or will change). So, remember to keep feedback loops (very) short, from the very start of the project to the very end. I suggest 1-3 week loops. Notice that this puts a different demand on the amount of customer involvement than with a traditional approach: the customer needs to be involved (much) more, and earlier. If your customer is not comfortable with that then you’re better off with a traditional approach – but you will less likely to succeed, and the project will be much more expensive because you will have to put risk margins in your pricing.

Fourthly, derive a release plan from reality rather than dream one up ahead of time. Don’t lie to yourself or (worse) the customer by claiming you know exactly what you will be able to deliver by when. You don’t know this! And anyone who claims to is a liar. Instead, commit only to time. Then continuously observe your actual progress rate and use those observations to calculate what parts of the scope it is likely that you’ll be able to finish before the deadline date. You work in priority order and have short feedback loops involving the customer that spark “change” often and early. When you reach the deadline date you have the most important things done.

Fifthly, test early and continuously, and always finish things (completely). Don’t leave some parts of testing for later. Don’t postpone code reviewing. Don’t wait with code merges. The sooner you do things the easier and cheaper they are. Started, half-finished work has no value. For every new feature you start without finishing completely, you add to a pile of more or less known remaining tasks. Over time this pile grows to a mountain of unknown stuff that will get you in the end. Avoid this by really completing things early and do all types of testing early. Continuous integration is key here, and automated testing is a helpful tool.

Since change and unpredictability is inevitable, we have to find a way of working where change is not made ugly by processes. Where there is as little waste of effort as possible when change happens. This is what Agile Development is about – a software development philosophy which covers process frameworks such as Scrum, XP, FDD, DSDM and others. But remember: tThis isn’t the silver bullet that automatically solves all your problems, but it brings maximally good odds of succeeding. Software development and project management is still hard, but at least you’re not making it harder than necessary.

If you’re interested in reading more about Agile and Scrum here are some links:
My blog: http://scrumftw.blogspot.com/
Agile Manifesto: http://www.agilemanifesto.org/
Wikipedia about Agile: http://en.wikipedia.org/wiki/Agile_development