I work for a software development company, and a few years ago we contracted with a midsize firm to create an administration network that would replace multiple legacy systems. Little did we know that the project would become a major source of frustration and puzzlement -- and that we'd still be working on it years later.
The project started with all of the usual requirement studies and sign-offs. Our development team, along with the client's IT project team, system users, and management personnel, worked together on the project details. The design specifications, budget, goals, and timelines were set and agreed upon by all. But reaching just this phase of the project took two years, instead of our normal one year. That should have been an omen.
[ Also on InfoWorld: Batten down the hatches, there's an IT rogue on the loose! Here's how to spot admins gone bad and how to minimize the fallout. | Get a new tech tale in your inbox every week in InfoWorld's Off the Record newsletter or follow Off the Record on Twitter. ]
Finally, we started programming. As per our agreement, our company delivered each module of the system as it was completed.
But the way the client acted, you would think it had never been involved in the design process at all. When we'd work on the module, the client would demand major changes, such as creating new design specs, testing, and deliverables, all while holding our feet to the fire to complete our work as scheduled. A "phase II" extension was totally out of the question in the client's eyes.
With all the changes on its end, the client was now way over budget, with no end in sight. How this company's management had allowed this to happen, especially in a recession, was beyond anyone's imagination. The client's top managers wouldn't even return our top managers' phone calls to discuss the issues, while the client's project manager insisted that everyone was happy.
Part of the problem is that the client's IT staff are mostly contractors and are allowed to run the project with very little user input, knowing that when finished, many of them will be out of a job -- no wonder they dragged their feet. Still, it didn't explain the managers' puzzling actions.
Now, several years after starting this project, all programming is complete and ready for production on our development end. On other side, the client is still revamping screens and changing structures, without having conducted any user testing at all. The reason? The client is "waiting until development is finished."
Each week's project conference call produces new changes in every part of the contact, policy, claim, and reporting subsystems. Also, as per the agreement worked out at the beginning, we've tried to conduct training sessions for the new product. But the client claimed it "knew it all" and stopped this process.
On the bright side, this situation is the source of much humor during our company's status meetings, and the client continues to pay for the additional programming and support costs that keep piling up. Even though we are tired of working on the project, it may be a continuous source of income for many years to come.
Get a $50 American Express gift cheque if we publish your tech experiences. Send your story of a lesson learned, of dealing with frustrating coworkers or end-users, or a story that illustrates a relevant takeaway to today's IT profession to firstname.lastname@example.org.
This story, "We don't need no stinking IT specs!," was originally published at InfoWorld.com. Read more crazy-but-true stories in the anonymous Off the Record blog at InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.