Migration Project

[A0C61ZZ]

Hello all,

Currently I'm managing a migration project, migrating from older version of PB to the latest.

We estimated the migration time to be 6 months, but now its getting delayed as we are in the 7th month.

There were some design flaws in the older version of the system, which resulted in errors. These errors were not prevalent in the older version (once in a month occurence) and were rarely re-producible.
But now the these bugs have become more prevalent in the newer/migrated version.
My question is who should be responsible for these?

We agreed with the client to fix the bugs caused due to migration (that goes without saying) and had made it clear that bugs not caused due to migration would not be fixed and the client had agreed to that.

My question is where do we draw the line and what approach should be adopted for these type of issues?
Thanks,
A0C61ZZ

 

[grooke]

A difficult problem that I have met before.

If it goes all 'legal', then you have significant problems. So my first thoughts are 'Talk to them'. That is probably so obvious, that you have already done it.

If not, collect your evidence in a form that they will understand; not that you understand, but they understand. Relate it clearly to the written agreement you have with them.

If it is as you say, then they will probably find funds to cover the extra costs.
If the increased sensitivity to this problem is due to your new architecture or you evidence is not 100%, then you may have to agree to share the costs.
If you are wrong, then the costs are yours.

The choice of these options will depend on how clearly you prepare the case. Of course, if you are in doubt, you may prefer to muddy the water, rather than clarify it.

I dont think there is ever a cut and dried set of rules for such cases.

Gil

 

[PDQBach]

A few random thoughts.

(As an initial aside: I know you couldn't write a 10-page analysis of the situation for us but that means that any advice you get here may not be as germane as we could offer with additional background.)

The 7th month of a 6 month conversion is not particularly relevant. What's the forecast completion: next month? or late next year? If you've been keeping the client up to date with progress and writing change notices to reflect increasing knowledge about the conversion process then you and the client are already well down the road to a negotiated understanding of the rest of the project. Of course, if you haven't then that's an entirely different situation.

There aren't a lot of "size" numbers in your discussion. "Rarely" and "more prevalent" don't really provide sufficient information. There's also no sense of ranking for these errors: nuisances (columns on reports don't align nicely and sometimes a blank page appears in the middle of a report) or showstoppers (accounting ledgers don't balance at the end of the month; pay advice notices don't show proper tax deductions).

I'm presuming that you already have weekly status meetings with the client and I'm assuming that the errors have some visibility within both organizations.. I'd add a weekly triage meeting: the client brings the error list, a good-faith effort is made to allocate the list to "part of the conversion"/"not part of the conversion".

The "part of the conversion" list is triaged into "will fix immediately", "will fix at the end of the conversion", "will not fix". (This triage will let you focus on the main task: doing the conversion.)

The "not part of the conversion" errors are your company's revenue-enhancing (!) opportunities because of the additional (billable) work you will do.

My experience suggests that many errors will be handled this way and that only a few will be contentious. The triage meeting approach lets you deal with many items easily while escalating the contentious ones to more senior execs in both organizations.

There's one other sizing issue, too: your company and your client's company. If you're a smaller shop then the success/failure (profit/loss) of this contract may have a material impact on your company's future. In a larger consultancy, your organization may decide to throw resources at the problem to keep the client happy. If you client is large then they are likely a mature organization and may be well accustomed to situations like this and, equally, a much smaller organization might be more flexible and understanding but, simultaneously, not really unwilling but simply unable to pay for any remediation over and above the contractually agreed upon work.

GRooke (above) makes an *excellent* point: you have to explain things in terms they understand. Far, far, far too often, techie types think everyone speaks their language and sees the world their way. "The latest release's pre-insert trigger fails on a null secondary key where the key is defined as an alternate index" means absolutely nothing to a user or user executive.

It also only means that you've found a problem. You need to explain things so they understand it -- and you need to be able to follow through with "We have looked at this and here are two possible solutions ...".

 

[A0C61ZZ]

Basically we are close to finishing this project and I am positive we will close this soon.

There were a couple of troublesome bugs which occurred only once in the old version app. Basically it was faulty code/design but the robustness or the architecture of the s/w overcame these.
Now these occur frequently (we are jumping from PB 4 to 10 - a large version/architecture difference).
Also we are usign an outdated version of the database and the new version of app is proving to be too fast for this.

One lesson learned was - I didn't pay much heed to the estimates. The estimation was done by a prior manager who obviously forgot to account for this architecture difference - in hindsight.
Although I did point out the older db issue initially, I didn't follow-up till the end to get a closure on this.


Result was a bug occuring under special circumstances once a month, which was rarely noticed by the users, started occuring thrice a day, shutting down the system during peak ours.

Regarding PDQBach query - A problem which was a nuisance in the older system due to its faulty design/coding became a show-stopper in the new version.

Although the client showed understanding, I couldn't deny that the users cannot sign-off unless the system became "stable".