Plan to fail, then plan again: Recommendations for IT Project Management

Plan to fail, then plan again: Recommendations for IT Project Management

‘If you fail to plan, you are planning to fail’, so said Benjamin Franklin, American inventor and founding father. And today, we may add ‘but a plan to fail is the path to success’.

According to a 2012 study by the Standish Group, only 39 percent of IT projects were considered successful, meaning they were delivered on time, within budget and met all requirements and goals. In that same study, 43 percent of IT projects were considered challenged (late, over budget and/or missing features and functionality). Nearly one in five IT projects, 18 percent, completely failed.

These failed IT projects probably stained a few careers, hurt some office relationships and caused some strife at home, but at what cost? A study in 2011 deduced that $150 billion is wasted annually on failed IT projects in the United States. The European Union falls close behind, where failed IT projects cost $140 billion.

Common sense tells most of us that those failed IT projects lacked proper planning to successfully execute. But let’s not forget our friend Benjamin Franklin, who also famously said that the problem with common sense is, it isn’t.

So why do IT projects fail? IT projects, and really any type of project, are constrained by the “iron triangle.” The triple-threat of time, budget and scope. People, who are deeply flawed and ever-changing themselves, are in a battle against the iron triangle, constantly fighting against its limitations and unpredictability.

Brian Collins, former graduate student at American Public University, sought to learn more about IT project failure when he wrote his 2015 master’s thesis, Against All Odds: An Examination of Project Management Failure in the 21st Century. He did extensive research on existing studies and articles in peer-reviewed journals. He also did a survey of 519 IT project managers to get a first-hand account of why IT projects fail.

When Collins’ research began, he believed that there were three main causes of IT project failure: project leadership, team dynamics and process and procedure. He claimed that leadership was the most important of these factors because an ineffective leader makes poor and untimely decisions.

A 2015 leadership study found that 80 percent of failed projects were caused by poor leadership. When Collins surveyed IT project managers, he asked them to select the top eight factors that impact the success of IT projects. Four of the eight factors selected by the participants were related to leadership.

In that same study of IT project managers, Collins asked participants to identify the eight most unimportant factors that impact IT project success. Five of the eight most unimportant factors were team-related. Other recent research has shown that teams can work as or more effectively when not working in person, like over Skype or another data-driven system. This proves that it isn’t about being on a physical team, but being willing to work together regardless of the medium. A project that plan to fail can have processes in place to manage poor leadership.

Process and procedure are another variable that can impact IT project success (or failure). The Project Management Body of Knowledge (PMBOK) was created by the Project Management Institute to provide a general framework and highlight best practices for project managers across a myriad of industries. Unfortunately, PMBOK is very generic and doesn’t provide sufficient guidance for a rigorous IT project.

In the end, Collins found that not only was leadership the most important success factor in an IT project, but it can reasonably be regarded as the only important factor. He eloquently wrote, “Just as strong leadership can propel a project to a monumentally successful project outcome, poor leadership can hurl a project towards catastrophic results and epic failure.”

Collins also concluded that IT project managers should avoid using generalized project management guidelines, like PMBOK. PMBOK works well for some industries, but it just doesn’t pass muster when executing a complex data-driven project. Instead, industry leaders should create an IT project-specific management guide to give project managers a reliable, consistent reference to produce successful IT projects. Again, a project plan to fail can include approaches to manage bad organisational process.

Certainly, team dynamics and process and procedure play a role in IT project failure, but their impact pales in comparison to strong leadership.

Collins research also paved the way to create a new leadership model for successful IT project managers. The model, Dynamic Sensory Leadership, combines visionary leadership, high emotional intelligence and a sense of discernment that enables a leader to eliminate negative behaviours (hubris, hypocrisy and hostility). Dynamic Sensory Leaders can effectively manage team dynamics, follow process and procedure and deliver a successful project.

What does this mean? Collins’ research is certainly eye-opening, but how can it be applied to improve the way YOU execute YOUR data-driven projects?

The first step is to recognize that people, their actions and inactions, are the driving force behind IT project success or failure. People are unpredictable, emotional and sometimes difficult to deal with; accepting and adapting to your team members will increase your ability to succeed. Mastery of Collins’ Dynamic Sensory Leadership will help you better manage your project and your team.

Also consider an important variable that Collins’ study curiously overlooked: data. IT projects are data-driven projects. In 2015, an average of 2.5 quintillion bytes of data was created daily. We can only assume that rate of creation has increased. With so much change in the air, one wonders which is more volatile, the people or their data?

Data-based projects often fail because they are contingent upon a variable (data) that is in a constant state of flux. An ineffective IT project manager balks at such a prospect, but a successful one plans on change and plans to fail.

Planning to fail, as opposed to failing to plan, is the key to success in IT project management. When you plan to fail you account for unforeseen circumstances that could harm your project. Planning to fail enables you to adapt to a change quickly and effectively, limiting the effect on the overall project.

Is it possible to plan for every unforeseen circumstance, change and mistake? Absolutely not. It is possible to build concessions into your plan that account for the unexpected. Do that!

Failing to plan is an unfortunate yet all-too-common mistake when it comes to IT projects. But planning to fail? Could it work in your favor?

No project is perfect. There will always be someone or something that tries to limit or inhibit progress. Your plan to fail and ability to adapt will ultimately determine your success. Listen to Ben Franklin, make a plan, just be sure that plan includes a plan to fail.

[php snippet=2]