{"id":1565,"date":"2017-10-06T17:32:08","date_gmt":"2017-10-07T00:32:08","guid":{"rendered":"http:\/\/b-spoke.net\/?p=1565"},"modified":"2026-06-29T22:00:29","modified_gmt":"2026-06-29T22:00:29","slug":"control-your-schedule","status":"publish","type":"post","link":"https:\/\/thirdactmedia.com\/b-spoke\/2017\/10\/06\/control-your-schedule\/","title":{"rendered":"Take Control of Project Schedules"},"content":{"rendered":"
A Six Minute Read<\/h6>\n

Complaining about projects falling behind schedule is good sport for executives and sponsors, its popularity rivalled only by project managers providing excuses \"projects\"<\/a>of why their projects are off target.<\/p>\n

Good project managers know how to prevent their initiatives from falling behind, and avoid persistent blamestorming.<\/p>\n

Common scapegoats include unfriendly software, unyielding and\/or uncaring scheduling departments, and lack of resources. With a little bit of legwork and focus on the fundamentals, a PM can overcome these issues.<\/p>\n

Schedules are Built<\/i> not Spontaneously Generated<\/h4>\n

A project schedule is more than dates on a Gantt chart. Those dates come from somewhere, and the best initiatives have a project-specific logic underpinning that schedule.<\/p>\n

\"\"<\/a><\/p>\n

Dependencies<\/strong><\/p>\n

Before locking a schedule, a good PM understands the dependencies of the work involved. This goes beyond knowing, say, that a foundation must be poured first, or how long paint takes to dry. The project manager recognizes how each deliverable fits, Jenga-like, into the sequence. Good PMs ask, \u201cWhat must be complete<\/u> before this task can start?\u201d and \u201cWhich tasks rely on this one?\u201d. The PM also knows how long each task should<\/u> take. Then – and only then – can the PM overlay this string of dependent tasks on an actual calendar. (Project software is much friendlier when this work is input first).<\/p>\n

Project Calendar<\/strong><\/p>\n

Before sharing a \u201cstraw man\u201d schedule (\u201cWe think<\/u> we can hit these dates\u2026\u201d), good PMs look at actual calendars and determine when work can get done \u2013 and when it can\u2019t. This can be complex \u2013 thanks to multiple staffs working multiple shifts across multiple contracts, in multiple time zones (and whose countries may celebrate multiple holidays). This seems so obvious, it\u2019s astounding how many PMs ignore \u00a0it. \u201cWe didn\u2019t know their plant was shut that week\u201d, or \u201cThey only work one shift\u201d, are not<\/u> legitimate reasons for projects to fall behind.<\/p>\n

Resource Calendar<\/strong><\/p>\n

Before finalizing the schedule, good PMs review that straw man with their resources \u2013 and oftentimes \"\"their resources\u2019 managers. Either the resource is cool with the layout or not. If not, the PM can decide whether that specific resource is more important than the date: Then, the choice becomes replace the resource or re-negotiate participation (depending on the flexibility of the conflict). Either way, before the project kicks off, and a schedule is published, the PM and resources have agreed on what that schedule is. \u201cJoanie wasn\u2019t available when I scheduled her\u201d is not<\/u> a legitimate reason for a project to fall behind.<\/p>\n

Advance Negotiations<\/strong><\/p>\n

Note we said \u201cre<\/u>-negotiate\u201d participation: Before laying out \u201cDependencies\u201d, good project managers discuss project participation with potential resources and their managers. This can be high-level and vague: \u201cHey, I may be tapping you for some help in mid-September; what\u2019s your schedule like?\u201d This informs both the Project Calendar, and, obviously, the Resource Calendar. The PM may discover that even the tentative schedule is unrealistic, and\/or has time to make significant resourcing changes.<\/p>\n

On large or complex projects, obviously, PMs don\u2019t know each individual resource. But good project managers carefully select the \u201cprincipal\u201d resources for deliverables; these are the ones who provide subject matter expertise, build the teams under them, and share accountability for the project\u2019s success.<\/p>\n

Schedules Are Built on Resourcing Needs<\/h4>\n

Too often, people are assigned to a project because they are \u201cavailable.\u201d (Or because an executive thinks they should.) Good project managers take control of their resource pool and only assign work to those who can, well, \u00a0actually do it.<\/p>\n

The PM ought to review the work breakdown structure and understand what\u2019s required to achieve it. She does this before<\/em> anyone is assigned \u2013 or approached about being assigned – to the project. Careful readers will (correctly) infer that, because principal accountability is assigned before schedules are written, this resource review is done before any dates are laid out as well.<\/em><\/p>\n

The PM \u2013 and smart ones consult with experts \u2013 creates a Resourcing Index which lists the skills, knowledge, and abilities required to do the work. Not<\/u> names, not<\/u> titles, but actual attributes. (In other words, \u201cCan sweat a pipe\u201d, not<\/em> \u201cPlumber\u201d.) Think of this as a \u201cBill of Materials\u201d for people.<\/p>\n

\"\"<\/a><\/p>\n

This becomes important in two ways \u2013 when selecting resources in the Initial and Advanced Negotiations, it opens more possibilities to get the work done. \u201cHey, I don\u2019t need to wait for Joe on this,\u201d the PM can say, \u201cI just need someone who can sweat a pipe.\u201d<\/p>\n

This is also helpful if (rather, when) the schedule starts to slip \u2013 say, Joe calls in sick. Again, the PM (or the person who has primary accountability for that deliverable) can open the Resourcing Index and say, \u201cHey, we don\u2019t need to wait for Joe on this\u2026 We just need someone here who can sweat a pipe.\u201d<\/p>\n

Estimated hours are included to ease in negotiations and set expectations with resources. Even for internal (“free”) resources, capturing effort and assigning a dollar value highlights the opportunity costs of the project!<\/em><\/p>\n

The Completion Backward Principle<\/h4>\n

To pull this all together:<\/p>\n