Why Do Christian Church Projects Fail?

Large projects fail at an astonishing rate — more than 50%, by some estimates.5 min

148 shares, 77 points

Large Christian projects fail at an astonishing rate — more than 50%, by some estimates. Sometimes it is a single trigger event that leads to failure. However, more often, it is a complex set of problems that put together result in failure. Generally, these issues fall into two categories. Activities the team did poorly or even worse, activities the team failed to do. These failures easily demoralize a team.

“Every Christian leader will end up being called upon to lead some kind of project but find that they have few project management skills.   The projects may be short and quick such as putting together and running a special service or church anniversary weekend.   At the other end of the spectrum they might be large and challenging. In a church situation this may mean be being responsible for some kind of building work.”

What are the primary causes of a project failure? The following list identifies the most common mistakes that contribute to projects failing:

Lack of leadership and governance

  1. The lack of project management training or experience of many Christian leaders can be an enormous stress factor for them. Whilst natural organizational ability is enormously helpful, in itself it is no guarantee of any project being both successful and low stress.
  2. The manager lacks the interpersonal or organisational skills to bring the team together and make things happen.
  3. Failure to establish a governance structure appropriate to the needs of the project.
  4. A Sponsor who lacks the experience, seniority, time or training to undertake the role effectively.
  5. Failure to establish effective leadership in one of the three leadership domains including business, technical and organisational.

Visioning Is the First Step in Strategic Planning

No shared vision

  1. Without a strong vision, strategic plans cannot be properly delineated since there is no guiding principle or ideal to plan.
  2. A failure to understand the “why “behind the “what” results in a project team delivering something that fails to meet the requirements of the project and realise any tangible benefits.
  3. Lack of coordination between multiple projects throughout an organisation and identification of pinch points. This results in projects being misaligned and potentially in conflict with one another.
  4. Failure to document the “why” into a clear vision statement. Therefore not used to communicate the goal to the organisation or used as a focal point for planning.
  5. A vision statement that is put on a shelf and never revisited for subsequent decision making.
  6. Objectives are misaligned with the overall business goals and the strategy of the organisation.
  7. Without a strong vision, strategic plans cannot be properly delineated since there is no guiding principle or ideal to plan.

Poor planning

  1. Inadequate and ill-defined project definition and unrealistic planning
  2. Planning is seen as the manager’s responsibility rather than a team activity.
  3. Failure to break a large scale master plan into more manageable sections that can be delivered incrementally.
  4. Unclear team roles and responsibilities.
  5. Requirements are not prioritised.
  6. Failure to factor in culture change activities in the plan.
  7. Failure to provide sufficient user training when deploying the product
  8. Change requests handled informally without assessing their implications or agreeing to changes in schedule and budget.
  9. The underestimation of complexities.
  10. Working under constant and excessive schedule pressure.
  11. Failure to manage senior management and/or client expectations.

Configuration and information management

  1. A change in configuration is implemented without the required verification or approval.
  2. Failure to maintain version control over documents or components resulting in confusion over what is current, compatibility problems and other issues that hinder progress.
  3. Failure to adopt appropriate tools for organising and managing information resulting in a loss of key information and control.
  4. Information is retained in people’s head, rather than documented leaving it vulnerable to misinterpretation.

The Difficult Part of Requirements Gathering Is Not Establishing What the User Wants. It Is the Exploratory Development Activity of Helping Users Understand What They Need

Requirements Issues

  1. Poor requirements gathering techniques.
  2. Unless the end product is clearly understood, it’s almost inevitable that some activities will be left off the plan.
  3. Lack of formality in the scope definition resulting in misunderstanding among the team members of what is in and out of scope.
  4. Failure to address scope creep.
  5. Individual requirements are not vetted against the project’s overall objectives to ensure the requirement supports the project’s objective.
  6. The project requirements are written based on assumptions.
  7. Not resolving potential problems or challenging situations that could occur.
  8. Failure to fully understand the operational context in which the product needs to function once the project is complete.
  9. Requirements are defined by an intermediary without directly consulting or involving the end user.
  10. Failure to broker agreement between stakeholders with differing perspectives, agendas or requirements.

Unfortunately a Person Can Always Be “persuaded” to Agree to an Unreasonable Deadline

Poor estimation

  1. Allowing a manager, sales agent or customer to coerce the team into making unrealistic commitments.
  2. Unreasonable deadlines create a lose-lose position and is the cause of many sleepless nights and project failures.
  3. Estimating assumptions are not documented, discussed or validated
  4. Estimations are based on insufficient information or analysis
  5. Commitments are made to exact estimates, rather than using a range of values that encapsulate the unknowns.
  6. Estimation is carried out without reference to performance data gathered from previous projects
  7. Failure to include a contingency
  8. Assuming a new tool, process or system being used will deliver instant productivity improvements.
  9. Those actually performing the work are excluded from the estimating process.

Project tracking and management

  1. Schedule and budget become the key drivers, resulting in corners are cut and quality compromised.
  2. Project is tracked based on large activities rather than all activities.
  3. Failure to monitor vendor performance on a regular basis.
  4. Accepting without question a task reported by a team member has been complete.
  5. Believing that when a team member is told something once that they will remember what the task was and when they were supposed to do it.
  6. Believing that although the team is behind schedule, they will catch up later.
  7. The project plan is published but there is insufficient follow up or tracking to identify issues and address them early.
  8. Bad news is glossed over when presenting to customers, managers and stakeholders.
  9. Dismissing information that indicates the project is running into difficulties.

Team issues

  1. Selecting the first available person rather than waiting to for those best qualified.
  2. No clear roles and responsibilities resulting in confusion.
  3. Insufficient resources to complete the work.
  4. Lack of sector expertise needed to complete the project successfully.
  5. Failure to provide the team with appropriate training in either the technology, the processes or the business domain in which the system will function.
  6. Lack of feedback allowing resentment and discontent in the project team.
  7. Not addressing poor team dynamics or individual non-performance results in the team becoming disengaged.
  8. Decisions and general practices that undermine team motivation.
  9. Loading a team that is already overworked with more yet  work.
  10. Adding more resources to an already late project causes addition strain on the team and lower team  morale.

Poor risk management

  1. Risk management being seen as an independent activity rather than an integral part of the planning process.
  2. Failure to think ahead and to foresee and address potential problems.

Stakeholder engagement issues

  1. Not obtaining executive buy-in.
  2. Failure to identify or engage the key stakeholders.
  3. Failure to get stakeholder buy-in.
  4. Allowing stakeholders to dominate the project while ignoring the needs of others.
  5. Lack of regular communication/meetings.

Architecture and design issues

  1. Being seduced into using technology that is not required or inappropriate.
  2. Allowing a pet idea to become the chosen solution without considering solutions that might better meet the overall business requirements and goal.
  3. That lack of architecture results in duplication of effort, gaps, unexpected integration costs and other inefficiencies.
  4. Failure to take into account non-functional requirements when designing a product, system or process.
  5. Poor architecture resulting in a system that is difficult to manage and maintain.
  6. Development “gold plating”. Unnecessary add-ons and “would like to haves” hinder the project and devalue the final outcome.
  7. Trying to solve all problems with a single tool simply because it is available.
  8. New tools given to the project team without adequate training or arranging for appropriate vendor support.

Poor quality management

  1. Team avoids the difficult decisions as some stakeholders maybe unhappy with the outcome.
  2. Group decisions are made at the lowest common denominator rather than facilitating group decision.
  3. Key decisions are made without identifying or considering alternatives.
  4. Failure to establish clear ownership of decisions or the process by which key decisions will be made.
  5. Quality is viewed simply in terms of testing rather than usage.
  6. The quality of project deliverables are seen by the Project Team as the responsibility of the Quality Assurance group.
  7. Testing focuses on the simple scenarios whilst ignoring the more complex situations of error and recovery handling.
  8. Integration and testing of individual components created in the project is left until all development activities are complete.
  9. Not undertaken ongoing incremental ingratiation and verification to find and fix problems early.
  10. A test environment that is configured differently from the target production, or operational environment.
  11. Quality requirements that are never discussed, thereby allowing different people to have varying expectations of what is being produced and standards to be achieved.

Poor decision making  

  1. Expert advice regarding critical decisions is either ignored or never sort.
  2. Lack of “situational awareness” results in the making of ineffective decisions.
  3. Failure to obtain clear high level decisions results in procrastination and inaction.

To the seasoned PMs‘, which ones did we  miss?  Any suggestions you may want to share for overcoming these challenges?

Like it? Share with your friends!

148 shares, 77 points

What's Your Reaction?

hate hate
confused confused
fail fail
fun fun
geeky geeky
love love
lol lol
omg omg
win win
George Brzozowski
I want to help you to see news events as starting points for constructive conversations. I seek to cut through the froth of the political spin cycle to underlying truths and values. I want to be so focused on progress that together we can provide a credible and constructive counter-narrative to the hopelessness-, anger-, and fear-inducing brand of discourse that is so pervasive in the news.


Leave a Reply to Anonymous Cancel reply

  1. Thank you Dean for posting this. If corporations are not willing to take the steps to ensure that this criteria is met, they have no business even bidding on large projects. What’s worse is when the PM is made the pariah when it was the failure of upper management….PM’s manage what is handed them most of the time. Sometimes it is a well engineered and estimated project but when it isn’t it is hell, especially with no support. Think twice before accepting that responsibility

  2. Ineffective implementation in either of these two areas can trip up any project:

    Requirements definition – requirements must be clearly stated, communicated, and ratified while ensuring they meet systemic and organizational expectations for change.

    Scope control – effective management of the scope in relation to resource allocation and task execution focused on the requirements.

    Given project selection, leadership and vision, effective planning and its byproducts are the foundation of a project. Solid requirements that will affect the intended change, and sticking to the plan will go a long way toward achieving success.

    It’s not that we don’t understand this. The issue is really understanding it well enough to recognize that every project is susceptible to these pitfalls, and the best time to prevent them from being an unwanted complication is during the planning stage.

  3. 1. Poor communication.
    2. Rushing ahead without properly baselining a project 3. Not having an agreed business case.
    4. Having no change control procedures in place for changes after design freeze 5. Senior sponsor from hell. 3. Giving in to all client requests.

    The list goes on and on

  4. Successful projects balance project scope, cost, and schedule with user needs and project constraints.
    Identification of the user needs, project constraints, and resource requirements early in the project life cycle help projects meet their objectives. The greatest risk to project success is scope creep. Well-defined configuration management and change procedures are needed to control scope.

  5. So why do project fail?
    From my experience Projects fail for many reasons, from immaturity at commitment and the introduction of unfounded change to uncontrolled design development and having no idea about what ‘success’ looks like.

    Any other thoughts and suggestions?

    1. Crossrail are a highly regarded organisation in the project management profession. With their large-scale projects requiring many interlinking processes to run seamlessly in conjunction with each other, thorough plans must be put in place to minimise any setbacks and ensure that the project is carried out efficiently and correctly.

      These transferrable practices are ones that can be applied across all fields of project management.

    1. Another good set up items for why projects fail. Though it is talking about IT projects, it is certainly a list that applies to all. Thank you

  6. Remember that these articles refer to ‘project’ in a more comprehensive sense that we deal with for external clients. The stakeholder analysis, benefits analysis and realisation planning, project sponsoring etc has been undertaken within the client organisation before we get deal with the project, and these articles refer to that larger project picture.

  7. I agree. Focusing on success or failure can quickly become a binary choice, and since we can always do better, by definition, every project fails, just like any golfer who fails to complete a round in 18 strokes. While most of the article is good, if routine, advice, it perpetuates the binary myth rather than exhorting project delivery teams to strive for excellence and value driven delivery. If identifying ‘goals’ is simply a checkbox on a score card, it will not be embraced: If we are passionate about creating a better built environment and serving our client’s business – or passion (not their building or their project) we won’t be able to avoid knowing and embracing their vision. At the risk of hyperbole, I don’t want to be a project manager, I want to be a participant in the delivery of a great built environment, through great project managment.

  8. What defines a project’s failure? What are your metrics? I’ve worked many projects over the years and on most, there is some aspect of the project that fails as to one or more of the stated goals. Does that make the entire project a failure? I submit it does not. Some goals are inherently not measurable, or are unrealistic from their inception. Sometimes, external influences outside the influence of the project team cause failure to achieve a goal.

    I understand the point of the article, but I just want to point out that we humans quite often focus on failure to the exclusion of all related successes. Negative outcomes always trump positive outcomes for attention, even if they are associated with the same project or event.

  9. I’ve got another question, are project failures considered normal? Long-held beliefs and studies have indicated that a majority of projects end in failure, perhaps suggesting that project failures are becoming an accepted norm. The oft-referenced, now decade-old, Standish Group Chaos Report cited a 31% project failure rate effectively lowering the bar, and along with it any optimism for a successful project effort.

  10. This is a great article — I plan to include it in next week’s Business Management Training Program (BMTP) held at Management Services Headquarters in Germantown MD.

Choose A Format
Voting to make decisions or determine opinions
Formatted Text with Embeds and Visuals
The Classic Internet Listicles
Open List
Submit your own item and vote up for the best submission
Ranked List
Upvote or downvote to decide the best list item
Upload your own images to make custom memes
Youtube, Vimeo or Vine Embeds
Photo or GIF
GIF format
%d bloggers like this: