Random Acts of IT Project Management

Project Management for Information Technology

Don’t Make It Hard!

Posted by iammarchhare on 30 April 2009

It never ceases to amaze me just how complicated people can make things.  Human beings have a remarkable capacity to overcomplicate things.

Let’s take project management.  You plan it.  You do it.  You evaluate how you did.  So, what’s the problem?  Usually, the problem is that people are involved.  You not only have to manage risks and issues, but you have to be aware of the human potential for creating risks and issues independently.

A co-worker manager once remarked that managing software developers is like herding cats.  I cannot take offense at that, as I know I resemble that remark.  Cats are independent and unpredictable.  People are too.  Software engineers are sometimes even more-so.  In an effort to work out all contingencies and to be all things to all people, software developers will sometimes code in things that are too complex for what is needed.

A good PM needs to be mindful of these things and be able to cut through the noise.  Simplify, simplify, simplify.  Even doing a WBS is an exercise in breaking the complex down into simpler more manageable components.

That doesn’t mean that things don’t just plain go wrong.  In fact, I’ve noticed that things go wrong every day.  On a good day, perhaps only one thing will go wrong.

However, how your team reacts to these events can make things better or can make things a lot worse.  This is where the PM must put on their motivational hat and get the responsible party or entire team to focus.

I had a conversation earlier this week that bowled me over.  One of the people was making a big deal out of implementation.  All I could think was, “Why is he making this so hard?” and “Why is he making a big deal about this?”

Things go wrong.  We all know that things can and do go wrong during implementation.  What causes things to go wrong at implementation?  I mean big things; I mean things that go terribly wrong.

  1. Someone wasn’t doing their job.  Unfortunately, this is usually the cause.  Someone overlooked something, had a hidden agenda or otherwise had a “human moment”.  We’ve all done it (well, except hopefully the hidden agenda part).  That “someone” may be a developer, a tester, a manager or even the customer.  Yes, the customer has a job too, and it is your job as the PM to gently remind them of that if they forget, just as you would any other member of the team (including yourself!).
  2. It just plain wasn’t meant to work right, at least the first time.  It might be an act of God, nature or just plain chance.

These are both tricky.  In some environments, even the latter category can be a political nightmare.

When someone fell down on the job or even if they fell asleep at the wheel entirely, it is helpful to remind yourself of all the good the person has done throughout the project.  Go over this list at least 3 times before you have a chat with them.  If you have difficulty thinking of anything substantial they have done right during the project, at least one of you definitely has a more severe problem.

Some things just are going to happen.  Some things may be more predictable than others, and it is prudent to ask if reasonable steps were taken to mitigate such a situation.  It is unlikely you can predict a lightening strike during a rollout.  However, if all that occurred was that the power grid was knocked out, then a reasonable effort would have been to ensure servers are on backup power.  The question remaining would be if a remote PC console would be on a UPS under reasonable circumstances.

One thing about a rollout is that it is the culmination of effort up to that point.  The implementation phase is that is where the entire project will either be deemed a success or failure.  There is very little ground in the middle.  If contingencies have been planned throughout the project, it will likely be a successful implementation.  Otherwise, it could be a nightmare.  The implementation will be a culmination of not only the smaller successes along the way but also a culmination of the smaller failures made along the way.

When things go wrong during implementation, they are either from mistakes made much earlier in the process or they are things over which no one would have reasonably planned.  Implementation issues are rarely exactly that, as even the planning for implementation needs to take place before the actual event.

Advertisements

6 Responses to “Don’t Make It Hard!”

  1. Sorry about that super-awkward sentence. I fixed it up.

  2. […] Project Management Tips « Don’t Make It Hard! […]

  3. […] through the noise.  When people try to make it hard and complicated, then the PM’s job is to break things down and simplify them.  This is true when […]

  4. […] by iammarchhare on 17 June 2009 Remember that I said, “Don’t Make It Hard”?  Well, it is interesting to note a non-PM’s common sense approach to project management.  […]

  5. […] by iammarchhare on 29 June 2009 From the “Don’t Make It Hard” files: The right way and the wrong way to make things […]

  6. […] react when I give them simple answers to what they perceive to be complex questions.  They are making it hard.  What do you do when customer Z wants something, but you are working on customer A’s project?  […]

Sorry, the comment form is closed at this time.

 
%d bloggers like this: