A false sense of urgency

From: http://www.savagechickens.com/2008/09/deadline.html

One of the dilemmas with building something for yourself, rather than for a third-party, is you are never really forced to commit to a delivery date.

Or, at least, there is nobody else who will be angry with you when you run late.

For those of you in this position: how do you create a false sense of urgency for you or your team?

I’m interested in your ideas.

7 thoughts on “A false sense of urgency”

  1. 1. Development promises to long-term partners. Missing these are a major credibility blow, so motivation to meet or beat them is extremely high.
    2. Feature releases/redesigns for conferences or other public events. Wanting something ‘cool’ or ‘impressive’ to show off to your industry (customers/competitors/potential partners) is major motivation to get things done.
    3. Ultimately the boss/project manager has to impose and enforce deadlines to meet some rational (and preferably incremental) development plan.

  2. Even if you are building for yourself there are always consequences of missing deadlines. The key is to find the consequences or incentives that matter for an individual. They could be

    1. Business reasons – Less of a window of advantage in the market
    2. Can’t get onto the next thing until this one is done
    3. Personal cashflow (if I don’t finish this, then it can’t generate cash, therefore I can’t meet my other commitments)
    4. Personal credibility – stating a date to an Advisory Board can be helpful (which is a really good reason to have one)
    5. Tying delivery to a meaningful celebration / reward – could be a trip or a party or some other kind of thing

    I think the key is that it shouldn’t be a false sense of urgency – there have to be real consequences for missing dates (and conversely incentives to set and hit them)

  3. Personally I find this really difficult, working from home makes it hard to stay focused when there are a lot of other things to grab my attention. Regularly reviewing goals helps to stay on track. I was once told that instead of making a list of things you haven’t done (which can be demoralizing), make one of things you have achieved, say over a weeks period. It is motivating to see what you have done, then you can focus on what is left to reach your goal, whether that be a delivery date or something else.

  4. Small and regular releases. It means that getting stuff out the door becomes a hygienic activity and ultimately a part of the culture.

    So far September has seen 6 releases here at Ponoko. Our monthly average is 16 releases per month for the past 11 months.

  5. I like your thinking Dave5 [and I like your site too by the way]. Deadlines were the currency I worked under during my 24 years in advertising as a creative… miss them, job’s on the line. That wasn’t much fun but certainly got the juices flowing. Trouble is you get used to relying on those juices, and that only leads to trouble down the line. I know! Now I work from home and my greatest motivator/fear-factor is my good wife! Kidding. It’s the positive motivation of seeing my new baby grow… http://www.cleverbastards.co.nz

  6. I have been involved in companies int he past where ‘deadlines’ meant the night before we all stayed up until the early hours to get stuff done.

    I HATE working that late, and my brain is asleep well before we finish, so I have been looking at alternatives.

    So even though most of our work is client based now, and we only have 4 people working here, I have experimented with a deadline motivator.

    Set mini deadlines – actually plan the project out rather than waiting for the major deadline. We set smaller miles stones and stick to them :)

    We generally attempt to finish projects early (Unless they are literally a week long) and never have too much stress doing it. There is the odd exemption, but as a general rule, I find well planned projects = easy deadline meeting!

  7. I have had the most success by simply breaking the project, or daily coding life, down into smaller deliverables. Here is why.

    You have to remember that developers on an in-house team are in it for the long haul. There IS NO end of project, because there will be a continuous list of features and enhancements to add. The business sees new and exciting features to meet business requirements to help grow the business and every now and then some of these are REALLY IMPORTANT. Developers see a looong tunnel with no light at the other end. Also there is no big bad customer.

    By having smaller time-boxed projects you give them a light, and a deadline to work to. Keep these mini-projects (or sprints) consistent in size and length, for example 4 weeks in duration. By starting with the time-box you then figure out WHAT you can achieve in that time, and agree upon it. The developers know what’s in store for them in the next four weeks, and if they leave it to the last minute then they will probably get sick of spending every fourth Friday working to 2am to meet the agreed deadline.

    Also figure out who the customer is. This should be the person who OWNS the product and they are the person the team will be letting down if they don’t deliver. So make sure they are relevant and it is clear WHY the work is important to then. They could be the sales manager, and they need a new feature to counter a competitors surprise release of a new service. It could be the head of customer service, who needs some enhancements to make their job easier so they are not having to do a manual task 80 times a day.

    It is all about motivation, and nothing to do with laziness. If you have something to release every four weeks then there is a sense of completion, and be sure to celebrate it! The team should win together. Then take a break from coding, and plan the next four weeks. If you dont complete the four week sprint, then the team all fails together.

    The four weeks could be eight in your case, or two. This should be however long you can go as a business before you change your mind and need to change the deliverables. At the same time it is as short a period the dev team can run and achieve something meaningful. This period needs to include testing, and deployment also so at the end of it the team can 100% move on to the next sprint, and there is no tidy up from the last.

    So management get a fairly predictable road map.
    Developers get a manageable workload and a regular sense of completion.
    Everyone gets an agreed working contract so they all know the “rules” and nobody should break them.

    Thats it for starters. These are principals from SCRUM see http://en.wikipedia.org/wiki/Scrum_(development).

Comments are closed.