I see several possible problems here. They not surprisingly key around "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. "

First is while the new software may add functions and features, does it add to the job needing to be done? It sounds here like this might be a case of the consultant deciding what is needed and then foisting it off on the users. I have seen more and more projects fail for this reason. The fact that the only time this person engages with the users seems to be when there is a room full of them lined up and listening without giving feed back would indicate that user input is not part of the project.

Second how is this switch over going to occur? This is another key problem with this type of project. That deer in the headlight look is usually justified. Frequently any thought of true training of the users and allowing them to be less productive while learning the system is lost on management. It is "You are professionals you should not need training in order to just do the same job. Since the new software WILL make you more productive I fully expect to see this increase in production the day we start the new software." "If you can't do your job we will find people who can"

Three and closely related to the previous, is that the project may not allow for dealing with errors while the switch over is processed. The users may realize that they will have many angry customers and zero support from management in fixing their problems.

Then we have number four. This is the track record function. Even if the project has missed implementing the first three problems, there probably have been previous projects. If they have mostly implemented these three "features" the current project is doomed unless you can convince the users that this one will specifically avoid these "features" of the previous projects.

Re:Process change without formal process redesign

Hi Bob,
As usual you have some pretty good ideas when it comes to managing the unmanageable (aka Herding cats). But I think both yourself and your original correspondent are missing one important point. The new software may NOT be an improvement.
Shocking as it is to some IT people, those in charge of running the business often know the best practices for their environment. Just because a process popped out of shrinkwrap from SAP, Oracle or some other trendy vendor, it is not automatically the best thing on the planet for your business. Notwithstanding, there may be other reasons for its adoption, such as plain old economics. If this is the case, be honest and work through it.
We went through this pain sometime past, and replaced legacy systems with a sexy ERP (I am told the purchase decision was swayed by an influential vice president who liked the logo.). Implementation was a disaster. Senior management was less than honest about the reasons and expectations. The result is that the administrative overhead has grown by more than 50% for a 20% increase in business, with no improvement in sight.
As IT auditor, I benchmarked sample new processes against legacy processes for which performance data was still extant. When I showed the results to some senior managers who had sponsored the change, the only printable response was- "That's strange, I thought that all the old staff who new better had quit already!"

Ray & Ian's comments are sound and could be 100% correct (is system isn't an improvement), but let's play devil's advocate and assume Trapped is correct that the system is an improvement...

There are at least three types of change at work here: technology, business process, and *pyschological*.

Trapped doesn't mention how long the existing system or employees who use it have been in place. But usually the longer that something's around, the higher the resistance to change.

The existing system could be rotten, but if its been there for a long time and long-time users have figured out all the workarounds to its bugs and quirks, they grow to like the system for one main reason -- they're comfortable with it. It's like the old shoe with holes that still perfectly fits...

Introduce a new system and its unlikely the long-time employees will still be comfortable. You just asked them to jump back on a learning curve they may have avoided for years.

In my opinion, your obligations were this:

* End users need to have involvement from start to finish. If they were present for business process redesign, requirements gathering, prototype testing, etc., and you properly gathered their needs, there shouldn't be as great a system shock as you've described.

* the systems training quality/duration needs to be commensurate with the magnitude of the process and systems changes. Big changes require longer and higher-quality training.

If you've done a good job the above, then the issue is not the process or the system change, its probably the employees. If employees aren't willing (or can't) adapt in today's workplace, they're going to have a rough go of it..

Yeah, I've seen this one! I went to work at a place where it became my job to re-implement the ERP which had been implemented years earlier when the company had been purchased. This was five years prior to my arrival and the people at this place still were convinced that someday they would get their old system back! The old system worked and these people did everything in their power to ensure that the "new" (5 year old) system would not work. They had new reports written, new input screens developed, etc. and, sure enough, the system actually didn't work correctly! They had made so many modifications to what was actually a fairly simple process that the entire thing broke into pieces.

And it was my job to put it back together. I brought in an expert in the new system and together we strategized which pieces were important to fix immediately and which could wait, which were low cost/high return fixes and which were high cost/low return fixes. We implemented some of the low cost/high return fixes when management brought in a team of consultants who wanted to throw everything out and implement things their way.

That happend and, you know what? The system was still broken five years later when I went to my new employer.

Bob said, "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... then have them bring in a few hundred test cases to run through it..."

I seriously disagree with that comment, or I misinterpreted it.

That work would be a MAJOR amount of additional time to plan, communicate, and manage. Trapped could not, and should not, hide it.

Also consider the impact on whomever is going to author "hundreds of use cases". Ideally they already exist and helped drive the design of the new system, but often that's not the case. The "real" use cases tend to surface in the conference room pilots when a the up front work in the design process was short changed. The plan also needs to account for responding to the results of the pilot activity.

However, putting this activity into the project plan, explaining it's value, and showing the large magnitude of work involved would be a VERY GOOD thing to do.

Trying to sound a little less cynical about the employees... it may simply be a question of another hoary old buzzword, "buy-in". If the employees don't "buy in" to the new system, it's never going to be used properly, and it's never going to WORK properly.

Twenty years ago, I was a junior consultant at a packaging plant that had implemented a per-pallet inventory tracking system for raw materials (at that time, very advanced, though by today's standards...). But the inventory tags for raw materials used never seemed to match reported production numbers, nor did reported production match shipments plus inventory, nor did inventory reports match physical counts.

As a considerable portion of the inventory was customer-owned, it had to be accounted for, or paid for. At one point, they were reduced to doing a complete physical inventory every month just to catch as many problems as possible.

We would stress, over and over, to the warehouse staff, the production line crew, and everyone in between the importance of keeping track of each tag. But they never understood why it was important, so they didn't worry if they didn't.

Finally, I had the idea of gathering the folks in charge on the production lines and the warehouses to explain just how this "new" (by this time, 2 years old) system worked. I showed them how from the moment Customer A's Brand 1 (or 2 or 3... it all comes out of one big tank, in case you didn't know) antifreeze bottles showed up at our door, we needed to know exactly how many we had, so we could schedule production for Brand 1, so the customer could know (from our inventory) if they needed to send us more, and so forth. Then I pointed out to them that since the customer had been receiving computer reports that suggested we had received (and not used) some $6 million in inventory that wasn't accounted for on our physical counts, they wanted us to pay for that.

In a flash, they saw the importance of the tag system and every supervisor present committed to the system. I say I'm less cynical because to solve the inventory questions, we finally started with shipping (which we had external verification of, in the form of shipping manifests). We got the customer to agree to adjust production numbers to match shipping (we'd shipped a lot more than we'd reported produced, because people weren't tagging every pallet of production). We also got them to agree to count inventory usage at what was required for production plus a loss factor (for damage) at 0.5%. When we re-ran the numbers, the loss dropped from $6 million to $3,000.

So the employees were amenable to doing the right thing, once they understood why they were being asked to keep up with all these tags. Nobody'd ever bothered explaining it before.

I've got to go with Ray and Ian on this one. What happened to IT projects needing a business sponsor? Why are IT dollars being expended on purchasing, configuring, and rolling out new software when there was no initial business need? Software "upgrades" need to have a business case made for them, which should involve the affected business units, before anything else. To paraphrase, "if it don't add value, don't change it."

I have found the most effective method of process improvement is to gather all people who actually do the work into a room, and ask them to explain the process at a high level. During this session, the process is diagrammed on a large whiteboard. This can be disguised as part of the IT process of gathering project requirements if need be.

Invariably, common sense points out obvious problems. I once had a case where a person spent one day a week for years preparing reports that were filed and never used by another department who didn't know why they were being provided.

Labor intensive parts of the process are highlighted for potential improvement. Meetings for subprocesses are scheduled and the diagram process is used again. Technology solutions are proposed with the IT guy playing "Wouldn't it be great if the computer did...".

This approach a)involves the end users who have the institutional knowledge of the process, b)starts with a high level pipeline analysis to prevent bulges and bottlenecks in the pipeline, c)preserves the parts of the process that aren't broken and don't need fixing.