Skip to main content

Accomodating the Client

Working out how far to go to accomodate the client's needs.


Despite my talk about how I have "fired" the industrial client, I have been working with them over the past three weeks on certain issues that they are having with the VB 6/SQL Server systems I helped to build. This support has been for free. It is becoming the scenario that I didn't want to get into-- having to support their system because the project champions at the client don't have enough technical competence to support the users, and the IT department is unwilling to support the application because "something better" is coming along soon. Despite my desire to wriggle free from this client, I can't, after all, just throw them overboard; I don't see that as being the responsible thing to do. I have also committed to helping them with the application that interfaces with the tool controllers, but I have made it clear that that application needs to be written in C++, in order to accomplish what they want to do. It also serves my goal of being able to work with an application in C++, as a step away from VB 6-- the first step down what I hope will be a different path in my programming career.


I made a request that I be able to work from home, to minimize the amount of commuting I would need to do. The project champion at the client made my request known to the IT manager at the plant, and he said that it couldn't be done because of Sarbanes-Oxley issues. Which is interesting, considering that people at the staffing agency I work for tell me that other developers have worked from home for this client in the past. This could be interpreted as another attempt to squelch this situation and put up as many roadblocks as possible to using the software systems we have developed. To be fair, this client does have auditors who are following the practices of the plants pretty closely and tracking their compliance with Sarbanes-Oxley. But the only reason that they need these tool controllers and an application to track torque is because of an urgent safety issue that directly affects their customers. This is one situation where the "provinces" can't wait for IT to deliver a system.


I am not trying to take advantage of this client, and I am not trying to be difficult. My desire is to deliver an application that works well for them. My desire is also to build my skills for the future, and the tool controller app is a big opportunity to do just that. I am still wary of what kind of situation there will be when I return, even if I have a work space that is relatively free of distractions. One thing I am concerned about is how the project champion will pester me to tweak the other apps that are out there, and it is for this reason as much as the environment in the IT department that I would prefer to work at home.

Comments

Post a Comment

Popular posts from this blog

Where Things Stand Now

So it's been over five years since my last entry in this blog.  A lot has happened since then, personally and professionally.  I am now married, I have two little daughters, and for the past four years, I have been with a company that makes inserting machines for the mailing industry, supporting and extending software that works under the Automated Document Factory (ADF) concept.  I continued with the manufacturing client (an auto plant) until March 2006, developing in VB 6 and C++. I had a 3-month hiatus from consulting when my wife came from the Philippines and we had our wedding.  After that, I had a couple of short-term consulting gigs with another staffing company where I was involved with creating applications based on Microsoft Office VBA-- one in Excel, the other in Access on a tablet PC.  After this same staffing company sent me on yet another Access project, I decided that they were not taking me in a direction that I wanted to go, so I quit the proje...
Post a Comment
Read more

.NET: Separating the Hype From Reality

The .NET Framework is not the latest in application frameworks and tools from Microsoft. Windows application frameworks have been evolving continuously over the past 10 to 15 years. First, there was the Windows application programming interface (API), functions that were called from C that hooked into parts of the operating system that allowed you to do different things with Windows. Then there was Object Linking and Embedding (OLE), which allowed your application to use objects and incorporate them or link to them in both Visual Basic and C/C++. Later iterations of OLE have been known as ActiveX or COM (the Component Object Model). With the increasing use of the Internet, another extension of COM and OLE, called the Distributed Component Object Model (DCOM), allowed for the use of object linking and embedding over a distributed network computing architecture. In a lot of ways, these application interfaces have been built upon one another. OLE is built upon the Windows API, COM is...
Post a Comment
Read more