Carpet Factum

Last fall, an unfortunate flush of the toilet at the worst possible time created an "indoor water feature" in our newly remodeled family room beneath the aforementioned toilet. This sent us on a three month ordeal to completely gut and remodel the offending bathroom, as well as restore the family room to its prior glory. Always the project manager, I assumed most of the responsibility for selecting fixtures, dealing with the insurance company, and communicating with contractors. For the most part, the project ran smoothly with the exception of the carpet.

When we remodeled our family room the year prior, my wife went through painstaking research to find the perfect carpet, balancing texture, color, and a zillion other attributes. I even dealt with the same carpet company during the current fiasco, providing them with an exact sample of the carpet in order to match it perfectly. So imagine our surprise when the carpet laid was not the same as the carpet we already had down. When we pointed this out to the flooring company, they attempted to pull a few tricks to weasel out of their mistake, but because we had samples from the prior carpet and the carpet they laid, the differences were undeniable. When we went in to reorder, the "realization suddenly dawned" on our salesperson that our prior order might actually be in their computer system and - lo and behold - it was. (Duh! I only told her multiple times we had ordered our carpet from them just 15 months prior.)

In projects, we often ignore the "current state" of things because the project solution represents something new, something exciting, something different. The "as is" represents the old and stale status quo, so why bother with it? Our carpet salesperson didn't bother to consider what we had; she wanted to focus on what we would be getting. This mindset can be lethal for a project manager, as there are many valuable aspects to investing in understanding where you are before you define where you're going:

1. Pain motivates. Plain and simple. If people understand the pain associated with the current state, they will have greater appreciation for the new solution. The greatest resistance I've encountered on projects is from those who do not associate the status quo with organizational pain. Doing this well will generate appreciation rather than resentment from your stakeholders.
2. It's not all bad. Occasionally, things are being done well currently. In our rush to a new project solution, we are tempted to throw the baby out with the bathwater. Such was my experience on a recent software conversion project. I came in at a point where the commitment to the new solution was made, and my job was to execute. The former brass had not bothered doing a solid stakeholder analysis and didn't realize there were many desired features in the old system which wouldn't be in the new system. Through workarounds, communication, and change management, we were able to resolve this, but a thorough current state would have revealed features worth keeping in a new solution.
3. A numbers game. As the old quality adage goes, "If you can't measure it, you can't improve it." Helping a daughter through algebra, it's obvious that to measure a distance, one must have a starting point. Not knowing your beginning makes it really hard to figure out if you've arrived at your destination.

Virtually any process improvement model will prompt you to create a current state document. While it may seem like a waste of time up front, it's actually a sound investment to prevent wasting time at the back end.

As for our carpet, we eventually got everything figured out, and another installation later, we had our family room back to its former glory. I just wish our salesperson had known the importance and value of current state analysis before she ordered the wrong carpet. Oh well. Live and learn.

Comments

[Dr. Blood]

I love this post. I was particularly intrigued by the "pain motivates" section.

I recently read about a newish approach to job seeking taught by Human Workplace founder Liz Ryan. This approach shuns the rank and file cover-letter in which the traditional I-am-awesome-hire-me-pretty-please template appears ad nauseam.

Instead, Ryan encourages job seekers to write a "pain letter". Rather that drone on about one's education, skills, and experience, a pain letter points out where the letter-reader (hiring authority) is having trouble/experiencing pain, and then goes on to tell a story about how the employee-hopeful has solved a similar problem.

Sounds like Ryan's "pain letter" is the job seeker's equivalent for this concept that applies to project managers.

Great piece!