Another comment I’ve received on last month’s posts, relates to how would I handle IT projects that couldn’t possibly be completed in a two year period?
Yet again we’re back “eating an elephant” – breaking the project down into smaller, more manageable bites. But perhaps more importantly, it’s also down to ensuring that the requirements for the project have been accurately and completely defined – prior to a specification stage that includes detailed walk-throughs with real-life end users. This is the most important phase of an IT project – yet is typically rushed or overlooked, and frequently completed without adequate reference to the managers and end-users that will be using the system.
I’m a great believer in “phased fixed price” contracts for dealing with large projects that require the development of customised software – splitting out each phase into separate contracts where the current phase is on a fairly firm basis (ideally fixed price against an agreed definition), with budgeted prices for the next phases (typically based on some broad brush assumptions of what will come out of the each phase). Such an approach allows for the requirements collection phase to be contracted separately and carried out by potential eventual developer (if you want to know how to do this in a way that allows for subsequent changes in contractor, please contact me).
When dealing with my managers and team leaders, in the early stages of such projects, I’ve encouraged them to “define the box” – not necessarily what’s in the box, but where the edges are – so that we can know when the project “slips out of the box”. Sitting down with a customer to discuss those box outlines during the requirement stages then proves to be very enlightening – normally for the customer who starts to realise both those areas that he’d forgotten about, and the sort of size/scope of his project.
I also like to see throw-away prototypes, different screen layouts and sample reports as early as possible in the specification stage (but don’t try to turn the prototype into something used in production – every time I’ve seen this tried it’s failed). I remain a firm believer in documentation for all requirements and specifications – particularly for large projects.
“Rapid development” approaches can be adopted for individual “boxes”, but only on the basis of a clear, documented definition of the “box outline”, and full recognition by the customer of the implications of such a development route – but personally, I would try to stay away from such an approach in large projects, unless they are being completed by your own in-house development team (and even then, I’d look for a track record of success on smaller projects before employing this approach on large projects).
Contracting for the technical infrastructure can be handled in parallel, or more likely with large projects, after the detailed specifications for the major “box” elements have been signed off. Hopefully the needs of the training and roll-out stage will have been identified in the requirements collection and subsequent phases, to ensure that topics such as software installation and upgrades can be as automated as possible, and the need for end user training minimised.
There are many potential downsides to this approach but, handled properly, this way can add a level of certainty to projects that is sadly lacking for many current, large projects. Yes – as requirements grow, or specifications change, costs and timescales can increase – but then informed decisions can be made about subsequent phases, expectations set better, and there is a much better chance that the whole project will see the light of day as a success.
P.S. For some of the laws on project management for large projects, including the “90% complete syndrome”, O’Malley’s corollary to Murphy’s Law, and many others, please visit my website.
No comments:
Post a Comment