Here's an interesting tidbit: the word "deadline" originally referred to a line drawn around a military prison, beyond which prisoners were summarily shot.
By the way, how is that crunch project coming?
If you're like most people who oversee information systems projects, deadlines today can seem almost as threatening as those early lines drawn in the dust. Granted, you won't be dodging lead. But when a project's bullets are forged from internal politics, unreasonable expectations and unforeseen slip-ups, those crunch schedules when you're leading projects in which you're given less time than you'd like to get them done right can become dangerous to your career.
But the situation doesn't have to be hopeless. The trick, say those who've lived through deadline hell, lies in knowing what and how to negotiate with the corporate chiefs who started the project.
"You don't have to sign up for a death march," says Ron Caruana, director of information technology at GTE Telecommunication Services. "You do have to identify the alternatives and the contingencies for things you know are risky, and you have to let the top-level executives know what those risks are."
You want it when?
The first risk to negotiate: the deadline itself. Sure, tight schedules often are dictated by legal, regulatory and market factors. They can't be pushed back. But some deadlines seem almost arbitrary - as if an executive chose a date simply by throwing a dart at a calendar. Those not only can be negotiated, they must be.
Yes, that takes courage. No, it isn't a mark of personal failure if you show executives early in the process how impossible your deadline is. "Crunches normally happen when executives dictate the final date for a project, rather than ask when it can be done," says Doug DeCarlo, project management consultant and coach at ICS Group, a project management consulting firm in Connecticut.
"We advise our clients who can use project management software to schedule the project backward from the finish date identifying the phases, milestones and tasks and let the software schedule the project with reasonable estimates," DeCarlo says. Such software includes ABT's ABT Workbench and Primavera Systems' Primavera Project Planner.
When you make that presentation, it behoves you to suggest alternatives. Say the deadline can't be moved. Hiring temporary help, at a cost of X thousands of dollars, could make the date. Not an option? Then consider a phased approach breaking the project into chunks and delivering, on schedule, only those phases the business must have first.
"Requirements management is critical to success," Caruana says.
Remember that suggestion. It's perhaps the best way to compress time throughout most of a project's implementation cycle. The key, though, is making sure that the business side decides how the project can be divided.
Just be aware that this takes political skill. "Parsing a project requires real political savvy because, if you chunk a project into four pieces, the person with a stake in the fourth chunk usually goes ballistic," says Gopal Kapur, president of the Centre for Project Management in California. "That fourth-chunk person wants to know why his part of the project has to come last. That's why we involve politically savvy IT people and business people to do the chunking."
And speaking of office politics: just how are you supposed to deal with the inevitable delays caused by political bickering, turf wars and team members over whom you have no direct control?
The answer lies in the management process you've so painstakingly laid out and documented. Such plans, although vital for overseeing complex projects, don't define the personal interactions, authority and communication intended to remove the ugly obstacles that invariably rear up from internal politics. For that, you also need a well-defined process that's been agreed upon by the upper echelons.
Process, process, process
"This is so basic [that it] is almost embarrassing to articulate," Caruana says. "The very first thing a project manager has to do is make sure people understand the project management process their company embraces: how work is introduced, how it is planned, how contentions are resolved and how the cross-functional project managers work with the functional managers to deliver."
And what happens when conflicts arise among managers too high for you to command?
Just turn to the well-documented process to see which high-level executive has been designated to smooth out contentious behaviour among those particular departments. It's called "escalation".
"If you never have to escalate, you're either a poor manager or someone treats you as a god," says Jillayn Wolleat, a former project manager who now is a project management consultant in the Atlanta office of consultancy Computer Task Group. "I don't know a single project manager who hasn't had to escalate. I put it as part of the communications procedures in the project plan."
One against the other
That's right, competition; but not staff against staff so much as consultants against vendors. "I love pitting consultants and vendors against each other and letting each one watch what the other is doing. That way you can say, 'This is what the other guy is going to produce. Can you beat it?' It raises the denominator for the whole project", says David Starr, chief information officer at The Reader's Digest Association.
So what should you do if you find yourself in such an untenable position?
Beg for a mentor or a consultant, if you can. Ask to be taken off as lead project manager, if that fails.
Because if you don't understand project management and lack the political clout to get things done, you could very well end up crossing that imaginary line in the dust.
Why Projects Fail
Gopal Kapur, president of the Centre for Project Management, has a list of "Management's Seven Deadly Sins - Why Projects Fail."
1. Mistaking half-baked ideas for viable projects2. Dictating unrealistic project deadlines3. Assigning underskilled project managers to highly complex projects4. Not providing solid business sponsorship5. Failing to break projects into chunks6. Failing to institute a robust project process7. Not factoring in the competing demands of other projects