If you're new here, you may want to subscribe to my RSS feed. Thanks for visiting!
Hard to imagine in the world of projects that anyone would ask the question "Why do deadlines matter?" However, in the world of politics and world conflicts the argument is front and center. We learned this week, President Bush just won his battle with the Democrats in Congress. There will be no deadlines in the funding bill for the war in Iraq. To my surprise, I opened the June issue of Business 2.0 turning to Jeffrey Pfeffer, Professor, Stanford University, to see his essay Why Deadlines Matter.
Not only does Professor Pfeffer say that deadlines help when setting out to accomplish goals, he claims deadlines are particularly useful when faced with adversaries (anchor-draggers, naysayers, cynics, traditionalists, name-your-own-adversary). How? Pfeffer says, "Setting a deadline can increase the credibility of commitments, which is why you see deadlines used so frequently in labor bargaining, where, absent a strike threat, there's little incentive to read an agreement." He claims the deadline galvanizes the support of proponents. In short, our friends don't want to see us fail. If we have a deadline for moving on, then they'll come support us.
What does this have to do with projects? While we don't want to set deadlines (firm schedule dates) for every task, setting deadlines for major milestones can focus the team (friends) on doing what is needed to keep the commitment. But this only works when they know the deadline. Remember to share your major commitments. Better, develop the plan for accomplishing that work with the team that will do the work. As Pfeffer says, "…(setting the deadline) can also get allies to act, create a sense of urgency when you need it most, and even convince opponents that you're serious."
Tags: CPM, leadership, projectcontrol, projectplanning, projectscheduling, Business2.0, ProjectPlanning
? Guy Kawasaki wrote, "Less is the new more." Easy to learn: symmetry, seduction, subtraction, and sustainability. Very valuable to do. Step 1: Read Matt's book!! just 140 keystrokes.
![Reblog this post [with Zemanta]](http://img.zemanta.com/reblog_e.png?x-id=03314884-90d1-47e5-acf3-2821313e9fdc)
![Reblog this post [with Zemanta]](http://img.zemanta.com/reblog_e.png?x-id=4ce3f392-8989-448a-a97a-c1432dd3fce6)
{ 5 comments… read them below or add one }
interesting post. i actually agree in the fact that what really defines a project? In my mind it is anything that can be broken down into tasks with a defined end (i.e. deadline, budget, acceptance criteria, etc.). there is an interesting tool you may want to check out called communiclique (www.communiclique.com) which takes a similar approach to project management..
Hal,
There’s a corollary in the aerospace business. The DoD and NASA procurement processes defines fixed program events. Preliminary Design Review, Critical Design, Flight Readiness Review and many others. The fixing of these events and the dates creates a contractual deadline, nit just for the meeting, but for the materials created for the meeting. The design for example.
The “little joke” in the planning business these types of programs is the mark the day, plan backward and ask “when shoudl we have started this project?
Same goes for launch dates, closure dates. Deadline appear in newspaper publishing everyday, same for airline operations, road construction, FedeX shipments.
Why is it so hard to get our minds around deadlines in general project work?
Sort of apposite, a couple of quotes from Thucydides “the peloponnesian war”:
“If you take something on before you are ready for it, hurry at the beginning will mean delay at the end” (most construction managers, few clients know that one), and
“It is impossible to calculate accurately events that are determined by chance”. He’s talking about war here, but it applies to any human system: projects especially (I’ve just re-read Hal’s 2004 post on the state of the art in project management)
David,
Interesting quotes. From my experience on large multi-vendor programs, there is a possibly different interpretation of those quotes.
1. The time to take something on needs to be known ahead of time. This is the role of the Plan. The “Plan” is the strategy for the project, while the Schedule is are the times and steps for executing that Plan. This approach is defined in DID 81650 as well as the IMP/IMS process used on all projects larger than $20M.
2. The notion that it is impossible to calculate accurately events determined by chance,” is a bit of a manipulation. Statistics and statistical process control, statistical pattern recognition, statistical noise reduction, statistical modeling all depend on predicting future behavior from “events of chance.” In 300BC Thucydides may have been sleeping in his Bayesian Statistics class. The missing piece from that quotation is “to what confidence level can you know the future from events of chance?”
This statistical analysis approach is the basis of Monte Carlo simulations mandated for DID 81650 compliant programs. There are several tools available for most project management applications (Risk+, @Risk, PertMaster, Crystal Ball). Each depends on the user defining the underlying statistical profile of the task durations, having a properly defined network of activities, and an understanding of how the correlations between these activities impact the statistical behavior of the project.
So the “impossibility” and “accuracy” terms need units of measure before applying Thucydides’ quote to any modern project management problem.
I agree with Mr. Alleman. Best Case, Worst Case, and most likely! I am a scheduler, and I tend to write my schedules so they live and breath. While I may place a deadline on a major milestone, I will not in any way constrain that date. Hard constraints are a no no (unless you are receiving something from the “outside” and even then you should just use an external constraint).
If the schedule is written correctly the Project Manager CAN tell you how long its going to take, how much its going to cost, what the risks are and how he plans to mitigate those risks.
It seems that most people involved with the planning process don’t really understand the basics of planning! If you cannot point out your risks and have mitigation plans in place then you should not be in charge of the project.