For business systems, the project go-live date really does matter \u2014 and project managers seem willing to sacrifice budget limits more often than they\u2019re willing to blow past a scheduled deadline.\u00a0 There are sound business reasons for doing this as bonuses, commissions and stock valuations depend upon the revenues and earnings for the quarter.\u00a0 So you don\u2019t want to make any changes that would mess up this quarter\u2019s results, but you do want to implement changes as early as possible next quarter.\u00a0\nNow for the problem:\u00a0 You\u2019ve got a few days to go, and the time pressure to do the cutover will only increase.\u00a0 And with that, the collective IQ of the project team will only decrease.\u00a0 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.\u00a0\nInstitutionalized rationalization?\u00a0\nIn the final push to release, you\u2019ll hear all kinds of helpful suggestions to expedite things:\n\nSkimp on unit tests, focus on integration testing.\nDo integration testing and user-acceptance testing in parallel.\nSkip the configuration control overhead.\nDo debugging and make fixes directly in production.\nSkip some of the harder test cases, particularly for integrations.\nDo functional testing only for the top three use-cases.\nShift the user-acceptance testing to an offshore team.\nWorry about data quality after go-live.\nBring in a tiger team of additional staff.\nGet the consultants to work double shifts.\nForget about doing business process validation and code reviews.\nDon\u2019t turn on all the integrations until later; do nightly batch data updates to keep things somewhat synchronized.\nSpin 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.\u00a0 Meanwhile, developers will work only on the real version of the new system where there are no users.\u00a0 (You can call this the \u201cPotemkin Village\u201d strategy \u2013 you\u2019ll also need some low-cost offshore resources to do the triple-entry of data that will be required.)\nDon\u2019t do short weekly, task-based, effective training.\u00a0 Instead, do it as one day-long session.\nSkip the luxury of hand-holding, developing power-user mavens, or go-live-week support.\u00a0 These things will just happen on their own, and our developers will need to get on to the next project immediately (because that one\u2019s late, too).\u00a0\n\n[Related: How to find the perfect project manager]\u00a0\nIn other words, you\u2019ll hear all kinds of half-baked, rookie ideas coming from people who are otherwise professionals. This is the kind of stuff you\u2019d 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).\u00a0\nWe\u2019ve all been there.\u00a0 The whole industry has been there since the \u201860s (\u201cThe Mythical Man Month\u201d and horror stories from ControlData OS releases come to mind), and only the most zealous Agile team will resist the temptation to cut corners.\u00a0\nBut the industry doesn\u2019t seem to be getting any better at this, particularly when it comes to projects with lots of dependencies, or with complexities that could have been avoided.\u00a0 I\u2019m particularly irked about the kind of magical thinking that just begs for train wrecks:\u00a0 \u201cwell, while we\u2019re at it, let\u2019s add THIS risky artificial complexity to THAT out-of-control project\u2026\u201d\u00a0\nThe answer is in the question\nHow to avoid this kind of project schedule crisis?\u00a0 Make the project less tightly coupled.\u00a0 We did it with software (asynchronous web services), why aren\u2019t doing it with the project itself?\u00a0\n[Related: 11 communication skills of effective project leaders]\nTry these ideas on for size:\n\nMake bonuses and other incentives contingent on achieving IT goals, but make sure they are not tied to specific go-live dates.\nTo the extent possible, base all integrations on a real messaging system that logs all messages (and keeps the logs for at least a couple of weeks) to improve debugging, testability, reconciliation and recovery efforts.\nJust assume that every integration will have more dirty data and muddled semantics than you can imagine. So no matter how realistic the schedule is for migration, normalization and cleansing...add 25 percent to it. Really.\nDo the continuous integration thing:\u00a0 All code has unit tests, complete system builds nightly with test suites that grow along with the code, bring external integrations and some real data into the system as early as possible in the project.\nDo the user-centered design thing:\u00a0 get users working with the UI and evaluating the correctness of any results before you\u2019ve reached 25 percent of the project spend\u2026and keep them involved until the end.\nDo the staging\/sandbox thing early: spring for a \u201cfull sandbox\u201d or staging copy from every vendor that will sell you one. Use them from the mid-point of the project, at the latest. Really. Connect the sandboxes to each other so you have as realistic a development and testing environment as early as possible.\nDo the reality-therapy thing:\u00a0 your executive sponsors (you do have executive sponsors, don\u2019t you?) should be giving demos of their part of the system to their teams at the end of each sprint.\u00a0 This is good for user adoption but it\u2019s even better to make sure expectations about schedule and features don\u2019t get out of hand.\nDo the prioritization thing:\u00a0 the way to avoid the end-of-project crash is to reduce deliverables along the way.\u00a0 This is really difficult, but it is the rare project indeed that has more budget and schedule than it needs.\u00a0 So lighten the load at every turn \u2014 enforce a feature diet.\nDo the game-theory thing:\u00a0 otherwise known as \u201chave a backup plan,\u201d this involves a serious discussion at least 6 weeks prior to go-live about how the business would handle a \u201cno-go\u201d decision.\nUn-do the kill-the-messenger thing:\u00a0 at every significant milestone review, give explicit permission to team members to reveal negative information.\u00a0 Through your words, actions and facial impressions, encourage people to be realistic about schedules and risks.\u00a0 Never punish the delivery boy for bad news, and don\u2019t \u201cyes men\u201d and used-car-salesmen behavior.\nAnd the grand-daddy of them all \u2014 un-do the big-bang thing:\u00a0 use phased deployments, with each functional increment building upon a stable base from the previous cycle.\u00a0 Bring in historical data incrementally (start with last year\u2019s data, then add data from two years ago, etc.) and be willing to have low-priority data available only offline for a while.\n\n\u00a0Some of the above ideas may sound nuts.\u00a0 But why are we still making project decisions with management ideas from 50 years ago?\u00a0 It\u2019s time to try something new.