Gantt Chart Love

In this series of posts, I share what I’m learning as I make my way through Project Management Simplified, a Lynda.com course with management consultant, Chris Croft.

Step 6 of Croft’s The Twelve Steps to Manage a Project Successfully is to draw the Gantt (bar) chart for the project.

Croft begins by saying why he loves Gantt charts.

  1. They are the best way to show your project plan to other people, including getting people to commit to your plan.
  2. You can use them to forecast when the busy periods are going to be. You can see if you are going to have several tasks all hitting you at the same time or not.
  3. Monitor progress. (Croft’s pick for the most ) You try to keep up with the now line.

Croft really loves Gantt charts. He takes 8 minutes to illustrate how to draw a Gantt chart. (He also has a separate one-hour-and-seventeen-minute course, Learning Gantt Charts.) But I thought I would spare you that and just share the video, How to draw a Gantt Chart in less than a minute by SA Project Management in South Africa (see below).

I also found this Gantt Project Planner Template on Excel, for your Gantt chart pleasure. Get in touch if you need any help figuring out how to use it.

There are a few key points you need to know besides the basics of how to draw the Gantt Chart:

  1. Draw the critical path (the flow of tasks that will take the longest amount of time) first. All the rest of the tasks will need to take place within this time frame, so it makes sense to put this one in first.
  2. Then add in floater tasks (tasks that fit in somewhere simultaneous to the critical path). Sometimes you will put in floating tasks that are dependent on each other. For example, hiring of a program manager may come before the recruitment of a focus group, because the program manager is going to be involved in the recruitment. These tasks that are linked in some way are described as “sharing a float.”

Do you love Gantt charts? Even if you don’t love them, do you use them? Share your thoughts in the comments below.

Advertisements

Estimating Costs & Time

In this series of posts, I share what I’m learning as I make my way through Project Management Simplified, a Lynda.com course with management consultant, Chris Croft.

Step 3 of Croft’s The Twelve Steps to Manage a Project Successfully is to estimate times and costs for each task.

Croft discusses the dangers of estimating based on the average time it takes to do a task or the average amount something will cost. (The average is represented by the line down the center of the featured image for this post.) If you do that, you will have a 50% failure rate. Instead he recommends estimating based on 150% if the average time or cost. (This amount is represented roughly by the light blue bar on the right side of the featured image graph.)  If you do that, Croft believes that will bring your failure rate down to 10% and may help buffer against unforeseen tasks and work slowdowns.

How do you estimate time for your projects? Share your thoughts in the comments below.

Don’t Say “Ongoing”

In this series of posts, I share what I’m learning as I make my way through Project Management Simplified, a Lynda.com course with management consultant, Chris Croft.

Croft warns against saying “the O word” in reference to a task’s timeline. If you say a task is ongoing, you are essentially saying you don’t know when a task is going to end. Perhaps the task will start on the first day of the project and end on the last day, but it will not go on indefinitely.

The fact that you feel tempted to say the task is ongoing may be a sign that you don’t have sufficient granularity. You need to break the task down into smaller subtasks.

In your projects, are you currently thinking of any of them as “ongoing”? Would breaking them down into smaller sub-tasks allow you to give them more concrete start and end dates? Share your thoughts in the comments below.

List Tasks

In this series of posts, I share what I’m learning as I make my way through Project Management Simplified, a Lynda.com course with management consultant, Chris Croft.

Step 2 of Croft’s The Twelve Steps to Manage a Project Successfully is to list the tasks associated with the project. David Allen, the author of Getting Things Done: The Art of Stress-Free Productivity, defines a project as any outcome that takes more than one step to accomplish. But Croft lists examples such as “hire manager” or “purchase furniture” that certainly take more than one step. Really, he is talking about sub-projects.

Croft reviews three ways to list these sub-projects: right brain, left brain, and someone else’s brain.

  1. Right Brain: Host a brainstorm party with your team. Set up an environment where people are explicitly encouraged to come up with lots of zany ideas. Aim for quantity over quality.
  2. Left Brain: Take the relevant ideas and put them into an tree-diagram known as a work breakdown structure (WBS). For example if the project is a conference, your categories might be participant recruitment, presenters, site, etc. You can start doing it with paper and pen, but eventually you will want to share your WBS with someone else. I think PowerPoint is good software for creating this kind of document and I used it to create an Idea Tree Template that you can download.
  3. Someone Else’s Brain: Take your new fancy, schmancy WBS to knowledgeable people and ask for their feedback and ask them what is missing. You can also research topics you’re not familiar with and try to determine if you’ve missed anything.

Croft discusses the problem of “granularity.” How detailed should your list be? If your categories are too broad, it will be impossible to determine the costs. But if you get too detailed it becomes unworkable.

Croft’s rule-of-thumb is to break tasks down until they take no more than a week. He suggests that any longer than that makes it hard to hold people accountable—if a task is scheduled for a month, you might not know until the end of the month that the work isn’t getting done.

How do you identify the tasks required for a project? Share your process in the comments below.

Writing Up the Project Definition

In this series of posts, I share what I’m learning as I make my way through Project Management Simplified, a Lynda.com course with management consultant, Chris Croft.

Step 1 of Croft’s The Twelve Steps to Manage a Project Successfully is to agree to the success criteria and major constraints in writing.

For clear communication between the Project Manager (PM) and the client or boss, it’s important to write down the project definition. Depending on the nature of the project, it doesn’t necessarily need to be a signed contract, but at least an email saying this is what we agreed to.

A written project definition has the following benefits:

  • It prevents scope creep during the project
  • At project completion, it is a useful yardstick for measuring the success or failure of the project

Sometimes people want to leave it unwritten so they have some wiggle room. But it can lead to confusion because multiple people will make different assumptions about what was actually agreed to.

The written project definition allows all parties to look at what is proposed and say “yes” or “no,” rather than “I’ll try to get it done.” or “I have reservations about this project, but I’ll put off judging whether this is how we should proceed.”

It also allows future people coming in to the project to have a clear picture of what the project is all about and how it will be accomplished.

Croft encourages everyone to think about the projects we are in the middle of ask if we have everything nailed down in writing. He encourages us to write an email about existing projects to confirm there is shared understanding of where we are and where we are going.

Thinking about the projects you are in the middle of, is there an email you can write now that would help clarify expectations? Write about it in the comments below.

Lynda’s No-Brainer Chapter Quiz Results

Here’s the knowledge I demonstrated in Lynda’s chapter quiz:

  • PMs should not promise their bosses and clients the moon. You won’t be able to do every project cheaply, quickly, and perfectly.
  • Every project will involve quality (deliverables), cost (budget), and time (deadlines).
  • The purpose of a kick-off meeting is to discover what stakeholders are looking for and envisioning.
  • The risks of only having a verbal agreement on the project definition are:
    • Scope creep
    • Disagreement on deliverables
    • New project workers or stakeholders in the future don’t understand the project

Planning Your Kick-off Meetings

In this series of posts, I share what I’m learning as I make my way through Project Management Simplified, a Lynda.com course with management consultant, Chris Croft.

Step 1 of Croft’s The Twelve Steps to Manage a Project Successfully is to agree to the success criteria and major constraints with the customer, in writing.

Croft recommends Project Managers (PMs) facilitate two meetings with the project stakeholders to come to this agreement. Many projects will have multiple stakeholders involved, each with their own vision of the project. It’s important that the PM and the stakeholders come to an explicit, detailed agreement about what they want from the project.

In facilitating meetings, I like to think about Desired Outcomes. Meetings are a process to get from point A to point B, so meetings should ideally state their desired outcomes up front.

As Croft describes it, the Desired Outcome of the first meeting is to reach a shared understanding of the broad outlines of the project. As he puts it, “OK, guys. This is the plan I’ve come up with. What do you think?”

Once there is agreement on the basic idea, he recommends the PM then work their way through steps 2-8 of his 12-step process:

  1. Define the project
  2. List the tasks
  3. Estimate times and costs for each task
  4. Add up time and cost
  5. Shorten your project plan
  6. Draw a Gantt chart
  7. Calculate resource requirements over time
  8. Assess risks and prepare action plans
  9. Monitor progress
  10. Monitor cost
  11. Reschedule
  12. Review: learn and praise

The PM then brings this work back to the second meeting, perhaps even offering two different versions of the plan.

The Desired Outcomes for the second meeting are to:

  1. choose a plan among the options offered
  2. document ideas on how to improve the plan
  3. secure agreement to pursue the plan as amended.

In my experience, groups often get stuck when they ask themselves “Are we all in complete agreement about this plan?” It’s too high a bar for a group of people with diverse perspectives to reach complete agreement on anything.

Rather I pose questions such as “Would anyone object if we move forward with this plan as proposed?” If there are objections, you solve for them if at all possible. Then you ask the question again until you reach a plan that everyone can live with, even if it’s not their first choice about how to proceed.

How do you reach consensus in meetings? Share thoughts in the comments below.

 

Olympics vs. Nuclear Power Reactors

In this series of posts, I share what I’m learning as I make my way through Project Management Simplified, a Lynda.com course with management consultant, Chris Croft.

Croft describes the three drivers of projects:

  • Cost
  • Quality
  • Time

It’s important for a project manger to identify which of these is the key driver.

Croft gives the examples of the Olympics and the construction of a nuclear power reactor.

The key element for the Olympics is time. The event will take place on a particular day no matter what, even if the cost goes up or the quality goes down.

With the construction of a nuclear power reactor, the key element should be quality; even if it takes 2 more years to get it right, the quality has to be the driver of the project.

But in many projects, it may be hard to know which is most important, so Croft suggests using “Three Cunning Questions” in conversations with clients (or bosses) about project priorities:

  1. Why? Why does it need to be done on that date? Or: Why have you set the budget for that amount?
  2. What if? For example: What if we can’t get it done by that date?
  3. Can we trade? You could suggest to the client that if we spent more, we could put in some nicer features. Or you could say, “We can do it in that timeline but it would mean that we wouldn’t have time to accomplish everything you are asking for. Which would you prefer?”

Have you had conversations like these, either as client, employer, or project manager? Share your experiences in the comments below.