Current Articles | RSS Feed RSS Feed

To meet an impossible deadline, cut your time in half

Posted by Andy Singleton on Thu, Sep 13, 2007 @ 10:33 AM
 
[Repost]  A major consumer goods company told me last Tuesday that they wanted to put in a gift purchasing system. This involved a couple of roles (giver and receiver), a credit card gateway, Web services for fulfillment, email reminders, etc – a serious application. I would normally want about 6 weeks to build and test such a system. They told me that wanted it for the following Monday – 6 days away – and they were willing to pay a premium for that. I took the job, and I told everyone that it wouldn’t make sense to do it in six days. Instead, we needed to do it in three days.

When I plan a software development job that has a deadline, I use a 50% scheduling rule. We need to have a relatively complete, working version of the software available for testing when we are halfway to a full release. If I want to do a product release 3 months from now, I plan to have a testable version of the product in 1.5 months. The halfway release can be rough and even ugly, but it needs to do most of the things the complete release will do. This rule ensures that the incremental release process can work its magic. You have half of the total time available for finding and fixing problems and making improvements.

What if someone gives you a seemingly impossible schedule? What if you don’t have enough time to get even the first version out? In this case, I still use the 50% rule. You force yourself to deliver something in half the time.

This just recognizes reality. In reality, no product is done in its first testable release. If you think you can do a release without spending half your time on incremental improvement, you are probably wrong. If instead you make a simpler product and give yourself a few cycles to make it work properly, you will look pretty good. As an added bonus, you motivate the business guys that you are working with to deliver all the stuff you need.

We posted our midpoint release early on Friday. It didn’t look great, but it had all of the transactions and it worked. I got my gift. Thursday was an all-nighter, but now it’s Sunday, and I have time to write this blog post.

[This is a repost of something that appeared on my personal blog last December.  It's a useful hint that we forgot to bring over when we moved to the Assembla blog in June.]

Tags: , ,

COMMENTS

I just drew this up last week in advance of yet another mid-sized website, then found your post from a friend's Delicious bookmarks. It's inspired by Joel Spolsky's Evidence Based Scheduling, but based on what I actually did with my development colleagues on the last two projects, which worked really well. My aim was to limit iteration with the client to crucial stages that require firm approval, and otherwise get on with the job. Clients (mine, anyway) like to see something complete at milestones, and not be asked 'what do you think?' too often. 
 
1. break down the project and roughly estimate each distinct job in hours. Omit nothing. Compare this to the proposed budget. 
 
2. track ALL time spent on the project: 
 
keeping track of time: 
- start the clock when you start work and give the work a name 
- stop the clock if you need to do something else yourself 
- keep the clock running for interruptions about the project 
- keep the clock running for drinks and short breaks, but not meals 
- make a note of the time elapsed when you stop the clock 
- map all time against your hourly fee and the budget 
 
managing emails and meetings: 
- time initial meetings with client under contingency fees 
- allow time for exchanging emails throughout the project 
- collate responses to multiple smaller emails in one reply 
 
3. strategy and development form logical stages 
 
planning and strategy: 
- constrain expectations about the project to available resources 
- draw up a firm written outline of the project as soon as possible 
- add the author, a date and version to each written document 
- make sure every document filename reflects the date and version 
- do nothing until the outline is approved by all parties 
- resist 'can we just' features unless they are very good ideas 
- use your experience to guide clients towards workable solutions 
- identify all essentials but include optional items as choices 
- save optional items that can't be fitted in for future stages 
 
prototyping: 
- get the client to write up a complete content plan 
- group the content into site plan sections (IA) 
- agree to make a prototype based on the firm plan 
- use typical real-world content from the client 
- build the prototype quickly with what content you have 
- add a sense of ownership with house styles or logos 
- make it look neat and clean without any clutter 
- get everyone to test it and feed back their ideas 
- confirm that the prototype is approved before building 
 
design and development: 
- make a visual of the proposed style for one page only 
- get approval for all the details of the design 
- once approved, apply the style to the whole prototype 
- make everything work with real-world examples 
- tackle and discuss unresolved issues as soon as they arise 
- be very honest about what can't be done at this stage 
 
testing and final approval: 
- as soon as there's a final version ask the client try it out 
- implement immediate feedback over the next few days 
- then leave the site for the client to try for a week or so 
- use the remaining budget for final changes 
- agree on a cut-off point once the client is happy 
- agree to retain a small amount of budget for small changes 
- agree to add outstanding changes to the next phase 
- sign off from the job when you get paid 
- continue to log feedback from the client and users 

posted @ Thursday, July 02, 2009 8:08 AM by Dave Everitt


Actually, I forgot to add that experience allows you to estimate time against budget intuitively. If you don't have this intuition, or find yourself delivering too much for too little, the rough estimate is a reality check to help stop you taking on underfunded or over-ambitious projects.

posted @ Thursday, July 02, 2009 8:23 AM by Dave Everitt


Comments have been closed for this article.

Follow Assembla

twitter facebook youtube linkedin googleplus

Subscribe by Email

Your email: