August 4, 2008 - Failure to Manage

Our house recently went through some medium size renovations. It began with replacing the hot water heater with a tankless model. During the installation the plumber explained that our galvanized pipes were badly corroded. In some places the rusty build up was seeping through to the outside of the pipe and in other it was clogging the water flow.

Scope change #1: add $5500 to re-pipe the house using copper.

Since they were taking the shower wall apart we opted to rip it out and tile the entire bathroom.

Scope change #2: another $3500 + materials.

It finished with the “Since We’re Here” special: I was in the process of digging up my front lawn to install sprinklers and they offered to run the pipes.

Scope change #3: $800 + materials. Good thing we recently refinanced!

Instead of going with a company, I hired a couple of independent contractors. They did a great job with the work, but there was a lack of basic project management from the beginning. That failure to manage caused disappointment, minor frustration and more work for me:

• The hot water heater went in smoothly, but the promise to run the wire and mount the thermostat went unfulfilled.
• The bathroom and shower look terrific, but when they said they could raise the shower head above 6 feet, I thought they were actually going to do it.
• Refitting the house with copper was a success except for a minor design change. They originally planned to come up through the floor instead of the wall. Evidently they changed their minds and now I have big holes in my walls were the pipes come out. Evidently they don’t do drywall so now I have to.
• Removing the old shower and other trash evidently wasn’t in the plan, either.

Technically, I got more than I paid for. They charged quite a bit less than they could have, did a solid job and the bathroom alone increased our house value by more than the cost of the whole project. But if I had it to do over again I would have applied more project management myself by:

• Defining the Scope. There were several items I assumed were in scope that I ended up doing: wiring an outdoor electrical box; removing old pipes from under the house; disposing of garbage; and filling the holes in the walls to name a few. I’m sure it would have increased the cost of the project but at least communicating it up front would have prepared me for it.
• Identifying all requirements. As the “sponsor” this one was my fault. When they replaced the main water line to the house they dug under the sidewalk to connect it at the meter. Had I told them I was looking to add a sprinkler system we could have used that same hole and saved some digging.
• Documenting Changes. A potential problem was averted by writing down the prices quoted to me and verifying my understanding.
• Establishing Timelines. It seemed to take forever to complete all the projects. There were scheduling conflicts on our side and theirs that stretched the duration.
• Tracking Commitments. Every time I take a shower I will likely think, “I should have reminded him to raise that pipe.” As for the thermostat, I finally hung that to the wall today.
• Customer Satisfaction. The ultimate item a project manager would have brought to the mix was a better customer experience. Small details matter, like placing a runner on the floor to minimize tracking dirt across the floor; letting us know arrive and departure times; and setting expectations.

With the help of a project manager, I have no doubt these guys could double their work load and obtain great referrals every time. Then again, I’m probably biased.

March 3, 2008 – Estimating Lessons Learned – Side Track

After last week’s blog entitled “Estimating Lessons Learned” I received the following comment:

“On the contrary-publishing an estimate of 1,433 hours may be entirely appropriate, unless there's a general disclaimer and/or policy noting that all estimated in a named range are rounded up to the "developer day" (five or six hours) or to a calendar week.

Generally I avoid spontaneous schedule adjustments-over time, they'll distort the schedule and play havoc with historical analysis of estimating accuracy. Any moderately quantitative sponsor or executive stakeholder should question estimates that always end in "0", because it signals subjectivity in the estimating process, and that's something we don't want.” – posted by "badge number ?"

I don’t have time to write a full blog this week (finalizing a presentation for PSQT’s Las Vegas conference), but I do want to respond to this line of thinking.

Let me begin with the last statement: “...because it signals subjectivity in the estimating process.” If you work in an industry that is able to do quantitative analysis and produce a spot on estimate, go for it. The construction industry has a well established, quantitative estimating practice based on years of historical data. However, by definition (http://www.dictionary.com/) an estimate is “to form an approximate judgment or opinion regarding the worth, amount, size, weight, etc., of; calculate approximately.” The use of the words “approximate” and “opinion” denotes subjectivity.

Having said that let me agree with the reader’s comment on two counts. First, “publishing an estimate of 1,433 may be entirely appropriate.” It certainly is when you are putting together a Definitive Estimate. It is not true for a rough estimate when you lack the necessary information to be that accurate. If you can support the detailed estimate, give it to them. Otherwise, don’t give them a number that they will assume is more accurate than it is.

Second, “avoid spontaneous schedule adjustments.” They are bad. I have never advocated them and didn’t in my entry. There are key points throughout your project that you will have significantly more information. At these junctures it is important to re-evaluate the reality of your estimates and communicate any changes to management.

As we will see over the next couple of weeks, that communication begins by clearly stating the logic behind the original estimate with the estimating assumptions made to get there. When re-working the estimate later in the project, those assumptions are may not be true any longer. If the basis for your estimate changed you have a responsibility to communicate the resulting change in your estimate to management.

December 3, 2007 – Lacking Commitment

They stripped a month off my project. Okay, technically I misunderstood them when they said go-live was September. What they meant was there would be a month long parallel run in production before they turned off the old system in September. Either way there were four less weeks of development time.

After sketching out the timeline, System Testing was scheduled for July 18. The four weeks to that date didn’t look long enough to me for the interface team. I wanted desperately to return to the steering committee with evidence to support my suspicions, but when asked, the team assured me it would be ready. Every status meeting I checked. Between meetings I followed up. Always the same answer: “We are on schedule.”

On July 17 we had the pre-System Testing meeting to tie up loose ends, the interfaces being one of them. The technical lead smiled and said with confidence, “We finally did it. The design is complete.” Yes, he said DESIGN! During the somewhat heated discussion that followed it became clear that they were no where near ready to test. The code didn’t even exist. They had said the words but had never committed.

Obtaining Commitment. Before anyone can (or should) commit to anything they need to know what they are in for. Walk through the expectations with the team that will do the work. Ask them for their estimates, timelines and constraints. Deadlines I impose can be dismissed as unrealistic but if the team develops the dates they own the estimate and associated commitments.

Scheduling Commitments. Before finalizing and announcing any dates, put a schedule together to lay out the commitments. Ideally you would use Primavera, MS Project or other tool to detail phases, deliverables, activities and tasks with planned hours and baseline dates. Even without those you can still put a meaningful schedule together. At a minimum, break the effort into pieces (ex. Interfaces A, B and C) and sketch out the tasks to complete them. Lay out the timeline based on the commitment and assign resources to the tasks.

Tracking Commitments. If your team has matured to the point of using actual hours and estimates to complete to rework the plan on a weekly basis, consider yourself fortunately. Many companies aren’t there yet. For everyone else, you can work it using the due dates and percent complete. Each week have the team report on which tasks are completed and the percent complete of started ones. Also have them review the task end dates and confirm they are still realistic. If a task slips, check the ripple effect and have them determine how to get back on track. Projects usually fail at the task level. Keep them in line and you stand a chance of completing on time.

Breaking Commitments. Sometimes commitments can’t be kept. Your team has to know they can tell you when they can’t meet a date. For whatever reason, my interface team waited until it was too late. By communicating the progress along the way adjustments can be made. Scope can be altered. Resources can be added. Alternatives can be discussed. When communicating the disappointing news to your management, have your facts in place. Instead of just saying, “We can’t make it,” spell out:
· Cause of the problem.
· Plans to get back on schedule.
· Proposed new dates.
· Steps to keep the problem from happening again.
· Help needed from management.

To solve our problem we ended up bypassing the interface engines by generating test material until they were completed. With significant sweat and long weekends we were able to meet the aggressive September timeline with a shortened parallel run.