Put a stake in the ground

Many years ago, I learned an important project lesson that I have carried with me throughout my career. I had just joined Cadence Design Systems as a support director in 1998. This was my first major career change. The only reason that I felt comfortable at all was that my prior manager from IBM recruited me and assured me that I would be able to leave the unique and sheltered halls of IBM and be successful elsewhere.

The first big project that I took on there was as the support lead and project manager for a massive changeover of their CRM / Support ticketing system. Going in, I was told that the project had suffered repeated delays and that it was mired down by the decision making process from the support team...not any big technology or architecture issues. It seemed as though every single decision was relentlessly debated with little consensus and no decision making. It was admittedly a large transition - to go from an ancient support system that had been built up and customized over a decade to a fresh new implementation.

In my first meetings, I learned that everything I'd heard was true. Every design decision devolved into endless discussions, repeated meetings, and decision paralysis. It wasn't that the support managers on the project were bad in any sense. In fact, they were excellent. We went on to build a world-class support team together. What I did see was two main issues. Firstly, the team was afraid to make decisions and having to live with the consequences if they were wrong. And secondly, related to that, they would need to work through every possible corner case...no matter how rare or unlikely. You probably know what that might be like..."what if a support engineer setts the status to pending and then is hit by a bus?" We were way off the current committed schedule and spiraling towards 'never' as the date.

As you might imagine, I made a number of changes to the project and how it was managed. That included resetting the schedule one more time...but with the commitment that we would not miss the new date. As to the issues above specifically, I started intervening in the support design decision process. I let meetings flow like they had been as they knew the system and I didn't, but the minute we started veering into designing for irrational worries, I stepped in. I ended up using a particular phrase at this point. I would take the core design elements that made sense and tell everyone that we would "put a stake in ground" and decide on that design. I told them if there was more data that would change the design we would stay open to it...and if there was an issue in testing, we could make changes as well. But we needed to make a decision and move on to the next set of fields or workflows.

And the funny thing was, we almost never went back and made those changes. The corner cases didn't materialize and the core design worked perfectly. All the fears and concerns melted away by simply forcing a decision by putting a stake in it. We started making real progress on the important decisions once we could clear the minor ones. We delivered the project on time and with new capabilities and quality workflows on the exact day set in the revised schedule.

The lessons I learned were two fold. First, it is good to have a team that is going to examine the problem space in detail and make sure that key items are not missed. But like any strength overused, that quickly becomes a weakness. It slows decision making to a crawl by working out details on something that is likely never to happen...and even if it did happen, the actual cost or risk is minimal. Secondly, when a team comes from a culture where missing even a tiny requirement is a sign of failure, they are likely to fall into the paralysis noted above. If you don't understand and cannot convince them that the project actually getting implemented is more important than not making a mistake or omission, then good luck ever getting done.

The fun part of the story is that I used the "put a stake in the ground" phrase so much in the early days of the project, it took a life of its own. Our vendor partners and our team began to use it as well. When we went live, I actually went out and found an artist that would engrave old railroad spikes. I had them do up the company and project logo and the phase on the spikes (stakes) and gave them to the project team members as a memento of a job well done.