Project

Jack,

I was in a meeting today where the discussion revolved around "what does the project manager do?"

A concept we use a lot is that there is a difference between scheduling and planning. It is in the planning domain where trust becomes more important. In the scheduling domain, the mechanical aspects of making, updating, measuring and maintaining the scehdule become more important.

I'd suggest that PMBOK is about scheduling not planning and therefore is missing the aspects of PM that you mention.

If you mean "most valuable tool" in the sense the "last tool to relinquish when we have to cut costs" ... I think trust essential and should be nutured and protected absolutely. That being said, there is a long list of other tools absolutely required that without, even with trust, project won't progress. So the concept of a debate about "most valuable" doesn't mean much to me. Sort of like the awards to "non participants" at the end of a project.

Jack,

It's interesting in our domain where security clearances are required and displayed on your badge, that "trust" is a seemingly non-issue.

Where someone says they'll do something, or when they make a statement about a situation, I can't rememeber the thought ever entering my mind "gee this guy is blowing smoke," or "I'm not sure I can trust that this will happen."

There are of course the counter-examples - of not delivering - but those people usually don't last long in any position of importance.

One of my teachers used to say a fool with a tool is still a fool. So I agree that the key tool is not MS Project or any other SW package for that matter.

The 3 key tools in project management in my opinion are,

Scope Statement (including a list of key milestones)
Work BreakDown Structure (WBS)
Statement of Work (SOW)

I think a project without those three is destined to failure.

The PMBOK is only a standard that defines a methodology, there are others out there such as PRINCE for example.

Ayman

There would not be a project anywhere which did not rely on people doing what is required of them in the time frame needed. MS Project, Artemis, projectview are mere tools to help manage the project and identify likely and actual points which are critical to meeting the end date.

BUT assigning a task to the wrong person cannot be recitified using project planning tools. Communication is fundamental to a project, if the scope, and outcomes are not properly documented and communicated to each person in the project team, no matter how much you can trust them, the project will have problems.

Once the right people have been selected/assigned to the project and they have been properly briefed on what the project is about, what the deadlines are and how they fit into the success of the project, then trust becomes important. After that everything is about management of the project. This is the part that uses the tools to see if the project is on track or if some remdial actions are required.

So often I have seen people trying to use the tool as the 'bible' for the project, it is but a guide and monitoring tool from which management decisions can be made with better certainty of outcome.

In summary:

First identify the project Scope
Second select the right people
Third communicate roles, responsibilities and outcomes to the project team
Fourth delegate properly, give them the control to do their job.
Fifth monitor and manage and use a planning tool to help in the monitoring and management process

Trust is only one of the tools necessary for Project Mangement. My experience has taught me to know the capabilities of my staff so I will know how much to trust them. I have had managers whose budget inputs I always doubled because i could trust that he always bid about half of what he would really need to do a job. I also had some that I could trust to put in fat budgets. I know about what percentage to take out of their budgets through experience with them. KNOW YOUR PEOPLE'S CAPABILITIES. This is where my trust of them to perform comes from.

I have used MS Project, Artemis and Primavera. These are good tools (and there are others, as well), but the results of using them is no better than the capability or honesty of the personnel preparing their task time estimates prior to insertion into these automated analysis toos. It is the same with WBS structures and the cost/schedule/progress analysis tools available for PM use.

CFH

Communication strikes me as the most valuable project management tool.

Tasks are done by people and teams, results are reported to management, deliverables given to end-users. All of these events revolve around people and take place in a context set by expectations. These expectations are set or defined by the information conveyed to the people involved and by the way people are made to feel in their interactions.

Project management tools can help relay information. But good communication skills seem to be essential for good project management.

I am struggling to get the remaining work in hrs for the tasks as of specified date.
Ex: Today's date 8/18/06.
Task1 (start date 8/16/06; End date 8/25/06)
I am tracking the task by % complete. I wanted get a report which tasks are late and by how many hours as of 8/18/06?

Help will be very much appriciated

Do you think PMBOK is a useful tool for the implement of a knowledge base.I'm a student in Knowledge Management, i do an internship in an IT Company, i've to present my project in few days, a friend of mine has just send me the Guide of PMBOK.
The IT Manager propose me to use Owl, do you know this application?

/BINTA

My experience tells me that there are enough tools for PMs out there and attempts of constant innovation and revision do not result in major improvements. With that being said, there are 3 things that don’t fall into most obvious and major categories of project failure causes (e.g. bad requirements gathering, bad planning, bad PM practices) but they do cause project failure (in my humble opinion off course):

1. Inappropriate scaling or matching of PM methods and/or frameworks to the task at hand. This usually ends up on one side of the spectrum, either a large plan for small tasks or vice versa.
2. Lack of accountability and ability of involved management to estimate and plan tasks in their area, enforce project deadliness and in some cases balance project tasks with their operational tasks. Errors usually begin at planning stage and simply keep growing.
3. Steering Committees that don’t understand their responsibilities and lack experience, and are therefore simply unable to take appropriate action when presented with issues.
4. Users that don’t understand or don’t know what to do about their project responsibilities (e.g. requirements gathering and user testing). User involvement at all stages of the project is critical but most of the time it is management that gets involved and most of their staff that executes tasks never even heard of the project before project deadlines are already suffering from lack of their involvement.

This can be summarized by simply saying, organizational experience with all aspects of project management. The devil is in the details.