Too Big to Succeed: Managing Project Complexity
by Tunde Ajia, Project Consultant
Image source: https://www.historic-uk.com
When complex projects fail
When it went belly-up in 2011, the National Program for IT (NPfIT) or Civilian Computer System (CCS), as it’s popularly called, was the largest public-sector IT program ever attempted in the UK. The CCS would have ushered the UK’s National Health Service into an era of info-tech driven bliss. It promised, among other things, online out-patient booking services, integrated electronic patient records systems, computerised referral and prescription systems, etc. However, what began as a £6 billion national asset gradually dilated into a whopping £11.4 billion drain pipe, according to a 2013 estimate. Why not? If a project employs some of the biggest players in the IT industry—I’m talking Accenture, CSC, Atos Origin, Fujitsu and BT—less is not expected.
But almost a decade after Prime Minister Tony Blair initiated it at a seminar in Downing Street, the CCS caved in from a deluge of indiscriminate contractual changes, technical issues and prolonged stakeholder disputes. The Public Accounts Committee called it one of the “worst and most expensive contracting fiascos” in public sector history. As a public-sector programme, there is enough literature to reminisce the failures of the CCS for the next 50 years. But that is not the aim of this article. While analysts blamed technical problems, stakeholder disputes and incessant contractual changes, only a handful realise that these factors rode on CCS’s complexity.
In hindsight, the CCS bore several red flags initially masquerading as strengths.
First off, for a project of that size, magnitude and pioneer status, its procurement and implementation processes were rushed, allowing too little time for consultation with key stakeholders. Though lauded for its speed and efficiency, that became its Achilles’ heel. The lesson here is simple: complex projects would self-destruct if you involve active stakeholders without a clear definition of the project scope and deliverables.
Secondly, it being an IT-based project spanning several years to complete increased the risk of the original deliverables being outrun by technological advancements.
Lastly, at the time of its implementation, there was enough evidence of mistrust from CCS’s overall userbase. Basic stakeholder management wisdom says no project can survive opposition from those it was supposedly designed to serve. These and many factors wrapped themselves around the CCS’s enormous frame, constricting it to death.
When does a project really fail? Can we cry failure when a major stakeholder pulls the plug or when the project fails to deliver socioeconomic returns on investment?
“The lesson here is simple: complex projects would self-destruct if you involve active stakeholders without a clear definition of the project scope and deliverables.
Project failure at a glance
Any attempt to define project failure invariably links back to earlier studies by Lyytien and Hirchheim in 1987. In 2013 a further study into why projects fail, indicated they do not: satisfy approved schedule, accomplish cost objectives, and deliver on expected project scope. The study further classifies all types of project failure into four categories.
- Correspondence failure. I.e., Design objectives or specifications not met.
- Process failure: I.e., the project cannot be executed within the allocated time or monetary budget.
- Interaction failure: I.e., user attitude, satisfaction, and frequency of use do not correspond to the level of project usage.
- Expectation failure: I.e., project does not meet stakeholder requirements, expectations, or values.
Project failure and complexity
Though Ewusi-Mensah (2003) identified eight causes of project failure, further research revealed that they are indeed mere by-products of two root causes: “a lack of adequate and sufficient resources (including skilled management personnel provided for the project) and the complexity inherent within the project itself.”
More studies on IT project failure such as Al-Ahmad et al (2009) extended the root cause of project failure to include the complexity and size of a multi-faceted project.
Whilst in Whitney and Daniels 2013 study they argued that “Unlike a rational, simple system, the complete knowledge of a complex [project] system exists at a tacit level that we will never be able to fully understand or precisely represent in a model as a representation of a complex system will be always incomplete, abstracted, historical and subject to the perception of the observer’s vantage point in time.” The study also faults traditional [project] management approaches for “treating projects like ‘rational’ systems and considering the artifacts that result from the planning and design phases of a project as part of the formalised structure to be executed with encompassing authority of the project manager.”
That is to say as living systems, larger-than-life projects often evolve into a form of their own. As they adapt to their economic and socio-political environments, they assume a dynamic nature that cannot be managed using the structured, control-centered thinking of traditional project management.
“While technical know-how and experience will continue to have their place, project managers and stakeholders must exhibit an openness to learn, unlearn and relearn.
Handling Complexity
There is no one way to mitigate the risks that come with complex project systems. The dynamic nature of the project environment, the politics of projects and human factors would weaken any blanket strategy. Nonetheless, there are constants. While technical know-how and experience will continue to have their place, project managers and stakeholders must exhibit an openness to learn, unlearn and relearn. That said here are five ways to navigate complexity.
1. Assemble the Right Team
Teams determine whether a project succeeds or fails. However, team building is not as easy as it seems. The eyes to recognise the best, sell them on an offer and manage them to work together is a skill only a few project managers have mastered.
Complexity thrives in uncertainty, dependency and interdependency, technology and innovation. You want to have a team who understands these dynamics well enough to predict a project’s future and prepare for it. Also, assembling a dream team is only one of many steps. Your team must understand their roles, play their positions and learn to assist other teammates throughout the project’s duration.
2. Prioritise
The earliest sign of complexity is the abundance of legitimate distractions. What starts as a building project could easily veer into a mini tech project if you fail to priroritise.
Distractions are the most expensive factors of project failure because they zap your most valuable resource, time. As a project manager, you must master the art of stratifying your tasks using the Eisenhower matrix: Urgent and Important, Urgent but not Important, Not Important but Urgent, Not Important and Not Urgent. When you master prioritisation and focus, you and your team are a formidable force.
3. Know Your Stakeholders
Your team members qualify to be called stakeholders. But there are levels to stakeholdership. On whose say-so does the project succeed or fail? Who represents the interests of the project outside the project’s delivery environment?
Many project managers assume that everyone impacts the project uniformly. From my experience, this is far from true. The most powerful stakeholders I know occupy some or all of these positions: The client or their representative, government authorities, project boards, subject matter experts, community leaders and those affected directly by the project. So, identify your stakeholders, understand their roles, clarify expectations and keep them involved.
4. Communicate
Dynamism is the stuff of complex projects. The intricate interdependency in the system means that you’ll experience fast, multiple changes. Realtime communication is key here.
A complex project could be affected by a sudden labour crisis or a market tickle that sends the price of essential materials over the roof. While there are contingency plans and shock absorbers built into most projects, how well and soon your team members can bring them to bear depends on the strength of your communication system.
As digital tools continue to make face-to-face meetings unnecessary, don’t forget to have a real conversation with your team and stakeholders.
5. Adapt and Assess
No matter how realistic your plan is, it will be miles away from the reality after implementation. Therefore, adaptability and continual assessment is key.
Projects fail due to lack of regular assessment by the project manager; for smaller projects, most PMs simply set goals, assign tasks and check in near the deadlines. This system cannot work in complex projects because it’s harder to expedite last-minute changes due to the projects nature. Therefore, continual assessment is crucial to knowing what’s working and what’s not before it gets too late.
Overall, complexity cannot be managed or controlled in the literal sense of the word. But we can influence the interaction of its individual parts in a way that engineers desired outcomes.
Author Tunde Ajia
Tunde is a project management consultant and strategy advisor and has managed the delivery of complex projects and major programmes across diverse industry sectors. He is an active APM and ICCPM volunteer, a board member of the PMI UK Chapter and Oxford Urbanists (OU) and currently researches the complexity of megaprojects at Cranfield School of Management at a doctoral level. Connect with Tunde on LinkedIn @Tunde Ajia and Twitter @Tuibaj.