Oh boy. I've been around these trenches long enough to have seen the dark side of 'shipping' strategies.
Rarely in large enterprise environments are projects greenfields. The new system is often there to replace some existing Line of Business system.
Inthese cases the pervers but common shipping strategy is:
1. freeze all maintainance and evolution of the existing system. Seems reasonable until you realize that these enterprise projects are multi year calendar endeavours and the business will not stop changing during that time. The idea is not realy to halt all development, just to inctease the friction of getting anything done on the now declared 'legacy' system above an administrative pain threshold.
2. Commandeer all the IT staff to serve on the 'new' system's project team and overwhelm them with tasks. Make sure they remember any time spend on the 'legacy' (keep hammering in that term) codebase is basically waisting time assuring you'll end up at the bottom of the corporate dinosaur tar pit at best.
3. Force they 'new' system into production long before it is ready. Use all the leverage you build from point 1 to promise 'going forward'. When essential gaps to support the business are pointed out en mass week1, reverse the tables and intigate a very heavy administrative process demanding proof that the lacking functionality is actually required with a full ROI breakdown coutering your handwoven 3 minute overinflated guestimate for implementation. Again, you know essentials are missing, you are just trying to gain time as the longer you can stay deployed the higher the chance you will.
This process is very destructive to not just the business, but also moral of most involved. Most projects taking this scorched earth shipping strategy fail regardless. This is no small contribution to the cynicism oftem found in veteran battle hardened corporate IT shops.
Eventually someone important gets a call from a more important client on the golf course about how his company fucked up on his watch, the new thing is cancelled, the old one is reinstated (to much rejoicing) and the 15% of the huge new effort that actually worked is distilled in to a plugin feature and bolted on to the old product and everyone moves on.
The original PM responsible for all this gets an L+1 diagonal promotion at a new company and pulls this shit again.
PMO never comes out of these debacles worse off, even if the project burned dozens of millions with 0% result. It is never their fault, there are plenty of scapegoats around, preferably smaller external contracters. The threathened lawsuits with the big contracters get settled and kept hush hush as neither party wants the bad press. Just the cost of doing business for them.
Most of the time project leads can stay with the company in another division as tension with the old IT crowd woul be a bit much, and even get promoted as they 'gained experience'.
Rarely in large enterprise environments are projects greenfields. The new system is often there to replace some existing Line of Business system.
Inthese cases the pervers but common shipping strategy is:
1. freeze all maintainance and evolution of the existing system. Seems reasonable until you realize that these enterprise projects are multi year calendar endeavours and the business will not stop changing during that time. The idea is not realy to halt all development, just to inctease the friction of getting anything done on the now declared 'legacy' system above an administrative pain threshold.
2. Commandeer all the IT staff to serve on the 'new' system's project team and overwhelm them with tasks. Make sure they remember any time spend on the 'legacy' (keep hammering in that term) codebase is basically waisting time assuring you'll end up at the bottom of the corporate dinosaur tar pit at best.
3. Force they 'new' system into production long before it is ready. Use all the leverage you build from point 1 to promise 'going forward'. When essential gaps to support the business are pointed out en mass week1, reverse the tables and intigate a very heavy administrative process demanding proof that the lacking functionality is actually required with a full ROI breakdown coutering your handwoven 3 minute overinflated guestimate for implementation. Again, you know essentials are missing, you are just trying to gain time as the longer you can stay deployed the higher the chance you will.
This process is very destructive to not just the business, but also moral of most involved. Most projects taking this scorched earth shipping strategy fail regardless. This is no small contribution to the cynicism oftem found in veteran battle hardened corporate IT shops.