Friday, June 18, 2010

Micro Management Kills Teamwork

One of my favorite shows on television is America's Funniest Home Videos.  One of the winning videos is a little boy who is playing Director for the story of Little Bunny Foo Foo.  I was watching that again last night and thinking about how he reminded me of one of my counterparts on a project a couple of years ago.  I was the Assistant PM and he was the PM on the State side of the project.  In the State of Missouri you generally have a PM on the Consultant side and one on the State side. 

This man liked to Micro Manage his people, and his consultants.  He wanted to know every time a programmer started a new module.  He had to review every e-mail that went  out before you could send it.  When I was working on a report, he literally came into my office every five minutes for an update.  After the fifth time, when he asked "How far are you now?"  I replied, "Not as far as I would have been if you hadn't interrupted me again."  Ohhh.  That did not go well.  The final straw was when he called me into his office and informed me that I was taking four bathroom breaks per day at an average of 2.5 minutes each.  That meant that I was "wasting" 50 minutes of his time each week and that he was considering docking my hours for that time. 

That was the straw that broke the camels back for me.  Rarely do I lose my composure with a client, but I did that day.  I informed him that I was on high blood pressure medication which caused me to have frequent bathroom trips, and that if he didn't like the fact that he had to let me either use the restroom or pee in the floor of my cube, then he had better get someone else in there to fill my position.

Just like the Director who blew the whistle and expected his brother and sister to jump, this man had ridden me too hard and micromanaged me to death.  In the video clip the brother blows his whistle and expects his younger brother and sister to come running to do exactly what he wants.  Then when they don't perform to his expectations he yells at them and blames them for messing everything up.  At the end of the clip you see the Director brother sitting in a recliner, blowing his whistle, and no-one answering. 

By the end of the project this manager had done that to himself with the micromanagement of his team.  The team turnover was tremendous.  We had one programmer that came in for two days and then left for the east coast, telling the manager to kiss his nether regions.  The communications on the project became so cumbersome that they were almost non-existant.  And finally the PM and myself went to our prospective companies and told them that the project was doomed to fail and we wanted out. 

This PM on the state side wasn't the only problem the project had, but the culture of micromanagement at this agency was rampant throughout the staff and contributed to the circumstances.  Users were not consulted on the project and buy in was never acheived.  They had the project shoved down their throats, much to their dismay.  The project sponsor was a political pet who was weak and wishy washy.  Policy conflicts, Political Power Plays,  and the lack of a clear understanding of the goals made everything a moving target.  The project was started poorly, inherited by a team who came in too late to change it, and was doomed from the beginning.

What could have been done to save it?  The first step would have been for the PM to step back and let his consultants do what they were hired to do.  Work competently and efficiently without micro management.  Stop the communications killing micro management of e-mails and phone calls.  One of the most important things about being a PM is knowing when to let your people do their thing and when to reign them in.

Thursday, June 17, 2010

Communications in Projects

The most important aspect of any project is the communications within the team.  When you are working with a distributed team this becomes even more important.  Many PM's believe that you need a multimillion dollar video conferancing system to keep communications in the project going, but that is not true.  Most of us work on a shoestring budget, especially in this economy.  That means finding cheap (or free) methods of communications.  In this post I am going to review some of the tools that I have used or know of. 

Skype:  This is a free tool that features instant chat and even voice calls.  My most recent project has used Skype for communications across a distributed team to great success.  One of the best things about Skype is that you can send the message, even if the user is away, and it will be waiting for them when they log in.  We have used it not only to communicate with our remote team members, but even with the ones in the office.  This allows us to remain at our desk, with our train of thought and documents, while talking to someone in another area of the building.  In all, it streamlines our work process and speeds us up because we don't have to get up and go hunt the other person down to talk to them.

Log Me In: This is a free tool that provides a Citrix remote desktop to any computer you add to your account.  You can install Log Me In and log to your home computer to retrieve that document that you forgot at home.  You can log to a team members desktop and show them how to accomplish something they are having an issue with while they are still logged in.  You can actually control the mouse on their desktop while they watch.  It's a great troubleshooting tool.

DimDim: This is a free webinar tool that you can use.  You can use DimDim for demos, meetings, and presentations.  You can have up to 20 participants, standard audio, standard features, web cam, and standards support for free.  For 25.00 per month you can have the premium features of the set with unlimited participants.  All in all a good tool to use.

Google Docs: This is free with a Google account.  You can upload and share documents among team members without having the costly installation of SharePoint.

Google Calendar or Yahoo Calendar: Email accounts with these sites gives you a shareable calendar that you can use.  Team members can subscribe and view events and post to a common calendar.

WikiSpaces: This is a free tool that allows you to create a team wiki where members can post questions, get answers, modify flows, etc.  An excellent ongoing conversation for the whole team

There are many more options, but just these few will enrich your team work environment and give your communications a deeper significance in the project.  Make sure you have a good working relationship with your IT department and that the use of these tools is permitted.  My bet is that if it lessens their work load they will be more than happy to accomodate you in most cases.

Tuesday, June 15, 2010

Procrastination Causes Slippage

Project slippage is one of the main causes of failure.  We work so hard on planning out our project schedule, and then end up behind.  How does it happen?  Procrastination is one major cause.  If we have a project and we estimate that we are going to take two weeks to complete a task, but we know it will only take one week to do, we have a tendancy to procrastinate that first week.  Then you start the task and you hit a snag.  Someone gets sick, or a resource is on vacation.  Then you fall behind schedule.  This impacts everything else down the line.  Before you know it, your project has slipped.

Fighting procrastination is exceedingly important in project management.  Especially during the first portion of a long project.  If you start slipping at the beginning, everything else is affected and the problem just compiles.  By the end of a six month project you are three weeks late because of your one week of procrastination.

So how do we fight it?  We all know that we are going to procrastinate to some extent.  We know that we are going to run into sick developers, vacation times, missing resources, and the unexpected. (Like wild unicorns running down the aisles.)  So we need to plan for those items.  If it is a small project and I am VERY confident of the time line, I will estimate 25% of the tasks will be late, 50% will be on time, and 25% of the tasks will be early.  Then I will add a 10% buffer for the unicorns.

If it is a long project, spread over several years, I will break the project into years and estimate time for each year.  For the first year I will estimate 30% of the tasks will be late, 50% will be on time, and 20% will be early.  Then I will add in 10% for zombie attacks.  For the second year I will estimate 40% of the tasks will be late, 40% will be on time, and 20% will be early.  Then I will add 10% as a buffer for water buffalo stampedes.  For every year after that, I will estimate 50% of the tasks will be late, 40% of the tasks will be on time, and 10% will be early.  Then add a 10% buffer for sea monsters.

This formula has worked for me over the past 15 years and I don't really see any reason to change it.  Of course, as time goes out, it could change.  I haven't been on any projects that take more than 3 year to implement, so that is unknown territory.  There lies dragons.

And just what are the unicorns, zombies, sea monsters, and dragons?  They are equipment malfunctions, staff shortages, people leaving and coming onto the project at unexpected times.  Vacations will overlap.  Budgets will get cut.  Babies will come along, and marriages will happen.  All of these things are the unknown critters that affect project slippage and eat up that 10% buffer that we build in.  The longer your project goes on, the more critters you encounter.  So don't forget to give the critters their due.  Your projects will be more accurate and timely if you do.


Blog Directory

Globe of Blogs

As Featured On EzineArticles