I was inspired to write this article after viewing a post on a LinkedIn group, posted the following question: “As a project manager when is the best time to monitor and evaluate a project, if for example the project will take up to 5 years“.
There were many comments posted in response, such as:
- “Every day. That is the job of a project manager.“
- “I do it weekly, monthly and summarize the activity on a term basis; it requires a rigorous schedule however it pays off.“
- “I do it at least at the end of a major phase. If it is an extensive project that doesn’t have clearly defined phases, I do it quarterly.”
- There were many other comments but no need to repeat them here
The actual trigger
What triggered this article is the following comment:
“Let’s give our poor PM some time to sleep. Constantly and Continuously are inherently time-intensive and there are only so many hours in the day. Pragmatically we need to think in terms of triggers, frequency and depth, so that a reasonable amount of monitoring provides the maximum information delivered, and there is time left over for other useful things like planning, risk management, communications and the host of other things everyone would like more of.”
We did respond to the above and the following came in response from the same person who posted the above:
“A PM has many responsibilities and one of the things I try to protect against is one of these overwhelming the others. So if you have a client that says, I require you to constantly and continuously monitor the project as a higher priority than anything else (I can’t imagine such a conversation but indulge me to make the point), it will take up a disproportionate amount of time and so other responsibilities will suffer, such as those I listed.”
What are the issues with the above?
We do have a fundamental difference of opinion on what a project manager (AND project management team) should do.
The first fundamental difference
In every stage (or phase) the project manager (PM) and project management team (PMT) must work on putting together a good plan to implement the project stage (in addition to project plan) reflecting objectives, requirements, deliverable, etc.
Once we move into stage implementation than the PM/PMT job is primarily to deliver the project product per the requirements, objectives … that were defined in the project initiation and planning documents.
What other work is there?
We have to stress here that monitoring and controlling do not mean reporting. They mean verifying work is being done per the specification (quality requirements) using the planned resources within a reasonable time frame and cost while minimizing threats and maximizing opportunities. All of these “efforts” are related to control … meaning delivering to objectives.
The second fundamental difference
In the message above (the one triggering this article), the person said: “So if you have a client that says, I require you to constantly and continuously monitor the project as a higher priority than anything else” … Our issue here is a good PM should not be doing this for the sake of his client but for the sake of his team and organization to do the best they can do to ensure effective delivery (per the earlier point). If a PM ensure a good job that would allow his organization to profit and earn a good reputation than the client is indirectly being taken care of.
Is it semantics?
Maybe the difference of opinion is related to semantics.
The way we understand the comments is that monitoring/controlling is somehow narrowly defined and seem to exclude “risk management, communications, and host of other things …”. Whereas we view controlling is encompassing all of the above.
Basically project management is about planning and control (or better say, planning, management, and control) AND of course since projects must start and end — there is initiation and closing but in term of processes, initiation and closing require a fraction of the effort required for planning and control.”
What do you think?
We will offer more in a future articles, addressing the project baselines (yes with an “s”) and the various control reference points along the project life span.