When signing on for a project, no matter what kind, a key resource is always time, as expressed through a schedule. Anybody who has even a little control over what projects they become involved in is well-advised to be very careful about agreeing to somebody else’s assessment of how much time a project will take. In larger organizations, all too often the amount of time available has been chewed up by front end administrative activities, often to the point where the project schedule is now a problem, maybe even THE problem. It can be tempting to agree to take on projects that seem cool, or important or challenging, despite their alarming deadlines, but there’s one thing you need to be clear about – the minute you say yes, their schedule problem has become yours.
That’s a fact — no matter how unrealistic, optimistic, or just plain crazy a project schedule seems, once you’ve said yes, the problem of delivering on it is now owned by you. Once handed off to somebody else, schedules that once seemed really far-fetched, are now viewed as achievable, maybe even reasonable. No amount of you reminding a client or manager about what a long-shot this project has always been will do you a bit of good, it falls to you to deliver, come hell or high water.
Nobody wins in this scenario. You get blamed for dropping the ball, when you were thrown a pass that hit the ground before it got to you. The manager or client doesn’t win, not really. Yes, they may have been able to transfer the blame for their bad planning to you, but ultimately they didn’t get what they wanted when they needed it, with consequences ranging from inconvenience to catastrophe, depending on the nature of the project. You’re now left with a damaged reputation, by agreeing to assume responsibility for somebody else’s scheduling mistake.
So, what to do when offered one of these “opportunities”? It’s always tempting to think that if some more manpower were added to the project, it could be accelerated. There’s a principle of software development known as Brook’s Law that states that “adding manpower to a late project will make it later”. I believe that this law has wider application to many types of projects and becomes more dramatically true as available time diminishes. As Brooks states: “Nine women can’t make a baby in one month.”
A better solution is to negotiate changes to the scope or schedule itself before the project starts. This is the ideal time to bring a voice of reason to a situation that may have been sliding out of control. I have often been pleasantly surprised by how receptive clients are to hearing “I can do these things for you, but not this, there’s just not time for it” or “yes, I can do it, but I’m going to need more time than you’ve allowed.” It’s a dose of reality that somebody owning a schedule problem can really use. In many, many cases, this is a problem that has been transferred to the project manager or client by somebody higher up the ladder from them. They may have had no choice but to accept it, and getting an opinion from an outside expert that validates what they probably already knew at some level is extremely reassuring. For you, it’s a chance to recast an otherwise desirable project in terms that are better calculated to assure success, and to me, that sounds a lot more like a win-win than accepting an assignment that’s doomed to fail.
Like this? More from the Design Process category.
Follow me on Twitter (@intudes) for interesting links and occasional observations.
Subscribe to the RSS feed, and don’t miss another post.
