Why Projects Fail

Any of us who are involved with “project work” (and I am speaking especially of software projects here) have seen the evidence: Projects fail. Often. They fail in spite of our Microsoft Project Plans, Work Breakdown Structures, Resource Leveling, Critical Path Analysis, etc. They fail in spite of our PMI Certifications, Project Charters, Requirements Documents, Functional Specifications, Change Management Processes, Time Tracking Systems and Weekly Status Reports. After so much energy and effort has been put into defining and refining various processes for project planning and execution, why is it that project failure rates remain more-or-less constant? As with everything else, the Bible provides significant insights into this problem.

First, we are inclined as project managers to believe our own rhetoric. In particular, we believe that we can foresee every eventuality and build every possible contingency into our project planning such that we avoid “surprises”.

Come now, you who say, "Today or tomorrow we will go into such and such a town and spend a year there and trade and make a profit" — yet you do not know what tomorrow will bring. What is your life? For you are a mist that appears for a little time and then vanishes. Instead you ought to say, "If the Lord wills, we will live and do this or that." As it is, you boast in your arrogance.

The problem here is not with the planning. After all, we are commanded to "count the cost" before we undertake a project. The problem is with the underlying assumptions of enlightened modernity. In our pride, we really believe that it is possible to understand and ‘model’ all of the interactions that take place according to nice clean rules with units of measure like ‘function points’ or ‘man hours’. But God did not create us like that. Individual team members will vary in productivity from day to day and different team members will vary in productivity both ‘in general’ and with respect to the specifics of the tasks to which they are assigned. The ‘interchangeable part’ approach to project staffing is like building a wall out of mass-produced bricks, but we are individually created ‘living stones’ … each with different sizes, strengths, etc. … that need to be carefully placed into the project “wall” to avoid gaps and weaknesses. So our first mistake is to ignore the reality of our God-created individuality.

Second, we are inclined as project managers to focus on law, not grace. For instance, there is typically a heavy emphasis on accountability which often takes the form of penalties of one kind or another for missed deadlines. As project managers, we seldom stop to realize that we may have imposed the deadlines themselves as a result of our failure to fully understand the complexities of the problem at hand. As Dilbert’s manager puts it, “Anything I don’t understand is easy.” Furthermore, if we do “empower” team members by having them set their own deadlines, we have only moved (not removed) the uncertainty. Holding people strictly accountable for predictions in this environment will only lead to longer time estimates and/or more elaborate excuses, not improved productivity or reduced time-to-completion. Grace is never free, and I am not suggesting any sort of project management antinomianism that absolves sinful team members from their obligations, but I am suggesting that a strict legalism is as counterproductive in project management as it is in the church. “Grace” in this context, then, refers to an approach to project management that encourages team members to take responsibility, to promptly “confess” when problems arise, and to accept the “forgiveness” that is available through the flexibility built into the project plan. [Note that these thoughts are based loosely on the application of Theory of Constraints to project management, and I intend to elaborate in future postings.]

But most importantly, we are inclined as project managers to believe that everybody else understands things in exactly the same way we do. With apologies to Lewis Carroll & Humpty Dumpty, “My status reports, design documents and work assignments mean exactly what I intend them to mean, nothing more and nothing less”. Communications problems of various sorts are at the root of every project problem and every problem project. Consider for a moment the most successful project in the history of the world: the construction of the Tower of Babel. My next post on this topic will elaborate on this passage, but in the meantime consider … With literally infinite possibilities available, God chose to remove only one small component of this otherwise successful project. He chose to "confuse their language.” By simply introducing confusion into their communications he effectively derailed the project without ever addressing such mundane issues as resource contention, scope creep, funding, etc.

Stay tuned for more on this topic. In addition to project communications lessons from Genesis 11 (next), I also intend to cover project planning, staffing and work breakdown (from Exodus among other places), project execution (from Nehemiah) and contingency planning (from Ecclesiastes and Proverbs). Betwixt and between I will also address project manager qualifications.