This morning as Christine and I left our comfy confines for our normal Sunday breakfast at our local Caribou, I was struck by something. Our neighbors’ upstairs windows were open – not surprising given the gorgeous weather we’ve had the last couple of weeks but given the nearly 3/4 of an inch of rain that fell in last night’s thunderstorms (and I should emphasize the thunder part) I figured they were probably elsewhere on this holiday weekend. For reasons that will make sense in a bit, their windows got me thinking about change management and its importance in successful projects.
Those of you that know me and have been subjected to one of my rants knows that I’m not a fan of heavyweight methodology or professional methodologists. The so called process leaders are no different than those hearty souls that maintain corporate frameworks – from time to time, they need to spend some time in the trenches or they lose all appreciation for what the grunts face day to day. So it’s in this almost antagonistic context that I pen this piece on change management. While I may not be a cheerleader for RUP anytime soon, I do have a significant appreciation for controlling the inevitable change that occurs on any project.
To illustrate my point, I’ll turn to a story unrelated to software in an effort to explain why I think a disciplined change control process is a key aspect of project success. A few years ago, Christine and I built a new house. As anyone that has undergone home construction knows, it is a mixed blessing: you (usually) get exactly what you want but for the duration of construction, you tend to eat through stress balls like Mick Jagger goes through fashion models. I won’t bore you with all the details (it will be repetitive for anyone that had the misfortune of working within earshot of me a few years ago) but lets just say, we had our share of issues. Beyond sub contractors that obviously didn’t read the painstakingly prepared plans (even I could tell where the washer and its so called “panic pan” was supposed to go) our closing was delayed due to a slight oversight: it turns out that our house was about seventeen feet too close to the road that runs along the West side of our lot. I still don’t know how the city (which approved plans clearly showing the house well over the line), the surveyors, or the builder all managed to miss this minor error but it happened (I know, abandon all hope of a better past.) Oh well, after enduring more city council meetings then anyone not actually on the city council should be forced to endure, we moved into our brand spanking new house.
After going through a relatively painful build, I assumed all was well once we moved in – seriously, what else could go wrong? Well, a few months later, we got a call from the sales rep saying we needed to discuss an issue with the windows next Tuesday. At this point we couldn’t imagine *what* could be wrong and the rep didn’t have much info but we weren’t too concerned – after all, we survived an amendment to the PUD (no, I’m still not sure what that means.) With this baggage, we showed up at the appointed time and I was quite surprised when the person we were meeting had a last name that bore a striking resemblence to the builder of our development – turns out he was the developer’s son so I knew something had to be major for kin folk to be running the meeting.
Mr. “son-of-the-developer” was very polite and explained that our home had a slight problem. It turns out that the windows in the two upstairs bedrooms (you know, the ones where children go) weren’t exactly up to code. Apparently rooms where people sleep are required to have an opening of x inches so that a fully outfitted fireman would be able to enter and drag you to safety in the event of a fire (good luck to anyone that has to drag my unconscious body from a burning building – I hope there are a few of you.) Now, I’m not sure what home inspectors are actually looking for these days but I know they signed off at various points throughout construction so I figured (wrongly it turns out) that our home was up to spec. How silly of me.
Once I got over my surprise that our brand new home wasn’t quite up to code, I was curious how exactly this could happen. Mr. “son-of-the-developer” explained how, due to considerations in the laundry room, they had moved to smaller windows on the lower level of the house. Like any changes to their plans, this modification went through their normal change management process where it was reviewed by numerous individuals including folks that know the building code. Unbeknownst to them, at a later date, a draftsman then modified the windows directly above those changed on the lower level to match – for this guy it was all about the symmetry! Of course the draftsman wasn’t up to speed on the building code in this county (or any county for that matter) so he didn’t realize that his minor change made a material difference in the home – but it sure made it prettier to his eye!
Of course I’m not sure how their review process allowed such a modification but I was told that draftsman was no longer employed by the company (turns out ours wasn’t his first transgression) and they used our experience to further strengthen their process. So what does this have to do with software? As my (soon to be former) team knows, change happens but when it’s not managed well, it really is painful. You see our customers tend to be very demanding and as one said the other day “Everything I want is a high priority” (and then went on to say, uncharacteristically, that in retrospect, many of his emergency requests weren’t quite as critical as he thought at the time.)
Building software isn’t the same as building a house – once your foundation is pored, it’s pretty hard to decide you want to tack on an extra thousand square feet. But just because software is more ephemeral doesn’t mean the change is any easier than that made in the physical world. However, my builder knew exactly what it would cost them to fix our situation (which they did) and had we decided halfway through the process to make a change to our plans, they would have obliged – with the additional fees required to make it so.
Many of the customers I’ve encountered over the years have no idea how expensive it can be to make what they perceive as minor changes to a system. Much as I would like to place the blame squarely on their shoulders, I really can’t – we are as culpable as they. We need to educate our customers on the cost of change, we need to help them make informed decisions. As much as it pains me to say it: we need a process to manage change. There, I’ve said it. I feel a little dirty, but darnit, we need it!
So, how do you manage change in your projects? How are changes prioritized? What happens when they aren’t? Let me know what you think.