Mind Reading in Braille

I've always been amused by the scenes in movies when people are gathered around an attorney's office for the reading of the last will and testament of a deceased person.  There are usually a bunch of well dressed people sitting in high back leather chairs in a mahogany paneled office with soft music playing in the back ground.  They build up the suspense and then it all becomes pretty formulaic:  somebody inherits something great that they weren't expecting, and somebody else receives some tacky little trinket (or nothing at all) and felt they deserved more.  Then there are a few "You don't deserve that" comments thrown around, a threat or two to contest the will.  Then switch to the next scene.

Now imagine that you're in that scene, and the attorney says, "And to [insert your name here], I bequeath the project I was managing.  Good luck.  You're going to need it."  You sit there, dumbfounded for a moment, your jaw dropping so far down that a first year dental student could get a complete history in one glance.  After you try to trade with the person next to you who inherited the priceless Ming vase, you resign yourself to your fate.  And now comes the really tough part:  you have to figure out what was going on in their mind and try to pick up and move on.

Sometimes you have the luxury of "reaching beyond the grave" and talking to the exiting project manager for a smooth transition.  More often than not, that transition may be an unceremonious handing off of a huge project folder and a pat on the back.  Then you're left flying blind and trying to read the mind of your predecessor.

What do you do next?  Well, this is not too unlike a project rescue and recovery effort in many respects; however, there are a few basic steps you should take in the first week as you are ramping up:

• Talk to people - don't just send out a mass email introducing yourself.  Schedule an all-hands meeting your first day on the project.  Then follow it up with one on one introductions with the key members of your team.  Get to know them and give them a reason to start respecting you.  I was on a project a while back where the team wouldn't have liked anybody, but it still didn't stop me from trying to build the relationships.
• Confirm scope - if there are things about the original requirements or tasks that don't make sense, now is your time to correct it.  You don't have to go hog-wild on change requests, but this is your opportunity to kill a sacred cow or two.
• Review the project plan - if the plan was structured in a way that makes you uncomfortable (i.e., too general), then now is your chance to redo it.  People may be frustrated that you're slowing down the progress of the project, but sell them on the investment of making sure that you're all successful at the end.
• Revisit assumptions and risks - one major assumption was already violated on this plan:  the project manager left.  There may be a domino effect.  Your job, Sherlock, is to figure out what other assumptions and risks may affect YOUR management of the project.
• Figure out why the previous project manager left - sure, we all want a challenge, but nobody wants to be set up for failure.  If the issue for their departure is fixable, then fix it (or add it to your risk list so it's documented).  If it is not fixable, then ask whether the project should move forward until the problem is fixed.  (NOTE:  That's a tough discussion to have with senior management, so make sure your back bone is straight and strong.)

At some point, we all have to take over somebody else's project.  Sometimes the transition is painless.  Other times, you have to do a lot of telepathic mind reading.  Whatever you do, just don't go barging in without a little questionning first.  Good luck!

Ogres Have Layers... So Do Project Plans

"Tim, can you help us?  We have a project plan we need you to look at."

It wasn't the first time I'd received that request, and I always enjoy looking at a project plan to help troubleshoot.  Keep in mind, MS Project is my favorite tool.  I realize that there are challenges, and those who are unfamiliar with the tool can easily fall into many of the pitfalls that the software offers.  One of those challenges is simply in how the basic entry screen is set up.

The tool asks for too much information too quickly for many project managers.  It lends itself to asking for information that should not be input into a project plan.  For example, adding in start and finish dates on tasks creates unintended constraints.  Adding in resources automatically calculates work effort and duration... without the user often realizing it.  Even the folks at 37 Signals are anti-Project.  I don't know that I'd go so far as to call MS Project an "enemy," but I can certainly agree with the opinion that the tool... ANY TOOL... should focus more on facilitating communication that generating charts and graphs.

Because of these software pitfalls, I tend to recommend the "Shrek Approach" to project planning.  Instead of attacking all task information requested on the "entry screen" on the first pass, I recommend creating custom tables and views to allow for an iterative approach to project planning:

1. WBS Pass - The first pass on a project plan is simply building the tasks associated with the work breakdown structure.  Start with deliverables and then "back into" the tasks needed to achieve those deliverables.  Include milestones and notes.  Add in the WBS numbering column so you can see how the plan structure is developing.
2. Dependency Pass - This pass is about building in dependencies and constraints.  (Hint:  use the "Split Screen" function to add in lag and lead times.)  Focus only on identifying how tasks are related to each other rather than on the duration of tasks.  Avoid constraining tasks to specific dates unless absolutely necessary (i.e., don't enter dates in the start or finish fields).
3. Resource Pass - Build the resources for the project team.  In order to avoid scheduling WUHOTs to staff your project, the first pass of building the resource pool might be best accomplished by identifying skill sets rather than names of people (e.g., enter "JAVA Tester" rather than "Joe Bob Smith").  Add in other relevant information about your resource pool:  rates, calendars, etc.
4. Assignment and Estimation Pass - Here is where you actually assign resources to tasks, determine how long (in both work effort and duration) each task will take, and perform an initial "reality test" to see if it will float.
5. Leveling Pass - By the time you are at this pass, names should have replaced skill sets in your resource pool.  Ensure that these resources have reviewed their own tasks and verified the reality of them.  Also be sure that resources are not overloaded (MS Project can be fickle in how it defines overallocated resources; email me if you have questions on how to mitigate this problem).  If your project is part of a larger program, this is where that integration occurs.
6. Approval and Baseline Pass - Obtain the approval of the needed stakeholders and baseline your plan.

Diana Lindstrom once compared a project plan to a musical score, a very good analogy (and certainly "prettier" than comparing it to an ogre like Shrek).  As some musical scores are longer and more complex than others, so are some project plans.  Determine the level of complexity that is appropriate for your plan and is custom to your project.  Then just choose the right "layer" of complexity for your ogre... er... um... plan.