Keerin Saeed Forwards Advice from Steve Cotterell by Email 9/1/05 from across the UK
Dear Max,
Thank you for your Ask an Expert question.
You asked, "How long should a software, or IS/IT project take?"
Steve Cotterell, Technical Editor of Project Manager Today replied:
Because of their nature, I think that 'normal' commercial software projects lend themselves to treatment as RAD (Rapid
Application Development) projects. Basically this involves setting a time limit on the development, prioritizing the work to
be done and accepting that, on the agreed end date, the project is finished.
The opposite of this method is to treat a software development as a normal project, accepting changes in specification etc. as the project evolves and allowing the developers to tinker with each piece of code until they consider it to be 'perfect' (and it never will be!). The danger with this approach is that the project is certain to over run, wildly exceed its budget and, as a result, fail.
The need is, therefore, to keep the development team focused, with a sense of urgency and, I suggest, this means that the time to finish should be measured in weeks or (a few) months - no more than, say, five or six. If this is not going to be possible, because of the sheer size of the task, then I suggest that, before it is presented to development teams, it should be broken down into separate applications, each of a more manageable size, and treated as a programme of projects, each project handling a separate application. These projects should be worked on, concurrently, by different teams. There should, of course, be inter-team and inter project liaison!
This is even more important if the specifications of the job to be done are affected by something that is subject to rapid change, without much notice - government legislation comes immediately to mind. If the legislation that the software is designed to comply with changes during its development, the project is almost certain to run into difficulties.
Having issued a successful first version of the application, there is no reason at all why another, similar project should not be set up to produce version two which incorporates some of the functionality that there was not time to include in version one, fixes bugs (there are always bugs) and incorporates (if possible) any changes in specification that have arisen since the specification for version one was agreed.
Software projects that involve safety and/or matters of life and death (for example, air traffic control) are a different matter. Whilst it's still important to keep the developers focused and with the same sense of urgency, there has to be a much greater emphasis on accuracy and testing and so the additional cost of providing these will have to be written into the project budgets from the outset.
I hope this answers your question
Kind Regards,
Keerin
keerin.saeed@apmgroup.co.uk
Max's Comments
Steve Cotterell is Technical Editor of Project Manager Today and wishes to retain copyright to his response so that neither
it, nor extracts from it, may be re-used elsewhere without his express written permission. Project Manager Today is a print
magazine and membership-based site supporting the project management community in the United Kingdom. Keerin Saeed is Webmaster
of The APM Group's Interactive
Community of Practice (www.apmg-icp.com), the first online community for anyone involved in program, project and risk management.
|
Gary
Pollice Comments by Email 8/8/05