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.

Can Project Management be Agile?

I am surprised by all the different viewpoints I have seen since I posted Does Agile Project Management Exist? There are those who say that Agile Project Management is an oxymoron.  There are those that say it is simply management of Agile software development projects.  There are still others that consider it a philosophy or set of values, but not a methodology!  Please understand that I am not an Agile-hater.  My projects these days are mostly IT infrastructure.  I was a software developer for many years  and a project manager of software development projects.  I am not clinging to Waterfall or the “old ways” of doing development.  I just think Agile has been over-hyped and everyone has an Agile something if they are in IT.  Now project management can be Agile; or so it would seem.

Let’s start with the PMBoK definition of project management: “…is the application of knowledge, skills, tools, and techniques to project activities to meet the project requirements…”

This is a broad definition that goes way beyond Waterfall vs. Scrum.

Here is the manifesto from agilemanifesto.org:

Manifesto for Agile Software Development

We are uncovering better ways of developing software by doing it and helping others do it.

Through this work we have come to value:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

Notice that this is specifically directed at software development, not project management.  Software development can be done outside the bounds of a project and not all projects are software development.

The only thing that might be seen as conflicting with project management is the statement “Responding to change over following a plan.”  Even this is accommodated by change control.  Some might say that this is saying that change should not be controlled.  I have seen many systems fail because of uncontrolled change, so I don’t think this is what was meant.  Being too rigid and preventing change at all costs is a bad idea.  This may be practiced in some places, but not many.  It is not something that is considered “good practice” by the PMBoK or related standards.

What this manifesto describes sounds a lot like what we did a long time ago, before projects were managed.  There were a lot of problems with this, but that is a topic for another post.

Here are the twelve principles (my comments in red):

Principles behind the Agile Manifesto

We follow these principles:

  • Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

Good idea for software.  Can this be applied to a tangible product?

  • Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

This works for software, but does it work for tangible products like a bridge or even a house?

  • Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

Incremental and iterative software development was done before this manifesto was written and since.  Still trying to see how it would apply to a tangible product.

  • Business people and developers must work together daily throughout the project.

That is ideal if you can get the business people to do it.  Not a conflict with any existing PM principle that I know of.

  • Build projects around motivated individuals.

That is ideal if you can get them.  Most PMs I have ever known would love this and try to get it.  No one says, “Give me some apathetic resources and we will get this project done!”  It is hard to maintain high morale in an economic climate where you can lose your job any day.  This principle does not tell us anything new.

  • Give them the environment and support they need, and trust them to get the job done.

If you have a competent and mature team this works great!  I always try this until I find out that they do not have the skills or experience needed to get the job done.  This is not often a problem.  This is what I would call a general management principle, not even a PM principle.  It has been done this way for at least the last 10 years in the organizations I have worked at.  None of them claimed to be Agile.

  • The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

This is very true and is understood by every project manager I have met.  This is the reason for meetings that project teams often dislike.  Sometimes it is not possible however because of geography or people moving on to other jobs or projects.  Some documentation is also needed to retain knowledge.

  • Working software is the primary measure of progress.

This is a way of quantifying physical percent complete.  This has been used in many projects with tangible results like construction for a long time.  Measuring software is trickier though, so work percent complete or schedule percent complete is often substituted on software development projects.

  • Agile processes promote sustainable development.

Agile has processes?  This is not what some of its advocates say.  I believe that this relates to the next principle.

  • The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

This is where Agile Software Development ceases to become a project.  A project must have a beginning and definite end and is a temporary endeavor by definition.  None of the customers I have met in my career would agree to this at the beginning.  It may wind up that way in effect, but usually not without pain.  This is the only principle that is incompatible with project management.  Software development becomes a business operation, not a project, when this is done.

  • Continuous attention to technical excellence and good design enhances agility.

This is a good software development and engineering principle.  It does not conflict with PM, but is not a PM principle.

  • Simplicity–the art of maximizing the amount of work not done–is essential.

The KISS principle of engineering right?  No one wants to do unnecessary work, and PMs don’t want that either.

  • The best architectures, requirements, and designs emerge from self-organizing teams.

This is often true in software development.  Sometimes the self-organization is painful however.

  • At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

This is done at the end of the project or between phases on most projects.

Pasted from <http://agilemanifesto.org/principles.html>

My point here is that there is nothing new to project management here but there are a few things new to software development management.

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.

Agile

Does Agile Project Management Exist?

I have been reading a lot about something called “Agile Project Management.”

Agile project management is very popular for something that doesn’t exist.  Agile is a software development methodology and not a project management method.  It is often contrasted with the Waterfall model of software development, which is also not a project management method.  It is about doing incremental development with a co-located team of developers and a customer.  The development is also ongoing and the product is constantly changing and probably requires a dedicated team.

It is obvious that project management covers more than just software development or even the broader field of Information Technology.  I don’t think I would want to drive across a bridge that was built using “Agile PM.”   :)

I also don’t think Agile Software Development is appropriate for all software development efforts. What about software that goes into devices that cannot be updated easily? Sure, the Mars Rover can get a software update, but it takes a long time and you can’t replace it if a bug causes it to wind up in a ditch. How many people really update the BIOS in their PCs after they get them? There are a lot of corporate software systems that are large and complex that would not be good candidates for Agile software development. This is because they are so pathologically coupled that a small change in one system can have a lot of repercussions if it is not thought through and vetted with a lot of people.

Does this mean that Agile is not a good software development method? No. Agile did great in commercializing the web and is still valuable in that environment and perhaps others. It just isn’t appropriate for everything. Just because it is the hot new thing, does not mean it applies everywhere.

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?

The Myths of Innovation

There is a new book that came out in paperback today called The Myths of Innovation. It is about the process of innovation and how to overcome barriers to it. The author, Scott Berkun, is a creative person judging from his blog. You can preview it here. I read this and was intrigued enough that I will be getting a copy of it.

What does this have to do with project management? Project managers are often tasked with implementing innovative ideas. It also necessary to be innovative to solve problems encountered in projects. One idea discussed in this book is that innovation is a product of courage more than intelligence. In reflecting on this, I realize that I have been limiting myself by not taking more risks. There are a lot of other neat concepts like this in the book. Order yours by clicking the picture below:

The Myths of Innovation

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.

IT Project Manager

What Does it Take to be an IT Project Manager?

There has been a lot of debate on LinkedIn.com about what an Information Technology (IT) Project Manager (PM) is supposed to do.   It is fascinating because there are so many different views on this.  It is up to almost 900 posts at the time of this writing!  There has been around 400 unique contributors to this discussion, so it has really brought everyone out of the woodwork.

What are the duties of an IT Project Manager?  What qualifications are needed?  Can a non-IT PM manage IT projects?  There is a wide variety of responses as you might expect.  Here is the spectrum:

  • IT PM must be the technical expert with some experience on projects
  • IT PM must have been a technical expert once and has been trained as a PM
  • IT PM must be familiar with the technical area, have technical experts on team, and experience as PM
  • IT PM must have some experience in IT,  have technical experts on the team, and experience as PM
  • IT PM should have some experience in IT,  have technical experts on the team, and experience as PM
  • IT PM must be experienced in PM  with technical lead on the team.  Exposure to IT would be helpful.
  • IT PM must be experienced in PM. No other qualifications needed.

I wrote about whether a project manager has to have technical skills a while back, not knowing how widespread this controversy was.  Which one is correct?  It depends on where you work.

Why such a diversity of opinion about this?  Hasn’t the Project Management Institute (PMI) laid to rest what a project manager is supposed to do?  The problem with any standard is that the broader it is, the less specific it becomes.  The PMI’s A Guide to the Project Management Body Of Knowledge (PMBOK) is very broad when it describes project management.  The position of project manager has come about in many organizations without PMI’s input.  Project management itself is thousands of years old(e.g. the Great Pyramids).  The rush to get Project Management Professional (PMP) certified seems to have happened mostly in the last decade.  The result is that project management has grown up differently in different industries and organizations.  PMI’s standards are compiled from common practices across these industries.

What do project managers do in your organization that is not described in the PMBOK?  Do they write code?  Do they troubleshoot technical issues?  Do they design a technical solution?  What about people issues?  Do they mediate conflicts between team members?  Do they investigate why a team member isn’t performing well?  Do they do any team building activities?  Please leave a comment here!

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?

Project Management tips and techniques