Seems every discipline in the interactive space has their little motto or saying. Account services are famous for “ the client loves it but wants to change everything”, or perhaps just make the logo bigger. Designers are simplicity’s pimp because “a design is finished only when there is nothing left to take away”. The marketing folk ceremoniously commence brainstorm sessions by making sure everyone has “ their green hat on”. Developers default to “ unable to replicate” much in the way an apathetic local might not speak your language because they couldn’t be bothered. And well project managers, there are so many sayings of the beige variety.
I wanted to find something that really spoke to me - as much as something such as Pareto’s principle does. And so in my quest, I found a true rare gem - one that skyrockets my office popularity rating and seals my fate as being the name promoted to top honours on that secret gone postal list everyone mentally scribbles down. I graciously ripped this phrase from the internet and now bestow it onto you. Use it at your own risk.

Bad planning on your part, doesn't constitute an emergency on my part.

When I first read this phrase, I thought the sentiment it conveyed could not have been stated better. I wondered - would these words be forever inscribed and never uttered? It took me awhile to place it, but I have heard a variation of that sentiment which I will share in a bit.

The sentiment itself, it’s a bit misplaced. We are typically, after all, a team, even if the process we are following is one of a waterfall where accumulated project debt is generally a burden put on developer’s shoulders. Certainly everyone has had a moment where they have wanted to say something along those lines - but thankfully few cross check the inside voice to the boards to actually say something of that nature. If we all did it, inventory at the jerk store would be constantly backordered.

Bad planning. What is bad planning? Most people would consider bad planning to be lacking in thought, attention and detail. Yet, over planning could be considered bad planning - when something is defined and determined at the most granular level, flexibility is compromised. Smaller shops deal better with chaos - with anywhere from 3 - 7 people on a team - they inherently foster a more agile environment where communication is key, and anyone who is out of the loop is quickly identified as an asshat. For larger organizations, chaos isn’t an effective motivator because they often fail to manage/ prepare for it properly citing “growing pains”. Larger organizations typically possess more defined and layered organizational hierarchies. Communication starts to resemble something close to a rousing game of telephone, where each pass the message is further brutalized beyond recognition.

When it comes to the project cycle, most interactive agencies still favour that waterfall approach - where project phases may see some overlap, yet they generally do not run concurrently. We are used to this process - determining the solution, creating the design, putting in the pretty FPO images, making sure the client likes how it looks regardless of if it works as good as it may look. Milestones, and signoffs also follow these phases typically as they are viewed as units of completed work towards the finished product. Discussion moving forward, will now make the assumption that this is the process of choice - whether it is a process that works, is another article entirely.

I’ve had many heated debates over the importance of a schedule. I believe they are valid and useful. Others have suggested the opposite, that with evolving or changing project requirements, they are rendered useless because they are never accurate. If we determine the validity of an item based on its accuracy, then we could render almost any deliverable in a project, invalid. Estimations, project scopes, functional specifications, client deliverables, even distributed meeting notes - all are rarely completely accurate. As Scott Berkun outlined in his book the Art of project management, the value of a schedules doesn’t necessarily lie in accuracy.

Schedules frame a project. Their data is not just time based, but resource based. Who is working on what, and when. Immediately, even if at a superficial level, it has engaged someone to do something. That someone, is responsible for something, and is now put in a position where they a) have responsibility and b) may be made accountable for upholding that responsibility. I suppose they also keep people invested in the project as well - its harder to be apathetic when you realize that in a waterfall process, failure to meet your deadline/ commitment means you’re basically setting up the next person in the production line for failure and you have the front row seat.

A schedule is merely data. Clients love data. Their love for arguably valuable deliverables is founded in the belief that they illustrate progress of a process from which they are most often alienated. As data, schedules can help identify bottlenecks for a project manager. They are not meant, however, to replace all communication. If we need to file this under project manager math - the time spent with data should be less than the time spent with the team. The value derived from each simply isn't comparable.

Nothing truly goes according to plan. Anticipation of that fact necessitates not just one plan, but two. Now imagine someone, someone typically being a project manager, attempting to articulate the grand scale of the massive cluster the project has become and the immense failure of plan A. He/she is looking to team members for confidence and guidance, looking to everyone to help navigate their way over a topography everyone knows so well. And now I present the variation of the sentiment I started this article out with - it’s a phrase uttered by an old colleague of mine, only when a project has entered the land of complete Botchdom. It must be delivered with upmost sarcastic glee to truly drive the message home- " OMG, what are you going to do?".

Plan A just isn’t enough. Bad planning means someone forgot to create the contingency plan. It’s like getting on a flight to realize there are no emergency exits. Plan B is just as important as Plan A and not having an alternate plan is bad planning. In the interactive field - what does this mean? As a developer, to me, this means - if we are in a situation where at any point the success of plan A is at risk - plan B needs to be what we fall back on. If the worst part of a developer's job is being given the responsibility of a miracle delivery, then surely the worst moment for a project manager must be administering the delivery shocker to the client when they least expect - at sign off.

Plan B is the alternate plan. The one that has to be put into place if something puts the project at risk at the various milestones. Its not just about readjusting a schedule. Its about possibly altering or scaling back the deliverables - because often, depending on the client, there may other external factors like media buys, conferences, trade shows, that make moving the deadline, just not an option. Its most often in moments of crisis when reactive damage control kicks into high gear. Its as if people have come out of hibernation - having removed their heads from that oh so warm place they’ve been hiding them and finally realizing, with the exact same clarity and understanding you as a developer have possibly possessed for some time - that plan A is nothing more than a sales guy wet dream about an anticipated commission.

It’s a simple mistake to make - determining what plan B is at the time that the master plan A failed epically. Some would argue its impossible to presume what would be the factors that would cause the plan to go so horribly wrong at the beginning of the project and I have to agree. It could be something completely unforeseen. It does seem however, that this need for a backup plan does arise only when the project has gained recognizable Fubar’d certification. Many factors could play into this - but most often its one of honesty. Honesty in the status of the project. Honesty in quality control. Honest in project debt. No wonder developers tend to be pessimistic - if they set the expectation that they won’t get what they need when they need it, they’ll be pleasantly surprised when they get it remotely close to on time.

If the scope is fixed - a plan B could be something that handles the ability to phase in functionality. Any functionality that is required and that other features/items are dependant on, would have to be of top priority. But other features that don’t deter from the overall experience, could be items that could be pushed as they become complete and demoted from the must have list. This does two things. It shows the client you are committed to their deliverable yet are more committed to delivering something of quality. For the team, it alleviates some stress and pressure by providing an alternative and knowledge that the clients’ expectations are being properly and actively managed.

Clients typically are flexible. No one wants to order and pay for a beamer and get a sup'd up chevette instead.

ﾠ

ﾠ

ﾠ

Read more from Stacey Mulcahy.