Project Perfect - Project Management

Milestones and Tasks in Gantt Charts

In reviewing a project recently, I came across a problem that seems to keep reoccurring in many Gantt charts. When a project plan is being produced, it should consist of two types of activities.

- Tasks are things you have to do and should start with a verb. Produce report; Recruit staff; Test prototype.
- Milestones are definable points in the project where something is delivered. Report complete; Staff joined the project; Prototype testing concluded. It might sound like repeating a task, but it is not. It is a description of the outcome of the task(s).

The reason for having milestones is to track progress. It is the railway line approach to knowing where you are. If you are travelling from "A" to "Z" in a train, you don't want to get to "Z" and then find you are late. You should know that if you go through "B" on time, and "C" on time you are on track to get to "Z" on time. If you know you are late at "C" you have a chance to take action to catch up.

In order to reach milestones, you need to undertake tasks. Only when all the relevant tasks are completed will the milestone be reached. Using the same analogy, if you leave "A", the driver closes the train doors (a task), accelerates the train (a task), slows for a curve (a task), etc.

The reason for not tracking by task is that tasks seem to get 90% finished, and then stagnate. How people calculate the percentage completed is arbitrary. Sometimes it is the easy 90%, and the hard 10% takes all the time. At least if you focus on tracking deliverables, you can see clearly if you have reached a milestone. The deliverable is either finished, or not finished.

How far apart should milestones be? As a general rule, I suggest somewhere between one week and two weeks. If it gets out to a month, it is a long time between railway stations and not knowing if you are ahead of, or behind schedule. If you can't find a milestone for a month, try breaking the deliverable down. For example if the deliverable is a feasibility report which will take a month to put together, think about milestones such as "Gathering all technical input" or "Preparing report tables".

When preparing a Gantt chart, make sure that you put in plenty of milestones. Also make sure you clearly state (using verbs) what tasks are required to reach the milestone. You will find a plan based on this approach will help keep everyone focused on tracking to schedule.

Project Management "Why"

As Project Managers, we tend to focus on the "what", "how", "who" and "when".

- What needs to be done?
- How will we do it?
- Who will do it?
- When does it have to be done by?

Unfortunately we often forget to ask why.

"Why" has two dimensions - past and future. The reason we are doing the project needs to be understood by first understanding what has happened to cause the project to come into existance. It is related to the business problem behind the project. It is related to the needs driving the project. Understanding the background is half the answer.

The other half is the future. You need to understand the objectives of the project. You need to understand what it is trying to achieve. Most importantly you need to understand the outcome. The outcome can be described as how will the organisation be different when the project is successfully completed?

Many project managers prepare a project charter, or project plan and pay lip service to things like objectives and business problems. They don't really see the importance of not only understanding these components, but getting agreement from the key stakeholders that they have the same understanding. Unless that understanding is there, the project risks delivering the right solution to the wrong problem.

This thinking goes down to the micro level, which is what prompted this post. Recently I had a discussion regarding a presentation that I was asked to make to a large group of people from an organisation. There seemed a number of ways in which the topic could be presented, and we were debating what information to include, and what to exclude. After a period of time, it occured to me that we were focusing on the "what" and the "how" rather than the "why".

I changed focus and started talking about why the presentation was taking place. It quickly became clear that the purpose of the presentation was to alert people to a particular situation in the organisation, and gain their support in addressing certain aspects of that solution. Once this was understood, it made it easy to determine what should be covered in the presentation. Once the desired outcome was identified, it was easier to understand what we needed to do to get there.

As project managers, if you seem to be going around in circles with a particular situation, ask yourself if you understand the "why". Even better, ask those involved in the discussion to stop focusing on the "what" and "how" and articulate "why".

For more information see a white paper called "Vision, Business Problem, Outcome, Objectives & all that stuff...." at http://www.projectperfect.com.au/info_vision.php

Project Steering Committee

The role of a project steering committee is always difficult to sort out. Some become involved in the trivia of a project and some are so removed, you wonder why they exist. If a project has a sponsor, how do they relate to the project manager and where does the project manager escalate issues - steering committee or sponsor? In many cases, a steering committee is just a dilution of responsiblity.

If you are asked to work with a steering commitee, here are some possible authorities and accountabilities that a steering committee may be given. It will depend on how remote the sponsor is from the project.

- Ensure the project manager is keeping the sponsor advised of any changes to time or cost. In particular, monitor completion of milestones and significant changes to the plan.

- Ensure all project governance activities are being undertaken

- Approve scope changes up to a certain level (dollars and days). Escalate to the sponsor changes above that level with a recommendation.

- Recommend to the sponsor the project proceed or not proceed at go/no go checkpoints (after discussion with the project team)

- Through its representation, ensure cross divisional support. This implies senior management (probably GM level) participation on the steering committee.

- Meet within 24 hours if requested by the project manager, to address issues being escalated by the project team. If the steering committee is not able to resolve the issue immediately, it should be escalated to the sponsor within 24 hours.

As a project manager you can fight a steering committee, or turn it into a tool to help you manage a project. The key is to define their responsibility.

New release of Project Management Software

Project Perfect is proud to announce the release of Project Administrator version 3.3. Project Administrator assists project managers to manage issues, risks, action items, scope, documents, budgets, timesheets and more. The latest release adds change control to the functions available to a project manager.

"We have a philosophy of letting our customers decide what developments they would like to see for the software." said Neville Turbit - a director of Project Perfect. "There are many refinements in the new release including new reports, and easier data entry. One suggestion we were happy to take up was to include an area to track changes on a project. You can use this function to manage proposals through approval and allocation to a person for implementation."

For more information see www.projectperfect.com.au/pa.htm