In any walk of life, two things are true about failures: They are common and nobody likes them. They cannot be entirely avoided for various reasons. Not all failures are absolute. In fact, most failures are relative. Success does not teach much, if anything; it is the failure that provides lessons to do better in the future. Thus, not having failed at any time is probably a false claim and, if true, it suggests potentially very little positive change in the entity. The irony is that failures come with costs. In IT projects, for example, the cost may be in terms of not meeting the scope, missing the deadline or overrunning the budgeted monetary cost. On the human side, failures can be demoralizing and may negatively impact employee productivity across all functional areas involved in the failed project.
A failure signals that some risk has materialized. Two dominant risk aspects of IT projects have to do with:
- Investment (failure to provide value for the money)
- Project ownership (failure due to accountability).1
In a 2004 global survey of 200 IT professionals from companies with annual revenue in excess of US $50 million, 71 percent and 72 percent of the respondents, respectively, considered investment and project ownership risk factors “very significant.”2 Numerous surveys have unequivocally echoed a related result: The failure rate of IT projects is alarmingly high despite potential improvements in project management techniques over time.3
Even a small improvement in the project failure rate would result in impressive progress. IT projects have gained an increasingly important role in most organizations. Not only is IT a generalized enabler of just about anything (e.g., supply-chain improvements), it is also a key to innovation and growth. Therefore, successful completion of IT projects is important. Any slippage in timeline, for example, can result in delayed time-to-market, and any scope compromises can cascade into a series of revisions that frustrate both the developer and the user community.
Anatomy of an Information Technology Project
An IT project is a culmination of three subsystems:
- Process (project planning and delivery)
- Context (system to be served)
- Content (system that serves)
The chief influencer of the process is the project manager (PM), with top management support; the chief influencer of the context is corporate management and users; and for the content, it is the IT/IS professionals. The first is accountable for creating the synergy between content and context, aligning the two subsystems to work together; the second is responsible for the “why” of change, including the culture, leadership and organizational issues; and the third addresses the “how” of change.
When an intention is fed into this triad, outcomes materialize. Clearly, any substandard outcome may have to do with the fact that process, context or content did not work as intended and, as a result, the outcome is deficient (e.g., faulty, late, expensive). The complexity of success or failure lies in these three relatively independent subsystems—their own maturity and performance, culture, and the interaction effectiveness across them.4
With this amount of complexity, issues of communication, clarity in visibility of goals and accountability of one’s role (done right, on time and within budget) are key factors in project failures. Any lack of alignment across these three subsystems will mean degradation of some kind, possibly resulting in a less-than-optimal outcome. Culture, power structures and even language across these systems differ so much that keeping the whole of the project initiative in balance can be overwhelming.
The primary cause of overall project failure may stem from any of the three intertwined subsystems. For example, a lack of process maturity or project discipline is sourced in project planning and delivery, and the translation and execution of business requirements into technical specifications are rooted in content. A company with even the highest level of status in the Capability Maturity Model Integration (CMMI) may fail because subsystems responsible for context and content do not deliver effectively.
This view of project management can be fairly useful in tracking early triggers of failure and assessing how best to recover from the failure. If an influential champion and change agent is missing (in the context subsystem), the outcomes may degrade across several key factors. Or, immature planning processes in the planning and delivery subsystem may result in inadequate risk analysis of a project. And the content subsystem may be at fault when it picks weak or inadequate software for project execution.5
Finally, it is important to recognize that projects come in many varieties. Size, importance, duration, cost, technological depth, community of users, strategic importance—these are among many factors that drive differentiation among projects in an organization. Consequently, project failures may have varying impact on the organization and its response to the degree of failure.
Case Studies
To determine causes of failure and recommend mitigation measures, three failed projects at different organizations can be examined.
Case A
A multiyear, multimillion-dollar project has missed due dates. It was determined that the project planning and delivery subsystem was responsible for the slippage. The project management office (PMO) failed to consistently report progress on the project. Even in the limited effort to report progress, the PMO described 14 project success factors, but some could not be quantified. Besides, the list of measures to track the achievement of business goals and objectives was incomplete, leading to poor tracking of real progress.
Broadly, if a planning and delivery subsystem is the source of failure, problems will surface across many, if not all projects, for the weakness lies in the absence of maturity and discipline in planning and delivery. This could affect many stakeholders in the context subsystem and also frustrate otherwise competent IT professionals in the content subsystem.
In the context subsystem, it was found that, whereas functional area support staff was dedicated, there was confusion regarding the functional manager responsible for key decisions. Consequently, such decisions were delayed or not made. Moreover, there were significant differences across functional areas concerning the project management approach. Among other factors, this contributed to mistrust between functional areas, leading to myriad problems.
The following steps illustrate recommended actions:
- Clearly define the responsible manager with decision-making authority for each functional area.
- Ensure full, complete and open participation, coordination and communication among all stakeholders, including vendors, to reinforce expectations, draw upon each other’s expertise, and build confidence and trust in the project.
Case B
A multiyear, multimillion-dollar project suffered from delayed execution of decisions, causing a cascading effect on project cost, schedule and scope. The key reason: undermining the PM’s and PMO’s authority. When the discipline and authority of project management are marginalized, projects suffer. For example, a hosting decision paper was developed and briefed outside of the defined governance structure.6 Timeliness of execution was also hampered by the lack of synchronization of the timeline for vendor contract negotiation and project approval processes. The underlying factor was the limited authority of the senior PM and PMO to make project-related decisions, pushing many decisions onward to executive leadership.
To resolve the situation, the following steps were suggested:
- Revisit the decision-making authority of the PM, change control board, steering committee and executive sponsors, and adjust where appropriate.
- Establish a contract change process with clearly defined time limits for an expedited approval of change under certain circumstances.
- Ensure that everyone understands their authority and the defined governance structure and hold individuals and departments responsible for adhering to the governance structure.
Clearly, this case points to the problems of process maturity and discipline and the lack of leadership influence on the planning and delivery subsystem. As a result, any and all projects undertaken by the organization are at risk of underperformance.
Case C
A multiyear, multimillion-dollar project suffered from weak project risk identification. Some of the observations made during the root-cause analysis included:
- Defined business requirements were lacking clarity, common understanding, completeness and quality. This affected the definition and comprehension of the project scope and, in turn, impacted performance expectations and schedule, effort and cost estimates.
- Stakeholders did not understand their commitments.
- Requirements review, verification, validation and approval were immature.
- Requirements traceability was inconsistent.
- Omission of critical functionality and quality attributes was likely causing inaccurate or incomplete design.
To resolve the situation, the company should consider the following steps:
- Establish a formal requirements development process to include requirements review, acceptance and commitment.
- Establish a mature requirements management process to improve traceability (e.g., functional, technical, interface, hardware and software).
- Ensure that the requirements peer-review process truly adds value.
IT Project Audits
The role of auditors in IT projects has to do with providing assurance that critical projects of the organization are managed properly to achieve success.7 IT projects essentially define the future of the organization; assuming they are prioritized and selected properly, their success is critical to building a thriving future. IT projects, in this sense, are the precursor of what to expect going forward. The role of the IS auditor in providing an expert opinion on the state of IT projects, including emerging and unmitigated risk, should prove valuable to the organization.
Practical Implications
The “iron triangle” of the PMO (people, processes and technology)8 and resources (e.g., CMMI for Development V1.3)9 demonstrates that a key area impacting project performance and success is people. The cases described herein highlight the fact that even process maturity and the adoption of industry best practices over time can still fall short on solving cultural issues.
Organizations with an emphasis on processes invest heavily in establishing templates and mandates, and yet, institutionalization of these processes may be weak. A high rate of project failure suggests that project processes are not perceived as value-added at all levels, nor do they align with organizational culture. The management (in the cases discussed previously) later implemented the recommendations based on the specific CMMI process areas, which, in turn, resulted in measurable improvement in project(s) success rate and a favorable change in organizational culture toward processes, as evidenced in subsequent quality assurance assessments.
Finally, since organizational memory is limited, it is hard to harness the lessons learned from failures unless causes and remedies of all significant project misses are properly documented. When shared with stakeholders, this real, organization-specific case history could minimize future failures.
Author’s Note
The opinions expressed in this column are the authors’ own and not those of their employers.
Endnotes
1 The Economist Intelligence Unit, Global Study on Information Risk Management, 2002
2 IT Governance Institute, Information Risks: Whose Business Are They?, USA, 2005, p. 9
3 See, for example, The State of Project Management Survey, Wellingtone Project Management, 2016
4 Yeo, K. T., “Critical Failure Factors in Information Systems Projects,” International Journal of Project Management, vol. 20, iss. 3, April 2002, p. 241–246
5 Op cit, Yeo
6 IBM, Global Making Change Work Study, 2008, https://www-07.ibm.com/au/pdf/making_change_work.pdf
7 Ibid.
8 Project Management That Works, “The Iron Triangle of the PMO: People, Processes, and Technology,” 3 June 2011, www.pmthatworks.com/2011/06/iron-triangle-of-pmo-people-processes.html
9 Chrissis, M. B.; M. Konrad; S. Shrum; CMMI for Development: Guidelines for Process Integration and Product Improvement, 3rd Edition, Addison Wesley, USA, 2011
Vasant Raval, DBA, CISA, ACMA
Is a professor of accountancy at Creighton University (Omaha, Nebraska, USA). The coauthor of two books on information systems and security, his areas of teaching and research interest include information security and corporate governance. He can be reached at vraval@creighton.edu.
Rajesh Sharma, Ph.D., ITIL-F, Six Sigma Black Belt
Is a quality management office (QMO) chair at Software Engineering Services. He has more than 19 years of experience establishing and managing a project management office, a QMO, a metrics program, and as a lead for independent verification and validation (IV&V) projects. As a QMO and IV&V lead, he has performed quality audits, process improvement and IV&V assessments. He can be reached at rajsharmane@gmail.com.