Program management and the value of Gantt charts when dates are predetermined

Question

I work for a very large organization not in the PM role that has historically had problems with project leadership and project management in general. They have recently broken up and were reformed as now a Program Management Office (which I don't really know or understand the difference). The impression from my colleagues is that this is merely an abstraction away from real project management so that they won't have to be directly responsible for future project failures.

Our interaction with this group is generally that they coordinate BA, Dev and QA resources to hit arbitrary dates as laid out on a Gantt chart that they generate. Developers are never really asked for estimates by PM's but we are asked early in project initiation for a "rough guess" on level of effort, but even then the dates that appear on the Gantt chart don't seem to correlate with any numbers we provide. We track hours that are put towards a project, but we do not track project resource availability in any system. For all intents and purposes the dates on the Gantt chart appear to be arbitrary.

When I asked about this in a meeting I was told that resource availability is just not possible, but upper management insists that we all work towards a hard date as a goal, and that everybody should view these dates as merely goals to try and achieve. That is all well and good but our direct managers ask us for real estimates after the fact and then a date that originally started as merely a "goal" is now an unbending unmoving high pressure deadline by our direct managers. The presence of the PM sort of disappears later in the project.

My original thought on the purpose of the Gantt chart is to demonstrate resource availability and visualizing the Critical Path. Wouldn't predetermined dates minimize the real value or usefulness of a Gantt chart? Is this concept of pre determined dates on a Gantt chart a common paradigm for the field of Program Management?

Answer 1

Fantastic question; significant overlap with my situation. I've got a couple of disorganized observations in response.

First, planning without the team violates the assumptions in the PMBOK. I don't mean to treat the PMBOK as gospel, but I've found that pointing out that a given practice is at odds with the PMBOK is enough to get the audience to listen to my next two sentences; it is vital that the next two sentences be worth listening to. The PMBOK planning process is based on planning with the best possible information and based on planning involving the whole team. Once you eliminate the team from the planning effort, the quality of your plan will suffer. If there are operational constraints that prevent involving the team in planning, management (and the PMO specifically) are responsible and accountable for compensating for that weakness. I would suggest:

• Emphasis on lessons learned, and retroactive quality assessment. After you finish the plan (or any observable sub-unit of the plan), take an hour or two to measure how close the plan came to reality and ask what can I do better next time?

• Frequent, Short, Modular plans. If you know that the quality of your plan is going to be constrained, then the best way to limit the damage is to shorten the plan. Transform the one large plan into 3, 5, or more shorter plans. We currently have a master plan that is long, and then we build a set of rolling six month plans based on the master plan. A catastrophic planning failure can only set us back only 6 months or so. That also gives us more lessons learned sessions, and more opportunities to adapt our planning process to reality.

Second, you can still manage to this program plan, but the importance of Risk Management rises dramatically. The program plan is set without consultation from the team, but that doesn't mean that the PM can't have a discussion with key internal stakeholders (e.g. developer team lead, or SME) and ask,

• The schedule says we'll deliver X on date Y; is that realistic?
• If we fail to deliver by that date, what is the most likely cause of failure?
• I'll bet you $100 that we'll miss this milestone; how much will you bet me that we'll make the milestone? (One of my favorites; when I talk risk, people stop listening, but when I phrase the question this way, people listen).
• If our lives depend on making milestone X by date Y, what impact will that have on quality and cost?
• What can we do to make it more likely that we'll make the milestone (and you'll win our bet)?

Just as a sidenote, I prefer not to have the discussion about likelihood and impact until we've discussed the problem and both have a reasonable understanding.

If Program Dates are edicts, then schedule risk is a major component of your risk mangement. Discuss all the schedule risks, assess the likelihood, and assess the impact in terms of the number of weeks delayed. This is an ideal situation for a monte carlo analysis. This supports a strong brief to external/senior stakeholders.

The program plan shows the next milestone as Date X; we are Y% likely to meet that date. The overall program plan shows program completion on Date W; we are Z% likely to meet that date. If we are willing to spend $N, we can improve our chances by P%.

Answer 2

A Gantt chart is a scheduling and not a resource tool. It documents the planned order and inter-relationship of activities needed to develop project products, and from this you can identify a critical path, but not resource constraints. A program like Project will integrate resource calculations with scheduling calculations, but conceptually they are different things.

Whether or not an "arbitrary" goal invalidates a project schedule depends on whether or not you're talking about an aggressive goal or an unobtainable goal. Aggressive can be good, unobtainable is uniformly bad. I don't think I've ever worked on a project where aggressive goals have not been set.

However, your question is only looking at a couple of components impacting project success, namely schedule and resources. Mark talks about impacts of risk, but there are also considerations around budget, quality, business value and scope. My experience is that if you challenge your leaders on things like quality ("I can deliver that by date X, but testing will be compromised and quality will suffer, are you OK with that?") and business value ("We can push this out but we won't have XYZ which are necessary to save us the 5 FTEs of effort we are counting on to justify the project, are you OK with that?") they will almost always push out delivery dates.