As I look at our projects, we have about 15 months between now and final implementation. We also have all our requirements completed, defined and ready for programming. All this is great, but I’ve been thinking a lot about our ability to make changes (mostly scope) over the remaining time.
In looking at this, the first question is: What is our capacity for change? I think this has to be determined based on resources, schedules, lead times, budgets and the like. We may actually have the capacity to make a 180 degree change, or a series of changes that add up to that. In any case, I think each project must have some “change limit” – this being the amount of change that can be absorbed within the time and budget available.
The first existing method that comes to mind for managing change is the management reserve budget. The intention of this is primarily to deal with risks, but something similar might be arranged for change. Maybe a change reserve budget. This would then define the capacity for change up front and allow us to track against that capacity. I think that we could then add something called a “change rate” to allow us to better allocate that capacity across the project.
The rate of change would naturally (I think) have to decrease over the course of the project. So that while we might have the capacity to make say $100,000 worth of changes, we could not reasonably make all of those changes at once, nor would it be possible to make them all at the last minute.
I think that the rate would have to continually decrease across the duration of the project, and at some point (depending on methodology, flexibility, resources, etc) the project would not be able to sustain any changes - we used to call this “the freeze.” I think then that our change model would look something like that below:
I have not figured out how to determine a good rate, but the idea here is that we pace ourselves with our changes, and that if we try to make too many at any one point, we end up overloading the project- impacting dates, etc.
I know that the traditional model of change control is that we always assess the impact and elevate that to the “powers that be” for a decision on whether we can do the change or not. But experience has shown that we often end up making certain changes and not changing any dates. How many times have you heard “it’s only a week, can’t you absorb that in your 10 month project?” Well yeah, I did absorb the first 12 one-week changes, but this is lucky 13. Now with a “rate” or speed limit, you can schedule the changes, or push back if there is too much at any given time. One way might be to say that we can only accept X amount of changes for the next cycle / month / period.
I think that the concern I am looking to address is the tendency to use up our entire change budget at the beginning of a project and get ½ way through with nothing left. If we use the rate as a limit, then we can actually have the ability to make changes later in the project when they’re needed.
Another idea I hear was about prioritizing changes, I worry about this for the simple reasons that if you only have one change, then it is top priority. Then after you put that in the next change that comes up will be top priority. The priority system is useful when you have all the information in front of you, but with change, you don’t know what is over the horizon. If you did, you would have planned for it and it wouldn’t be a change and you wouldn’t need to prioritize it.
So I think the answer is to pace yourself. Whether you are running a marathon or a sprint, if you use up all your energy too early, you’re in for a hard time. If we use the change rate, then we know we will have the ability to handle at least some part of what is coming.
Of course, I have no idea how to determine a change rate, and as I think more, I realize that this will create a backlog of changes – which we can then prioritize! Hmmm
No comments:
Post a Comment