Timothy Johnson Photo in Header

Puppy-Proofing Your Project

Fergus_PuppyA few months ago, I reported that our furry family member, Zorro, had gone that great Milkbone Factory in the SKy.

Since we are "dog people," I figured it wouldn't take us long to add another pet to the mix. We had discussed waiting until spring to get a dog, figuring potty training would be a lot easier. However, when this adorable pooch arrived into the world (on Abby's and my shared birthday, no less), we knew it was fate that Fergus Geronimo Johnson would be a part of our family. And so the week of Thanksgiving, he entered our lives and we haven't looked back.

It's been a while since we've had a puppy in the house. After Zorro, I quipped that I like my dogs as I like my cars: certified pre-owned. So we've all had some adjusting to do over the past couple of months to keep Fergus and our belongings safe and sound. As with most things in life, this experience got me thinking about new projects within the organization, and there are some parallels to acclimating a puppy to the house and getting your project onboarded smoothly:

Alpha Dog - your puppy will probably latch onto one person in the house as the "leader of the pack." Fergus looks to me for a lot of his commands and needs. In the same way, your project needs an alpha, preferably your project manager, although one could argue the sponsor is an even better alpha. An alpha's job is to protect the puppy and provide guidance and direction.

Toxic chemicals - we have tried to lock up all the dangerous chemicals around the house to keep Fergus away from them. This is an area where many organizations fail in protecting their puppy of a project. Toxic employees can kill a project as well as the morale of the project team. Get rid of them or isolate them if they won't change their ways. By the way, people do not become toxic overnight; they've probably been that way long before your project came on the scene. Do something about them before you bring the project into the organization. In the same vein, a new project is a good way to find out which company policies and procedures may not be safe for your organization's new accomplishments.

Put away the valuables - puppies can do a lot of damage with their sharp little teeth, so putting up shoes and spraying furniture and picking up miscellaneous toys and papers is a good play. The puppy doesn't know it's causing harm; it's just doing what puppies do. In the same way, a project introduced to an organization is trying to accomplish its scope, but it may not realize what harm it's doing to other parts of the organization. Running pilots or prototypes before rollout can allow your puppy project to wreak its havoc in a safe environment.

The Kennel - many puppies are "crate trained" as owners work during the day. The kennel is the puppy's safe haven. It contains the chew toys and bedding. Provide your project team with a safe haven where they can work together without distraction. A dedicated conference room or office for higher profile, more involved projects can help a team considerably.

"Accidents" - there will be times when the puppy can't hold it in any longer. When accidents occur, simply redirect the puppy to the correct actions and don't freak out. Eventually, the puppy gets it. In the same way, things go wrong on projects. If you play the blame game and freak out with every issue or risk event, people will learn to hide their messes rather than learn from them.

So congratulations on your organization's new project. Give it lots of love and direction and consistency, and it should flourish into a happy, fuzzy accomplishment.

Just a Little Late

WatchHey! Lay off! My post is here, isn't it? Oh sure, it's minutes before November ends. Big deal! Why are you being so rough on me? I'm not "technically" late.

Hmmm... sound familiar?

In project management, late tasks happen. A lot. More than most project managers care to have them happen, anyway. We work with our teams. We communicate. We build grandiose project plans. And the task is still late. And we wind up with egg on our face with our executives and our customers.

But how does a project manager prevent it from happening?

Well, the first step is figuring out WHY it happens in the first place. A few years ago, Samuel Okoro published a great blog post on project task tardiness. Some of his top reasons:

  • Estimates - because our "best guesses" are padded with contingency due to the task uncertainty, we're already shooting blindfolded.
  • Students' Syndrome - procrastination... enough said.
  • Parkinson's Law - work expands to fill the space allotted to it.
  • Integration - making sure all of the predecessor tasks are done on time so your task can start.

Sure, there are others. But these give you a pretty good idea why our projects don't get done on time. That last one is especially difficult, when you consider the compounding effect of one late task.

But how do we prompt task completion punctuality? Here are a few good tips:

  • Schedule tasks into your calendar
  • Be a time pessimist
  • Prioritize
  • Be honest with yourself

Those are great ideas for the project team member working on the task. What about the project manager who has oversight? A couple of my approaches are as follows:

  • Schedule ahead - I avoid surprises by giving my staff a look-ahead report of tasks coming up in the next 2-4 weeks as well as the current week, so they are always looking at the present and the near-term future.
  • Work weekly - Don't be a micromanager. Let your team know what's due that week and on what day. If it's on the critical path, then you can show a little more due diligence in following up; otherwise, leave them alone and trust them to do the work. If the task is completed within the week it was assigned to be done, I'm not going to ask if it completed exactly on the day it was supposed to be done.
  • Public accountability - if at the end of the week, the task is incomplete and there is no good reason (or change request) to push the date back, publish the late task list (along with accountability) and share with everyone shy of CNN. I've found this to be a great motivator, as nobody wants to see his or her name associated with a late task.

Your job as a project manager is to maintain your credibility through building a culture where "late" is not acceptable... even a little late.

(Reprinted from a post at Iowabiz)

Mind Reading in Braille

LastwillandtestamentI'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.

Projectex 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.

ShrekBecause 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.

Like What You're Reading? Buy A Book

subscribe to feed

  • Click the button for the free RSS feed. (What is RSS?)

    Or get the feed in your email. Enter your email address:

    Delivered by FeedBurner

Follow Me!

Search Carpe Factum

  • Google

    carpe factum
Powered by TypePad