Negotiating tight schedules

I follow very few TV programs. One that I happen to love is called game of thrones.

In one of the episodes, one of the characters demonstrates power in a brute way. Jeremy Sadler gives a great summary of the scene EXAMINATION OF A SCENE: CERSEI AND LITTLEFINGER

As developers, we sometimes come into direct contact of this kind with corporate politics. Not being used to dealing with politics, we usually end up feeling hopelessly trapped like little finger.

In my last entry, Dangers of underscoping I highlighted the importance of pushing back on unrealistic schedules. Thankfully most clients don’t walk around with armed guards. Even better, the client wants their project to be successful. Being the technical one, you should be able to provide some solutions to the schedule dilemma.

For this entry, we are going to look at some of the more effective ways to ease schedule pressure without offending the powers that be.

You ain’t gonna need it

Pareto law, otherwise known as the 80/20 rule states that 80% of the effects are caused by 20% of the factors. This is just as true in software Chaos report 2015.

A good number of the features that the client is requesting, they will probably never need it. Telling them so is however not likely to be an effective strategy. What would be an effective strategy is suggesting that an MVP be built first.

The MVP would then inform the next work to be done. This is good for the development team because now they have less work to do with the available schedule. It is also good for the client team because they get their product to their customers faster and at a cheaper rate.

Highlight time consuming features

Believe it or not, it may not be as obvious to the client that features that they are requesting take inordinate amount of time. You may find for example that initiating an automated refund policy consumes four weeks of development time, but only a minute to explain the functionality.

Based on your estimations, you can tell the client how much it actually costs in terms of development time to roll out the various features. They may then chose to drop time consuming features that have little value to the project.

Buy don’t build

For all the vendor software available in the market, you maybe surprised at how much needless development actually goes on.

Sometimes a bespoke solution that would take weeks or even months to develop could be easily replaced with a generic one that takes minutes to install. Sure it may not be up to the quality that you expect but if its not core to the clients business then sometimes just enough is all you need.

For projects that are really squeezed for time, I would go so far as to recommend that you build the project in a way that aligns with existing third party tools.

Bigger team

If you are not yet deep into the project, more developers can make the project go faster. This can be an option for clients who don’t care about the budget as much as they care about timeliness.

This option is a dangerous one for new products. This is because the scope may not be clear and bigger team means higher communication overhead.

Motivate the team

Energy acts as an accelerator of productivity. If all else has failed and now you must work with a tight deadline, then it’s time to sufficiently psyche up your developers.

A trip to the coast, promise of new devices or even just their own private space. This external rewards can prove to be the elixir that burns all the stories in half the time.

Be warned, this strategy will not suffice over the long term. Eventually burn out catches up even to the most energetic of us.

How do you negotiate tight deadlines? Talk to me on my twitter @jchex or in the comment section below.

Facebooktwittergoogle_plusredditpinterestlinkedinmail

Published by

jchencha

API Engineer