What is already interesting (after half a day) is that this approach drives a type of behaviour. The behaviour is that the "process" is the end... not a means to an end. This is the wrong behaviour for any programme... and explains why Government IT projects fail. GF could comply with every process, to the letter, yet never deliver the project...
GF looks back at a crusty old project manager of his... His view was that the project management process should be invisible, unless things were going wrong. GF never knew a single project of his to fail (and he played a mean harmonica).
So what do you need?
- A clear (common) vision
- Clear business requirements from an empowered, small, business expert - with a common understanding on between business and the project.
- A plan that shows the interlocking components
- Some resources who are skilled and dedicated and understand the vision
- Good communications
- Good change management to control impact of late changes to requirements
- Test management (involved from the beginning)
- Configuration management
- Talent
- Sufficient budget
- Realistic timescales
[File under: Project Management]
No comments:
Post a Comment