The Perils of Projects

In 1987 I was introduced to the world of project management through a comprehensive course on the Program Evaluation & Review Technique (aka PERT). From that point forward, I have been fixated on how to improve project outcomes.  

A month or so ago, I read the Standish Group's CHAOS 2020 report which documents IT project success rates and identifies best practices. It brought back a flood of memories of "projects past" and lessons learned. The report also spurred me to research the "state of the art" in project management tools and practices circa 2020. The good news is there are great tools available or emerging that can help improve project outcomes. But before we talk tools, let's assess the state of technology projects in 2021.  

In 38 years, I have witnessed the growth of waterfall system methodologies, the proliferation of high-powered project management tools, the introduction of program management processes, and the emergence of agile techniques. Yet, for all our advances, technology projects continue to fail at an outlandish rate. The CHAOS 2020 report indicates that only 35% of technology projects were fully successful in meeting time, budget, and scope commitments. 19% of technology projects are cancelled before completion, and 47% of projects will be "challenged" (fail to meet time, budget, or scope commitments).  

However, it wasn't all bad news. Agile projects, especially those with mature agile + DevOps teams, were much more successful. Agile projects alone (across all team types) were two times more likely to succeed than waterfall projects. Some of this success is due to the more focused scope and time-boxing of agile. Also, with agile, failures will typically occur earlier in the cycle, mitigating some of the costs.  

Reading through the CHAOS 2020 report, I reflected on all the projects (good and bad) I have participated in or observed throughout my career. I thought about the common traits of successful projects (on time, on budget, on scope). I found these successful projects had four common traits: 

• Active and engaged leader(s)
• Clear project requirements
• Invested project team (both IT and the business)
• A well-conceived and realistic plan

Does anyone ever recall starting a project with what you thought was a flawed plan, without sponsorship, or without what you thought were clear end goals? No? Me either. 

We begin with what we believe is an achievable plan and great intentions. But somewhere during the life of some projects, things start to turn bad. 

At Lowe's, we implemented a rigorous (some might argue too rigorous) approach to program and project management. All projects had a defined task-level project plan. Project hours were captured by resource and task and aggregated against plan in a central repository. Project managers updated the central repository to create the aggregated information to feed a standard set of dashboard/reports for all programs and projects. The dashboard provided a color-coded circle for each project's scope, time, budget, and overall status (and a similar aggregate view for programs). You could click on any project and drill down into the hours planned, actual hours applied, etc. Project Managers could enter issues that needed management attention to also appear on the report.  

I reviewed this report with my staff every week. We implored project managers to be realistic in making their status assessments. Yet, inevitably, some project would go from all green to red in less than a week. It doesn't seem possible, does it?  

At L Brands, our projects were more tightly defined. The average project duration at L Brands was roughly 60% less than the ones at Lowe's. The primary reason was L Brand's fast-fashion business model that made longer projects nearly impossible to execute. To enable speed and visibility, we implemented a mobile, digital dashboard that allowed leaders to see active project status and incoming technology requests (the "backlog"). Yet, with smaller projects, and clear visibility, we still had projects that did not deliver.  

At both companies, we had the quantitative measures of a project covered. However, when you participated in a "post-mortem" meeting on a failed/challenged project, you would hear some of the same themes. "We never thought the plan was realistic", "no one stood up and took charge", "the requirements were always changing", and "no one seemed to listen". Sometimes these comments were from project leaders, but mostly, they were from the rank-and-file team members that could see the impact of decisions (or indecision) above them.  

So, it wasn't surprising that the CHAOS 2020 report identified lack of user involvement, incomplete requirements, unrealistic expectations, changing requirements, and lack of executive support among the primary factors leading to unsuccessful or challenged projects. In other words, the factors that are not readily identifiable by reviewing typical quantitative project reporting.   Also factors that tend to erode, if not given the appropriate amount of attention throughout the project life cycle.

Project status reporting always seems to lack qualitative inputs. Yet, as the CHAOS 2020 report points out, these qualitative factors significantly impact project success. This finding points to a need to collect and measure qualitative factors in sync with quantitative project data (such as hours worked and task status).  

You may be asking by now, "what's the punch line?".  While I don't offer a silver bullet, I do believe there are several things that you can do to improve project outcomes. The four items I discussed earlier in the article (leadership, clear requirements, invested project team, realistic plan) are the precursors. If you don't have these, all of these, it will be extremely difficult to be successful. Next, you need to develop and cultivate a culture of feedback. You need to be asking the right questions, of the right people, at the right time to ensure projects are on track. Bringing this data together with your quantitative project data will give you a much clearer picture of your true project status. 

Finally, you need to train your teams (technology and business) on the proper way to plan and execute agile projects.   The numbers don't lie. Agile is a better way.  

I often get asked about project management tools. In my career, I have worked with several high-quality project management tools. While a tool won't solve all your problems, the right combination of tools, coupled with training and the right culture, will offer you the best chances of success.  

Tools such as Atlassian's JIRA, PivotalTracker, and Asana provide outstanding capabilities for managing project issues and progress. These tools also have built-in collaboration capabilities or integrate with collaboration platforms such as Microsoft Teams or Slack. Obviously, with teams working remotely now than ever before, collaboration plays an even more important role.  

Finally, I recently reviewed TrueProject by CAI.  TrueProject adds another dimension to project management. TrueProject automates and aggregates the project feedback process leveraging a broad library of project best practices. It ingests project quantitative data from Microsoft Project, JIRA, and others, combining that data with qualitative project team feedback to display likely the most comprehensive status dashboards I have ever seen.  It also leverages the best practices to predict project success, almost like a Waze for projects.  

Let's face it, a simple 30-to-40 hour project can be managed on a piece of notebook paper or in Excel. However, when projects grow in complexity and business outcomes ride on success, we need the right culture, leadership, techniques, and tools to drive project success. 

The perils of projects are very real. With digital technology driving more business value, organizations must understand why these projects struggle and take actions to set the table for success.