Category Archives: Project tools

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.

Businesswomen Balancing Over Money

Project Risk or Issue?

Uh-oh. This is a show-stopper.  We can’t complete the project on time because the part that we need won’t be available for another 3 months! What will we do?

If you have managed projects for very long, you have run across a situation like this.  Is this a risk or an issue?  Does it matter?  A risk describes an uncertain event that might happen.  It is something that people are worried about.  If something has already happened that affects the project, then it is called an issue.  In the example given in the opening paragraph, we are certain that the part we need won’t be available when we need it.  This is an issue.  An example of a risk would be: “We may not be able to complete the project on time if the part we need does not arrive on time.”  In this case, we are not certain that we have a problem yet.

To be a project risk it must be something that might affect the cost, schedule, scope, or quality of the project.  If a risk will not materialize until after the project is over, then it is not a risk to the project.  It may be a risk to the program or organization, but not to the project.  The same is true of an issue.  Does it affect the things that a project manager is responsible for?  If not, then it should be handled by those responsible for the program or organizational area.

Being able to distinguish between these is one of the hardest things for project managers understand.  It causes problems because risks and issues are dealt with differently and dealing with non-project risks and issues wastes a lot of a project team’s time and energy.  The examples given so far are in the scope of the project.  Here is an example of a non-project risk:

“The system we are building is designed for 100 concurrent users, but if we get more than that it might run slow or even crash.”

If the project ends when the system is deployed, then this risk will never occur during the project.  If the requirements for the system say that it must support 100 concurrent users and it does, the it is not a project risk, it is scope creep.  The risk of actually getting more users than that and the ensuing consequences is the domain of business operations, not the project.

The source of this confusion is usually failure to distinguish between a project, a product, and a program.  A project delivers what is asked for, often a product. It does not make claims about the value or benefits of the product.  That is the domain of the program or product owner.  Sometimes the project manager, program manager, and product owner are the same person, but often they are not.

Risks are documented when they are discovered, most being at the beginning of the project.  The probability and impact are assessed and mitigation tasks are added to the project plan.  A contingency plan may be created to document what we plan to do should the risk occur.  These risks are monitored and updated as needed throughout the project.  Should they actually occur, they become issues.

Issues are problems right now that we have to do something about.  The actions that we take might involve adding tasks to the plan, extending the schedule or increasing the budget.  Issues are tracked and actions are taken until they are resolved and no longer affect the project.  These get a lot of attention in most projects.

That is the difference between risks and issues.  Handling each appropriately will communicate more effectively and make management much easier.

Businessman Stepping on Banana Peel

When Things do not go as Planned (in MS Project)

“A plan never survives contact with the enemy.”  If you are using Microsoft Project and things do not go as planned, your project has “issues”.  :) You can track these issues as tasks in the project schedule.  This allows you to easily capture the impact on schedule and costs.  This is also useful to explain the reasons for variance from the plan in a way that can be quantified.  It can also be used during the lessons learned session after the project or phase is completed discuss with the team how they could have been avoided or predicted better.  This would then lead to better planning in the future.

An issue is a problem that prevents a task from being done.  It may be related to a risk that was previously identified or it may be completely unexpected.  These come up all the time in projects, especially IT projects.  They are typically tracked in an issues log.  In the issues log the problem is stated and an action item to resolve it is described along with a due date.  The task being affected should be indicated, but often isn’t.  Each action taken to resolve it is logged until the issue is resolved.  The task being affected can then be finished unless there is another issue that prevents it (an all too common occurrence).  This usually results in schedule slippage and perhaps additional cost, which is often not captured in the issues log.

How do you do this in MS Project?  When an issue is identified, a task would be added to the project schedule.  The task description would identify it as an issue with a brief title and perhaps an identifying number from the issue log.  This issue task would then be linked to the task that can be completed using a finish-to-start or a finish-to-finish dependency.  The start date would be the date it was identified.  When is the finish date?  It depends on whether the resolution is known at the time it is identified.  If it is, you can make the finish date be the date it will be resolved.   Here is an example using the Example MS Office Project 2007 template for Security Infrastructure Improvement Plan from Microsoft Office:

MS Project example of Issue as a task 1

The pricing information needed for task 29 is not available because the contact person is not available until next week.  For this example, we are assuming that the contact person is irreplaceable for that week.  You will notice that this change has caused both the issue and the task that it is linked to become critical (red) and will delay the entire project by 3 working days.

Sometimes the resolution is not known right away. There is always a next action however.  In this case create another task as a subtask of the issue.  The start date would be the same as the issue start date, and the finish date is the due date of this action item.  If this action does not resolve the issue, it is marked as complete and the next action is added as a subtask of the issue with a finish-to-start link to the previous action item.  This continues until the issue is resolved.  The advantage of this is that you can show progress toward resolution as completed action items (tasks in MS Project) and capture the impact of each action and the entire issue accurately.  Continuing with the previous example:

MS Project Issue Task exmaple 2

Here task 43, “Solution Implementation” cannot be completed because a software module was discovered on some of the client workstations that is incompatible with the solution being implemented.  Not all client workstations are affected however so the team decided to implement the solution on those while finding a solution for the ones affected.  We have put a finish-to-finish dependency between the issue and the task affected with a lag of 3 days because the team has determined that they can implement the solution on the affected machines about 3 days after a solution to the incompatibility is implemented.  The critical path is not affected yet.

After a week of analyzing the problem, the team has found that an upgrade of the client software to version 1.2.2 will solve the problem.  It will take a week to upgrade these so we add another subtask to the issue for this.

MS Project Issue Task example 3

Now the critical path has been affected and caused a delay of 2 more working days to the project schedule.  This is why the Gantt bar for this task is now red.  It also shows that the solution implementation is 50% complete in spite of the issue, because we continued working on the unaffected workstations.

If progress is reported weekly, this will show that analysis of the problem was completed and what the impact of the problem is to the plan overall.  You can also track labor and perhaps software license costs to the issue to know the cost impact of the problem.  If root cause analysis is done, this information can be used to determine what corrective action is worthwhile.

This is just one example of how tracking issues as tasks in MS Project can help you and those you report to make better decisions.

wbs feature

Work Breakdown Structures are Useful If Done Right

A Work Breakdown Structure (WBS) is a tool used to describe the scope of a project in terms of deliverables that are broken down into pieces that are small enough to plan and work easily.  These pieces are called work packages.

It is created at the beginning of the project right after the project charter is approved and the team is assembled.  The project team creates this in a team meeting.  It is important that the people that will be actually doing the work are present.

The top level of the chart is the product that the project is to produce.  The next level is a list of all the deliverables listed in the project charter.  These are all nouns, not verbs (e.g. “database” not “convert data”).  These are primary deliverables that will exist after the project is finished, not intermediate deliverables that may not.  These deliverables must describe 100% of the product.  If any of these deliverables are broken down, the components must describe 100% of the deliverable.

As a group activity, the Project Manager (PM) would put the product and deliverables on a whiteboard or other display that the project team could all see at once.  The PM would then start at the first deliverable and ask, “What does this consist of?”  The team’s responses are then recorded.  The PM would then go to the next deliverable and ask the same question.  Some of the deliverable do not need to be broken down because they are small enough.  What is small enough?  When the work required to produce the WBS element is well-understood by the person that will have to produce it and it is clear to everyone when it is complete.  This last part is especially important.  Knowing what “done” looks like is vital to the success of the project.  Glen B. Alleman writes more about this here and here on his blog Herding Cats.

It is important to note that the WBS is not a project schedule.  It does not contain actions or phases.  This is a common mistake that drastically reduces the value of the WBS.  The Project Management Institute’s (PMI) A Guide to the Project Management Body of Knowledge, 4th ed. (PMBOK) gives a bad example of a WBS in section 5.3, figure 5.9.  It is shown below:

Glen also writes about this in his blog.  The problem with this is the System Development Life Cycle (SDLC) is imposed on the WBS.  The SDLC is a scheduling artifact, not a scope artifact.  Here is an example of a simple WBS for a Blog:
1.  Blog

1.1 Posts

1.1.1 Post Attributes (Author, Date, Content)

1.1.2 Facebook Like button

1.1.3 Tweet This button

1.1.4 Multi-Share (Facebook, Digg, Email, etc.)

1.1.5 Post Edit

1.1.6 Post Publish

1.2 Comments

1.2.1 Comment Moderation feature

1.2.2 Tracebacks

1.2.3 Author attributes (name, website)

1.2.4 Comment attributes  (Date, Content)

1.2.5 Comment Edit

1.2.6 Comment Publish

1.3 Blogroll

1.4 Header

1.5 Archives

1.5.1 List by month and year

1.5.2 Post List

1.5.3 Select Post

1.6 Pages

1.6.1 About

1.6.2 Home

1.7 Search Blog

1.8 Follow Me button

1.9 Hosting Service

1.10 Domain Name

Once the WBS is developed it can be used to estimate and track costs, identify activities in the project schedule, identify risks, and control scope.

How do you use a WBS in your organization?