Project Management Central

Please login or join to subscribe to this thread

How much details do a project manager have to keep about a project schedule ?
Network:1151



In most times, or in common cases, does a project manager have to maintain each and every detail about a project schedule, or is there is a minimum level of details which is accepted and do the job ?
Sort By:
Network:129401



I am not too sure I understood your question fully so Id appreciate it if you could ellaborate a little bit. Maintain the project schedule details for what ? You mean Lessons Learned ?
Network:1151



Thanx a lot for your prompt response Rami. What i really want to know is the following:
A project schedule mostly have ten's of attributes (activities times, resources, measurable values such as variances...etc) and much more....
Is there is a set of attributes that is commonly known to be considered enough to handle a project schedule fairly?
For example, most of the firms i have worked with, are always concerned with mostly 2 to 4 KPI's (time and cost mainly) and that's it for them, they don't care or pay attention to other schedule data or details which has been set by the project management "science" itself, for example, in many cases no body is paying attention to the lessons learned...
So.. whats the deal ? for example, do i really need to master all schedule compression techniques ? do i have to always to do things by the book ? or is there is an internationally trended practice or best practice that i have to worry about ?
is there is something common or it varies from one project to another ?

sorry for being long and wordy :), thanx though..
...
1 reply by Rami Kaibni
Feb 20, 2017 12:03 PM
Rami Kaibni
...
Hi Abdulrahman,

This is an important point that you brought up. It doesn't hurt to be aware of all attributes but you can include what you feel is most important for your project. You have the whole big picture and framework then you can tailor it and include / exclude what you believe best serves your project.
Network:20161



Book is consists of 'Best practices' , implementing the all attributes will formulate best results. depending the situations. lets say if you master the 'schedule compression' then if your project comes to a situation when 'schedule compression' is necessary, they you will benefit of it. but if you mastered the 'schedule compression' and any situation doesn't occurs where it is required then, here you might not get use of it. The ' lessons learned' will always be useful in future projects.
Network:2431



You bring up a common point. There is so much to know for the tools we use, but many of the functions are used so infrequently, you have to look it up to remind yourself of how.

I don't think that is very uncommon. You learn the functions required (which seems to be your point) but have a sense, or have practiced, some of the other, more advanced features.
Network:129401



Feb 20, 2017 4:47 AM
Replying to Abdulrahman Abuhayah
...
Thanx a lot for your prompt response Rami. What i really want to know is the following:
A project schedule mostly have ten's of attributes (activities times, resources, measurable values such as variances...etc) and much more....
Is there is a set of attributes that is commonly known to be considered enough to handle a project schedule fairly?
For example, most of the firms i have worked with, are always concerned with mostly 2 to 4 KPI's (time and cost mainly) and that's it for them, they don't care or pay attention to other schedule data or details which has been set by the project management "science" itself, for example, in many cases no body is paying attention to the lessons learned...
So.. whats the deal ? for example, do i really need to master all schedule compression techniques ? do i have to always to do things by the book ? or is there is an internationally trended practice or best practice that i have to worry about ?
is there is something common or it varies from one project to another ?

sorry for being long and wordy :), thanx though..
Hi Abdulrahman,

This is an important point that you brought up. It doesn't hurt to be aware of all attributes but you can include what you feel is most important for your project. You have the whole big picture and framework then you can tailor it and include / exclude what you believe best serves your project.
Network:28



Hi Abdul,
Monitoring and keeping tab over project schedule is one of the important tasks of project management and project timeline is a common parameter which the management looks forward to.Although the basic parameters to start with are task duration, resources mapped to tasks, the relationship between tasks, however, it is purely on the scenario that which all key parameters you feel cover your requirement at that stage. Also, all everything written in the books will not be applicable at all times. However, having an understanding of all areas will definitely help you.
Network:1937



At work package level. Usually it will be summary tasks in most of the software tools.
Network:566



Abdul - I've spent a lot of time over the years discussing the issue of "planning granularity" with clients and stakeholders, which I think gets at the heart of your question. The answer is unfortunately not a simple one in that there are multiple dimensions that must be satisfied.

Dimension 1 - Sponsor
This is usually a collapsed view of the plan showing high level milestones or deliverables. If the project and team are small enough, this may be all that's required.

Dimension 2 - Stakeholder
Tasks or activities in this area must be at a level of granularity that allows both the PM and stakeholders to measure progress, but not be so granular that they create administrative challenges for maintenance. Sergio's 'work package level' falls into this dimension. For this dimension to work to your benefit, you must feel confident that the plan represents an adequate model of dependencies such that changes or scenario planning can be easily accommodated.

Dimension 3 - PM
This is the trickiest dimension because it is here that things fall through the cracks. It covers all the ad hoc, 'watercooler' agreements and promises that are made during the course of any project, as well as items that may be recorded in risk or issue logs. Typically these items are too granular to be appropriate for a formal plan, yet are crucial for the project to succeed.
Network:1151



Thank You all a lot, your feedback's are appreciated

Please login or join to reply

Content ID:
ADVERTISEMENTS

"Wagner's music is better than it sounds."

- Mark Twain

ADVERTISEMENT

Sponsors