Establishing deadlines

[lucall64]

I have discovered GTD about a month ago looking for a PocketPc software for list management and it's the thing I was looking for for ten years!
I am a software consultant and my activities are those of a software analyst, a sales rep, a software developer and a CEO of my own company

GTD is great to enhance productivity but I have not yet understood how to answer this simple, and legitimate, question from my customers:
"When will the sofware I have purchased be ready?"

When I do the macro analysis of a software to develop I break the application in some modules that I can evaluate as effort, or hours of work, to give a whole estimate to the customer. This is the simple part

When the customer approves the project I have to give a release date.
But if I don't create in advance all the Next actions needed, each with its own duration, how can I know when it will be released?
I don't have a fixed amout of time to schedule to the development, since I have to do all the other activities.

How do you manage this kind of situation?

Luca

 

[Cpu_Modern]

First, your question is THE unanswered question in software development, right? If you know how to estimate your production time in software you would be the first on this planet. I recommend Joel Spolsky's Painless Software Schedule. Far from perfect it is IMHO the best solution available out there.

 

[kewms]

When the customer approves the project I have to give a release date.
But if I don't create in advance all the Next actions needed, each with its own duration, how can I know when it will be released?
I don't have a fixed amout of time to schedule to the development, since I have to do all the other activities.

A Next Action is not the same thing as a traditional project planning milestone. In general, it's impossible to know in advance what all the Next Actions for a project are. For example, traditional project planning might have a milestone called "get customer signoff on user interface design." But it's unlikely that you'll know in advance that the Next Action to achieve that is going to be "@Email: customer IT guy to find out why email to customer is bouncing." or "@Phone: Tom, ask if he still wants to proceed after Harry quit?"

In other words, all the scheduling tools you've used for estimating are still relevant. They generally look at a higher level than the GTD Next Action list.

Katherine

 

[lucall64]

Thank you Cpu_Modern for the suggestion, I have found the article and planned to read it tonight

Katherine, I always look for your post in a thread since you seem to have that pragmatism that I like.

I know that the phases of a software project have a different granularity than Next actions, but still I have to give a Release date to the customer and none of them will accept "It will be ready when it ill be ready", I myself won't accept such an answer

Is there any software consultant who has experienced this same problem, and found a solution?

Luca

 

[jknecht]

My two cents...

The only simple answer to this is to sell smaller iterations of the software. So, instead of having to estimate "when is everything going to be done", you only estimate "when is module X (without features A, B, and C) going to be ready". Of course, "module X" has to be something marginally useful to the customer, but that helps manage risk because (1) you are working in smaller chunks, and (2) the customer gets to see progress rather than having to wait until the whole thing is done.

You should also provide an estimated end date for the whole thing, but then tell your customer that you will re-estimate that end date upon delivery of each module. Your customer should only contract with you for one module at a time, so that if they feel progress is insufficient, they can stop after any milestone and still have a partially complete but usable application.

Do a google search on "iterative development". Lots of good info there.

 

[cornell]

Hi Luca. You've hit the biggest problem in software development, the one that makes it a lot different from other forms of engineering (e.g., building bridges). Many, many opinions on this out there... Fred Brooks wrote about it decades ago in "The mythical man month" - highly recommended. I think the current "agile" techniques are great - I set up a research lab with Extreme Programming (XP), which has some deep thoughts on why giving a deadline is difficult. With XP, the deadline is no longer the issue - but *scope* is! Strongly suggest you read the Extreme Programming Pocket Guide. The best starting point I know of for this...

References:

Productivity for Programmers, #2: Efficient vs. Effective

The Mythical Man-Month - Wikipedia, the free encyclopedia

 

[kewms]

Hi Luca. You've hit the biggest problem in software development, the one that makes it a lot different from other forms of engineering (e.g., building bridges).

As a resident of the region that brought us the Big Dig, surely you know that the alleged predictability of bridge-building is greatly exaggerated?

I would say that "how long does it take" is horribly difficult to answer for almost all knowledge work. Maybe lawyers are better than most at meeting deadlines, but that's only because the courts impose horrible penalties which law firms will work their associates to death to avoid.

Katherine

 

[Barry]

It sounds like you have already broken the project into modules and estimated the number of hours of work required for each module and used this information to determine a price.

Maybe I am missing something, but if you know the number of hours to complete the work (just an estimate, of course) then the release date is directly calculated from that if you know you can dedicate x hours per day to the project. But then of course you stated that you have other duties that make it hard to know how much time you can dedicate to the project. So that would be a problem, but maybe the solution is to commit to spending x hours per day or week to the project and make that happen no matter what. Now you have something to base a release date on.

Of course the hours required may be off, etc. which is why the release date will just be an estimate, but at least you have come up with a number for the client. You can always revise it later if necessary.