Planning for Project Time Management

I would like to talk about something that Dominant (current) Project Management literature has all but ignored completely: the planning that is an essential prerequisite to effective Project Time Management. It is my contention that Project Time Management doesn’t just happen; it is carefully planned and just as mindfully executed. Little is left to happenstance. And since Project Time Management is the key to successful Project Management, this blog ought to be of interest to anyone who cares how their projects turn out.

About Those Other Planning Processes

Before I delve into this virtually uncharted territory, let’s distinguish it from the other, commonly-cited planning processes that are discussed in Dominant Project Management literature.

Project  Management Planning: The Big Daddy of them all is, of course, Project Management Planning, as espoused by the Project Management Institute (PMI). In its Guide to the Project Management Body of Knowledge (PMBOK Guide), it identifies Planning as one of the five major Process Groups that, together, essentially describe what Project Management is all about.  The five Process Groups are:

  • Initiating
  • Planning
  • Executing
  • Monitoring and Controlling
  • Closing

The PMBOK Guide is quick to explain that Project Management Planning encompasses a number of more specific planning processes that are performed by the ten “knowledge areas.”  Hence:

  • Project Integration Management incorporates the following plans into the Project Management Plan
  • Project Scope Management develops the Requirements Management Plan
  • Project Time Management develops the Schedule Baseline
  • Project Cost Management develops the Cost Performance Baseline
  • Project Quality Management develops the Quality Management Plan and Process Improvement Plan
  • Project Human Resource Management develops the Human Resource Plan
  • Project Communications Management develops the Communications Management Plan
  • Project Risk Management develops the Risk Management Plan
  • Project Procurement Management develops the Procurement Management Plan
  • Project Stakeholders Management develops the Stakeholder Management Plan

The way it all works is that, under the heading of Project Integration Management, the Project Team develops the Project Management Plan, which is reasonably enough comprised of the various other subordinate management plans. So, of significance to us, when the PMBOK Guide speaks of project planning, it is really talking about Project Management Planning.

Project Execution Planning: Now distinguish Project Management Planning from Project Execution Planning. Here, we are talking about efforts to contemplate, brainstorm, negotiate, and strategize an approach to the actual prosecution of the work. It takes a meticulous examination of the PMBOK Guide to find any discussion of such planning, even if referenced by another name. By process of elimination, we arrive at Project Time Management as the likely place within the PMBOK Guide where Project Execution Planning would be discussed. After all, such a topic does not fit as well, or at all, under the other knowledge areas. Yet, in the Project Time Management chapter we are hard-pressed to spot any reference to planning, per se.  One would expect planning to either be the essence of Project Time Management or, at the very least, a core prerequisite to subsequent Project Execution Scheduling. Instead, we find this opening paragraph to the Project Time Management chapter:

“Project Time Management includes the processes required to manage timely completion of the project. The Project Time Management processes are: Define Activities, Sequence Activities, Estimate Activity Resources, Estimate Activity Durations, Develop Schedule, and Control Schedule”

So, where is Project Execution Planning? We know that the overall planning for Project Management is being addressed by the Project Management Plan, the assembly of which is being orchestrated by the Project Integration knowledge area. But where are the processes involved in conceiving a Project Execution Strategy? You may be thinking that the Project Schedule is the Project Execution Strategy. And, apparently, that is how the PMBOK Guide thinks as well. It would seem, then, that according to the authors of the PMBOK Guide, scheduling a project’s execution is the same as planning its execution. But wait! At the top of the second page of the Project Time Management chapter, we find this statement about planning:

“Although not shown here as a discrete process, the work involved in performing the six processes of Project Time Management is preceded by a planning effort by the project management team. This planning effort is part of the Develop Project Management Plan process, which produces a Schedule Management Plan that selects a scheduling methodology, a scheduling tool, and sets the format and establishes criteria for developing and controlling the project schedule.”

Well, it looks like we got excited for nothing. This planning effort that precedes the development of the schedule is not focused on the project’s execution, but rather on the performance variables attendant to the development of the schedule itself.  False alarm.

So it would seem that the PMBOK Guide does not address, either substantively or at all, the hugely important planning effort needed to figure out just how the project will be executed! Unless, as we stated earlier, it considers scheduling to be same as planning.

Project Execution Planning versus Project Execution Scheduling

This begs the question: Is there a difference — between Project Execution Planning and Project Execution Scheduling? Before you go asking any gathering of project planners and schedulers, you had better suit up for a battle. For those of you on the periphery, let me give you the Bottom Line news: there is no consensus. While there are many different opinions on the meaning of the terms planning and scheduling, there are two primary schools of thought, as matter to our discussion here.

  • One group sees Planning and Scheduling as collectively responsible for the six Project Time Management processes that the PMBOK Guide identifies (see above). For members of this group, the first four processes constitute planning, whereas the remaining two processes constitute scheduling. The distinguishing component: Activity Dates. Planning involves defining and sequencing the activities, and then estimating resources and durations. It is at this point, when those four variables are acted upon by established formulas, that Planning becomes Scheduling, with the appearance of Activity Dates.  Thus, Develop Schedule and Control  Schedule are considered to be squarely in the Scheduling bucket.
  • The other major opinion group subscribes to the notion that all six of the above processes are Scheduling processes. Then what do they consider to be Planning? This is where things get really messy:
    • Some, including ICS-Research, think that Project Execution Planning is a separate set of processes, ones that the PMBOK Guide simply overlooks.
    • Others think that such strategic planning actually takes place during the Define Activities process.
    • Still others think that Planning and Scheduling are essentially synonymous terms. And while that does not answer the question as to whether Planning entails anything beyond Scheduling, that is as far as they wish to carry the discussion.

As if to make matters worse, there is equal confusion as to what constitutes a Planner and what constitutes a Scheduler. LinkedIn is a great place to find debates about these two terms. Many view Planners as higher on the experience food chain than Schedulers, whom they see as little more than computer technicians, or note-takers. Most, however, see the two terms as synonymous. And then there are geographic differences: what are called Schedulers in North America are called Planners in Europe and Australia.

Cognitive Project Management’s View of Project Execution Planning

Keep in mind that Cognitive Project Management is being developed for the construction industry, with pronounced sensitivity to its organizational and operational nuances. Among those many nuances is the ad hoc nature of the Project Team. Each project represents a unique combination of players, coming together many for the first time. For Project Leadership, there are immediate challenges of team-building, leader identification, strategic consensus, unification and alignment of project goals and objectives, etc. The initial Project Execution Planning process provides an excellent opportunity and rich environment in which to secure many, if not most, of these initial communal attributes.

According to Cognitive Project Management, there are four stages of Project Execution Planning:

  • Project Feasibility Planning
  • Project Optimization Planning
  • Project Consensus Planning
  • Project Commitment Planning

The Project Execution Planning stages are progressive, each building on the ones that come before it.

  • Feasibility Planning is typically performed by the contractor during the bidding phase, the goal being to determine whether the project, as described in the bid documents, is feasible – at least for a profit.  If it is not, then the contractor decides not to bid the job at all.
  • Optimization Planning also takes place before the bid is submitted. The goal of this planning effort is to see how many other approaches to Project Execution it can think of, and then to choose from among these the most appealing one(s).
  • Consensus Planning may happen before bid submittal, but more often happens along with Commitment Planning after Contract Award but before Start of Work. These final two planning stages share a common feature: they involve the contractor as well as the major subcontractors and suppliers. As the names suggest, the purpose is to take the Optimization Plan and further sculpt it into an overall Execution Strategy that will earn consensus acceptance, capped by firm performance commitments to one another (whether formally signed off, or with just trusting handshakes).

Hopefully you are quickly concluding, from the previous paragraphs, that there is indeed more to Project Execution Planning than simply creating a list of activities to be included in the Project Schedule. Yet, you may still be fuzzy on how differently (if at all) a Project Execution Plan might look from a Project Execution Schedule. A great question! Especially considering that both processes typically use the same Critical Path Method of modeling execution strategy. The answer has to do with intended end uses. And this is the same point I have tried to make so in so many professional discussions concerning scheduling thresholds. Just this week I made this same point to a panel of scheduling experts (on which I serve) that is working to develop scheduling standards for the United States Government Accountability Office (GAO).

“It all depends on how the Project Time Management document will be used,” I keep repeating. How the final document will be used dictates important factors like: level of detail, minimum or maximum duration size, use of milestones, use of date constraints, use of automated calendars, resource or cost loading, resource leveling, diagramming choices, frequency of updating, formality of approval and acceptance, regulation of revisions, etc.

The answer to your question is that the Project Execution Plan will look a lot like the Project Execution Schedule, but there will be differences. Both will likely be written using CPM notation. Both will contain activities with durations; there will be logic ties between the activities, and they may appear in both graphical and tabular outputs. Both will contain dates, milestones, and can identify one or more critical paths. But, more often than not, the Project Execution Plan will not be as detailed as the Project Execution Schedule. Neither is it likely to have a rigid, formal infrastructure of Work Breakdown Structure (WBS), fully-defined activity codes and activity identifiers, automated calendars, etc. It will also most likely contain a whole lot more date constraints than would be considered acceptable in a normal Project Execution Schedule.

Which Brings Us Back to Project Time Management Planning

As I have said, many times, Project Time Management entails much more than simply Planning or Scheduling. Even more than the PMBOK Guide process group of Monitoring and Controlling. ICS-Research posits that the essential core of Project Time Management is Project Execution itself – not the Planning or Scheduling that happens before, or the Monitoring and Controlling that takes place after. The real achievement of effective Project Time Management is accomplished, not by pencil-pushing planners and schedulers  or fancy project management software but instead by the Project Executors – by those who actually perform and oversee the work of the project. Plans and Schedules are just tools to make their work more efficient, more coordinated, more pleasant and more successful.

So, think this through with me: if Project Time Management is this project-long set of processes (Planning, Scheduling, Executing, Monitoring, and Calibrating), then wouldn’t it benefit from an initial planning session to carefully deliberate on just how the Project Team wishes their Project Time Management System to work? And that is precisely what the Project START Summit is all about. In an upcoming blog I will write about this all-important meeting that takes places in the days following Contract Award, and attended by representatives of all of the key Project Time Management stakeholders. For now, just know that the main purpose for holding the Project START Summit is to encourage candid and productive discussion of all of the critical factors that will drive, or prevent, temporal success on the project. The primary work product coming out of the Project START Summit is the Project Time Management Plan.

[As a closing parenthetical remark, in recent years there has been growing disappointment over the contribution made by certified Project Managers. One after another, companies that had invested heavily in certifying their project managers according to the latest and greatest Project Management dogma are finding that their projects are not improving much at all, when it comes to time and cost performance. Sure, they may have better organization and better reporting systems. But, when it comes to results, the projects are still missing their goals. This blog dares to ask whether there could be a correlation between unsuccessful Project Execution – and the absence of any real treatment of either Project Execution Planning or Project Time Management Planning in the source Project Management treatises upon which such certifications are based?]

What is your opinion? We'd like to know!