1-855-561-4606 info@inteloom.com

Introduction

In their 2015 Chaos Report, The Standish Group, in their assessment of more than 50,000 projects, found that less than 29% of projects were successful (i.e. on time, on budget and, completed as planned). More concerning is the finding that as many as 19% of all projects fail outright (Fig. 1) [6].

Project management models such as Agile, Waterfall and Lean are reputed to help us achieve success rates as high as 39% and limit failures to just below 10% (Fig. 2), but they are unable to explain the mechanics of why they work… or don’t work. In addition, their implementation in organizations can cause excessive disruptions in operations.

One fundamental question stands out: Why is 39% an acceptable rate of success?

There are many reasons that projects fail.  If you talk to any project manager who has been practicing for a while, he or she will give you a list of reasons; some valid, some not. This paper will explore some of the most common reasons for project successes and failures, offer an alternative management and project management model and show how Inteloom’s Object Oriented Management® model can contribute dramatically to improved project success rates, through our GOOM® Training offering.

The Challenge (“Why Projects Fail”)

Several studies, articles and investigations have shown that there are a number of distinctive reasons behind challenged and failed projects. [1] [2] [3] [4] [5] These reasons tend to be common across multiple industries (construction, IT, automotive, manufacturing, etc.). The consensus is that current models and methodologies are not complete enough to address many project management functions all at once and, therefore, leave gaping holes in the process.

The following factors are not the only ones that affect the success or failure of a project, but, in many studies and reports they appear near, or at, the top of the list.

1.   Lack of Visibility of all Projects

All three tiers of the project team, executive management, project managers, and team members, need visibility into the right information at the right time. The use of multiple tools all at once (email, project management software, spreadsheets, etc.) means that information is often scattered and not visible to all team members or cumbersome to link together. Scattered information is a recipe for disaster.

Similarly, a lack of visibility into all concurrent projects contributes significantly to over-allocated resource workloads.

2.   Poor Resource Management

Resources are often overloaded because executive management has no visibility into all of the projects and tasks that any particular team or individual is performing. They labor under the belief that the organization can achieve more than it is capable of in terms of workload. Furthermore, managers often find it difficult to quantify their positions on capacity.  Managers struggle to organize the overall resource workload and the situation is so fluid that team members are regularly confused as to their priorities.

3.   Gaps & “Noise” in Communication and Information Scattering

Recognizing that many projects are plagued with communications issues, email ranks at the top of the list. Many project teams use email to communicate about their projects and tasks, which leads to project communication residing in individuals’ email inboxes.  In these scenarios, if a new resource joins the project or, if there is a change to the team, there is no centralized view of the project or task.

Team members frequently complain about the volume of emails they receive and the inefficiency of finding those that are the most relevant to them. This practice wastes valuable time that they could be used working on tasks.

Non-integrated communication tools, redundant information broadcasting, as well as, organizations that are typically structured in silos all lead to information scattering.

4.   Poorly Defined Requirements (Poor Scope Definition)

While the project charter describes the ‘what’, the low-level requirements explain the ‘how’. Poorly defined requirements can be a guaranteed path to project failure. A lack of detailed and/or accurate descriptions of what needs to be delivered and when, leads to a myriad of issues in a project.

Poorly defined requirements also leads to the dreaded “scope creep”. Since there was a lack of understanding of the deliverables in the first place, projects will begin to mutate into unrecognizable beasts that no one had planned on.

5.   Poorly Defined or Unrealistic Timelines

One of the most challenging duties for a project manager is scheduling.  A schedule defines the timeframe, milestones and key deliverables for a project. When scheduling is either performed inadequately or if unrealistic goals and timeframes are set, the project is destined for failure from the outset.

6.   Inaccurate and Unrealistic Estimating

Contributing to poorly defined or unrealistic timelines is inaccurate and unrealistic estimates. The usual fall-back position for estimates is to base them on the last time a similar task was done.  Many project managers on hearing the estimate will then pad the estimate further, based on their experience (either of the team member or a past task). What you end up with is, in essence, an educated guess which, when the project begins, has little basis in reality. When viewed cumulatively across many tasks within a project, inaccurate estimates can have a serious impact on whether a project will succeed or fail.

Basing estimates on what a project was “sold for” is also frequently a sure-fire way to a failed project. Every project manager knows that there is often quite a gap between what a sales team promises a client in the way of price, time and scope and what will actually be required to fulfill the contract.

7.   Monitoring and Control

Monitoring and Control refers to setting baselines, monitoring for variance and, if need be, taking corrective action. Monitoring percentage complete of a schedule doesn’t reflect how the actuals have affected the schedule. Furthermore, the basis of the reports is always behind reality if the actuals are not calculated in real-time.

How Does Object Oriented Management® Work?

I developed the Object Oriented Management® model in 2010 under the supervision of Professor Christian Navarre of the University of Ottawa as another paradigm for management and project management.

In 2013, Inteloom trademarked the acronym GOOM®, a marriage of Gestion Orientée Objet® and Object Oriented Management®.

Although glimpses of an object-oriented approach to managing projects have be seen across several sectors, including; aviation (Boeing), construction (SNC Lavalin), automotive manufacturing (Renault and Toyota), furniture (IKEA) and, more prevalently, in the field of software programming, no one had been able to accurately identify the components that make this type of model successful. More importantly, no one had been able to compile the successful mechanisms into a working model that could be taught and learned, regardless of the industry or sector.

The key success factor of the GOOM® model lies in the quality of the development of the architecture of a project. The GOOM® model works more completely than any other stand-alone project management model or methodology.

How Will GOOM® Improve Project Success Rates?

GOOM® tackles the challenges that lead to project failures.

1.   Breaking a project down into objects, rather than tasks

Although a task can be an object, it is important to understand that an object can be ANYTHING. By thinking of tasks as objects, they can be more easily managed using the GOOM® model.

The model dictates the use of a tree for organizing a project’s objects. The tree structure for all types of objects (e.g. tasks, meetings, documents, inventory, bugs, releases, etc.) allows for centralized information which results in better communication and less information scattering.

2.   Assigning agents to objects and defining the interface

In the GOOM® model, three keys agents are assigned to each object: managers, experts and clients. The agents collaborate to define the interface, attributes, inputs and outputs of each object. Managers are responsible for the object. They define the “what” (e.g. what the outcome should be), not the “how” (e.g. how will the work be done). The “how” is left to the expert(s), who apply their skills to the objects assigned to them. The client is ultimately the agent who will “consume” the object. They have quality expectations, and help define the interface and validate that the object is completed to their satisfaction.

It is absolutely essential for the project manager to ensure that the primary requirements for the project are as detailed as possible with all relevant agents.  The GOOM® model emphasizes the importance of approaching requirement gathering as an iterative process, as the requirements will evolve as the project evolves. They need to be reviewed during the execution phase to ensure that any changes are captured and adjusted for as soon as possible, and that the output satisfies GOOM®’s commitment to total quality.

3.   Delegation, Autonomy and Responsibility (reducing micro-management)

Through effective delegation the manager gives the experts the autonomy and responsibility to manage the “how” of their objects, thus significantly reducing the occurrences of time-wasting micro-management. The manager should not interfere with the execution of a object’s requirements once they have been defined. The expert is responsible for breaking down their object(s) into manageable “child-objects”. This can only be effectively accomplished if the interface is well defined at the commencement and revisited regularly through the execution phase of the project.

Quality is managed on the level of the object. The agents involved in defining and describing the interface of an object also define the quality expectations. The GOOM® model is designed to provide the client with TOTAL QUALITY with the minimum amount of management interference as possible in the inner process of a task.

4.   Centralizing information, better communication and reducing the noise

GOOM® emphasizes the centralization of all aspects of a project so as to avoid information scattering.  Agents work off the same object, adding any relevant information about that object in one place. Agents only see and hear what is relevant to them. The combination of permissioning and notifications ensures that the people that need to be notified are and those that don’t aren’t constantly bombarded with unnecessary information (noise).

Access to real-time metrics, workflow state and centralized communications contribute significantly to eliminating many of the most common barriers to successful projects.

5.   Real-time management

For projects to succeed, managers have to manage reality, not the plan. Having access to accurate, real-time metrics will make for better informed and timely decision making. By centralizing the access to real-time information the project manager can easily measure the “actuals” against the assessment and make any needed adjustments rapidly and with confidence.

Real-time management also makes it possible to take a different view of the Triple-Constraint Principle. Traditionally, this principle tells us that; the costs should be like planned, the time should be like planned and the quality should be as much as possible. A long-held belief is that you must sacrifice one if you want to achieve any of the other two. This is because everything revolves around the initial plan and tends to ignore reality.

Conversely, the GOOM® model takes a different approach to this principle:

a)   The costs will be what they are to fill the requirements of reality.

b)   The time will be what it is, because it will take a specific amount of time to deliver the objects in reality.

c)   The quality must be total, for customer satisfaction.

With real-time management, adjustments can be made to the plan and promptly communicated to the agents with confidence that the recommendations are being made based on reality. There is no argument that this approach contributes significantly to increased client satisfaction.

6.   Work Cycle Management

Learning how to organizing agents’ workloads through work cycle management is a fundamental that GOOM® teaches, that will allow managers and stakeholders much better visibility into the allocation of resources within individual projects, as well as, across multiple projects. Having a true insight into an agent’s workload will permit managers to plan work and timelines to a greater degree of accuracy thereby aiding in a project’s chances for success. Moreover, Executive Management will be in a much better position to plan for future sales and growth with the increased insight into overall resource workload.

7.   Rapid iterations

Rapid iterations are an essential component in the success of the GOOM® model. Employing the theory behind Pareto’s Principle or, the 80-20 rule, the GOOM® model maintains that 80% of a task or project is completed in 20% of the time and, therefore, 20% of the task or project takes up 80% of the time. By staying in the 80-zone and then beginning a new iteration once the 20-zone is reached delivers a much more productive work cycle than spending an excessive  amount of time floundering in the 20-zone. GOOM® will give you the knowledge to identify when you are trapped the 20-zone and what to do about it.

Likewise, breaking an object down into rapid iterations allows for more frequent assessments of an object’s progress, thereby giving the manager more timely information in order to supply feedback and guidance. This, in turn, produces a better quality product, faster, without having to go too far back and fix an issue that could have been addressed earlier on.

Conclusion

It is not enough for the project manager to identify what factors lead to project failure; they must have the tools and processes to overcome or eliminate these challenges. GOOM® will give a project manager the necessary tools to be able to stay on top of details in real time and get the jump on any problems that arise and, in so doing, minimize the prospect of project failure and maximize the likelihood of success.

Objects, Agents, and Iterations are all key components of the GOOM® model. Learning how the model works and understanding how to apply the methodologies and practices contained within GOOM®, organizations will resolve many of the challenges of “Why Projects Fail”.

GOOM® provides a model which will help demonstrate why your successful projects were successful, why your unsuccessful projects were challenged and provide sound methodologies to follow that will ensure all your future projects have a stronger foundation for success. You will understand why some tools can be helpful (e.g. short sprints) while others can seem a burden (e.g. maintaining Gantt charts). Participants regularly come out of GOOM® workshops feeling that many of their experiences and frustrations have been validated, and they have tools to address them.

Inteloom predicts that, as the GOOM® model is adopted as the primary model for existing methodologies, the Standish Group’s Chaos Report will see a significant trend towards an increased number of successful projects.

References

Title image: http://blog.globalknowledge.com/wp-content/uploads/2009/03/word-cloud1.jpg

(Fig. 1) (Fig. 2)         The Standish Group, 2015 Chaos Report

https://www.infoq.com/articles/standish-chaos-2015

[1]           Cynthia K. West, Ph.D., V.P. Project Insight

 

 

 

http://www.projectinsight.net/white-papers/four-common-reasons-why-projects-fail

[2]        Top 10 Reasons Why Projects Fail (Jim Stewart, PMP – November 7, 2015)

 

 

 

http://project-management.com/top-10-reasons-why-projects-fail/

[3]           Why Projects Fail (Tom Tsongas, PMP, CSM, SPC – April 18, 2011)

 

 

 

https://programsuccess.wordpress.com/2011/04/18/why-projects-fail-top-10-reasons/

[4]           The World of Project Management; Getting it Right (Dhanu Kothari – July 5, 2009)

 

 

 

https://www.projecttimes.com/articles/the-world-of-project-management-getting-it-right.html

[5]           Top Ten Reasons Why Projects Fail (Jim Stewart, PMP – October 31, 2012)

 

 

 

http://www.slideshare.net/jpstewar/top-ten-reasons-why-projects-fail

[6]           Standish Group 2015 Chaos Report – Q&A with Jennifer Lynch

 

 

 

http://www.infoq.com/articles/standish-chaos-2015

GOOM®, Gestion Orientée Objet® and Object Oriented Management® are trademarks of Inteloom Incorporated.