Category Archives: Working with people

Effective Project Status Meetings

Project status meeting

One of the duties of a project manager is to find out from team members where they are at on their project tasks.  This can be done in a lot of different ways including automated or email-based solutions.  I have found that these type of solutions generally do not work very well because team members are people and progress is not just a matter of percent complete.

The method of project status reporting  between the team members and project manager that I have found to be most effective is the project status meeting.  This can be in person or on a conference call but it should include all the team members at the same time.  The team members must provide status orally in front of the team.  Why do this so publically?   For accountability and transparency.    People will be more motivated to complete their tasks on time if they know that they will have to admit any lack of progress in front of their peers.  Team members also need to know where everything is at and how their actions affect each other.  This builds teamwork and can help build trust.

What should the agenda for this meeting look like?  Assuming that you have planned start and finish dates for each task, here is one format that can be used for weekly status meetings:

  1. Accomplishments – These are the tasks completed this week that the PM knew about before the meeting.  Yay team!
  2. Are these done yet? – Tasks that are supposed to be complete by now, but have not been checked off.  If the answer is no, then the next question is “When will it be done?”  You may want to also ask what they need to complete it. There are more suggestions for this in my posts Getting the Truth and Hidden Reasons Why Things Don’t Get Done.  Beating them up about missing the planned finish date is a bad idea.
  3. Have these started yet? – Tasks that are supposed to be started, but not yet finished.  Just like the previous agenda item, if the answer is no, then the next question is “When will it start?”
  4. Are these due dates still realistic? – Tasks that are due in the near future but not yet.  This does not include tasks already listed previously.  If a due date is unrealistic, the sooner you know, the better.
  5. Are these start dates still realistic? – Tasks planned to start in the near future but not yet.
  6. Issues – Problems that are interfering with planned tasks.  This is usually a narrative description with action items that are taken to resolve it.  These are often technical in nature.
  7. Risks – Problems that might occur, but have not yet.  Lots of things might go wrong, but you should discuss the highest risks and solicit new risks.
  8. Changes – Changes to the project that have been requested or approved.  These are usually scope changes.  Discuss with the team how these changes affect the plan.  These do not usually happen weekly on most projects.

One thing this agenda does not cover are long-running tasks in progress.  It is best to avoid long tasks in the project schedule.  Tasks should not be more than twice the status report interval.  If you are reporting weekly, tasks should not be more that two weeks long.  Tasks longer than that need to be broken down unless there is an objective way to measure progress, like physical percent complete.

This agenda may look daunting to do every week, but it can take as little as 10 minutes to get through it depending on the size of the project.  The data collected from this meeting is used to update the project schedule and prepare a project status report for the project sponsors and stakeholders.

fearful resource

Fear Itself

We were gathered in the conference room and the project team was scared.  The project was six months late and the system barely ran.  They were afraid to even sneeze because it might generate another cryptic error message they had no idea how to fix.

“They want us to push this buggy mess to production!”, cried one team member.

“We will look terrible if they do that!”, exclaimed another.

“The vendor says all the bugs are fixed in the new release we just got”, I said.

“I doubt that!”, someone muttered.

“If what the vendor says is true, what are you worried about?”, I asked the team.

I had just taken over a troubled project and this was how the first meeting with the team started.  We had hired a vendor to customize a software product for us.  They were having trouble getting their product to work in our environment.  No one had ever done risk identification on the project and it showed.

By asking the team what they were worried about, I was starting the risk management process.  They responded verbally and we had some discussion.  I then gave them a form to document other things they were worried about and had them return it to me a few days later.  About a dozen risks were identified.  In the next meeting I gave everyone the consolidated list of risks and we discussed how likely they were, what the impact of them would be, and what we could do now to mitigate them.  For those few that did not have good enough mitigation, we came up with contingency plans.  I took the result and published it to the team and all the stakeholders.

The effect on the team was awesome.  Everyone calmed down and quit fretting about the project.  the team went from being paralyzed to being energetic.  We were finally able to move on with the project!

Simply going through a classic risk management exercise reduced the primary impact of the risks, which was fear.  Fear had paralyzed the team and sucked out all their energy.  Fear causes people to focus more on CYA than work.  It kills morale and reduces productivity to nothing.  Risk management reduces fear.  It is a people exercise as much as a mathematical one.

The risks themselves never materialized.  The vendor had fixed all the bugs and the system was suddenly stable.  The system was released to production a few months later and the stakeholders were happy.  The project team was proud of what they had deployed.

Have you ever seen risk management have this effect on people?  Please comment.

Social Media in the Workplace

Social Media in the Workplace

Lotus Connections by IBM was just deployed where I work.  It is a social media tool for the workplace.  While it has collaboration features like Wikis, shared files and shared activities, it also has more social features like status updates, blogs, discussions, communities and news feeds like you would find on Facebook or something similar.  While blocking access to Facebook from your desk, they deploy something like this.  It is interesting.

I can see how a tool like this would allow for public, but casual, conversations with co-workers.  This would be like a hallway conversation or group discussion between cubicles I suppose, except on the record.  I am both thrilled and terrified.  Saying something within earshot of co-workers is not the same as publishing online.  You have to choose your words carefully and not just blurt out stuff.  It’s like learning how to use email all over again.

I can see how this could improve communication between people that don’t sit near each other.  By seeing posts and status updates, your co-workers can get to know you better.  People can imagine all sorts of things about someone they don’t know very well or have never seen.  Just posting a picture on your profile can help if your organization is large or spread out geographically.  Trust between people should improve because of this.  That will result in fewer squabbles about things that don’t matter and fewer misunderstandings.  Just learning the vocabulary and jargon of other people about work issues by seeing frequent updates from them will help prevent miscommunication.  Better communication will result in better efficiency because of less wasted effort and energy as well as happier people.

I am also frightened.  Like other media, this could — and probably will — be misused.  It is important to be professional when interacting with your co-workers.  This social media gives you the opportunity to look bad to a lot of people at the same time.  It is sort of like sending broadcast emails all the time.  I have used Facebook for years and have several hundred friends there.  I have seen people post stuff that they shouldn’t because they were mad and wanted to embarrass someone else in front of their friends.  I could see it happening in the workplace too.  I also wonder if information that isn’t ready for publication will be casually posted and get to the wrong people because people are not aware of the span of a social network.  I’m not talking about trade secrets or social security numbers, but rather projected finish dates on projects or the cost of a new piece of equipment.  Just as people had to learn what is appropriate to put in email, they will also have to learn about the new workplace social media.  Some will have to learn the hard way.

There is also the barrier to adoption.  People will hesitate to use it and it is not that easy to mandate.  They will hesitate not just because they don’t like to change, but because they don’t know how it is supposed to be used.  There is not a lot of precedent yet in the workplace world for this type of media.  Being a social tool, it is much less valuable until most people use it.  I predict it will take several years before it becomes fully adopted.  I don’t think it will take off like Facebook did.

Those that can express themselves well in writing will have an advantage over those that do not.  Everyone can participate since everyone can read, but some will have a louder voice on the social media and perhaps more influence in the organization as a result.  This may change the balance of power somewhat in some organizations.

If you were to write blog post for your co-workers to read, what would it be about?  What would be your status update today for them?

From Geek to Project Manager

Hi, my name is Bruce and I am a Geek.  I am also a Project Manager.  I started out as a Geek though.  When I use this term, I am talking about a technical professional that speaks in jargon and is good at what he or she does.  Being socially awkward is not a requirement.

When a technical professional becomes very good at their job they often want more influence in the organization.  They are often trusted by management to deliver results and believed to be able to influence others to do the same.  The Geek is then made a Project Manager.  This is often a difficult transition however.  I know this not only from my own experience, but also from watching other people go through it also.  Here are some of the problems that can occur and what you can do to avoid them.

  • Treating human resources like machine resources – People are driven by emotions, not a CPU clock.  Getting them to do something you want is not always as easy as it sounds.  Ignoring emotional drivers is not effective at getting things done.  The more the PM understands about why people behave the way they do, the more effective they are going to be.
  • Failing to delegate everything – If the PM does technical project work, they become much less effective because their focus changes to solving technical problems instead of team problems.  This article discusses this further.  It is hard to let go of the technical stuff, especially when someone less experienced is doing it instead.  It is okay to mentor, but being responsible for working technical project tasks is something that should be avoided.
  • Estimating tasks for team members – An experienced technical person can often make accurate estimates on how long it would take them to do a task.  It is sometimes difficult to get an estimate from a team member or to believe the estimate.  However, if the team member does not buy into the estimate, it is not accurate and they cannot be held to it.  It is just wishful thinking and not useful for creating a project budget or schedule.
  • Telling the team how to do everything – There is a difference between mentoring and micromanaging.  A technical expert has a lot of knowledge, but a PM must respect the skills and maturity of the team.  As a PM your job is to ask the team what needs to be done and then organize that and track it.  Telling them in detail how to do everything will result in the PM doing everything.
  • Imposing a technical solution on the team – Geeks can often arrive at a technical solution alone that will work faster than a team.   If the team did not have input to the solution then they are not as motivated to implement it.  A Geek that is now a PM should get input from the team on what the solution should be so the solution will get implemented with the team’s full energy.

Is there any advantage to having a former Geek become a Project Manager?  Of course!  Here are some of them:

  • Understanding what the Geeks on their team are saying – Geeks speak in jargon that must be translated by the PM into a status report that management understands.  A PM that speaks Geek and plain language will communicate more accurately than one that does not.
  • Intuitively knowing the risks with various technologies – Risk assessment must still be done with the team’s input but a PM that was a Geek can suggest things to get the team going on this.
  • Knowing what motivates other Geeks – Things motivate Geeks that do not motivate other people.  The opportunity to work with new technology, gadgets, peer recognition, etc.  A Geek PM will know about these from their own experience.
  • Expert authority – Geek team members will respect a PM that used to be a Geek like them because they know that the PM has “earned their battle scars” so to speak in the technology arena.  This is very useful to a PM because they do not usually have direct authority over these team members.

Geeks can make the transition to Project Manager if they avoid the pitfalls listed here.

Hidden reasons why things don’t get done

People are reluctant to report a lack of progress on a task even when they don’t have everything needed to do it.  The fear is that the truth about why they didn’t get it done will not be acceptable.  I know when team members that are late on tasks start avoiding me that this is probably their fear.  Most of the time the problem that they are having with getting it done is common and correctable once it is identified.  These are still hidden, so it may take some coaxing to identify them.

Here is a list of the most common hidden reasons why tasks do not get done and what to do about them:

  • Work is not well–defined – The resource is confused by the task description but does not want to look stupid.  This could be cause by any of the following:
    • The task needs to be decomposed further and the resource assigned to the original task will only be doing part of it.
    • The task is assigned to the wrong resource.
    • Requirements for a deliverable need more elaboration.
    • The task may not need to be done at all.  It is not applicable.
  • Don’t know how to do it – This is often the case in IT where the technology changes quickly.  I am not talking about incompetence here.  One cannot get a person with 3 years experience with a tool that only came out last month.  A resource does not want to look stupid, but they may be the best person available.  Training or allowing time for the learning curve is the way this is often resolved.  Assigning the task to someone else is another alternative
  • Don’t have everything needed – There is a previously unidentified dependency on something else.  This could be another task, a tool, equipment, or specifications.  Sometimes resources just need help identifying what they need.  Simply asking them what they need and then providing it usually resolves this.
  • Higher priority work – When resources are shared they are reluctant to tell you that some other project, customer, or work effort was more important than yours.  That may be the case however.  It is important not to take it personally and escalate within the organization if needed.  If the organization deems the other work more important, then you adjust the schedule accordingly.  If not, then the resource gets corrected about today’s priorities.
  • More complex than expected – This often happens in projects.  The resource did not realize the complexity until they started doing the work.  There were constraints that they did not realize existed.  Resources may be embarrassed to admit this because it makes them look like they don’t know what they are doing.  Getting a new estimate and revising the plan is the usual remedy.
  • More volume than expected – The work is well understood, but the volume of things to be worked on is much greater than expected.  This is so common it even happened to Bob the Builder. :) This could be a case of scope creep (see below) or just underestimating.
  • Scope creep – A stakeholder asks the resource to do more than planned or the resource gold-plates their work.  Quality standards will help with the latter and encouraging honest and open communication will prevent the former.
  • Technical issues – This is very common in IT projects because the technology being used is often not very mature.  Tracking these in an issues log until they are resolved is the technique used on most projects.  Publishing this issues log lets the team and all the stakeholders know what is being done about the problem.  This is not usually hidden if the team knows there is a process for dealing with it.

Being able to identify these help you deal with them in your current projects and being able to discuss them openly with your team helps them find ways to prevent them in the future.

Getting the Truth

All tasks are being completed when planned and within budget.  There are no issues, risks have all been mitigated, and the project team members love each other and work perfectly together.  How would you like to give that status for your projects every week?  If you did, would anyone believe it?

Real projects don’t go perfectly most of the time.  They have a few warts and sometimes are downright ugly.  Our job as Project Managers is to report the truth, whatever that is, to the world.  Getting that truth from the project team is sometimes difficult though.  What follows are some tips that will help you get to that truth.

  1. Don’t shoot the messenger – During the Operation Desert Storm (the first Gulf War), there were stories being reported by the media that Saddam Hussein would shoot his Generals if they didn’t perform well.  As a result he was often not told the truth about what was really going on.  This caused him to make a lot of bad decisions.  Verbally attacking project team members that do not tell us what we want to hear has the same effect on our projects.  If you have a customer, project sponsor, or boss that is like that you may be tempted to be less than candid in your status reporting.  Don’t go over to the dark side!
  2. Document issues – When a task does not go as planned it should be documented as an issue in an issues log.  The task could be late or over budget for a lot of different reasons.  It is important to document these in an objective way that identifies the problem and what is being done about it; but does not blame team members.   This issues log should be public to build or maintain a culture of transparency.
  3. Probe estimates – The estimates of time or cost that seem too good to be true probably are.  People are often very optimistic and do not account for risks when giving estimates.  Making mistakes and having to do rework is a daily reality in the workplace that is not always taken into account.  Reminding resources about this and asking them for more detail about the task being estimated and what they need to do it usually yields more realistic estimates.
  4. Ask for clarification until you get it – Sometimes people create confusion deliberately to hide their own failures.  This can be done with technical gibberish or just disorganized rambling.  When someone you are collecting status from does this, take the time to organize what they are saying and ask them to explain until you have enough information.  This requires some patience, but stick with it until you know the truth.  There is probably something there that you need to know.