It's Bigger On The Inside

My older daughter has been working feverishly at turning me into a Doctor Who fan this year. (Actually, given most of the crap that passes for television viewing, I'm a thrilled parent to find her interests lie in British sci-fi and mysteries.)

For those of you not familiar with the Doctor Who series, the Doctor (generally with a companion) travels around time and space battling nefarious aliens and underworld creatures who seek to destroy the human race. His "vehicle" of choice is called the TARDIS (Time And Relative Dimension In Space) and is cleverly disguised as a 1960's police call box. However, when mere mortals are invited inside, they see how vast and advanced the inside of the TARDIS is. Their first line of incredulity is almost always, "It's bigger on the inside."

With the advancing 50th anniversary episode called "The Day of the Doctor" coming this weekend, this observation about the TARDIS got me thinking about some of the projects I've managed over the years, as well as others I've observed. One of the biggest pitfalls of project management is scope creep, where the amount of work seems to grow once the project has begun; hence, "it's bigger on the inside."

In addition to just having sound change control procedures up front, I've learned a few tricks over the years to predict whether scope creep may be an issue. Here are my top tips to use at the beginning of the project before you travel into the future and see what's really inside the TARDIS:

1. Can the Executive Sponsor articulate the scope? When I interview the sponsor, I like to see if they can succinctly sum up the purpose of the project. If I find them droning on and on and not coming to a point, that's a big warning flag.
2. Can the Sponsor tell me what "Done" looks like? In addition to the purpose, I want to see their vision of successful completion. In other words, "we will be finished with this project when _____." If the one signing the checks can't recognize completion when s/he sees it, how do they expect the rest of us to know what it looks like?
3. How many outcomes are expected? I'm of the Thoreau camp of "let your affairs be as two or three, and not a hundred or a thousand." The fewer deliverables expected out of the project, the better the focus will be for everybody involved.
4. Are the Business Analyst(s) and Programmer(s) doers or accomplishers? This is tricky, but in getting to know my team, I like to determine the orientation of those doing the work, so I'll ask them questions about their jobs. Those who talk about accomplishments rather than tasks and work, are generally more focused, where those who talk about the doing over the completing tend to allow more work to creep in than necessary.
5. Do they "know no"? Prioritization is key in projects, and my favorite quote has always been "the quality of our YESes is determined by the quantity of our NOs." In the Midwest, we've had customer service pounded into us, and the overcommitment of "yes" gets a lot of projects in trouble. I'd rather take the heat for saying "no" and getting done on time with the critical tasks.

Following these simple tips at the beginning of a project can save you a Dalek-attack-load of trouble once you hit execution. Now, Allons-y! Geronimo! (And when it comes to scope creep, Exterminate!)

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.

Lessons from Vacation: Focus

When vacationing out West, there's one thing virtually everyone can anticipate: driving in the mountains. My experience was no different, and we ventured over Trail Ridge Road in Rocky Mountain National Park. Outside of snow and rain, the biggest challenge to driving was the wind. Driving in a fairly solid SUV, we were able to withstand most of the cool mountain breezes 50+ MPH wind gusts, but there were points in the road where we were unprotected on both sides, leaving us vulnerable to crosswinds. Despite being in a heavy vehicle, we felt like we were being tossed around a bit.

To remedy the situation, I had both hands on the wheel at 10 and 2 with a Vulcan Death Grip that would have made Spock jealous. I kept both eyes on the road at all times and kept child-induced distractions to a minimum as we lurched our way around the rugged terrain up and down the mountain.

Sometimes we have the same issue on our projects and our accomplishments. We have a goal at the end of the road, but there are crosswinds trying to knock us off course. We label these crosswinds "issues" or "scope creep" but we don't give it the recognition it deserves: something is trying to keep us from reaching our accomplishments. In reality, this trip reminded me there are always techniques for dealing with them:

1. Stay focused - when your eyes are on the road and you watch where you're going, it makes it easier to see where you're going and not worry as much about the things trying to knock you off track here and now.
2. Keep a grip (but not too tight) - granted, it took a firm grip to keep the car on the road, and as project managers, we need to keep a firm grip on our accomplishments. That being said, we also need to know when to loosen the grip and let gravity and the car have a little room to run.
3. Speed up a little - we were generally fine when faced with wind from one direction (i.e., having a mountain cliff on the other side of the road to protect us). There were a few places on the road where we were unprotected on both sides. It was in those places where I sped up a bit rather than slowing down. In the same way, hurrying to get to the next milestone and post an easy victory might be the best strategy when your detractors are coming at you from all directions.
4. Downhill is not the time to relax - in mountain driving, I've almost found going downhill is more stressful than going uphill as I have to manage the speed using the brakes more than the accelerator. When nearing the finish line of our accomplishments, we have to know when to feather the brakes, when to pull off and give the car a rest, and when to coast. At all times, reading the road will help your decision-making discernment.

We made it up - and down - and enjoyed some beautiful scenery in the process. What are YOU doing to manage the mountain driving of your accomplishments?

The Holman Expectation Curve

I posted this on Iowa Biz over a year ago, but I think it's worth revisiting.  One of my colleagues, Lyle Holman, created what he calls the Holman Expectation Curve of Project Management.  At the beginning of every project, fantasy is very high and reality is low.  The two start creeping toward each other as time progresses throughout the project life cycle until they collide in an uncomfortable moment referred to as the OMG point, followed very closely by the "Come to Jesus" meeting (CTJ).

One corollary I added to Lyle's insights is the maturity of timing.  A mature organization will have the OMG early in the project life cycle (i.e., the initiation or planning phases).  A less mature project culture will wait until potentially the closing phase before having this epiphany that what was promised is not what is going to be delivered.

I posed this question to my project management students last week, but I'll let you in on the fun:  how do you expedite the OMG for your project and your organization?  Having frank discussions all along help... and having them frequently (because sometimes - just sometimes - executives don't listen the first time you tell them something... go figure).

So what do you think?

The Midas Noogie

It was a typical project management training exercise:  get the participants to understand the importance of defining requirements in order that they will eventually be able to turn it into tasks and activities.  Hence, I divided my class into four teams.  Two of the teams had to plan a wedding for Bridezilla (yeah, yeah, I know pretty typical), and the other two teams had to design the ultimate "man room" (now we're talkin').

Then I threw the curve ball.  For one of the wedding teams, the budget was limitless; for the other only had $10K for the whole shooting match.  For one of the "man room" teams, the sky was also the limit; the other team had to design a man room which was "wife approved."  I gave them the standard amount of time to complete the assignment, and when we started to debrief, there were two teams who were begging for more time.  Can you guess which ones?

If you guessed that the teams with no boundaries had a harder time with the exercise, you would be correct.  In project management, we like to blame our short-comings on the triple constraint (good-fast-cheap... choose two).  In reality, the constraints more often lie within us.  King Midas found that out the hard way when everything he touched turned to gold.  Those project teams that have unlimited constraints generally have the hardest time getting any traction; they zip right past the "Midas touch" and wind up with a Midas "noogie" (for those of you who do not know what a "noogie" is, borrow somebody's older brother to demonstrate the process).

Roger von Oech had an interesting post a few weeks ago about the Planet-formerly-known-as-Pluto.  He then posed an interesting question of his readers:  Since we do not appear to be missing Pluto all that much, what other things can we eliminate?  What are the essentials vs. the nice-to-have's?  Where can you eliminate the fluff that is preventing you from Carpe Factum?

Some Assembly Required... Or Else!

I now know why Santa's elves are so short.  Years of caffeine and alcohol consumption have stunted their growth.  It's the day after Christmas, and I'm just now recovering from playing "Santa's Little Helper" until 2:30 in the morning assembling a kitchen set for my 2-year-old.  (And yes, it was worth it.  This toy has brought her limitless joy the past two days, allowing me to get caught up on sleep.)

The problem was not so much in the assembly as it was in the expectation-setting.  My wife, wonderful saint that she is, did all of the Christmas shopping this year since I was playing road warrior for my last project.  The problem occurred on Christmas Eve, as I was just settling down for a "long winter's nap."

"You do realize you have to assemble Abby's gift, don't you?" (It was not really a rhetorical question as much as it was a direct order.)  "It should be easy.  The picture on the box didn't look that complicated."  So... at 10:30 PM, I settled on the floor with my hammer and my screw driver and my allen wrench and 1,265,497 pieces of the kitchen set in order to "insert Tab A into Slot B, as shown in Figure C" - AAAAAAAAAARRRG.

Unlike the typical male, I do pull out the instructions first... and I read them.  I inventory parts.  I make a list.  I check it twice.  Hmmmm, only 17 steps.  "This shouldn't be too bad," I mused to myself.  By midnight - 90 minutes into it - I was only on step 6.  An hour later I was muttering incoherent ramblings that would certainly have placed me on Santa's naughty list.  And by 2:30, the final screw went in, completing the project.

As a project manager, I tend to be pretty adamant about the importance of a good work breakdown structure (WBS).  For those who aren't into project management lingo, the WBS is simply the inventory of tasks needed to get the project done... your Carpe Factum roadmap, as it were.  For a good read about the "technical academics" behind the WBS, check out this post by Elyse at the Anti-Clue blog.  However, for the reality of a good WBS boils down to two things:  clarity and communication.  If those who have to act on your WBS don't know what you want or can't read it clearly, then you've failed at defining the scope of your project, and your "all is calm, all is bright" suddenly becomes "ho! ho! hopeless"!

As you begin to ramp up your new initiatives for 2007, think long and hard about what you want to accomplish, and plan how you will communicate that scope.  We'll all get a lot more sleep if you do.