Protecting Deadlines for Interactive Projects

A common mistake that marketers and executives make is in assuming that deadlines for interactive application design and development can be flexed in a similar manner to traditional marketing, advertising, branding, and visual design deliverables.

In particular, I am referring to two common scenarios that can compromise the integrity of your final deliverable—functional, stable, and bug-free code that renders properly across multiple browsers or app platforms.

Scenario 1: Heel-dragging at the initiation of a project—either in receiving a signature, payment, or critical information to start work—with the assumption that there is enough "give" in the first few weeks of the schedule to reach the provisionally agreed-upon deadline.

Scenario 2: A request is made by the client during the first few weeks of the project for the agreed-upon deadline for project delivery to be made earlier, often to accommodate a critical internal meeting or public milestone that wasn't on your direct client's radar while the scope was set.

Allowing negotiation about the boundaries of the project after you've entered into a signed contract should be a last resort for you and your team.

Here's why.

 

Fly Before You Buy

You're being tasked with building a plane, which your client wants to then use for flying tourists to some beautiful destination, like Tahiti.

Building the plane is your project. Your client believes that you and your staff are the best people to design and construct the plane, and your team requires a specific amount of time, money, and resources to make sure that the plane is functional and flight-ready. (It helps not only that the plane is pleasing to the eye from the outside, but also that tray tables can be set to the locked position, the toilets work properly, and so forth.)

You've signed a contract with a client, with a discrete set of start and end dates—when you'll begin building the plane, and when you'll deliver the plane to them.

But the contract doesn't just detail delivery requirements for the plane. You need proof that your plane can fly multiple routes without falling to pieces in mid-air. You only get paid when you've delivered the plane (the physical deliverables) as well as demonstrated proof that it can sustain an almost unlimited number of flights with proper fueling (content) and upkeep (bug fixes and updates).

Clients often aren't experts in building planes or flying them, so they'll look to you to explain the decisions you'll be making along the way that contributes to the design and construction of the plane, as well as demonstrated evidence of the plane flying for a good length of time, as well as training as to how they can fly the plane themselves. The first time they get behind the cockpit—and sadly, many CMS systems befall this problem—they may be bewildered by the proliferation of controls required to keep the plane in the air.

 

Quick Takeoffs and Market Tradeoffs

So, the question remains: Why would a client want to rush the launch of an application, at the risk of crashing their plane?

From their perspective, the takeoff of their plane—no matter how much risk there may be in crashing—can be associated with a number of factors you may not be aware of. While you are heads down, the following factors may be percolating in the background:

1. Perceived pressure from competitors, who may have announced site updates or new online products that will steal the thunder of your efforts
2. Promises made to shareholders and investors, regarding progress on marketing and product initiatives
3. Possible rewards from internal stakeholders from meeting internal milestones
4. New employees coming on board to take over responsibility—or upcoming vacations that may interfere with management of a launch

Out of all these factors, the most risky item to contend with is factor #1, missing a window for landing a new or improved product in market. If you're trying to be innovative, you have to be one of the first people to do it!

To preserve landing in that window, client will take calculated risks. And one of the easiest risks to calculate is how much pressure they can exert on their internal team and external vendors to try and make that deadline. When we lack information about an outcome, our minds most often drift towards the worst possible results. So the risks of missing that deadline often aren't quantifiable until well after the deadline has passed and the market effects have been felt. (And often correlated with #2, #3, and #4 above.)

At the start of an engagement, you need to know the rationale behind each deadline and the repercussions for not making the final launch date. This helps to guide the protection of resources and reviews over the life of the project, as well as critical features that need to be managed with deadly seriousness.

However, this assessment should gauge what are real deadlines, that carry with them quantifiable competitive advantages, and internal deadlines (i.e. arbitrary) that map to defined goals, implicit rewards, boss satisfaction, and so forth. A product launch announcement at a major trade show is quite different from an internal staff meeting. Both are important, but you have little to no flexibility with shifting the dates of SxSWi.

If a provided contract to a client has a set start date, and the client signs the contract after the agreed-upon start date, you must have in your document a clause that allows you to shift the project end-date (by an agreement in writing with the client) or adjust the project deliverables (via a zero-sum change request) to protect your project timeline.

One of those variables, time or scope of deliverables, must budge. You're providing poor client service if you can't manage a client to a market deadline with an agreed-upon set of deliverables without error or a baseline measure of quality. You're putting the error-free launch of your project at risk for every day that you give away. You know in the beginning the pain that you'll feel in the end.

Many designers are afraid to negotiate on limiting scope and giving money back to their client as a result. But it's in your best interest to earn less for the right to work less, deliver a quality product, and create the space necessary to ensure the right level of service you can deliver in the time frame.

Even clients with a modicum of website development savvy try to rush for a takeoff window—with a set of errors that may be troublesome for their customers, and your reputation. So part of every negotiation you make with a client over scope and time must acknowledge the market conditions the client is operating under, and what duress they may be placed under if they don't make a defined launch window.

*

The analogy I'm using in this post may not be perfect, but it's a vehicle that serves its purpose.

For those of you that deploy simple websites, these thoughts still apply. Even if your designs are built off a platform like WordPress, I'd still slot it in the category of "web app." (I've argued in the past for "web system" as a term to just replace how we talk about websites, web apps, and all other flavors of interactive tech, but it's not considered the Kosher lingo and I won't use it here.)

Photo from Flickr / #492776263 by Tomek Augustyn (og2t) / CC share / remix / attribution

Comments

[yvette]

amen.

[Raela Drigger]

And with the fickle internet as the plane of competition, expect take offs to be delayed, landings to be rushed, and weather interference in between. A strict deadline should be bargained before a contract is signed, and the deal should be followed to the letter. In that case, you are given fair time to work and deliver quality service.