My latest is at this link at AITS.org with the provocative title: “Failure is not Optional: Why Project Failure is OK.” The theme and specifics of the post, however, are not that simple and I continue with a sidebar on Grant’s conduct of the Overland Campaign entitled “How Grant Leveraged Failure in the Civil War.” A little elaboration is in place once you read the entire post.
I think what we deal with in project management are shades of failure. It is important to understand this because we rely too often on projections of performance that oftentimes turn out to be unrealistic within the framing assumptions of project management. In this context our definition of what defines success turns out to be fluid.
To provide a simplistic example of other games of failure, let’s take the game of American baseball. A batter who hits safely more than 30% of the time is deemed to be skilled in the art of hitting a baseball. A success. Yet, when looked at it from a total perspective what this says is that 70% failure is acceptable. A pitcher who gives up between 2 and 4 earned runs a game is considered to be skilled in the art of pitching. Yet, this provides a range of acceptable failure under the goal of giving up zero runs. Furthermore, if your team wins 9-4 you’re considered to be a winning pitcher. If you lose 1-0 you are a losing pitcher, and there are numerous examples of talented pitchers who were considered skilled in their craft who had losing records because of lack of run production by his team. Should the perception of success and failure be adjusted based on whether one pitched for the 1927 or 1936 or 1998 Yankees, or the 1963 Dodgers, or 1969 Mets? The latter two examples were teams built on just enough offense to provide the winning advantage, with the majority of pressure placed on the pitching staff. Would Tom Seaver be classified as less extraordinary in his skill if he averaged giving up half a run more? Probably.
Thus, when we look at the universe of project management and see that the overwhelming majority of IT projects fail, or that the average R&D contract realizes a 20% overrun in cost and a significant slip in schedule, what are we measuring? We are measuring risk in the context of games of failure. We handle risk to absorb just enough failure and noise in our systems to both push the envelope on development without sacrificing the entire project effort. To know the difference between transient and existential failure, between learning and wasted effort, and between intermediate progress and strategic position requires a skillset that is essential to ultimate achievement of the goal, whether it be deployment of a new state-of-the-art aircraft, or a game-changing software platform. The noise must pass what I have called the “so-what?” test.
I have listed a set of skills necessary to the understanding these differences in the article that you may find useful. I have also provided some ammunition for puncturing the cult of “being green.”