An Architects Perspective on IT Programme Management
I have managed a lot of IT Infrastructure projects in my time, and a couple of smaller programmes. I have also keenly observed the management of several large programmes as a Chief Architect. This article is written from this perspective.
Some initial observations:
- IT Infrastructure Projects generally fail from at least one perspective and often more
- IT Infrastructure projects look superficially simple
- The programmes have been overly influenced by the personality and skills of the Programme Director
The following are a set of Article Titles that I intend to write over the next year or so; they give you a good idea of the issues I think are important:
- What does he do? The importance of top down Journal keeping to programme communication, coordination and team spirit
- The need for a balanced management team instead of Super Men
- Management information is a team resource
- The customer is not the same as the client
- Objectives and Requirements, why they are different and both important
- The importance of programme maturity reviews
- Conceptual integrity and how easy it is to loose it
- The lost art of estimating – take different perspectives
- How to plan a programme, top down meets bottom up and debates
- Why has my green programme suddenly gone red, (see next topic)
- How to milestone a programme
- Avoiding death by meetings
- The importance of “assumed responsibility” to successful scope management
- The importance of “eating your own dog food” and “daily builds”
- Achieving autonomous – coordinated – motivated teams
- Making the most of a co-located team
- Mitigating the risks of a virtual team
- Risks, Issues and Change a collective responsibility
- Key programme documents and processes
- Dangerous metrics and incentives
- Understanding the relationship between DCO,TCO and TVO
- The “red team”, or what to do when it all goes wrong
I think you need to focus on few ‘differentiating’ articles:
– Needs vs. requirements vs. in-scope deliverables.
– Quantifiable value delivered vs. cost of deliverables.
– Top-down design vs. bottom-up implementation planning.
I look forward to reading AND USING your ideas.
Feel free to contribute some articles along these lines, although I think these are good topics worthy of my own effort as well. Others have provided other ideas and are going to contribute. You never know we might build an alternative body of knowledge 🙂
A friend of mine wants me to add:
– Don’t assume people understand or do basic project management
– Manage the message