Reaching the point of diminishing returns on a project

Over the past month, I have been working on a project to automate payroll entry for a client that has close to 300 employees and is growing. Naturally, it is the company's best interest to get this payroll automated as much as possible.

To do this I've been developing an application to bridge the payroll info to Microsoft Great Plains Integration Manager.

One of the criteria I've used to evaluate a client's payroll is a consistent layout in a good format, so that I can tell the program where to map regular hours, overtime, cash reimbursements, etc. In some cases I'm able to tweak the payroll to make it into a layout that is consistent enough for me to automate.

This particular client is a construction company, and the only electronic version of the payroll is a text file that is not delimited. The file is basically a report from the client's system, and it has page headers and department footers, as well has breakdowns of withholding, etc. Most of that I can ignore in the program.

My colleague was able to import it into Microsoft Excel, using spaces as the delimiter. From there I saved the file as tab-delimited text, the format used in the other bridge applications I've developed.

The big problem is the inconsistent layout, which has come from using spaces to delimit the text, depending largely on how much detail is on a particular line of text. Look at the following 3 lines of text:

• E 22 Per Diem - C AZ 3 99
• E 22 Per Diem - C AZ 3 XYZ111 99
• E 22 Per Diem - C 99

In each of these lines, the payroll item is Per Deim, and the amount is 99. When you space-delimit the lines the amounts are in different columns.

This is just one major aspect of complexity that has come from my attempt to automate the payroll. After talking it over with my boss, we realize that we've come to the point of diminishing returns.

I'm off this project until there is another way to parse the payroll information and am able to move on to another project that's in the queue.

Related tags: microsoft+great+plains integration+manager payroll+automation microsoft+access vba programming application+design peo daniel+johnson+jr

When the feature became a problem

When I was initially developing the bridge application a couple years ago, I had set up the Close button on several forms to be the Cancel button. That way a user can just hit the Esc button to close the form, if they prefer to use the keyboard.

As the applications for various clients have been used, this feature had become more of a bane than a benefit. It turns out that users hit the Esc key to Undo what they have typed, but the application would close the file. This results in some records being incomplete, causing errors when the application is processing.

While you can try to anticipate the user's experience as much as possible beforehand, some bugs still show up.

No big deal. I just removed that functionality from every bridge application we have in use so that program behaves in a way that users expect it to behave.

Lesson learned while on a mission critical conversion project

Here's a project I worked on where I learned an important lesson.

The client was a global consumer products company, and the project was to convert an Access 2.0 application to Access 95, which was a conversion from a 16-bit environment to a 32-bit environment. I'm not even going to claim that I understand what all that means, except to say that there were a lot of procedure calls to the Windows Application Programming Interface (API) that needed to be changed over. This application was used to facilitate preparing the company's profit/loss and balance sheets for all of their business units around the world. Hereafter, I'll call it the "financial reporting application".

Where I went wrong was that I didn't test portions of the program as I converted the code. It demonstrated a skill in programming that I needed to learn, and I learned that lesson the hard way because, once the program was "converted", i.e., all the code compiled correctly with no errors, there were other application errors that began popping up all over.

I created a tool to help me keep track of all the errors and the steps taken to resolve them and provided the client with daily progress reports.

As I think back on it, I would have done much better if I had taken more time to understand how the program worked in its prior environment and tested the program incrementally as I revised the code.