Finally, make those projects happen

Why do we do projects & programs?

Business is in continuous motion, taking steps to do craft something new, adapting or adjusting to changing conditions or maintaining old stuff to keep it alive and running.

The collective name for such efforts is “project”, as they usually time-bound and result from the collective work of a team. The results of these projects are “work products”, with quality and specifications matching the original requirements.

Massive privatizations and the looming Y2K deadline and the concept of Program (“Programme”) was created in the UK, reflecting the additional complexity and business dimension of complex projects, aiming at achieving a value or a state. The practice became a global standard in the industry.

The original reason to undertake these efforts, projects or programs remains: the need to get something (a work product or business value) delivered, preferably within pre-approved budget and time.

This is business after all: investing into a new venture, implies believing that the returns will be worth the investment. The capacity to deliver is key to the initial approval and funding. Meanwhile, the average poor performance of the execution has been undermining trust for decades, and stakeholders have been growing weary of launching another yet bottomless money pit.

Projects used to be relatively simple: run the payroll, manage inventory, perform financial transaction… Automation and more computing power led to more complex projects and programs: to pilot the robot-welding of car frames in a plant; inspect the tank of a nuclear reactor; land a spacecraft on a comet). Quantifying and realizing the expected value became an increasingly complex effort, as the actual use of the new construct was determining the true value. The delivery of a work product is not a business enabler, but only the justification of the now sunk costs. 

The realization of the value of a car is not when it sits on a dealership, but when a customer provides a payment for it. Until then, it was an investment (dealer) or a cost (manufacturer). Limiting projects valuation to their budget-to-delivery is reducing the overall project value to its costs of delivery. The problem is that project management models do not account for what happens after delivery, creating a major disconnect between business stakeholders and project management teams.

Project Management has become a quasi-commodity skill for technical staff as they became the trademark of technology roles. Since IT Department has been running projects for a long time, they appear best prepared to run all projects. This point of view carries some truth, as most technologists are comfortable with process discipline, reporting and team work already.

While this de facto specialization was good for the general practice of the discipline, a side effect has been the disengagement of non-technical staff. Business and functional specialists can hardly compete with technologists when the primary focus is adherence to methodologies and processes already part of their daily lives. The more process discipline brought into project management, the greater the gap with business priorities, drivers and insights, leading to a growing frustration by the business teams. This gap exacerbated over time and has turned into a somewhat toxic environment, loaded with misunderstanding and distrust between “project specialists” and “business leads”.

Building neutral ground to help rekindle this critical collaboration would help turn around the success rate of projects from a lower 50% ratio to 80% and above, where it should have been all along. There is no material reason explaining why project performance is low, except that the projects being measured are almost always viewed as incomplete by the business owners.

To make it worse, business teams do not have a path to remedy the gap, as any challenge to the delivery triggers a review of the “final product: against the “Business Requirements” that were approved initially, in the process muting any chance to recast the original business needs.

I have led and managed hundreds of projects and programs, strategic initiatives, transformation efforts and business endeavors for many years around the world, and never found a systemic or unpreventable reason for failure or dissatisfaction on the outcome.

The core reason why projects fail

The ratio of success in projects across the USA for the past decade has barely moved from the barely 50% threshold. Including into the ratio projects completed but which value has been dismissed or greatly reduced by the business leaders expected to benefit from it, the actual successful rate might possibly be in the single digits. A recent survey showed that barely 25% of organizations trust their own development teams.

Although pure technical projects can be more predictable than business undertakings, a project remains at the core a declared intent, an intention. Based on rough estimates, and an educated guess on circumstances and time, estimates are crunched, and budgets are released. A problem of course, is that all is based on extrapolations about the future, and the mechanism to handle variations is weak, to say the least.

The more external components, organizations and dependencies involved into the scope, and the more likely one or more will fail.

Project management primarily focuses on variances against the execution of the plan, only recording the external variances and adjusting the project timeline or resource plan accordingly. This is comparable to a sailor going at sea with a whole manual and descriptions, but not checking the weather or adjusting when meteorological conditions change.

Projects do not fail because people are incompetent or ill-prepared (usually). They fail because the project discipline approach is imperfect, and organizations have delegated this activity for too long without realizing the downstream impact.

Core reasons for projects to fail can be grouped in 8 main categories:

Let’s explore a few of them:

1.  Lack of General Project Discipline & Knowledge

Project management is not a glamorous activity; hence people mostly study this discipline when they need it or are inclined to it. Even with seasoned specialists, the core project discipline is about the proper execution and control of tasks, as per the plan and estimates.

In some cases, like technical projects, this is enough as a team of engineers usually handles such micro-management well. But unless they had an opportunity to be involved previously, most business and functional project members come with little or no knowledge, or even understanding of the rigor and dynamics of a project execution.

The key thought leadership movements of the past decades have in effect discounted or ignored the actual execution of their recommendations, a gap that still has not been filled. Only recently have tools and practices included a “how to” portion that addresses project execution at a high level.

So technical staff took over the discipline, its rationale and its education, moving it deeper into the technology realm, and further disenfranchising non-technical people.

2.  Business and technical silos impairing communication and creating misunderstanding

The growing disconnect between technical and business leaders creates many hurdles, most coming to surface when a project requires them to work together.

Business and functional leads have a common, but insufficient knowledge of technology and its boundaries (both possibilities and limitations). This lack of knowledge, while understandable, prevents them from fully engaging with their technology counterparts, and creates multiple layers of miscommunication or misunderstanding.

On the flip side, technology personnel have usually a very shallow understanding of the business, its priorities and constraints. Their lack of knowledge is often worsened by a low appreciation for accounting and financial matters, and the concept of quick ratio or double-entry bookkeeping can make their head spin.

The ineffective communication creates tension and can easily turn into hostility, as each side will consider the inadequacy of knowledge of the other before their own shortcomings.

No surprise that the final delivery of the joint effort might not satisfy anybody.

3.  Inadequate validation of estimates

A funny thing about estimates is that the precise calculation of times, costs and efforts is almost always based on questionable data. Benchmarks exist that spell out the number of lines of code, database elements, web page components in average are delivered by a standard-skilled person. Here lays the confusion about the meaning of average: practitioners tend to jump to a Gaussian representation, where variances to the centered average (the mean) need to be explained and resolved to achieve a better Sigma value.

While this would work if the numbers plotted were just a pure distribution of comparable runs (e.g.: a factory process). The elephant in the room here is that the conditions and context of each project can vary dramatically between two projects, impacting the performance but not recognized in estimating assumptions.

It is better to have bad estimates than no estimates, at least in most cases; but there is a fundamental ethical issue assuming that the budget, effort and costs of a project are based on actual science. The result is both hardship on the project execution, and project stakeholders mislead into believing that the predictions are rock solid, then feeling distrust when they find out it is not true.

4.  Imperfect agreement on scope, goals and outcome

Most ideas come from a business need or imperative, linked to an expectation of return or value to the business: improving a process or function, launching a new product, optimizing a performance for instance. At some point, the need is translated into business and functional requirements. This is the raw material that the technical and design team will be working from. The problem is that the requirements are an interpreted vision of what must be created to fulfill the business need. What is lost in the translation will never be achieved, because it fell off the wagon from the start.

You cannot achieve what you do not know, and you cannot measure what you cannot understand.

The “encapsulation” of projects’ Requirements and Delivery into Business Needs and Business Needs Fulfillment respectively is a key reason for projects failures. The solution implies breaking down these barriers and holding back launching any effort until technical teams can describe the business need and vision, while business and functional leads can describe the solution in technical details, in such way that the other parties understand and agree.

5.  Management of changes and variances in insulation

Changes are inevitable, whether caused by external conditions evolving, imperfect estimates that did not account for external and out-of-scope causes, or a whole stack of other reasons.

Most of the project methodologies include a comparison between actuals, plans and projections, with of a Gantt, burnout chart or other representation. Good project discipline includes recognizing the variance against the model, as well as the record and the root cause for the change, and a revision of the forward-plan.

Solutions to variances often include removing something from the scope, increasing the budget and timeline or changing the architecture of the solution. While this might allow the project to come back on the estimated track, little consideration is given to the downstream changes to the business value.

Every modification to the scope, solution or costs should be considered as a proposed business case for change. The review should include a typical 5 years view of the additional investments or reduced returns / benefits, to determine if the change is worth it and to prepare the business for the new configuration of the solution.

Managing changes in insulation, as a reactive and mechanical adjustment might cause a project a much bigger impact than the original variance suggested.

6.  Inadequate deployment preparation and discipline

A solution to the business need has been created and tested, hence the technical management of the project is practically over. The Delivery and Receipt or Acceptance are mostly formalities, as they are based on the approved and signed off requirements. This is where the technical versus business dysfunction creates the largest gap, between irreconcilable views.

Field users of the new solution will need to change their way of working, their work habits, how they think about the function being changed. This is not always easy, especially when people have been doing the same thing for a long time or are under pressure to produce results. They can manage the new tools, the new scripts; the hard part is moving from a way of thinking to another, against all they learned and believe until now.

A second category to be taken care of is the middle management. Top management got the briefings about the change and are often comfortable with it. But those who will be responsible for the actual implementation are line managers and their reports. They will need to tell their teams a story that makes sense; they will face the hard questions; they will have to manage errors, setbacks and frustrations. This population is routinely forgotten in the deployment efforts, or just get a high-level Power Point presentation which is good for general communication, but grossly inadequate for field deployment.

The combination of insufficient support and training for those directly impacted by the change and the resistance of the middle-management to put their neck out without proper support can be lethal for a project.

7.  Inaccurate and often incorrect assumptions and business case justification

We saw earlier the impact of imperfect estimates on the outcome of a project or program.

A part of the issues with estimates is that most are based on assumptions, themselves a weak spot for validation. Explicit assumptions are made on yet-undetermined decisions or options, for the sake of creating an explicit solution. No project can start without having at least a few question marks to be validated later. They can be a decision to be made, a technical solution to work, a performance to be achieved as a result.

It requires a high level of rigor to ensure that all assumptions are periodically revisited, especially upon delivery or change mandate. An aggravating factor is that in many cases, a team making assumptions to build a case or define a solution does not share all assumptions with other teams, which end up blindsided.

The outbound counterpart to the assumptions is the calculation of returns, benefits or value of the solution upon full deployment. Whether straight ROI case, a more complex NPV or even an advanced Equity Value Added, the representation of the investments / costs and returns / benefits is always based on gross estimates and calculations of impact. These estimates are most of the time wrong, unless a complete business modelization is performed.

8.  Inadequate support and engagement from Sponsors and Owners

Over and over studies and debriefs highlight the negative impact of project and program Sponsors and Owners not pulling their weight enough, or not making the hard decisions when needed.

While some Sponsors might give lip service to the commitment, it is hard to believe that senior leaders and executives do not care for some of the core investments of their organizations, especially after they approved them.

But are they aware of the true expectations attached to the role, and were they given the tools and support needed to be able to succeed?

The Project Sponsor is ideally placed to communicate with peers, make a decision happen, obtain deployment commitment and discuss the impact of a change with the relevant parties and functions.

The Sponsor requires to be fully informed and supported by the project team to be successful as a Champion. In addition to the commitment of time and attention made by the sponsor, the project team needs to make asimilar commitment to help and support the sponsor until the end of theproject. Only when both sides of the equation are defined can a project besuccessful.

This is not rocket science; you can do it

Many of the causes for projects and programs to fail are in fact relatively simple things and do not require extensive project management training.

Managing large meta-projects, roadmaps or programs as well as portfolios can require additional skills and tools. But while most projects and programs do not require advanced methodologies; rigor and a clear understanding of the ultimate goals are absolutely necessary however.

Years ago, we experimented with zero-variance projects; a reserve was created that could be added to a project if needed, and after justification. This very simple mechanism helped move the variability of projects across the company from almost 30% to less than 12% in a year, and less than 6% the following year.

By declaring that variance was no longer OK, it changed the focus and the way people looked at it. No project failed, and all those that justified a need for variance were granted it timely. What changed was the mindset.

Adopting a new state of mind and a new set of values for managing projects is no easy task: this is a big cultural change, after all. It does not require to change the project methodology, Waterfall, Phased, Agile, RUP, Extreme or other. It does not require adding more resources to the team.

The primary change is to reshape the project scope within a Business Intent, and the project delivery into a Business Fulfillment. Recognizing that every dollar spent on a project must be for a reason. This reason is the constant reminder for all efforts and decisions, from the start and until the final closure.

Adding more project methodology, more rigor in reporting, more resources will only create more costs unless the 8 areas described earlier are turned into tools for success.