Long Projects

I recently found out that a project I started years ago was just cancelled. I was devastated. How could this happen? We did everything right with this project! It even had a code name that indicated it would be a success.

This was a technology disruptive project. It would change the way we do our work and work with our business partners. It had strong backing from many management tiers. These managers were committed. They knew the perils of supporting a multi-year project like this and also meeting their commitments to deliver a steady stream of new products in the meantime.

From the beginning there were constant challenges because we could not get enough engineers on the project. I was moved off the project in a cascade of reorganizations. But as I watched from afar, many talented engineers were moved on the project.

And yet, I smelled the trouble from afar. The project communications were stellar. I was impressed with the progress. They were creating deliverable systems and getting all the key stakeholders involved. More and more of a working system was delivered. But every time I asked how much time before it would be delivered I was gold “two years”. Another year passed and I asked the questioned again and got “two years”.

That “two years” is kiss of death. In fact “two” of anything is the kiss of death. We have an engineer in another organization who we have been waiting months on for a design. Every month he tells us it will be done in “two weeks”.

After six months we gave up and now we did the design ourselves. It’s not as solid a design because he is an expert in this area but we are learning. We’ll have to build the design expertise ourselves.

Long projects notoriously fail. Here is some research from objectmentor.com:

The project I started on was about four years old.

I recalled when we made the key decision. We were going to do something that was more malleable and could be done slowly over time or something disruptive, which was ultimately chosen. At the time, it appeared the disruptive technology would be more robust and indeed that is still the case. But ultimately, the business could not sustain the investment to make this disruptive change.

What does this all mean for architecture? Architects have to make decisions that the organization can follow through on. I had my doubts seeing our organization not follow through on other disruptive changes. And yet I felt at the time, that this environment was different. In the end, however, business needs usually win. And software architecture may have to work with business demands versus the most elegant architecture.