Many organizations continue to deal with the daunting problem of failing projects. Over the past 10 years, there has been numerous studies on the problem of project failure. Yet, project performance has not improved. See a few surprising recent statistics.

• Over 1 in 3 (34%) projects have no baseline. (Source: Wellingtone)
• For every $1 billion invested in the United States, $122 million is wasted due to lacking project performance. (Source: PMI.org)
• Less than a third of all projects completed successfully on time and on budget. (Source: Standish Group)
• 75% of business and IT executives anticipate their software projects will fail. (Source: Geneca)
• 75% of IT executives believe their projects are “doomed from the start.” (Source: Geneca)
• 33% of projects fail because of a lack of involvement from senior management.

Project Failure Symptoms

Projects continue to run over budget, behind schedule, produce poor quality, or just do not meet the intended objectives. Implementing project controlling strategies, consulting project management experts and leveraging new development methodology approaches (i.e., SCRUM) has not solved this problem. Why are we still failing?

Below are 10 examples of reasons given as to why the projects fail.

1. The business case, scope, deliverables or requirements were poorly defined
2. The project was forced to start execution without proper planning
3. The project expectations, success metrics and objectives were never defined or accepted
4. The project was understaffed, under budgeted, or missing critical skills roles
5. There was a lack of user input and active participation from stakeholders
6. The project’s scope, requirements and priorities keep changing
7. The leadership and key stakeholder never bought into the project
8. Project baselines, change management and quality assurance standards were not set
9. The project team did not understand the business needs and requirements
10. The technical lead/resources did not have the right technology skills

Although all these reasons have some validity, they do not truly address the underlining reason why the project failed. Most cited reasons for project failure are really symptoms. Instead of dealing with symptoms, organizations must begin to address the contextual issue. Contextual issues are complicated by the increasing ambiguity in which most projects operate.

Project Boundaries

One critical contextual issues is the overall lack of understanding of the project’s boundaries. Project boundaries are the guidelines, rules and limits that are defined to determine the reasonable and acceptable environment in which the project will operate and how the project should respond when something happens to take it outside of those limits. Project boundaries aid with establishing success measure by defining what is in the project, what is not in the project and when the intent of the project has been met.

Setting of project boundaries is a business contextual exercise that requires defining the overall business strategy and aligning that strategy to the project outcomes. Establishment of project boundaries must be completed prior to starting project activities. Project boundaries are critical inputs to the planning process.

Below are key project boundaries that should be established in order to increase the likelihood of project success from the start.

• • Business Strategic Objectives. When defining business strategic objectives, the activity should include the project sponsor, project governance, critical project stakeholders, business and technical architects and the project management expert. The objectives should clearly layout what the business is intending to achieve through the project. These objectives should be tied to project’s results, outcomes and/or deliverables.
  • Project Scope Description. A short description that lay out the deliverables (functions, features, components, and documents), outcomes and outputs of the products, services, and results of the project. The scope should be socialized and finalized with the key stakeholders. Any changes to the scope, should result in an assessment of all the project boundaries to determine if realignment is required.
  • Minimum Success Criteria. Defining project’s success criteria establishes what total success looks like. However, this initial list can get very long and be full of assumptions. This list should be narrowed down to the minimum success criteria. The minimum success criteria represents the smallest outcome that is acceptable to deem the project a success at meeting the critical business objectives. Having this will take the guesswork out of understanding at what point the project has truly failed.
  • Organizational Assumptions and Constraints. Organizational assumptions and constraints should be described at the start. These should not be left for the project team to discover on their own. For example, if known that the project’s new application must reside on the existing infrastructure due to security requirements, then this should be called out upfront.
  • Project Management Policies. Projects typically have to adhere to a number of policies and controls. Having a clear understanding of what they are and what types of constraints they will put on the project will reduce the number of roadblocks. All governance and compliance groups should be consulted so they may aid with defining the policies that will govern the project.
  • Communication and Engagement Objective. Early communication and establishment of engagement rules can significantly reduce the confusion and frustration during the project. If there a multiple stakeholders or conflicting needs, establishing a business representative that will serve as both a liaison and referee is a great option. This removes the project team from the politics and assigns someone directly with the responsibility for keeping everyone aware and involved at the correct levels.
  • Roles, Responsibilities and Authority. Knowing external roles, responsibilities and authority lines enables the project team to receive quicker decisions and increases probability that the information received is accurate. It is critical to define authority clearly. Titles and roles do not always equal authority.

Carla Griffin, BSC, MPM, PMP, ITIL, COBIT, has over 18 years of Analysis and Project Management experience in various industries (Government/Public Health, Financial Services, Information Technology, Claims Processing, and “Big 10” Consulting).