Home
 > Research and Reports > TEC Blog > Never Gonna Give You Up, Never Gonna Let You Go

Never Gonna Give You Up, Never Gonna Let You Go

Written By: Chris Tanner
Published On: March 8 2011

Cost overruns are an all too common phenomenon with information technology (IT) projects. A myriad of causes are to blame: scope creep, improper budgeting, and customization cost underestimating, just to name a few. Then there’s one that I experienced in a previous occupation, let’s call it “One More Week” or “OMW.”

The client company’s goal was to resolve some compliance issues that had emerged during its last audit. It had identified that automating some core business processes would be the best way to make the auditors and shareholders happy.

I was to go on-site for two weeks to conduct training on how to configure and deploy our Business Process Management (BPM) module. In most cases, one week is sufficient to train an established BPM team, as they are generally quite familiar with the concepts of BPM and seek only to find out how to implement their established plans. In this case though, two weeks was thought to be more appropriate, as the team wasn’t quite as familiar with BPM in general. A dedicated compliance resource was also on hand to vet and approve the workflows that were created by the client team. In the end, the client did have all of their workflows in place with some custom features and a bespoke automated data bridge to third-party software.

There was only one little wrinkle in all of this—OMW.

For the sake of general estimation, I’ll say that the cost per week for me to actually get to and stay on-site was approximately $1,500 (USD). This included taxi to and from my home airport, flight, car rental, hotel, gas, and per diem. We’ll say that my time was billed at $5,000 (USD) per week, so the two-week engagement would have cost approximately $13,000 (USD), as I would fly home every weekend when feasible. In the end, the cost difference compared to the original estimate was shocking. Those two weeks ballooned into five and a half months. Travel costs were around $33,000 (USD) and the cost for my time was $110,000 (USD). How the hell does the cost of an implementation go from $13 000 (USD) to a whopping $143,000 (USD)? That’s more than 10-fold over the original cost after all! Also, time was ticking on the whole issue of compliance, of course.

The training did take the allotted two weeks and all features and functions were explained and demonstrated in detail using specific examples of portions of the workflows to be automated. Except that midway through the second week, the client uttered what would become a commonly used phrase.

“I think we’ll need you next week; we’re not quite there.”

To maintain continuity with the training and deployment, the client wanted me on-site for the following weeks to avoid having a new consultant who would need to be brought up to speed on the project. So with this in mind, my schedule was shifted and I was back the next week, and the next, and the next, etc. There were several reasons for the time overrun, which could be categorized along the lines of the comments I received:

  • I forget

  • I’ve thought about it and this/these need(s) to be completely redone

  • It would be really great if …

  • Oh shit, we have to have that too, but I didn’t know it


“I forget” was a commonly heard phrase from the team lead in regard to module functionality. Okay, fair enough, I can acknowledge individual learning differences and need for different instructional styles. So, I switched it up to a more participatory style, where I sought to have the team lead configure every single tiny detail of the examples we were working with. Previously, we had done spot checks—now he/she was going to have to really get his/her hands dirty! This really didn’t quite go to plan. The individual accused me of being lazy and making him/her do all the work while I got paid to sit there. This became a recurring theme for the entire five and a half months. Actually, I wound up doing 95% of the configuration work while he/she did what could best be described as ‘busy’ work.

All of the workflows needed to have director involvement and approval. This is not an uncommon scenario. Unfortunately, the individual who oversaw the most complex workflows was unusually indecisive. We would toil for weeks with this person humming and hawing at every turn. We would eventually arrive at a finished model ready for compliance review. The next morning we would consistently hear something along the lines of that this person had thought about it overnight and he/she felt it was totally and completely the wrong approach. It would have to be redone—nothing was salvageable. This happened multiple times with several of the workflows.. In my opinion, it’s reasonable to rethink an approach to something, but to be so ridiculously unable to finalize something is going too far. Needless to say, this was a significant factor in the OMW situation. At least the project finally got completed and deployed to the production environment.

It would be really great if the software did all sorts of things. All software has features lacking for many reasons. A few examples are lack of demand, lack of return on development investment, belief that a feature would dilute the core purpose of the software. Several customizations were needed according to the client. These of course took time. I conducted in-depth requirements meetings and drew up full functional specifications for use by the development team. Then there’s the time it took to get the development task to the front of the task queue, and the time for the development/QA cycle. Then, finally, I did the installation on-site and went through everything with the client for final client sign off. Not all the customizations were billed for if it was felt that they would benefit other clients. A series of approximately half a dozen customizations contributed to the OMW factor.

Our system was deemed to require data shipping to a third-party application. This wasn’t expected from the outset, but later became a requirement—a classic case of scope creep. Meetings were held on-site with the other vendor and we worked out all the requirements to be met. As everything had to be done at the database level, it was most feasible for me to do it on-site. The need for rapid turnaround for testing and changes in requirements dictated it was most effectively handled in this fashion. In the end, the data bridge I wrote worked according to specification but consumed three weeks of time from inception to completion.

Many factors contributed to the time and cost overrun with this implementation project. Changing requirements and scope creep played a big role, but certainly human factors also contributed to the enormously extended timeline. So this is the postmortem of a failed software deployment project. But all was not lost, as the client actually persevered and was very satisfied with the end result.
 
comments powered by Disqus

Recent Searches
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z Others

©2014 Technology Evaluation Centers Inc. All rights reserved.