Even tragic projects can have happy endings

Not long after finishing graduate school, I found myself working at what used to be known as an “operations research consulting firm” (today, this company would be called an “analytics services provider” or some such), working full-time on a project for a large client.

I still have a lot of scars from that project.

The core of the model that we were building was coded and implemented on a mainframe computer. This meant that I often had to struggle with writing a few crucial and confusing lines of Job Control Language (JCL) – something that I never did quite master – and every time one of my compute jobs crashed, I would receive a late-night phone call at home.

Also, upon joining the project team, I had inherited a largely undocumented SAS program from a departing colleague, a mess of spaghetti code that contained the guts of the model that we were implementing. I spent countless hours trying to sort it out and clean it up without causing our nightly production runs to crash (see “late-night phone call” above).

The Biggest Problem

By far the biggest problem, however, was the lack of clarity about the project’s purpose. The project was sponsored and funded by the client’s IT organization. The actual business groups who were expected to use the models were not at all clear on what the value proposition was for them, and we could see that our project deliverables were being shoved down their throats.

Not surprisingly, the business users we worked with were motivated to find problems with what we were doing – and they often did. Some instability in the networking infrastructure often prevented us from delivering updated results, which generated one set of complaints. Even when everything worked on schedule, our results (based on a daily snapshot of the system’s state) would inevitably be out of synch with the latest data that was available, which in turn produced a whole other set of complaints. At core, there was a fundamental disconnect between the business users (who believed they had asked IT for a tactical reporting tool) and the IT organization (who believed that we had been asked to deliver a more sophisticated decision support system).

Meanwhile, we were pushed for political reasons to get the model into production as soon as possible, while the business users kept finding reasons not too sign off on the deliverables and refused to use our solution at all until it had been formally accepted. As such, a huge amount of effort was spent designing the perfect user interface, right down to the choice of colors to be used to represent different kinds of outputs, while the model’s core logic and functionality was never seriously examined by the clients who would ultimately have to use it.

Project’s Value Proposition

Though nearly 20 years have passed since then, this project came to mind again the other day when an old friend of mine (let’s call him “Doug”) told me a familiar tale about one of his recent projects. “From the beginning, our understanding was that the purpose of the project was to build an alpha version,” Doug explained, “something to demonstrate the potential of the application while giving us a chance to establish data connectivity, get a bunch of technologies talking to each other, and use a sample of the operational data to show that the optimization could actually provide significant savings.”

So far, this made great sense to me. In fact, of late I have had conversations with many people in the analytics field about the value of rapid prototyping for engaging potential stakeholders, for demonstrating business value, and for ensuring that the team really understands the problem domain.

So what went wrong for Doug?

Turns out his project was also being led by the IT organization, and that those folks did not have any sense at all about the project’s value proposition. In addition, not long after Doug and his team had begun working, someone somewhere in the IT chain of command made an ad hoc decision to roll out the alpha version of the software to a group of business users around the county. Within the client’s IT group, this was interpreted as a decision to treat this alpha version as a “production system” and as such to hold the consultant’s feet to the fire as if taking delivery on commercial enterprise software.

Doug and his team were perplexed and distracted from what they thought their focus should be. A great deal of time was spent on minute details associated with the graphical user interface, including long discussions about the layout and coloring of various output values, even though there was no established acceptance criteria (since the GUI had not been viewed as a significant part of the original project’s scope). Meanwhile, despite repeated attempts by Doug, no one on the client side was willing to even look at the results of the optimization until the entire user interface design was signed off and fully functional.

In fact, with the possible exception of the original executive sponsor (who was extremely busy and far removed from the reality of the project), it seemed to Doug that no one really understand how the system’s pieces (including the GUI, a configuration rules engine, the optimization model, a relational database, and java code for developing and deploying the application) fit together, or why the project was being done in the first place.

Abandon Ship

After more than a year on my project, I had become fed up. The partners in my firm had made a great deal of money from my billable hours on this project, but I had come to understand that this was clearly just part of the standard professional services business model. However, I had nothing to show for my efforts but lost sleep, a bunch of unhappy people within the client organization, and a deep sense that I was wasting their time and my own. I left the project, and the firm, soon thereafter.

For many years, I felt quite smug about this decision to abandon ship. Indeed, I have since been told by several people that I respect and trust that the willingness to put your job on the line for what you believe every single day should be a core value for successful project leadership. In any case, I was young, single and free of debt, and walking out of my employer’s offices on that final day, I felt that I had very little to lose by leaving it all behind.

After talking to Doug, however, I’m not so sure. Far older and wiser now than I was then, Doug has worked through this challenging project calmly despite the many frustrations, communicating his concerns to his own management and doing his best to educate people throughout the client organization all the way along. Though the initial project was ultimately cancelled, the client’s executive sponsor has recently re-engaged with Doug’s company, recognizing her own part in the project’s failure and still believing in the potential business value that the optimization might be able to provide.

While his initial project had appeared to be a tragedy, or at least a black comedy, Doug’s story may yet turn out to have a happy ending. In any case, I plan to stay tuned, and I hope to learn something along the way.