For business systems, the project go-live date really does matter -- and project managers seem willing to sacrifice budget limits more often than they're willing to blow past a scheduled deadline. There are sound business reasons for doing this as bonuses, commissions and stock valuations depend upon the revenues and earnings for the quarter. So you don't want to make any changes that would mess up this quarter's results, but you do want to implement changes as early as possible next quarter.
Now for the problem: You've got a few days to go, and the time pressure to do the cutover will only increase. And with that, the collective IQ of the project team will only decrease. Because of the 4th of July weekend, everyone will be lobbying for a slash-cutover to the new system so everyone can make their Q2 bonuses.
In the final push to release, you'll hear all kinds of helpful suggestions to expedite things:
- Skimp on unit tests, focus on integration testing.
- Do integration testing and user-acceptance testing in parallel.
- Skip the configuration control overhead.
- Do debugging and make fixes directly in production.
- Skip some of the harder test cases, particularly for integrations.
- Do functional testing only for the top three use-cases.
- Shift the user-acceptance testing to an offshore team.
- Worry about data quality after go-live.
- Bring in a tiger team of additional staff.
- Get the consultants to work double shifts.
- Forget about doing business process validation and code reviews.
- Don't turn on all the integrations until later; do nightly batch data updates to keep things somewhat synchronized.
- Spin up a shadow copy of the new system and have a few low-impact users on it, so you can claim go-live even though the heavy-lifting users are still on the old system. Meanwhile, developers will work only on the real version of the new system where there are no users. (You can call this the "Potemkin Village" strategy -- you'll also need some low-cost offshore resources to do the triple-entry of data that will be required.)
- Don't do short weekly, task-based, effective training. Instead, do it as one day-long session.
- Skip the luxury of hand-holding, developing power-user mavens, or go-live-week support. These things will just happen on their own, and our developers will need to get on to the next project immediately (because that one's late, too).
In other words, you'll hear all kinds of half-baked, rookie ideas coming from people who are otherwise professionals. This is the kind of stuff you'd immediately reject a job applicant for suggesting, but when the ideas come from a review committee full of bosses...well, you sometimes have to bite your tongue (and sometimes almost clear off).