Category: Off-shoring

Categories
Humour Off-shoring

Off-shoring

Some observations on off-shoring:

1. You have to manage the relationship carefully and frequently. Do not let it drift – it is too important for that. The salesmen/account managers/practice directors/whatever like to claim you can “leave it to us to manage everything” – but they are not to be trusted. They don’t know your business – you do. And if you don’t then you are in the wrong job!

2. You must be very precise in defining your requirements – especially for software developments. Vague specifications and poor analysis up front will lead to a higher cost using off shore resources due to the amount of reworking needed. Remember – with most off-shoring you will get EXACTLY what you ask for … nothing more …. nothing less. So make sure what you ask for IS WHAT YOU WANT! 🙂

3. You must allocate budget for a QA process – and use an independent resource to carry out that review. Do not under any circumstances allow them to sell you a QA resource. Poacher / gamekeeper is not a safe strategy for a quality end result 🙂

4. Check for built-in “additional time & materials” in the code/design. Check for hard-coding and inflexible code – if they can write something that will work right now but break when your business changes they will. It is in their business model to gain value added on-going “fixes/updates/enhancements” that can be charged as time & materials outside the main contract.

5. Don’t let them convince you that changes are outside the original contract – if the original solution was not fit for purpose then make them fix it within the main contract – free of charge!

6. For every “good” resource there are at least 20 “average/below average” resources. Make sure the good ones you are allocated are not moved off to other projects/customers and replaced by less able ones.

7. Paper qualifications are no substitute for ability. Many of the resources are fast-tracked through numerous training courses to pass certifications. My experience is that many of the resources may be “qualified” but they just do not understand the technology.

Categories
Crystal Reports Off-shoring Peoplesoft

Crystal Reports is slow! Or is it ….?

We had a Crystal Report for Billing that took over an hour to create 230 bills in PeopleSoft 9.1.

Before I continue, I should add that this was a bespoke report developed by off-shore resources. I should also add that I had been doing development QA for quite a while on this project when this issue came up. I was also responsible for application performance analysis and tuning.

I undertook a performance analysis of this report, fully expecting some badly written SQL to be the root cause as that was a common issue with our off-shore resources. However, what I found was even more incredible in my view. To explain:

Continue reading “Crystal Reports is slow! Or is it ….?”
Categories
EBS ETL Off-shoring Pentaho Peoplesoft

Customers can only have one address …..

During my time converting PeopleSoft data to Oracle EBS, I remember being asked to create a spreadsheet output using Penataho for the dataload of customers with a number of tabs including:

  • Customer Info
  • Customer Addresses

This request came from the “off-shore” resource we had on-shore from India at the time. An EBS “expert” … or so we were told.

I was informed in quite a lot of detail which columns they wanted and some simple transformations/edits they needed performed on the data. The interesting thing about the Customer Addresses data they asked for was that there was no indication of the sequence the addresses should be in, nor how we should indicate (say) the primary address, the delivery address, the billing address etc.

I questioned this and was firmly told “just do it the way they ask for it – they know what they are doing”. I had my doubts.

But I did it.

The next day the EBS “guru” rejected my data file because it had duplicate addresses in it. When I questioned what that meant exactly, the guru said “there is more than one address for a customer”. I pointed out that the data was correct and that there were lots of customers with multiple addresses – in fact most of them had at least two. To which he claimed “in EBS a customer can only have one address”.

I think my face said it all really.

I suggested something along the lines of “RTFM”.

Note: It seems that the conversion approach taken by this off-shoring company was to load the data into staging tables they had created based on the EBS standard data load tables, but with only the fields they “thought” they needed. They then wrote scripts to populate the standard load tables from their customised tables. Clueless. A car crash waiting to happen … and it surely did.