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.

Avoiding inertia and estimating how long it will take to write requirements

Back in 2007, I decided to take a couple of months off from writing on this blog. A few months stretched into a few years really easily. Once a habit is broken, it's very easy to give into inertia. I guess this is why one should aspire to never miss a workout.

Recently, I received an email from Georgia on one of my posts in which she asks, "..., I was wondering if you have any tips on how to estimate how long it will take to write requirements for a project you've been assigned to. The project is new, you know nothing about the business, how can you provide an estimate? Should you just give a high-level estimate and then adjust as you go along and see the progress?"

Why do businesses execute projects? To improve how things work, to meet regulatory and compliance requirements, to capitalize on new opportunities or avoid potential threats.

At some points in your career you'll be asked to work on projects where you have little to no expertise. Don't be discouraged however, this is how we learn. What approach should you use to estimate how long it will take you to write requirements? Here are some thoughts:

1. Decompose the project into the key basic business processes which will be impacted (e.g., billing, order entry, inventory reconciliation, campaign deployment, etc...)
2. Create a matrix using the business processes versus the different stakeholders involved - such as finance, marketing, customer service, warehousing, etc...
3. Indicate which teams are involved in which processes and which team is the ultimate owner of each process (who do you go to if you need a decision.) The more teams involved, the more potential stakeholder complexity.
4. For each process indicate how complex you feel it is. If you don't know much about the process, rely on the stakeholders and management for guidance.
5. Using the information you've gathered determine which processes have high, medium or low levels of complexity. As a rule of thumb you could say high = 10 days, medium = 5 days and low = 3 days.
   
6. Add up the total number of days and this will provide a really rough estimate.

Understand this is merely a high-level estimate and as further analysis is performed the estimate will become more precise. This is project estimation after all. At the start, you might provide an estimate with 100% contingency, however as the project starts to execute the level of contingency drops as more things become known.

One side benefit of using the matrix is it will also help you plan out your requirements gathering sessions (you know exactly who needs to be involved for each process.) Use this to secure participation from those teams and your project's sponsors.