If It Is Not Documented, It Does Not Exist

Perspective can be a wonderful thing – the ability for two people to view the same piece of art, and have two completely different reactions is a wonderfully human trait. This ability, however, can lead to disaster in a project manager’s world. The fact that two or more people can sit in a meeting, hear the same words, but come out with completely different views on the information presented leaves a ticking bomb waiting to explode at a future time.

If this situation is left unchecked, then all people will continue with false impressions, until the difference is discovered – usually at a later point in the project.

Therefore, it is vital to document resolutions and determinations made in meetings, as well as actions agreed to. This documentation can take many forms; formal meeting minutes, formal action plans, informal email outlining the main points, informal personal meeting notes. The important point here is not the format of the documentation, but to make sure it is completed and recorded.

Develop the habit of keeping notes at meetings. Not only formal project meetings, but all meetings, discussions & side conversations. You don’t need to keep extensive recordings of who said what, but you do need to capture the most important points.

Also make it a habit to review your notes regularly. The aim here is to ensure any action items required have been followed through.

Here is the current process I use to make sure as much information as is necessary is documented:

  1. I use a pocket notebook to keep notes. At the top of each note I write the date, eg. 23May12 (I use this format so it’s clear to all what the date is – you can get stuck with different date formats being used in different countries), and a heading to give me context (eg. ABC Team Meet, where ABC is the company name).
  2. After the meeting I will type my notes into a note taking application – currently I use Evernote for this.
  3. Highlight actions – if writing formal meeting minutes, you can see how I do this here. If writing notes from an informal meeting, I highlight an action for me with a * character.
  4. Follow up the actions – so revisit every * and perform whatever activity is required. This might be to add a task to your todo list, or to send an email to a person to clarify a point or ask a question.
  5. If there are determinations that you’d like to be recorded, it can be useful to send these in an email to yourself. The thing I like about email is that it records the date/time, and is easily searchable.

Don’t ignore this important item, in fact it might be a good idea to make some quick notes for yourself right now – because if it’s not documented, it doesn’t exist <grin>.

Posted in Information | Tagged , | Leave a comment

Establish the Steering Committee

When starting a project, one of the first steps should be to identify and establish the Steering Committee.  The Steering Committee is the second most important group, next to the project team, as they own the project.

The Project Steering Committee have the following responsibilities:

  • Accountable for the overall success of project
  • Review and approve project definition documents
  • Review and approve project schedule
  • Review and approve project budget
  • Approve changes to scope, schedule or budget & resources
  • Work to resolve escalated issues in a timely manner.
  • Participate in regular project reviews with the Project Manager (Project Dashboard, Budget and Issue/Risk management)
  • Nominate alternates for meetings when necessary

To be effective the steering committee need to have representation of all effected business areas and/or external companies involved in the delivery and acceptance of the project.

When forming the Steering Committee, ensure that you gauge how the project sponsor relates to each member.  You’re initial responsibility is back to the project sponsor, but the Steering Committee has a job to do, and it is important that the sponsor allows that process to occur.  It will assist you in running meetings and facilitating issue resolution if you know the dynamics of the various Steering Committee members.

It is a good idea to write this down somewhere confidential.  Keep short notes about each member and behaviours you observe.  For example, is this person quick to make a decision, or do they need a lot of detail and background information beforehand.  Does one Steering Committee member always counter one of the others?

Each member of the steering Committee should be formally invited (usually email is a perfect mechanism for this) outlining their responsibilities (refer to list above).  Getting their acceptance at this time will assist with their buy in to problem solving should the need arise.

The overall responsibilities of each Steering Committee member are the same. However, they are also expected to represent the interests of their particular business area to the project.  Your responsibility is to deliver the project as specified by the success criteria, but the Steering Committee have the authority to change the course of the project, should they realise the outcomes are not in line with their larger responsibilities back to their business area.

The key points here are:

  • Always have a Steering Committee
  • Make sure the Steering Committee know they own the project
  • Get to know the individuals who make up the Steering Committee

 

Posted in Information, Tutorial | Tagged , , | Leave a comment

Testing in a Project Plan

I always get my project teams to create my project plans.  To keep things simple, at the early creation stage, I use a dependency based diagram process using post-it notes and arrows.

The rules are simple, every task must either come from another task, or from the start – and each task must go to another task or to the finish.  Also, no loops are allowed (otherwise you create the never ending project, every project manager’s nightmare).

 

In almost every project, I get the question of how to represent testing?  People want to create something that looks like this:  

 

…which represents a simple display of a typical development cycle.  You would stay in the development and testing loop until testing is passed, and then move on.

However, this is not good in a project plan, as it creates an infinite loop – and would make it impossible to do great activities such as critical path analysis or reasonably estimate the finish date. Continue reading

Posted in Tutorial, Uncategorized | Tagged | Leave a comment

Tools I use – Google Calendar

When deciding on a platform to utilize, I developed a check list of necessary and desirable features.  Here is the list I used for a calendar application, and how I’ve settled on Google Calendar. Continue reading

Posted in Information | Tagged , | Leave a comment

Be a Time Traveler

What are you like at travelling in time?  Never tried it?  Wish that you could?

A lot of the work a project manager does is toward the aim of travelling in time.  Forward in time, to a future point in the project, to the end of the project.  I’m specifically discussing forecasting.  Forecasting schedules, forecasting budgets, forecasting resources – these are all daily activities with the aim of answering the question “What does the world look like in the future.”
Here are some tools I use to be a time traveler: Continue reading
Posted in Information | Tagged , , | Leave a comment

Individual Communication Preferences

Some people like email. Some like face to face, or phone. Some like discussions, some like hard facts.  As a project manager, you have to communicate with everyone – which means you need to firstly pay attention to discover someone’s preferred communication method.  Then you know that if you use that method you will always get better results. Continue reading
Posted in Information | Tagged , | Leave a comment

Monday Morning Problems

“All project managers face problems on Monday mornings – good project managers are working on next Monday’s problems.”

Time is finite. Time can be the enemy. Time, once accepted, can also be a friend.

One of the three key things project managers are expected to manage is “schedule”, i.e. time. This is in itself a misnomer. Time cannot be managed, as the incoming tide cannot be halted. What you have to do as a project manager is report on how the activities are relating to the endless progression of time. Continue reading

Posted in Information | Tagged , | Leave a comment

Project Kick Off

Project kick off is where you frame the broad concepts of the project.  This is where we start communicating what the project is expected to achieve.  Consistancy in communication is vital to the success of the project, and this is true for anyone involved directly with the project, and for others within the organisation where the project is occurring.
For example, if the project is expected to implement a new process for delivering a product to the market, this message needs to be defined clearly and then repeated in all communications.  Clarity here will assist as the project moves forward, especilly for a long term project when people may lose focus, or get various projects mixed up. Continue reading
Posted in Tutorial | Tagged , , | Leave a comment

The Delegation Game

A wise old Project Manager (actually, she wasn’t that old, but she was experienced) told me the secret to great project management is to delegate, delegate & delegate.  It took me a few years to understand, but I now fully support this as being one of the keys to success.

There is a golden concept here, your job as Project Manager is to manage the project – nothing more, nothing less.  Managing, in this context, means overseeing, looking after and ensuring the outcomes of the project will be met.  There is nothing in the job description of a project manager that says they should be doing any of the tasks within the project.
Let me put that a bit more simply:  Manage the project, don’t work in the project. Continue reading
Posted in Information | Tagged , | Leave a comment

Don’t ignore the warning signs.

As a project manager a lot of your time and effort is spent reviewing what is happening in your project, creating status reports and updating various stakeholders about how things are progressing.  I expect part of these status reports have some sort of traffic light warning system to alert the reader to the current status.  eg:
  • Green, everything is on track.
  • Yellow, caution, there are issues here that may lead to something being late, over budget or less than the desired scope.
  • Red, we are definitely going to miss a deliverable date, scope item or go over budget.
The purpose of this article is to discuss how to respond to these warning signs. Continue reading
Posted in Information | Tagged , | Leave a comment