These are Human Factors that Cause Schedule Slippage

A Project Manager must constantly monitor and control the project scheduleA Project Manager must constantly monitor and control the project scheduleYou’ve planned the work. Now it’s time to work the plan. Often this is easier said than done.

The Project Management Institute’s “A Guide to the Project Management Body of Knowledge” (PMBOK® Guide), in my opinion, artificially separates project management processes. I understand why they might do this from a pure guideline perspective; but in my mind this separation also creates confusion and unnecessary overlap in process.

I cannot imagine directing and managing project work
  separately from monitoring and controlling project work
    separately from performing integrated change control
      separately from validating and controlling scope
        separately from controlling schedule
          separately from controlling costs
            separately from controlling quality
              separately from controlling resources
                separately from monitoring communications
                  separately from monitoring risks …

You get the point.

As a Project Manager, I found myself doing all of these activities as an integrated whole. I needed to focus in this way to keep my projects progressing on schedule and within budget. Not once did I separate these activities in my mind. So, I found it a little challenging to isolate the “Control Schedule” process from others in the “Monitoring and Controlling Process Group” for the purposes of this article.

I decided to researched this topic to see what the experts had to say. Disappointed, I once again found the majority of articles regurgitating the PMBOK® Guide, just in different words. And all process all the time.

My experience tells me that people cause project slippages. Process can help correct the mechanics of a schedule that has gone awry. It can even identify the factors that caused the schedule to slip. But process cannot fix the people aspects of the project delivery that created the slippage in the first place.

What are some of these people-related factors?

  • Loss of focus on what matters. This is the unforgivable sin of the inexperienced Project Manager. I have watched Project Managers become so focused on the technical challenges of their projects that they ignore schedule and costs – until it is too late. I have seen Project Managers so focused on fretting about daily schedule variances that they lose sight of the overall schedule – until it is too late.

    An experienced Project Manager uses the tools available to her through her Project Management Information System, Earned Value Analyses, Iteration Burndown Charts, trend analyses, and many others to spot critical variances from the schedule baseline. She identifies them early, analyzes them for the root cause, and immediately implements adjustments to the schedule to bring the project back in line.

    Consider an airline pilot. She knows that if she is off course by 1º, she will miss her destination by several miles on a cross-country flight. However, if she makes tiny adjustments each time her instruments warn her of a variance from the correct heading, she will land precisely at her destination.

  • Poorly estimated level of effort, task durations, and critical path. How many times do team members bare the brunt of poorly estimated project efforts? How many hours of overtime, how many missed family activities, how many disgruntled employees result from overly optimistic initial estimates?

    I come from the world of fixed-price waterfall projects. We were conditioned to bid aggressively to win the project, and then endeavor to manage our project team and the client to those estimates. We became exceptionally good at it. However, on occasion we would misinterpret the client’s intent or bid too aggressively. Or senior management would insist on tight estimates to win the business. Or the team developing the estimates was overly optimistic.

    Whatever the reason for the deficient estimates, they rarely resulted in trouble-free delivery. I personally walked away from a project that I felt was seriously underbid. I learned later that the project was a disaster. It was not a good career move at the time, but would have been far worse had I been the Project Manager tagged with its failure.

    When project variance reports indicate that the fault lies with the estimates and not with the team, it is incumbent on the Project Manager to negotiate a change to the schedule. The negotiation may be with the client stakeholders or with his own management. The team needs to be given a fair opportunity to deliver the project well.

  • Frequently shifting priorities. Have you ever been on a project where management continuously change their minds? I have.

    I especially remember one that initially started out as a proof-of-concept. The technology was new and unproven. Experienced developers were scarce. Both client executives and my own management, while familiar with the concepts, did not understand the complexity or shortcomings of the solution set. Hence the proof-of-concept approach.

    It did not take long until my manager requested that we add new functionality to greatly expand upon the original objectives of the proof-of-concept. I agreed and gave her the new estimates. She told me the client did not have the budget, so my team would have to “eat” the extra effort.

    A few weeks later, she and the client executive met with me to sketch out a new interface requirement to determine whether the technology was capable of exchanging data with a major mainframe system. Again, no additional budget.

    During the client’s user acceptance test, they determined that our software needed to change the method of how the input screens captured and edited the data to improve usability. It was significantly different than what was originally agreed upon. Again, no additional budget.

    My saving grace in all this shifting of priorities was that I documented each change for my manager (under the guise that she could use it to negotiate with the client). We did not make any money on completion, but my team became skilled in a new technology.

    The only solution for such a situation is to nip it in the bud immediately. Frequently shifting priorities lead to scope creep which leads to project failure.

  • Varying team member skill levels. Let’s face it. When you develop estimates for an IT project of any size, you cannot account for every staff member’s skill level or work ethic.

    When Project Managers estimate tasks, they do so based on organizational standards. They know that highly skilled staff will beat the estimates, and lower skilled or more junior staff will not be able to meet them. On average the team should be able to adhere to the overall schedule, as task assignments are adjusted along the way.

    Experienced Project Managers watch for factors such as these and make adjustments along the way. Less skilled staff may receive fewer and less complex tasks. Highly skilled individuals may be given more tasks. They may also be asked to mentor their less proficient teammates. Consistently poor performers may be removed from the project. Occasional bursts of overtime may be required.

    An experienced Project Manager knows his numbers, knows his team, and makes the required adjustments.

  • Scope creep. In two previous articles, I explored at length the causes of scope creep and how they can be mitigated on a project. Rather than repeat even summary information here, I refer you to the following articles:

    “5 Proven Techniques to Control Scope” and
    “6 Signs That Scope Creep is an Inside Job”. 

  • Poor team morale. This factor may be the unfortunate byproduct of all or any of the previous points. As we say in project delivery, “<bad smelly stuff> runs downhill.”

    And who is at the bottom of the hill? The teams that we expect to perform despite the Project Manager’s loss of focus, poor estimates, shifting priorities, poor work allocation, uncontrolled scope creep, and other such factors. As I have so often reiterated in these articles, project work is a people business. Project Managers need to look out for and take care of their people.

    Boiled down to its essence, schedule control is nothing more than a core activity of good project management. The process aspects are the easy factors to monitor, control, and adjust. It’s the people aspects of project delivery that the Project Manager must focus on closely to understand the underlying effect on the project schedule.

Get Your Free Guidebook

Subscribe and receive your free guidebook,
5 Ways to Master the Art of Managing People, Projects and Profits.