Making change requests tangible - the home reno

The cost of change requests are sometimes difficult for a client to visualize. This is especially true with software development projects. There is just nothing tangible a client can wrap their mind around. 200 lines of C+? 400 lines? What's the difference?

To make the impact of a change request more tangible, I suggest using an example most of us can relate to - home renovations. Last fall, I had a series of basement renovations performed. One component was to add a partial wall to split an area of a room off (notice the wall on left.)

After the installation of the initial studs and drywall, I decided the wall should be a little longer. This would provide me with the option of putting larger pieces of furniture on the other side (e.g., more shelves.) The contractor had to use more materials and time to extend the unfinished wall.

Had I realized my requirement for a longer dividing wall earlier, it may have saved my contractor some time (because I caught this early I didn't waste any materials.)

Now that the renovation is complete you can't even tell the wall was extended. I got what I wanted even though it took a little more time.

For arguments sake, suppose I figured out I needed the wall extended after all the painting, floors and baseboards had been installed. Considerably more time and material cost would have been incurred. Why?

If my contractor needed to remove flooring, drywall and repaint - I would have wasted a lot of materials. Some of the flooring and baseboards would have been thrown out, additional paint and priming time would have been required, etc... All of this costs money.

On a side note, the wife of a friend of mine was also performing a renovation - the kitchen. She decided to replace the marble tile pattern she had picked for the backsplash. She made this decision after the tiles had been bonded to the walls, grouted and treated (so oil wouldn't damage them.) My friend literally cried... he understood the impact.

The moral of the story - the earlier you can identify the need for a change the less costly it will be.


Paul Lear said...

Your moral, the earlier you can identify the need for a change the less costly it will be, is one answer. But, that leads to some of the worst problems of waterfall, trying to define everything up front.

The other choice is, don't make decisions too early - wait for the last responsible moment.

Marcus Ting-A-Kee said...

I agree with you. However, I do think the last moment possible may differ dramatically depending on the project. In software projects with short development sprints, the decision can be made very late. In projects where the implication of missing something critical is immense, the last moment possible may happen well before development starts.

Anonymous said...

Marcus, if you know how I can contact Ranford Ting-A-Kee, please write to I'd really like to contact him.

Floors Direct said...

You are right. Thank you for this suggestion, I got new knowledge for this post.

Floors Direct

Muthu vell said...

Thank you Sharing this blog. Its very useful to survive as business analyst and beyond.
href=""Business Analyst Program