The plan is to note all the little steps and stumbles that a new project takes on its way to failure.
Day 1: I’ve just had a meeting to talk through the pitch designs, proposed functionality, and sitemap for a new project, which has to be delivered by the end of July. The sitemap is out of date, including sections that apparently won’t exist in the finished project; functionality is uncertain, and designs are incomplete. We have another meeting later this afternoon to meet the Group Account Director, to bombard him with questions.
Day 1(a): We heard that the project, which had been costed at £94K, had actually been sold at £54K, and that we offered hosting at a monthly cost of £250, which by our estimates will require load balanced SQL Servers (which we recently costed at £2 – 3K pm).
No, there’s nothing that can be descoped or delivered later; it’s all Flash; and the designs haven’t been completed yet alone signed off.
Oh, but the deadline has apparently moved to the end of August 
One of the most concise and accurate summaries of available processes that I’ve come across. If only more devs and Project Managers printed this out, we would have a much more successful industry record.
37 Signals are experimenting with a 4-day week, and finding it works.
They reckon that “urgency is acidic” – it burns out morale, especially when working towards an emergency deadline lasts more than a day or two (like, say 7 weeks plus – you know who you are!).
If your deliveries are that critical to the hour or day, maybe you’re setting up false priorities and dangerous expectations.
Re-reading Agile Management for Software Engineering
*, I got stuck on the phrase “perishable requirements”.
I re-read it several times, and each time it sunk in deeper just how important this concept is: this alone proves the worth of an agile approach to project development. Requirements go stale.
Most obviously, they run the risk of becoming obselete as the team and client’s understanding of the project evolves; but, equally importantly, they suffer atrophy simply through lack of use.
Once captured and defined, a requirement has a half-life – the longer it gets left in the requirements document without being actively worked on, the poorer the knowledge of that requirement. Clearly, if the developer leaves, the team suffers massive impact in its understanding of the requirement. But, even if the developer stays, their understanding and knowledge of the requirement withers as they work on other things.
The reality is that a requirement can rarely be so fully captured that it doesn’t depend on an individual’s understanding and definition of it.
The solution to this problem?
Define a sub-set of requirements that can be worked on within a specific timeframe. Move from requirements capture and definition to solution implementation within the same timeframe. Work agilely.
* Eli Schragenheim & David J. Anderson, Prentice Hall, 2003 (ISBN: 0-13-142460-2)
Development, management, process | jamesk, May 7, 2008 3:29 pm | 
Comments (0)