The Horror of Surprise

The defenseless couple walk along the dark hallway, dim lights flickering among the cobwebs. Eerie music crescendos as they near the door at the end, unsuspecting of any possible harm as they slowly reach for and turn the knob.

Boo!

Sorry, that's as scary as we're going to get this Halloween season. Unless you're a project manager. And you're blindsided by the unexpected. Like some hideous monster jumping out from behind the shadows, there are always creepy-crawly things waiting to scare you:

• Indecisive executives
• Changing business landscapes
• New or forgotten requirements
• Office politics gone awry
• Sudden staff changes

I saw a t-shirt this summer that said "Life is all about how you handle Plan B," and that's especially true if you're a project manager. But with all of our risk and issue planning, few project managers TRULY give thought to Plan B and how it plays out.

What are the elements to creating a solid Plan B?

• Trigger Event - what has to happen among all your risks in order for you to jump away from Plan A? Define events, thresholds, or variances that must be present for you to go to your Plan B.
• Outcomes - what do you want Plan B to accomplish? Don't assume it's the same thing as Plan A. You may need to scale back features and functions of your scope to get done on time. You may need to sacrifice time or budget.
• Roles - what skill sets will help you achieve the Plan B outcomes, and which available staff have those skills? Avoid the temptation to simply reassign your Plan A team (after all, they may have been the ones who got you into the mess).
• Tasks, Dependencies, and Estimates - create your Plan B project plan to show how you will use the ROLES to achieve the desired OUTCOMES once the TRIGGER EVENT has occurred.
• Stakeholders and Accountability - who cares and how are we going to keep them apprised of our progress? How will we define "done" to ensure people are accomplishing Plan B?

So the next time you go sneaking around dark passageways on stormy evenings, make sure you have your escape route marked. Go Plan B!

But Did You Save The Project Receipt?

The ugly (as in "should be arrested for wearing it in public") sweater.

The 100-pack of sausages from around the globe.

The autographed autobiography of Charlie Sheen.

Tube socks and Old Spice.

So, do we have any other nominations for re-gifting? Or should we do society a favor and make sure these things make it to the nearest dumpster, never to see the light of day again? They are officially known as the undesirable Christmas present. The first year I was married, my wife's grandmother sent me some very "interesting" underwear that was two sizes too small. Suffice it to say, I was thankful that there was a gift receipt that came with them.

Unfortunately, projects do not come with gift receipts.  Some of them should. We tend to lock our projects down with constraints the way we lock our friends and family down with Aunt Maude's Fruit Cake (which is actually the same cake that was baked in 1951, the year she was married, and has been regifted for the past 60 years).

Being on the receiving end of projects, I've been gifted with some real stinkers. While I generally enjoy the challenge of project recoveries, there are some traits which make certain project rescues better than others. And there are other projects that are the equivalent of the bedazzled and hand-painted Christmas tie. One year I got a claims system project with a bi-polar sponsor, a passive-aggressive team, and a vendor with delusions of grandeur. Another one was a compliance project where the previous project manager had annoyed everybody to the point he was ostracized, the sponsor was young and clueless, and the lead BA had the charm of a porcupine.

The trick to avoid getting stuck with a dog gift is simple: set some expectations early with your key project stakeholders. Think of it as giving yourself a VISA gift card. Set some general parameters or boundaries. This allows the project manager to avoid micromanaging stakeholders, the project equivalent of being forced to wear the light-up sweatshirt that blinks "I brake for reindeer." A good idea is creating a "How We Work Together" document at the BEGINNING of a project. If 90% of a project manager's time should be spent in communication, then setting expectations up front on boundaries, scope, and parameters will be critical to creating a relevant and meaningful experience.

What about you?  How do you prevent receiving the project equivalent of the hand-knitted Santa Claus tissue-cozy?

(Modified from a post I published for Iowabiz)

Last Stop on SPARTA Trip: ACCOUNTABILITY

We've had quite a project rescue and recovery trip through SPARTA this week.  To get the full context of these points, I welcome you to read Race Through The Forest.  To recap,

• We STOPPED all work to regroup
• We set PARAMETERS around the recovery work effort
• We identified and documented ASSUMPTIONS and risks meaningful to our recovery
• We tagged relevant ROLES based first and foremost upon skill sets
• Lastly, we planned and estimated the TASKS that were important to our recovery effort

So what's left?  The most important piece:  ACCOUNTABILITY (the last letter in the SPARTA acronym).  Former U.S. President Harry S. Truman had a plaque on his desk that said "The Buck Stops Here."  Unlike almost every president we've had since, Truman understood the key element of his role was accountability.  No excuses.  No whining.  No finger pointing.  No spin-doctoring.  It ended with him (are you paying attention, Clinton and Bush???!!!).  When I am managing a project, I tend to keep reporting simple.  I provide all of my resources with a 2-3 week look-ahead report (on a weekly basis) so they know what is coming up.  I also publish a "late task" report.  That one single report lets EVERYBODY know what tasks are late and who is responsible for those tasks.  When I say "publish," you can translate that as the corporate equivalent of shouting it from a mountain top.  Every relevant stakeholder knows what is late and who is accountable.  It's an objective yet powerful motivator to get tasks done on time.

Sometimes accountability can take a simpler tone, though.  Last month, Steve Farber posted a great story about a Sleep Country delivery driver.  His take on accountability provides lessons for all of us.  When I'm in a restaurant, I tip my server based on one primary issue:  how well did they keep my beverage glass full.  That is truly the one thing that I know they are wholly accountable for.  Simple follow-through.  It's really not that hard.

Well, folks, I hope you've enjoyed this trip through SPARTA as much as I have.  Good luck recovering and rescuing your challenged projects.  Carpe Factum!

Technorati Tags: Project Rescue, Project Recovery, Project Management, SPARTA, Race Through The Forest, Harry S. Truman, The Buck Stops Here, Accountability, Steve Farber

SPARTA Trip: TASK(Master)

In rescuing a failing project, eventually a new project plan needs to be constructed.  TASKS (the 'T' in SPARTA) need to be defined (or redefined).  In building a project plan for a project rescue, tasks will probably need more scrutiny than they were given the first time.  There is a lot of skeptism regarding the ability of the team to execute the project successfully.  Your recovery team's credibility is on the chopping block, as well as your reputation as project manager.

The project went into failure mode for a reason, and I'd be willing to bet that the reason had to do with lack of planning the first time around.  Therefore, it stands to reason that a solid project plan will help your project recovery flourish (rather than flounder).  Some general guidelines to consider for constructing tasks this time:

1. Start each task with an action verb (examples:  test, build, write, meet, analyze, construct).  This ensures that there is action associated with each task.  Task names like "requirements document" tell the reader nothing.  What are you doing to the requirements document that requires time and resources that is relevant?
2. Sequence tasks logically.  Agree upon dependencies.  Know the constraints (i.e., testing must complete before year end).  Identify lag and lead times.
3. Estimate tasks sensibly.  No task should ever run longer than two weeks duration.  If it does, break it down to something more granular.  Similarly, on work effort, no task should be more than 40 hours for a single resource, 100 hours for multiple resources.  Otherwise, your tasks are being defined too broadly, and the last 5% of the task will take 95% of your time.
4. Use the logic discussed in the previous post on roles to assign resources.
5. Spend time with the resources to level the plan.  Make sure than no resources are unduly overworked or underutilized.  Review task estimates for feasibility.
6. Baseline the plan.  Don't put all that time and effort into building a plan without putting a line in the sand.  A project plan baseline will also feed into the final recovery step:  Accountability.

The new project plan must inspire faith in the stakeholders that this will be the last time this project will need to be in recovery mode.  A lot of credibility is on the line here.  Carpe Factum!

Technorati Tags: Project Recovery, Project Rescue, SPARTA, Project Management, Project Planning, Tasks, Dependencies, Resources, Estimates

SPARTA Trip: (Stop, Drop, and...) ROLES

Jim Collins' brilliant assessment of getting the right people on the bus before you take off is so applicable to projects as well.  I've seen projects that are poorly staffed from the beginning, making even the best idea with unlimited resources become nearly impossible to achieve.

At some point during your project recovery effort, you're going to have to figure out who can help you get from despair to glory, the ROLES (our 'R' in SPARTA) to get on the metaphorical bus.  However, whenevery you talk about staffing projects, there's a pretty straightforward laundry list of activities to consider (these apply whether you're recovering a project or just planning it for the first time):

1. Role Title and Skill Set - What do you need to have accomplished?  Do you need a Java programmer, an Agile tester, a RUP analyst, or an Excel guru?  (DO NOT LIST NAMES YET!!)
2. Experience Level - this can be variable (new, intermediate, advanced or number of years); just express how well a resource has to perform in the role or if you're willing to accept a little on-the-job training
3. Secondary Skills - Does your programmer need to have meeting management skills?  Does your business analyst also need to understand MS Project?  What additional skills will make this person more well rounded to fit your project needs?  Are these additional skills non-negotiable or are they nice to have?
4. Availability - Will this person be needed full-time, half-time, 3 hours every other Friday?  Provide a ball-park estimate.  Task planning will fill in the details.
5. Names - NOW you can begin assigning people based on the other criteria.  Beware the traps of WUHOTs and GLCTs.  I've been on a few projects where the level of drama and dysfunction kept anything productive from happening... and I wasn't allowed to vote the trouble-makers off the island.

These people will be crucial for your next step of developing the tasks for your project plan.  The cast may change once your plan is developed, but the investment of time to ensure you have the right people on the bus will be crucial for your recovery success.

Technorati Tags: Project Recovery, Project Rescue, Good to Great, Jim Collins, SPARTA, Project Roles, WUHOT, Project Management

SPARTA Trip: ASSUME (the position)

At one client site, there was another project manager who was working on an imaging system implementation.  Most of the imaging infrastructure was outsourced to the vendor, and the project manager was there to ensure that the requirements and standards were in place and that the data structure was ready to interface with the new imaging system once it was installed.

One day, the vendor called the project manager with a very pertinent question:  What version of Oracle (the database at that client site) would be in use at the time of implementation?  The client was currently on Oracle version 7, and the imaging vendor wanted to know if they would be upgraded to Oracle version 8 by the time the imaging system was installed six months into the future.  The project manager hunted down the first "techie database dude" (I believe that was his actual job title) and asked him which version of Oracle they would be on in six months.  He did not tell Techie Database Dude why he wanted to know, nor did he mention any pertinent information about his inquiry.  Being a somewhat confident and self-assured individual (which sounds better than arrogant and cocky), Techie Database Dude ensured our project manager that they would be upgraded to Oracle 8 in six months.  Project manager then informed imaging vendor of that piece of news.  He never wrote it down anywhere.  He never informed anybody else that these conversations took place.

The project progressed in green status for the next six months, both sides moving toward a smooth implementation.  Then the imaging vendor showed up, ready to install.  Guess what version of Oracle the client was using for their database?  The project went from status green to status red (bright flaming red with fire engine sirens blaring in the background) overnight.  Executives were livid.  And the project manager had egg on his face.  Lesson Learned:

Undocumented assumptions reincarnate as excuses

It may seem like a mundane task, but when you are in project recovery mode, ensuring that everybody's ASSUMPTIONS (the first 'A' in SPARTA) are laid out on the table before you venture into recovery execution is critical.  People already have a lot of assumptions (many of them unspoken) about why the project failed in the first place.  Analyze them.  Debate them.  Document them.  Use them as a springboard to identify project risks.  Revisit them often.  Undocumented assumptions are killers, and will have you backpeddling with excuses faster than a politician caught with his hand in the cookie jar.  A violated (and undocumented) assumption, as our earlier project manager friend can attest, will put you in a very uncomfortable position.

NOTE:  Facilitating a "risks and assumptions" identification meeting is very challenging.  Many people do not want to vocalize these things... some out of ignorance, some out of fear, some out of a malicious desire to see the project fail again.  I'll discuss this in a future post.  For now, Glen Alleman of Herding Cats has a great post on a one-minute risk assessment that can be easily extrapolated to assumptions.

ANOTHER NOTE:  None of the processes within SPARTA need to be treated linearly.  If you want to delay assumptions until after the recovery plan is laid out, or if you want to document assumptions over the lifespan of your recovery effort, that is great.  Whenever you decide the time is right, then do it.

FINAL NOTE:  When writing assumptions, I encourage project teams to write them as positive statements rather than negative statements (which I save for risks).  Examples:

• "We assume all resources will have the correct skill sets and be available as needed (per the project plan)" as opposed to "We assume we won't lose critical resources"
• "We assume the technology is compatible with our infrastruture" as opposed to "We assume nothing will break"

Technorati Tags: Project Recovery, Project Rescue, Project Management, SPARTA, Risk Management, Assumptions, Glen Alleman, Herding Cats

SPARTA Trip: PARAMETERS (Avoiding The 666 of Projects)

OK, so with all the hullabaloo about the re-release of The Omen on 6-6-6 (clever marketing, regardless of the quality of the movie), it stands to reason that somebody should take to task the Damien of project management, the demon of Carpe Factum, the true 666 of accomplishment:  Scope Creep.

Like Damien, Scope Creep starts out cute and cuddly.  That sweet, innocent little "oh, while you're at it, why don't you just...." (you can fill in the blank).  And then the demon reveals his little 666, which is why you're now in project recovery mode.  The bodies are piling up faster than the average horror flick remake, and you're left to fight the beast.

The silver dagger for slaying scope creep in a project recovery mode is pretty simple:  PARAMETERS (the 'P' in our SPARTA acronym).  Set some firm boundaries while everybody is alert to the fact that you are rescuing this project from the jaws of Satan.  Tell exactly what is in scope and what is out of scope.  Document it (preferably on parchment scroll... in blood, if necessary).  Since you are in project recovery mode, there will be a lot of uncertainty.  Slay that beast here and now and make it clear to all concerned what is (and is not) going to be addressed as you complete this project.  Ambiguity is not your friend.  You're already perched precariously on the balcony... don't let the little beast come along and knock you off.

(My apologies for the shameless exploitation of a major media event and countless pre-millennialist religious icons to get the point across about project management and project recovery... this one was just too easy to resist.  I promise to be back to my angelic self tomorrow... snicker... giggle.... OK, maybe not.)

Technorati Tags: Project Recovery, Project Rescue, SPARTA, Project Management, Parameters, Scope Creep, 666, Damien, Omen, Mark of the Beast, Silver Daggers

SPARTA Trip: STOP (in the name of love)!!!!!

Once upon a time, there was a Human Resources/Payroll system implementation project that was scheduled to last six months.  Eighteen months into this 6-month project, the project manager resigned "due to health reasons."  My client assigned a functional team manager from IT as the new project manager, and hired me to serve as her project controller/mentor to ensure that

1. she was successful in her new role
2. the project completed in a reasonable and timely fashion (translated:  get it done quickly and correctly or your butt is on the line)

We inherited a fiasco.  The vendor wasn't playing nice and wasn't delivering on their promises.  Certain members of the project team were working overtime to the point of severe burnout.  Others were taking opportunity to use the chaos to go on in-office vacation.  Management was pressuring all of us to deliver something... FAST!  So, we did what any logical project leadership would do in that situation.

We stopped everything.

That's right, we stopped all "work" on the project for two weeks so that the critical stakeholders could be pulled into a war room to identify and plan the remaining work, sequence it out, estimate it, assign resources, etc.  The regrouping worked.  We baselined the project recovery plan at 1:30 AM on May 1 (the day of the next Steering Committee meeting).  We estimated that the project would deliver on August 12 (it actually delivered on August 13 - without consequence - because IT had a silly little rule that programs could ONLY be put into production on one night of the week).  Why the four month success after 18 months of chaos?

From page 103 of Race Through The Forest:

"STOP is just as it implies," started Barry.  "All work on the project should cease while the project stakeholders regroup.  You wouldn't expect a surgeon to operate on a car wreck victim if he or she were still attempting to drive the damaged vehicle.  They would need to be taken from the accident site to the hospital where the doctor has the tools to diagnose the problem and help the patient to heal and recover.  The same principle applies to projects.  Assuming you are hiring a new project manager, which is generally a good idea, this person needs time to assess the damage and figure out what to do next."

Stopping a failing project to regroup takes courage and conviction.  There will be pressure to "dam the torpedoes, full speed ahead."  Politely, yet firmly, avoid that temptation.  Giving in to the demands of executives (who very well may have contributed to the culture of project failure) will only compound the chaos.  You will be grateful you paused, reflected, analyzed, and regrouped.

Technorati Tags: Project Recovery, Project Rescue, First Step, Stop, SPARTA, Project Management, Race Through The Forest

A Trip to SPARTA

In my last post, the topic of "recovery vs. flush" came up with respect to projects.  The decision to flush a bad project, while not easy, can bring relief to those who suffered through it over the months or years that it staggered along.

But what about project recovery?  What happens when you decide that the growing stink-bomb is actually salvageable?  In the book, Race Through The Forest, the Epilogue of the fable actually covers the topic of rescuing a floundering project.  As with many issues that need to be quickly and easily remembered, this one also involves an acronym:  SPARTA.

• Stop
• Parameters
• Assumptions
• Roles
• Tasks
• Accountability

The next few posts will be dedicated to reviewing what do to when rescuing the project that's on life support.  SPARTA this time of year should make for a fun trip.  Hope you'll come along.

Technorati Tags: sparta, race through the forest, project rescue, project recovery, project management

To Flush or Not To Flush

When is it appropriate to call it quits on a "bad" project and give it a decent burial?  Ah, 'tis a question for the ages, one that has befuddled many a project manager and executive sponsor.  If you've thrown $10 million after a project over the past eight years that has produced only an itty-bitty teensy-weensy sliver of the grandeur originally promised, is that enough to keep the project on life support to allow it just one more chance to make good on its promises?

Michael Krigsman recently wrote a couple of insightful posts called Knowing When to Quit and Throwing Good Money After Bad?  Both touched on this issue of determining when to pull the plug (or in some cases, blindly charging ahead, consequences be damned).  Michael's analysis of failed projects is indepth and spot on, as it appears he has made it his life's calling to study the phenomenon of failed projects.  Although I suppose, given the frequency with which failed projects happen, one could hardly refer to it as a phenomenon.  But I digress.  The point is, he's just darn good at uncovering story after story after story about project failure.

So... how does a money-strapped executive of the 21st century decide when to call it a day, say enough is enough, and flush that you-know-what down to the sewers of the dead project graveyard?  Here are a few simple questions that beg to be asked (and answered honestly):

1. Is the project recoverable?  If the variances have thrown the project so far off track to the point of humiliation for all involved, is it possible to do a course correction, change some staff, and perform a formal project recovery?
2. Do we still care about the project?  Will it add value to our organization through some kind of tangible improvement to our bottom line, cycle time, customer perception or infrastructure?  Is anybody out there still excited enough about this project to stand up and fight for it?  Was this project really important or was it an executive's pet idea?  (OK, who let the CEO read trade magazines again?  You know this always happens when he does that.)
3. Are we simply in love with the sunk cost?  "But we've already spent 15 years and $22 million dollars doing the analysis" is not a reason to keep a project on the books.  Nothing will recover that money or time... ever.  Get over it.  That is the same rationale that co-dependent people use when they call Dr. Laura to explain why they've stayed in a toxic relationship for years and years.  Maybe Dr. Laura should start doing project management consulting... er... um... strike that.
4. Is now really the right time for this project for our organization?  Do we have the right people?  Is our culture ready for this change or were we jumping on a proverbial bandwagon?  Can our capacity, infrastructure and architecture handle the results of this project?  Has the project caught us with our organizational pants down?

If your answers to 1, 2, and 4 were "no" while 3 yielded a "yes" then do yourself a favor.  Put your fingers to the handle, press down, and listen for the swish-gurgle-flush.  Trust me, you'll feel better.

Technorati Tags: Michael Krigsman, project management, project failure, project recovery, sunk cost, project value, Dr Laura, flush, toilet