Changed The Customer's World - how do we handle this?

Question

Some time ago, we were tasked with a project to come in and replace a customer's old Mainframe system with a new intranet ASP.NET solution using SQL Server as the back end. Part of this was a re-engineering of the business as well - essentially, as we change the system, we were to be thinking of how we can better do business.

So, the first task was to come in and do the logical and then physical data models. The customer was in on these dicussions and had complete sign off. The next phase was to actually do the design and building of each module. Well, to make a long story short, the programming has been done and we are now into parallel testing of the system. Things are going wonderful for most of the modules so far - Except One.

We have one system where - if you would only let the business users see the application and reports, all would be well. It works with the new integrated workflow and automates previously manual processes and performs great per the specifications. Parallel testing has uncovered a few issues though with the migrated legacy data. The builders of the legacy system are having a very hard time understanding the new schema and business process, therefore, they are having a very hard time understanding how to take the legacy data and put it into the new schema. Because of this, they are calling meetings of the business users and stakeholders and telling them that the new system doesn't provide data that the old system did (when it really does) - this does make the new system look bad.

This is frustrating, to say the least. The new system works great, and provides everything they need and wanted, and if not for the inability of the IT staff to fill in the new tables with the old data, the business users would be happy with the new features and functionality.

I'm asking for suggestions for how to handle this. Because of some political moves, the new "architect" has no idea of how the system works, and cannot fully understand the ramifications of the changes the IT staff is requesting. The IT staff wants some fundamental changes to the system, which are essentially un-necessary and actually are a bad design - but they ARE the customer.

Any thoughts?

Answer 1

Your team needs to do the data conversion for them. You really should have done it for them in the first place.

I've been involved in a number of expensive platform migrations and the vendor always, always has their own data conversion team who are responsible for understanding the legacy system, writing all the migration scripts, doing all the tests, and generally making sure that everything does what it's supposed to.

Some companies may have brilliant IT staff who can do it themselves. Others may claim to be able to do it themselves, but actually can't. In the latter case, you need to be humble enough to sit back, but also be prepared to step up if and when the management has decided that the internal team isn't doing a good enough job.

This is your system and your implementation. You and you alone are responsible for making sure that it succeeds. Do not expect the customer to be able to do any part of this themselves. Only if they absolutely insist on doing this part themselves should you even consider that option, and in that event, you need to cover your butts - there should be something in the contract saying that if they choose to do this themselves, then they are responsible for its outcome.

They can pay you to babysit their team if they want, and they can pay you to start all over if they want, but don't waste unnecessary cycles without some kind of agreement in place. Especially if you're on a time-limited or fixed-cost contract, this situation is death.

The point is, as you say, they are the customer, which means that they do not work for you. In fact, if you're a cynic like me, you might suspect that some of them are actively working against you to hold onto their job security. Relying on the customer to do any part of your implementation is a mistake.

If you have to hire a couple of minimum-wage data entry slaves to do the data conversion manually - do it. Anything to put the outcome back in your hands.

Answer 2

They are the ones paying the bills so in the end you have to give them what they are asking for even though it wouldn't be the best solution and a step backwards.

You have to consider however that perhaps the people who used to use the mainframe have a point. My wife used to work for a bank where she used some mainframe system to enter various financial transactions using hundreds of different types of codes. It was essentially its own mini-language. When the bank spent millions of dollars implementing a GUI based system that greatly reduced complexity and the steps involved, they found later that productivity PLUMMETED and never went back up.

The fact of the matter was that while the mainframe system was unnecessarily complicated and had a high learning curve, they were MUCH faster with it than the GUI system because they became adept at entering hundreds of transactions an hour simply by typing fast on a keyboard. It led to a mass rejection by the user base and the project was scrapped as a complete failure. Productivity returned.

The moral is, don't completely dismiss the customers concerns. Take their considerations seriously and ask yourself if the solution you are providing meets the needs of ALL the stakeholders.

Answer 3

them that the new system doesn't provide data that the old system did (when it really does).

You should take this VERY Seriously..

Then:

1) Assure management you are working with the Legacy guys to get all of there concerns resolved.

2)Be sure you fully understand what they are saying is missing and why it is needed. Work with the legacy guys to insure this. Then RESTATE The issue, and have them say "Yes, That is our concern."

If you agree with there concerns then:

3) Then propose a solution, get the legacy teams input\validation on\of the solution.

4) Proceed with corrective measures.

If you fully disagree with the Legacy guys, and believe they are concerns are not valid then :

3) Express there concerns to management using that same language that the Legacy Guys said was correct. And have Management decide where or not you should be concerned with it.

"The legacy Guys are afraid that XXX, I'm not sure its an issue because of YYY. Are they correct in there concern?"

Answer 4

I suggest a big - panic smothering email, hit everyone associated not just their management. Keep it short and to the point.
2 points:

1) We can address your concerns at a meeting/phone call (propose a time)

2) We have complete confidence in the system as it is without the hassle and expense of additional changes

It sounds like you have a list of their concerns and you can go down them point by point in the meeting. You just need to stop the panic, let them cool down a little, and then hit them with truth. Even offer to come in and help with the mapping of old data to new. If they still demand changes... well it's their money.

Answer 5

First, I want to point out that while the IT section may be your interface, the real customer IS NOT the IT section, but the business for which the IT section works. Doing something to hurt the business to appease IT would not be good service.

Sit down with IT, informally. Buy them donuts. Take the role of student to their teacher, and ask "What is wrong with our software design?" Listen to both what they are saying and what they are not saying. They might have a point that has been overlooked in the original specifications or have concerns based on past issues. Then again, they might be reacting due to fear of something new. But, the point is, if you know their objections intimately, you are in a better position to effect a positive outcome and answer their objections.

You had mentioned that the problem was in data migration from the legacy system to the new system. If the IT section is having a problem migrating the data over, I would consider building them a small tool to do so quickly and cleanly.

Answer 6

Consult with the IT staff of your customer to support the migration of the old data to the new system. Someone from your firm who understands the new data format should physically just go there and help the IT guys do the migration.

That way hopefully they can teach the IT guys about the new system, the data gets migrated correctly, and your implementation goes more smoothly.