Ahh big projects! We all love them.
It's where all the managers feel they have something to poke, whilst techies get to play with shiny new toys... or so it goes.
I'm working on one such big project.
$customer has decided the way to manage their big project (in the multiple billion dollar mark) is to flick it all off to a bunch of consulting firms, with little or no direction... and let it run.
Even better... they are replacing their entire business systems.
Now I might not be a big fat CEO or even a CIO but I think these are things you normally don't do on a project.
I'm starting to take bets that this ends up in the papers and falls down in a screaming pile of you-know-what.
What do you think?
It's where all the managers feel they have something to poke, whilst techies get to play with shiny new toys... or so it goes.
I'm working on one such big project.
$customer has decided the way to manage their big project (in the multiple billion dollar mark) is to flick it all off to a bunch of consulting firms, with little or no direction... and let it run.
Even better... they are replacing their entire business systems.
Now I might not be a big fat CEO or even a CIO but I think these are things you normally don't do on a project.
- Define no project milestones or determine what is a success on the project.
- Have no backout strategy
- Ensure you can't run the new and old systems in parallel... due to EOL hardware on the old. Which won't support much of the firmware updates on attached gear.
- Ensure you upgrade both your storage systems and backup software right in the middle of the data import. No chance of restoring.
- Performance testing completes 3 weeks after production roll out.
- All tools and processes will not work in the new environment. This includes monitoring, backup, and agents.
- When hit with a major risk. Respond with 'continue as normal'.
I'm starting to take bets that this ends up in the papers and falls down in a screaming pile of you-know-what.
What do you think?
No comments:
Post a Comment