How to Develop a Project Plan Acceptable to Management

It’s a plan, not a done. Project tasks are planned, executed, and completed.During my career, it was not unusual for our client to request a detailed project “plan,” then treat the next several months and years as though we were following a project “done.” They would demand that there be no variance from the plan. This then put the onus on us to educate them on project management and how the plan assisted us to complete the project, allowing complete flexibility to adjust as execution took its twists and turns.

Throughout the planning process, it is up to us as project management professionals to continuously educate our client’s management (and often our own) on what it means to plan a project, execute to that plan, and adjust as the project progresses.

Up to this point, I have written the following blog posts to focus on the discrete elements of developing the project schedule:

“Why You Must Involve the Client in Schedule Management Planning” (regarding definition of the schedule management plan),

“How to Conduct Activity Planning with the People Aspects in Mind” (re: development of the project activities),

“This is How Activity Sequencing Should Be Performed” (re: sequencing the activities into a project schedule), and

“Why You Should Educate Management on Estimating Activity Durations” (re: estimating the activity durations to define the overall project duration).

These building-block articles were written from the perspective of keeping the people aspects of project management front and center. It’s understood that they are almost always combined as a single project scheduling activity; nevertheless, it is important to look at them as discrete elements.

Assuming that all of this effort has been conducted using a sophisticated project scheduling software package, all that remains is to let the scheduling software perform its calculations. Voila! The project schedule is complete. We press the “print” button and voila!, the Gantt Chart is ready for mounting on the project “war room” wall for all to see and admire. The people aspects must be accounted for in this work of art because, after all, we’ve been taking them into account all throughout the development of the project schedule. Right?

Right. Except for one thing

That pesky scheduling software appears to be smarter than all of our critical analytical skills. As it performs its calculations based on the sequencing of activities, the lead and lag times that we’ve inserted, and the activity durations that we’ve estimated, it shoots the project end date clear off the page and into next year. All we did was ask it to analyze the Critical Path through the hundreds or thousands of activities that we defined for the project, and it determined that the end date was much further out than what we had anticipated (and certainly well beyond what the client requires).

As a reminder of my perspective, virtually all of my experience is in the bidding and delivery of fixed-price projects. However, I can assume that the same situations hold true for an internal IT organization whose CIO has dictated an unmovable end date for the project delivery. The scheduling software’s Critical Path Method searches for the sequence of activities that represents the longest path through the project which, by definition, is the shortest duration for the project; and which is now providing in an unacceptable end date.

As experienced Project Managers, we understand that developing an acceptable project schedule is an iterative process. So when faced with an end date that clearly will not be acceptable to the client, we begin to review and revise.

  • We revise estimates of activity duration and lead/lag times.
  • We refine our assumptions.

Soon we have a project schedule model that will be more palatable to the client – or, as in my typical situation, can help us win the bid.

And there’s the rub

We know better, but we begin to rationalize: “If we just reduce that activity duration estimate from 10 days to eight days; and introduce a little fast tracking across those three activities to shorten the overall duration; and use a little ‘crashing’ technique of 220-hour months (instead of the average 160 hours) during the development phase; and …”

Lo and behold! It doesn’t take but a few of these paper estimating tricks and the project end date is now within range of what the client would accept.

But what have we really done? For the sake of the win (and yes, I do understand that we need to win if we are to stay gainfully employed), or to placate the sales manager or the CIO, or to validate the client’s back-of-the-napkin estimates, we may have secured the project. But, in our heart of hearts, we know that it will be at the expense of the delivery staff. What happens if the sales manager then asks for more concessions? At some point we can’t get blood out of a turnip, no matter how good that turnip looks on paper.

I concede that it is sometimes necessary to rethink duration estimates, to analyze opportunities for parallel activity, or to plan short bursts of overtime. However, this should only be done through careful analysis and consideration, and not as a knee-jerk response to the sales manager’s need to win the project at any cost, or the client’s demands to hit an arbitrary completion date.

Let’s review a healthier scenario. Suppose in this iterative process of analyzing the entire project schedule, we estimate a critical path that will be acceptable to the client, the sales manager, and, perhaps more importantly, the team that will deliver. We present this workable project schedule to the sales manager or to the CIO, and she decides that if you can comfortably fit the schedule within the client’s timeframes without de-scoping any functionality, then there still must be opportunity to reduce the cost.

Have you heard these:

  • “Could you do it with fewer resources?”
  • “What if the equipment were delivered early, could that reduce the schedule and thereby allow you to implement earlier for lower-cost?”
  • “Instead of resource-leveling the schedule, why don’t you ‘crash’ the schedule and add overtime during the development phase of the project?”

Here’s the dilemma. In presenting an acceptable (read “optimal for delivery”) schedule, we may have opened the door for the sales manager or CIO to ask for more concessions from delivery.

All is not lost, however. I started this article with a reference back to four prior articles, and how all of these project planning activities work in concert to produce a well thought out project schedule. If we have truly taken the people aspects of project management into account in every one of these planning activities, then the overall project schedule will reflect this.

Yes, in iterating through the project scheduling process, there are numerous techniques that we can apply to allow the scheduling software to assist us defining an acceptable project end date. However, as Project Managers, we’re the ones who have led teams through project delivery. We know where the delivery “gotchas” are. We are experienced enough to avoid these for the sake of our staff.

So, let the scheduling process work for us

Let the sales manager or the CIO push us to develop a schedule that will be acceptable to the client and keep costs down. However, we need to remember that we’re the ones that control the planning process and have been all along. At some point it’s up to us to stand up on behalf of our project teams, and our industry in general, to let those that demand too much scope in too short timeframes know that some things just are not attainable. Until we do, projects will continue…

  • to suffer,
  • to fail,
  • to not meet client expectations,
  • and to drive away skilled delivery staff.

In my own project delivery experience, I have been on several “death marches” because the person(s) who did the estimating acquiesced to the person(s) who needed the sale. As I’ve noted repeatedly in these articles, that does not make for successful projects or happy delivery staff.

P.S. I’ll let you in on a little secret. It’s a mindset, really, that worked well for me whenever I developed project plans for client proposals. I determined that the project schedule needed to be as realistic as possible, while still designed to get the win. The win was important so that as experienced delivery staff we could educate the client on what was doable. In the proposal, everything is an estimate, and everything is based on assumptions that we can’t even test until we’re on the job.

After all, we were developing Project “Plans” not Project “Dones.”

Get Your Free Guidebook

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