Six signs that you might be inheriting a sick schedule

 

We'd all like to lead projects from start to finish, but the reality is that often times the project manager who kicked it off won't be the one who turns the lights off at the end. Steve McQueen said "We deal in lead, friend" and a fitting motto for project managers is "We deal in change" and that includes our own role.

As such, it is quite likely that you will occasionally find yourself taking over an active project from a departing project manager. In an ideal world, that project manager will have a generous knowledge transfer period and they will be handing over an accurate, complete and current set of key project information but when I've found myself on the receiving end, I've almost never had that pleasure.

While there might be issues with assuming full ownership for your project's financials, forming a positive relationship quickly with the team and other key stakeholders or just getting a clear understanding of project scope and delivery approach, one of the biggest headaches I've experienced has been taking over someone else's project schedule.

Each practitioner will have stylistic differences as to how they structure, populate and update information within their schedules and it might take you some time to understand their "way of working". This is not what I'm concerned with. Unfortunately, many times there are fundamental flaws in how the schedule was created or maintained which will make it tricky if not impossible to use effectively.

Here are just six of the many telltale signs that you might be taking on a schedule which sucks.

• There's no baseline information. As we teach in our fundamentals course, being a proactive project manager is not just about knowing where you are, it's about knowing where you should be, and understanding the implications of any variances. Without having baseline information for key milestones, you can't determine this.
• Constraint abuse. Some practitioners overuse constraints as a lazy way of getting activities to be scheduled on desired dates rather than using dependencies or calendars to do so. On top of that, if constraints are used but aren't documented, you know why a given activity is constrained which means that you will miss out on opportunities to improve your delivery timing if the real world situation which required the use of the constraint disappears.
• Ridiculous resource allocation. Whether it is people, equipment or materials, if your predecessor didn't take the time to ensure a realistic allocation of resources in line with labor contracts, materials availability, cash flow constraints and so on, then activities will rarely be started or completed as planned.
• Spaghetti dependencies. If predecessor activities are located both above and below a given activity, trying to troubleshoot negative float issues or just understanding the flow of the schedule will be frustrating.
• No calendars. Unless you really expect people to work on holidays and take no vacation, a lack of calendars will be another sign that planned dates might be missed.
• Incomplete activities are scheduled in the past. Unless you are a Time Lord or Lady with the benefit of a TARDIS, once an activity's planned start or finish date has passed, it should be rescheduled to reflect when it is expected to be done.

I provide this list as both a risk identification aid for those project managers who take on someone else's project, but also for those who are creating their own project schedules. If you don't want to be cursed by the project manager who follows you, pay heed!