Being realistic about large IT projects

This is well outside my normal area but I’ve been asked to think about the true costs of rolling out a major new (or replacement) system for a university, using VLE (virtual learning environment) as an example, and I’m assuming the system will have a projected lifetime of 10 years.

To start thinking about this I’m going to start with

• try to divide it into more managable tasks
• ask the community (Hi, that’s you!)

Phases

What seems clear is that we have some very distinct phases and that the costs, staff time and skills required will not be consistant.

Project management skills are required over the whole project until it’s fully deployed. As probably are user-experience skills in an ideal world.

1. Scoping;
   • What do we need?
   • Do we need to do anything at all?
   • Could we just invest this cost+effort in the current system?
   • Identifying stakeholders.
     • Need to make more effort to get typical end users represented not just “power users”.
2. Scouting
   • What’s out there?
   • What software and services could we use for this?
   • Could we build it in house?
3. Decision point.
   • Decide on a plan
   • Cost it
   • Get the costs agreed
   • (at this stage I think the IT dept usually lowballs the estimates and then ends up borrowing from normal operations resources as a result)
4. Learning, prototypes and recruitment
   • We’re going to need staff who grok this new system
   • They’ll need training and practice
   • …or we could try to hire them, but universities don’t have much wiggle room to pay for experienced specialists.
   • …if we’re training our own staff we should give them a chance to practice and play. That will cost time and money and probably software licenses.
   • We don’t do enough of this
5. Minimum viable product
   • Once we start building for real we’ll need more people involved
   • We generally seem to skip MVP and go straight to 100% deployed and if your feature isn’t in that version, tough luck.
   • Experience has taught people that “phase 2 or later” features are often never done so it causes way too many things to go into “phase 1”.
   • Information architecture within the system and integrating with other systems
   • User experience oversight both for the system and it’s integration into our overall user experience (we don’t do enough of this)
   • At this point the project also starts to use lots of resources from existing IT teams including
     • Data integration
     • Testing
     • Resource deployment (VMs, etc)
     • Interface design
     • Copywriting (documentation)
   • Moving information from the legacy system is a big job here and involves the data owners as well as techies.
   • Also need management of communication between the various teams and various stakeholders
     • I’m not convinced “putting documents on sharepoint” counts as genuine effective communication.
     • We shouldn’t be afraid of getting stakeholders and techies in the same room, or even from running “jam sessions” where ideas can be explored rather than comunicating via word documents. Also, done right, this makes the shareholders more tolerant and flexible and the techies feel more appreciated and proud of what they are doing
6. Content creation
   • This is a separate job to branding and templating and linking
7. Phases 2,3 etc.
   • This is something which should be budgeted for properly. Nothing is ever right first time and it takes 6 months of using it to understand how it could really be better.
   • We should ensure that small win deployments happen now and then so users and stakeholders see there is progressive improvement. This will encourage constructive suggestions.
8.  Business as usual
   • The system will still require maintenance, security patches and whatnot
   • Minor new features will be needed throughout it’s life
   • Other systems will want data out of this for reporting and integration
   • At this point we sometimes have the number of dedicated IT staff for a system drop to 1. It happens. And then they leave and the system gets dumped on someone who just caretakes it from then on. I’ve only see that happen on smaller systems, not Enterprise Apps.
9. Major upgrades
   • These are effectively a project in their own right, but in addition to the obvious technical cost they will almost certainly cause knock on resource requirements if they alter the object-model, APIs etc. They can also require reworking the documentation.
10. End of life
    • One day this service will be replaced with something new and shiny. At that time people will need a really good grasp of what processes it performs and what data it holds. Chances are those people all retired by now!

What actually happens is that the project phase-one pretty much always goes over time, usually by months or years. The reason for this is tricky to pin down for sure but is probably partly that really big IT projects are expensive to do right so we under budget them and then “borrow” from existing teams to resource the difference, hiding the true cost. I recently heard the comparison of a new university enterprise IT system to a new university building. The projected lifespan is a little different but I suspect the analogy holds up well, including the fact that you can move into a building even if not all the rooms are decorated yet, and that someone will need to find the budget to insure it and pay the heating bill.

This post was just a quick brainstorm to start thinking about the problem. What did I forget? Where am I naive or just plain wrong?