« Integrity in Project Management
8 Tips for Project Success »

Keeping Track of Project Details

April 14, 2011 | Author: PM Hut | Filed under: Project Management Best Practices

Keeping Track of Project Details
By Michael Stanleigh

Dear Project Coach:

There are so many details on my project that I’m a little lost. I have to: track progress against the plan, prepare reports for my customers and sponsor, hold meetings with my team, manage change requests, assess project risks, manage various crises that always seem to arise and so on.

Oh - I am assigned specific tasks to complete on this project. I don’t know when I’ll find time to do everything. Do you think I’m just disorganized?

Signed: Overwhelmed!

Dear Overwhelmed,

You’re not alone. Many project managers feel exactly as you do. Managing a project certainly comes with its challenges. However, I do have some ideas that will help.

The project plan is always the source of detail that lets you and the team know who will do what, when they will do it, what tasks they are dependent upon, etc. All of these activities and tasks are organized below one of the key deliverables that have been included in the Scope Statement.
However, the project plan should also include a deliverable I like to call, “Project Management”. This deliverable is generic for all projects. When completed, it becomes a great example of a WBS Template. It includes all of the tasks required to complete:

  • Project team meetings
  • On-going management of the budget
  • On-going management of the schedule
  • Sponsor meetings
  • Customer meetings
  • Monitoring and controlling requirements
  • Process to manage project changes
  • Risk management process
  • Reports required, to whom and when
  • Communications required both internally and externally
  • Project close-out evaluation process

These tasks generally do not have any dependencies or inter-dependencies with other tasks in the project plan. However, when sufficiently detailed and included in the overall project plan you will know exactly when to hold your team meetings and for how long, when to complete reports and to whom, what is the process of completing a change request (when required), the on-going process of assessing risks, etc.

Whenever I do a Health Check or Project Audit on a project I always look for these tasks in the project plan. These are usually not there. I ask the project manager questions regarding their project meetings, when are reports due, etc. They usually stumble on the answers. Rather, they should be able to point to their project plan to identify when these occur and as an auditor, it should be easy for me to verify that these did take place.

You have a lot to manage. Bring control to your project by completing the project management deliverable and getting these tasks into your project plan. It is all about controlling your own time as well as the time on the project.

Signed: The Project Coach

Michael Stanleigh is the President and CEO of Business Improvement Architects. He works with executives and senior managers around the world to help them improve operational effectiveness through strategic planning, leadership development, project management and quality management. Michael has been instrumental in helping his clients reduce waste and increase efficiencies and profits with his clear processes and quality approach.
For more information about this article, please contact bia(TM) at info@bia.ca.

Share this article:
  • Facebook
  • LinkedIn
  • TwitThis

This entry was posted on Thursday, April 14th, 2011 and is filed under Project Management Best Practices. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

1 person has left a comment

Michael, Your post contains a lot of significant information. But I’m going to challenge the use of two terms you employ.

The terms “Project Plan” and “Deliverable” have specific meanings with the PM community and to use them loosely as you have introduces the potential to mislead or confuse practitioners or the public.

A “Project Plan” is a document that contains the consolidated integration mgmt, cost mgmt, schedule mgmt, personnel mgmt, vendor mgmt, scope mgmt, risk mgmt, etc. plans. You use the term “project plan” in your posting to be synonomous with “project schedule,” which is only one small part of the project plan. If you are going to refer to the project schedule specifically, you should call it that and not a project plan.

A “Deliverable” is a Work Product that requires formal approval or acceptance by a project client, sponsor, or owner. “Project Management” is not a work product and does not require formal acceptance or approval, therefore it is not a deliverable. Typically, status reports, issue logs, risk registers and meeeting minutes, work products produced by PM activities, do not require formal acceptance.

On the other hand, a Change Request is a Deliverable. It is a Work Product and it requires formal acceptance or approval.

Non-PM deliverables examples include Requirements Document, Functional Design, System Test Cases, Test Results, and Final Acceptance.

It’s one thing to give general management or industry advice, but if this is going to tagged as “Project Management Best Practices,” you have a duty of accuracy to our discipline.

All that criticism aside, if you take your post and substitute “project schedule” for every occurrence of “project plan” and “work product” for every occurrence of deliverable, this is a valuable contribution to PM practitioners.

Chuck Morton, PMP wrote on April 18, 2011 - 10:45 pm | Visit Link

feel free to leave a comment

Comment Guidelines: Basic XHTML is allowed (a href, strong, em, code). All line breaks and paragraphs are automatically generated. Off-topic or inappropriate comments will be edited or deleted. Email addresses will never be published. Keep it PG-13 people!

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

All fields marked with " * " are required.

The Stevens Enterprise Project Management Master's Program

Project Management Categories