The Schedule – Resource Leveling

“Happy people plan actions, they don’t plan results.”

                                                                                                                - Dennis Wholey

We are nearing the end of the series on scheduling basics.  We have taken the WBS, added the dependency chain, estimated the effort and assigned resources.  The next step to completing the well-formed schedule is to level the resource assignments.  This is done to:

• Prevent over allocation of a resource within the project
• Prevent over allocation of a resource across enterprise assignments
• Accommodate non-productive time and absences

First, let’s assume the project is in an organization following best practices.  In that case, all team members record all of their time each cycle to specific project tasks and to operations, administrative, absence, and other non-project activities.  Your project management software integrates with these time records (or time is entered directly into the software, such as Sharepoint wih MS Project EPM, Clarity or Primavera).  In this case, you already have all of the elements in place to just “push the button” on your project management software to resource level the schedule.  You will then want to review and fine tune the results.

On the other hand, if you do not have the luxury of these conditions, you have more work.  For example, you will have to tune and adjust using heuristics to get the right productivity factor so that you don’t over allocate resources within the project;  and it will be much harder to track other assignments and activities to prevent over-allocation across enterprise activities.

In either case, this step will be repeated regularly over the life of the project.  Rescheduling and replanning are regular activities in the Project Manager’s Cycle.

In my next post, we’ll conclude this series of posts on the basics of creating the well-formed schedule by discussing risk buffers.

If you are not in a “best practice” environment, what steps do you follow to produce a resource-leveled schedule?

The Root Cause of IT Project Failure

Art is making something out of nothing and selling it.  Frank Zappa.

There exists anecdotal evidence that Information Technology (IT) projects fail at a greater rate than other types of projects.  Why is this?  Are we that bad at delivering projects?  Or is it that we’re that bad at planning?

Have you ever asked an artist to predict how long it will take to create a novel piece of art?  Or tried to get a marketing team to plan the schedule for coming up with the next campaign?  Why are we as IT teams so ready to come up with these precise, scientific – even optimistic – schedules?  What we do is often just as novel and just as creative.  But we’re ready to plunk down numbers on a schedule with the confidence of divine inspiration.

Project Management is a special kind of management.  That is, project management is the poster child of Management by Objectives (MBO).  The unique aspect of MBO – and thusly project management – is the objectives (milestones) with which are either tracking or off track.  To have objectives entails planning.  In project management, we call the objectives milestones and they are points on a (time or cost) schedule.

I want to distinguish here among varieties of projects.  Like the abstract water colorist who can knock out wilderness landscapes with the reliability of an assembly line, some shops do many very similar projects.  With those conditions your planning can get fairly precise.  It’s those other projects I’m talking about.  Not high risk, no, not those.  Rather, the high novelty projects.

Projects where you and the team have never really done anything like this before.  You’re breaking new ground and every design activity is a unique creative effort.

How can you say up front how long this will take or how much it will cost?  But we do.   And we commit to these numbers.  Why can’t we be like the artist or the marketer?  Why are they so much smarter than us when it comes to these commitments?  Is it because they’ve learned from their mistakes?

I assert that what we’re really predicting in our plans is not that it will take this long, but rather that it will take at least this long.  That it can’t realistically be done in less time.  And some of the engineering work can be planned.  For example, we can lay out that we will complete requirements in x days.  Or that development will take so many weeks.  But how long does it take to research alternatives?  How many prototypes will we have to do before we get it right?

IT projects – that is, novel IT projects – are just as creative as the artist carving the block of marble or the ad team brainstorming the perfect campaign.  And we should be just as resistant as those artists to committing too much (too little?) in advance.  We do ourselves, our team, and our stakeholders a disservice otherwise.

The root cause of IT project failure:  committing to a plan too early.  We don’t fail on delivery.  We fail trying to deliver to a faulty plan.

What happened when you promised when you should’ve waited?  What stories can you tell about trying to deliver to the wrong plan?

The Project Manager’s Cycle – Negotiate with Resource Managers

“Rainey, are you aware of any recent changes with Mani?” Don was having lunch with Rainey, the Analysis and Design Manager and Mani’s resource manager.  “She’s missed a couple of deadlines, which is unusual for her, and one of the business contacts mentioned she’s been ‘testy’ in some of the meetings.  I’m concerned.”  Rainey, after a thoughtful pause, replied “Have you asked her about it?”  “No,” Don answered, “not yet.  I will talk to her this afternoon; since we were here, I just thought I’d see if you had any background.”

Up to now in my series on The Project Manager’s Cycle we’ve primarily been working with numbers and reports, with little communication outside the project team.  This is the first activity where we start coordinating with project stakeholders.  This activity assumes a matrix organization, where you have temporarily and/or partially borrowed resources from department managers in order to staff the project.  If you own the resources – that is, they report directly to you as their line manager – then you can skip this activity.

This activity takes as input the results of the previous two activities:  replanning the schedule and reviewing team member progress and productivity.  As a result of those activities, there may be changes to the planned utilization of team members or concerns about their performance or productivity that you need to discuss with their managers.

For each project team member, prepare a schedule that shows their expected allocation by week for the next several weeks.  Depending on the organization and the resource manager’s planning cycle, this may be as short as 3-4 weeks;  other managers may require three months or a full schedule showing the allocation as long as the resource is needed.

You may also want to provide the information by task with completion dates, depending on the detail that the resource manager wants to see.  You can use your scheduling tool’s Gantt chart feature or populate a spreadsheet.

Provide these reports to the resource managers and, where appropriate, schedule to meet with them, especially if there are performance or productivity concerns.  Review the report, productivity, progress, and any changes you’ve noted from prior weeks.

But don’t expect the resource managers to just accept your plan.  They may actually have assignments, priorities, and expectations for these same resources, which, of course, may require some negotiation on your part and the possibility that you are back to replanning the schedule.

When you have performance or productivity problems with a project team member, do you talk to the team member first or to their resource manager?  Why?

The Project Manager’s Cycle – Reschedule/Replan

“What do you mean ‘You’re going to be gone for four weeks starting next month?,’” asked Alice, after picking up the phone on one of the rare occasions she was actually at her desk and listening to Ravi explain his new vacation plans.  “But … well, you didn’t know.  I just found out that Infrastructure is slipping their schedule so we’re going to need you until the end of the month after all.”

Now we transition from initiation activities to planning and design within The Project Manager’s Cycle. 

If it hasn’t been done already, all the team member updates from the metric validation and the task validation need to be posted to the project schedule, including closing completed tasks, updating effort estimates, and opening tasks ready to start.  Your perfect plan from last week is now corrupted from just one week of actual results – new end dates, team members who are now over allocated,  team members who won’t be available as previously planned due to conflicts or newly planned absences, newly exposed issues, political maneuvering, prioritization conflicts, team member conflicts, and stakeholder conflicts.

Now you, the project manager, apply intelligence to scheduling, adjusting start dates, shuffling tasks, balancing resource allocations, and drawing on schedule buffers as needed.  Sure, your scheduling tool “auto schedules” and probably has an option to load-balance resources.  However, the rule engines for these are notorious for making obscene messes of your schedule.  Depending on the need to maintain the original target dates and prevent slippage, you may need to consider adding resources, overloading resources (OT), reducing scope, and crashing the schedule.

As a further part of this activity, you will also address event-driven activities, such as unplanned/dynamic impacts, deliverable acceptances, reprioritization, issues, problems, commitments, and the other conflicts mentioned above.  This may involve adding project tasks, reassessing resource assignments and allocations, changing task estimates and getting team members to re-estimate their task assignments.

The end result is a new draft schedule that you have to validate and “socialize,” which transitions us to the next activity in The Project Manager’s Cycle and sets the stage for my next post.

Unlike most of the other activities in The Project Manager’s Cycle, rescheduling and replanning is not something that is done and then completes.  Rather, every thing you as the PM does has the potential to expose a need to adjust the schedule;  adjusting the schedule has the potential to expose the need to further adjust the schedule or to take some action that will … well, it’s called The Project Manager’s Cycle for a reason.  This keeps happening ever and forever for the life of the project.    You are constantly restarting this activity.  Plan on it.

How do you live with yourself when you have the perfect project plan?

Heroes

“Let’s give a big round of applause to Jeff for saving the eXrel project.  It looked like a doomed effort until he stepped in and saved it for us - again.  This is the third major project Jeff has salvaged in just two years.”

You do need to publicly recognize your team members who go the extra mile, but if your shop relies on heroes repeatedly, you need to step back and evaluate your operations.  After all, this describes the chaotic environment that defines a maturity level 1 organization, where success is dependent on spectacular saves, monumental individual efforts, and the performance of key personnel.

Therefore, while you as a manager should recognize and reward your heroes, you should be asking why you are dependent on them and what you can do to sever that dependency.  After all, there is a better way.  Higher maturity shops operate in a more consistent, more reliable mode.  In fact, in higher maturity organizations, there is rarely a need for heroes.

I can hear some readers saying that is because they plan better, and, while that is a true statement (if only because it is a tautology), it is more accurate to say that they can deliver to their plans.  That is, they have a delivery capability that is reliably consistent and can be modeled successfully and the model will include the elements necessary for successful delivery.  Their plans are realistic models of their actual delivery rather than the optimistic hopes and wishes of the planners dependent on good luck and herculean efforts of team members to bridge the gap between hope and reality.

So for executives as you observe, analyze and review your subordinate directors, divisions, managers, and departments, notice the ones that recognize their heroes.  Those are the departments that probably need the most attention, coaching, and guidance to mature their operational processes.  They are also the departments where you stand to gain the most from making improvements.

Planning

“Why does it seem that every one of our projects takes forever just to get out of the blocks?” asked Jack, Executive VP, HR.  Jack and Diane (apologies to Billy Joel) were having lunch at their favorite Italian restaurant and discussing the latest reorganization plans.  “I’ve never thought those IT guys were all that efficient, with all of their documents, checkpoints, signoffs, reviews, and meetings.  But they can sure get a project up and running a lot quicker than any other division.”  “It is strange,” responded Diane, CFO, “that we’re always complaining about how long it takes IT to finish a project, but we get grief for how long it takes us to start one.”

Planning is actually much easier in a shop that conducts many, similar projects and uses a standard project delivery methodology.  The corollary to this observation is that shops least qualified to plan are those that need planning the most.

These maxims are almost self-evident.  After all, when an organization has performed enough projects to build project delivery expertise, standardize their methods, tools, roles, and deliverables, and wean out the sources of failure, people know what to do, how to do it, and when.  Expectations are stable;  misunderstandings are reduced.  On the other hand, shops where each project is a novel endeavor have to negotiate roles and responsibilities from scratch every time and don’t have the luxury of knowing the best paths for avoiding project calamity.

These shops need planning the most, but, not knowing how much they don’t know, miss key elements.  It’s like a phonograph needle (remember those?).  An old, dull one sort of bounces off the top of the grooves while a new, sharp one gets into all of those little pits and pockets, giving a much more robust (and potentially noisy) experience.

So, should your shop commit the effort to plan or not?  There are two responses to this:

1)      Why bother?  After all, it probably won’t make much difference?

2)      Of course, because the project will turn out even worse otherwise.

Some might say that the best predictor of a successful project is good planning.  I say the best predictor of project success is having delivered lots of projects successfully.

Maybe that’s why a veteran project manager is so valuable.