Editor’s note: Evan Stein is an independent consultant with experience as a software developer working with financial institutions. This is his first article for TechRepublic.
Although I was a full-time employee of a consulting firm, I spent most of my days in the field at client sites. In one instance, I was at a financial firm for a long-term engagement as an Excel macro coder. The client used the Excel macros to retrieve accounting data from databases.
Being at the client site meant that I worked much more as a rank-and-file employee than a consultant. The work wasn’t glamorous, but I had my eye out for other opportunities.
I was working in the client’s Controlling department. We had two large databases, one Oracle and one Hyperion Essbase. The user community consisted of 300 users, mostly in New York where I was based, and a few more in other U.S. offices.
Almost 95 percent of my team’s projects involved creating reports from either Oracle or Essbase. All of these were generated in Excel via the macros that the team was writing. We’d pull raw data from the databases, massage it as required, and write out the recordsets to the Excel worksheet.
We used Excel for two reasons. First, Essbase is a multidimensional database that interfaces nicely with Excel. The second reason was data manipulation. The data returned in the reports was only the first step in most of the business processes. Having the recordsets in Excel meant the users could work with the data easily in any way they wanted to.
From a support and maintenance perspective, the process was a huge problem. When a user needed a report for the first time, it meant a visit from support to the user’s desk to configure the database connection, configure Excel, and install the report.
Subsequent reports were distributed via e-mail, and we would walk the users through installing them over the phone. Upgrades were a nightmare. Users installed the upgrades at their convenience, and we could never be certain that all users were running the correct versions.
I started looking for a better way. I wanted to:
- Centralize the reports for easier distribution and maintenance.
- Provide easy report access to the users.
- Support an interface to Excel for data manipulation.
The obvious choice, which would fulfill the three requirements, was to move the reports to the fledgling corporate intranet. While this sounds like a simple task now, this situation occurred several years ago when Internet technology wasn’t as advanced. The intranet existed but it was primarily used to disseminate static information.
I identified the advantages of my plan and presented it to my client. He liked the idea and saw its benefits, but I received an all-to-familiar answer: “No extra budget, no extra time. Let’s table the idea for now, and we’ll look at it in more detail when we get the time.”
I asked if I could pursue this after hours at no charge to him, and he agreed. Why did I make this offer? I was looking at the long-term opportunity. If I could demonstrate the advantages and simplicity of moving the reports to the intranet, it would mean a new project, the hiring of more consultants, and getting to use a new technology.
My plan was simple: Take two existing Excel reports and migrate them to the intranet. Because we were a Microsoft shop and IIS was included at no extra cost with Windows NT 4.0, I decided to use IIS and Active Server Pages (ASP) for this project. This would help me when it came to setting up the infrastructure. Active Server Pages was included with IIS and it was an easy tool to learn for someone with Visual Basic development skills, which I had. This left me with a few questions to answer:
- Which reports to migrate
- How to develop the reports and interface
- Where to get the infrastructure to run the reports on
Because none of my research showed how I could pull data from Essbase into a Web server application, I eliminated all the Essbase reports right off the bat. I could only run the Oracle reports, narrowing the list of reports by half.
I wanted reports that were used frequently enough to validate the points I was trying to prove. I identified a dozen of our more active users and polled them about the reports. Each of them came back with almost the same list. From that list, I chose two that looked fairly simple to code but that provided valuable information to the users. One report provided department budgetary and actual figures in a standard table format from a user-selectable list of cost centers and time periods. The second report presented similar information but also provided trends and alerts based on user-defined thresholds.
I also explained to the users what I was going to do. If this project was going to be a success, they were going to have to buy into it. Once they realized the reports would be a click away, without the complications of having the programmers do local installations and upgrades, they were excited. Of course, I was now on the hook.
How to develop
As I promised my manager, I would do the work after hours. I contacted the firm I worked for and explained what I wanted to do. I asked for help from two consultants that weren’t assigned to projects. I also asked for assistance from the graphic designer. I could write code, but I wanted these reports to look professional and appealing. (Convert a Windows-based Visual Basic application, with its gray background, square buttons, and occasional bitmapped icons to a Web browser and users will find it bland and boring. I didn’t want pizzazz and flash, but I wanted to make an impression.)
I took care of writing the code to access the database and generate the recordsets. The developers from my home office would be responsible for reporting selection criteria, generating the output, and getting the data from the Web browser into Excel.
Buying a server was out of the question. So was working with the corporate intranet team. Because there was no budget for the work I was doing, it would have been difficult getting another department involved. Also, I didn’t want another team taking this opportunity away from my consulting firm or me.
I needed to get this done simply. Even though it was a pilot program, I didn’t want it running on my desktop. The last thing I needed to do was crash my PC while installing the latest, hottest tech tool at the same time one of the pilot users was running a report. I grabbed an extra PC from the storage room and loaded NT Workstation with Personal Web Server. (Like I said, I was keeping it simple.)
I put the new Web server on the corner of my desk and asked my client if I could install a second network connection. He gave the approval but reiterated that this was still to be done on my own time. No problem for me. I was still looking at the long-term benefits.
Three weeks later, we rolled out the two pilot reports. I presented them to my manager and invited the rest of the development team. Everyone was thrilled. My manager arranged for a demo and formal pilot program with the identified users.
The most controversial step I took was committing to do the work after hours and at no expense to my client. But I had chosen the work carefully. The project was one that I hoped would be the first of many. It was a hook I used to get my client interested in a new approach and to demonstrate my knowledge and the resources my firm had to implement this technology and add value for my client.
What happened? During the next 12 months, the client brought in four new consultants from my firm on long-term contracts. All of the existing reports were migrated to the intranet and all new development was done that way, too.
The success factors
Why did this work so well?
- I involved the users from step one. They helped me identify the reports that would be valuable, and their enthusiasm helped sell my manager.
- I kept it simple. I didn’t go for the most complicated report with the largest amount of data. I did it quickly and kept it easy to support.
- I used a graphic designer. When I showed the final product to my manager, it looked like a professional report done by a professional development team. To this day, I still believe the client and most of the users were more sold on the look and feel than they were on the accuracy of the data.
- The client was open to new ideas. Yes, I involved the users and got them enthused, but I went to my client first and sold him on the benefits. I also kept him informed every step of the way. In the end, to his peers, it looked like his success.
- I sold my firm on the long-term benefits. No one is thrilled about doing free work. I had asked my firm for two developers and a graphic designer. Those aren’t cheap resources to be giving away. I sold my firm on the upside—a lot of future work and a lot of potential revenue.
I’ve learned that nearly every contract and every client has the potential to grow into more than the current engagement. I'm always looking for new ways to add value and make myself invaluable to my clients. The extra—or free—work that you do for a client can yield long-term benefits that will help you secure your next engagement.
Sound like something you’ve done?
Have you put in work for free in the hopes that it could lead to paid work for you later? Tell us about your experience and we’ll feature your advice in upcoming articles.