Dear Bob ...I just read Keep the Joint Running for this week ("Don't supersize. Chunkanize." 9/18/2006) about modifying business procedures to go along with "IT" projects. I quote (probably paraphrased as I have a lousy memory) your line all the time: "There are no I.T. projects ... only business change projects of which IT is a part."I understand this perfectly and it's my #1 reason IS projects fail: because ov Dear Bob …I just read Keep the Joint Running for this week (“Don’t supersize. Chunkanize.” 9/18/2006) about modifying business procedures to go along with “IT” projects. I quote (probably paraphrased as I have a lousy memory) your line all the time: “There are no I.T. projects … only business change projects of which IT is a part.”I understand this perfectly and it’s my #1 reason IS projects fail: because over and over and over and over we roll out new software, the users whine and complain until we change it to work like the old software to support their (usually outdated) processes, and the sum effort results in making life worse rather than better. They don’t get any of the benefits of the new software, they long for their wonderful old software back, and the IS staff is demonized as the monsters that ruined their lives. oy. Yet, here I am in the middle of another multi-year project with a few dozen people working on it (contrary to the “chunkinzation” theory of actually getting something done). I’ve tried as hard as I know how (as a consultant) to get the users to understand they need to change their processes to match what the new software adds for them … and I get Bambi-in-the-headlights from the entire room. I’m not looking forward to next year when we turn this monster on (mission-critical; four locations on the same day. It’s the Big Bang theory – it will not be pretty).– Trapped in a monolithDear Trapped … There isn’t a lot you can do (pointing out that the Big Bang was a universe-sized explosion will just annoy everyone).I do have one suggestion for you: Stop telling the users that they have change their processes – probably, they have no idea what that means in any practical sense. Instead add process change to the project plan.Yes, it’s scope creep, and radical scope creep at that. The good news is that you can probably hide it, since it will take a relatively small amount of your time, and redirect the time of the end-users already assigned to the project team. One way of doing this is to redefine the software quality assurance methodology so it includes a “conference room pilot” – an environment for the end-users to figure out their new processes using the new software without being intimidated by the thought of process redesign. You start by showing them the capabilities of the new software, then have them bring in a few hundred test cases to run through it. They figure out how to handle the test cases using the new software; your developers learn what they need to change to adapt the software to the cases, and it’s all automatically outside the constraints of the old process because what the users are bringing in are the test cases, not their old processes. You get to work with them to explore how to handle the test cases using the capabilities of the new software.– Bob Technology Industry