By Stephen Mukoyi
PROJECTS do not succeed simply because organisations have experienced Project Managers, well-designed methodologies, sophisticated technology or detailed project plans.
Successful delivery requires a set of conditions to work together.
If the right things happen at the right time—and the organisation actively supports them—the probability of achieving the intended project outcomes increases significantly.
From Asking Why Projects Fail to Asking What Must Go Right
In my earlier article, “Why Projects Fail in Organisations”, I argued that project failure is rarely the result of one isolated mistake. Weak planning, unrealistic deadlines, inadequate resources, poor communication, weak sponsorship, uncontrolled change, governance gaps and insufficient stakeholder engagement can reinforce one another and create the conditions for failure.
The opposite is equally true. Project success is not normally created by one heroic intervention. It is created when a number of critical success conditions are deliberately established, maintained and monitored throughout the project lifecycle. The question therefore changes from “Who is responsible when the project fails?” to “What must go right for this project to deliver the intended value?”
- Start With a Clear Business Problem and a Compelling Case
A successful project begins with a clear understanding of the problem or opportunity it is intended to address. Before approving a project, decision-makers should be able to answer several basic questions:
- What problem are we solving or what opportunity are we pursuing?
- Why is action required now?
- What business benefits are expected?
- How will those benefits be measured?
- What happens if the organisation does nothing?
- Is the proposed solution feasible within the organisation’s financial, technical and operational capacity?
A project should not be approved merely because a technology is attractive, a competitor has implemented it, or an executive wants it. A sound business case creates a common reference point for decision-making and protects the project from losing its strategic purpose during execution.
- Define Success Beyond the Iron Triangle
Scope, cost and time remain important, but they are not the complete definition of project success. A project can be delivered on time and within budget yet fail to produce meaningful business value. Conversely, a project may require an approved change to schedule or cost while still delivering substantial strategic benefits.
Successful projects therefore establish success measures that include outcomes, benefits, quality, customer or user experience, regulatory requirements and operational readiness. The project team should know from the beginning what evidence will demonstrate that the project has succeeded.
- Secure Visible and Active Executive Sponsorship
One of the strongest predictors of whether a project can navigate organisational complexity is the quality of executive sponsorship. A Sponsor should not simply approve the project charter and disappear. Active sponsorship means providing strategic direction, removing organisational barriers, securing resources, making timely decisions and protecting the project’s objectives.
When difficult decisions arise, the Sponsor must be prepared to act. When departments compete for resources, the Sponsor must help establish priorities. When risks threaten the business case, the Sponsor must ensure that the organisation responds. Executive sponsorship should therefore be visible throughout the lifecycle, not only at project launch and closure.
- Build a Realistic and Integrated Plan
Good execution starts with good planning. A realistic project plan translates the approved scope into manageable work, identifies dependencies, estimates the resources required and establishes a credible path to delivery. Planning should cover requirements, work breakdown structures, schedule, resources, procurement, testing, data, implementation, training, risks, communications and transition to operations.
The organisation should resist the temptation to announce a completion date before understanding what is actually required. A three-month deadline is not a plan. It is a constraint that must be tested against scope, capacity, dependencies, decision-making speed and risk. Where the deadline is fixed, management should also be prepared to prioritise scope, provide additional capacity or accelerate decisions.
- Provide the Right Resources at the Right Capacity
Projects require more than a list of names on a project team. They require people with the right skills, authority, availability and commitment. Assigning operational staff to a project on a nominal part-time basis while expecting them to maintain a full workload can create hidden capacity constraints.
Successful organisations therefore ask not only, “Who is assigned to the project?” but also, “How much capacity does that person actually have?” Resource planning should include business users, technical specialists, risk, compliance, finance, procurement, legal, operations and other functions where their involvement is necessary.
- Establish Strong Project Governance and Decision Rights
Governance provides the structure within which projects are directed and controlled. The Sponsor, Project Manager, Steering Committee or Project Board, project team and other decision-makers should have clearly defined responsibilities. Decision rights should be understood before a major issue arises.
- Who approves changes?
- Who accepts project risks?
- Who resolves cross-functional conflicts?
- Who approves additional expenditure?
- When must an issue be escalated?
- What are the stage gates and approval authorities?
Effective governance does not mean creating unnecessary bureaucracy. It means ensuring that the project can make timely, informed decisions and that accountability is clear.
- Make Stakeholder Engagement a Deliberate Management Discipline
Projects affect people, processes and organisational interests. Stakeholders therefore need to be identified, understood and engaged throughout the project. Executives, employees, customers, regulators, suppliers, technology teams, finance, risk, compliance and operations may all have different expectations.
The project should establish a stakeholder strategy that answers who needs to know what, when they need to know it, how they should be engaged and what decisions or actions are expected from them. Communication should be tailored to the audience rather than relying on one generic project report.
- Treat Risk Management as an Action, Not a Register
A risk register does not manage risk. People manage risk. A project can have an impressive register containing dozens of risks and still be poorly managed if nobody owns the responses.
Effective risk management should follow a continuous cycle: identify, analyse, respond, monitor and escalate. Particular attention should be given to risks that threaten the critical path, business case, benefits, regulatory compliance, implementation readiness or overall project viability.
The best project teams do not wait for risks to become issues. They discuss emerging threats early and make the necessary interventions while options still exist.
- Control Scope and Manage Change Properly
Change is inevitable. Uncontrolled change is not. Projects frequently experience a gradual accumulation of additional requirements: a new feature, an extra report, another integration, a revised process or an additional management requirement. Each request may appear small, but collectively these changes can transform the project.
A strong change-control process does not prevent change. It makes change visible. Every material change should be assessed for its impact on scope, cost, time, resources, quality, risk and benefits before approval. This enables management to make informed trade-offs rather than allowing the project baseline to change invisibly.
- Involve Users and Business Owners Early
A technically successful project can still fail if users cannot or will not use the solution effectively. Business users should therefore be involved in requirements definition, process design, testing, acceptance, training and implementation readiness.
User involvement is particularly important in technology-enabled transformation. Technology may provide the capability, but the organisation must redesign processes, prepare people, clean and migrate data, establish controls and ensure that the operating model is ready.
- Start Change Management at Project Initiation
Change management should not begin shortly before go-live. The earlier people understand why a change is required, what it means for them and how they will be supported, the greater the opportunity to address resistance.
People may resist because they do not understand the reason for change, fear loss of responsibility or employment, have not been consulted, lack confidence in the new process or believe the change will create additional work. Successful projects therefore combine communication, training, stakeholder engagement, leadership and readiness activities from the beginning.
- create a Culture Where Bad News Travels Fast
One of the most important conditions for successful delivery is a no-surprises culture. Project teams should be able to report that a milestone is at risk, a vendor is underperforming, a requirement is unclear or a dependency has failed without fear of blame.
The earlier management knows about a problem, the more recovery options are available. The question should not be “Who caused the problem?” but rather: “What is the problem, what is the impact, and what must we do to recover?” This shifts the culture from blame to resolution.
- Ensure Suppliers and Partners Are Actively Managed
For many projects, critical outcomes depend on external suppliers. Contracts alone do not guarantee successful delivery. Vendor performance must be actively managed through clear deliverables, milestones, service levels, dependencies, acceptance criteria, escalation mechanisms and governance forums.
The organisation should also understand its own obligations. Delays in providing requirements, data, decisions, access, infrastructure or approvals can affect a supplier’s ability to deliver. Successful projects therefore manage the relationship as a shared delivery ecosystem rather than treating the vendor as the only party responsible.
- Measure Benefits, Not Just Deliverables
A project produces deliverables, but organisations ultimately invest in projects for outcomes and benefits. Therefore, project closure should not be treated simply as the point at which the final system, building, product or document is handed over.
Benefits should have owners, measures and realistic timelines. Depending on the project, benefits may include increased revenue, reduced costs, improved customer experience, faster processing, stronger controls, reduced risk, improved compliance or greater operational efficiency.
The Project Manager is responsible for coordinating delivery, but benefits often belong to business owners who must embed the new capability into normal operations. Benefits realisation therefore requires ownership beyond the project team.
- Make Quality and Testing Non-Negotiable
Quality should be designed into the project rather than inspected in at the end. Requirements should be clear, acceptance criteria agreed and testing planned early. For technology projects, this may include functional testing, integration testing, security testing, performance testing, data validation, user acceptance testing and implementation readiness.
A project that reaches go-live quickly but creates operational disruption, customer complaints or control weaknesses has not achieved sustainable success. Quality must therefore remain connected to the business case and the risk appetite of the organisation.
- Give the Project Manager the Authority to Manage
The Project Manager should be accountable for project management, but accountability must be matched with authority. The Project Manager needs access to decision-makers, project information, resources and escalation channels.
Organisations should avoid the “hero Project Manager” model in which one individual is expected to compensate for weak sponsorship, inadequate resources, procurement delays, unresolved policy issues and organisational conflict. Project management is a leadership discipline, but project success is an organisational responsibility.
- Maintain Focus on the Critical Path and the Critical Few
Successful project teams distinguish between activity and progress. A project can have many meetings, reports and actions while the activities that determine the completion date remain unresolved.
Leadership should therefore maintain visibility of the critical path, major dependencies, high-impact risks, key decisions, unresolved issues and benefits that justify the investment. Attention should be concentrated where it can materially influence the outcome.
So, What Must Go Right?
For projects to succeed, several things must go right at the same time. The business case must be clear. Objectives must be measurable. The Sponsor must be engaged. Planning must be realistic. Resources must have genuine capacity. Governance must enable timely decisions. Stakeholders must be engaged. Risks must be actively managed. Scope must be controlled. Users must be involved. Change management must begin early. Suppliers must be managed. Quality must be protected. Benefits must be measured. Most importantly, the organisation must create an environment in which problems can be raised early and decisions can be made quickly.
The central lesson is simple: successful project delivery is not an accident and it is not the result of heroic Project Management. It is the result of deliberately creating the conditions for success and continuously protecting those conditions throughout the project lifecycle.
When organisations ask not only “Is the Project Manager doing the job?” but also “Have we created the conditions for this project to succeed?”, project management becomes a collective organisational discipline rather than an isolated function.
Disclaimer
This article was written by Stephen Mukoyi, a very experienced Project, Program and Portfolio Management Professional, in his own personal capacity. The views and opinions expressed in this article are those of the author and do not necessarily represent the views or position of his employer, clients, professional associations or any other organisation with which he may be associated.
