15 Apr
15Apr

Ever since the introduction of computer automation in the business process domain, have project failures raised its ugly head. This uncomfortable reality has experienced numerous attempts of understanding-analysis, to remediation interventions approaches. This evolution has regretfully also experienced countless disastrous outcomes. 

So, what have we learned? The first obvious step, sadly, had to be adopted from the human behavior sciences: Admitting that you have a problem. Sounds simple and obvious, right? Well not that obvious clearly, given the continuous state of project failures in global corporates and government agencies. 

Admitting you have a problem, takes a special type of mind-set, and more-so, thought leadership in a complex corporate environment. That type of leadership often time need to come from the top and set the tone and give direction for the business-as-usual folks to follow.

The second realisation that we have had to agree on, was that relying on the same people, skills and process that got our projects into a mess, will very seldom steer us out of it. Here are some reasons why this practice continued to lead to further failures: 

  • Egos and vested interests often time are the biggest single contributor that prevent the collective realisation that a project has failed, and that radical change is required
  • We have this bizarre notion that if we work harder at the problem, with the same team or more people, following the same process, things will change…. Sound’s familiar?
  • Changing the budget, up or down, will not fix the problem
  • Financial auditors have a role to play in an audit and rescue, but simply fall short in experience, in fixing complex technology projects
  • A technology project is always difficult due to the harsh reality that it serves as the intercept point of fusing business requirements with technology platforms. If your specification is accurate, then there is a high possibility that the project will be successful. Get it wrong, and the inverse is also true.
  • Even if the project sponsor, project manager or system-business owner accepts that there is a problem, it does not imply that the project team have accepted failure.
  • There is a point were trusting the vendor to fix the problem, is simply just irresponsible.
  • Impartiality is not possible through the myopic lense of an existing team.

 So, what is the answer? Here are some simple, but bold actions to consider in steering your team to a new reality: 

  • Get outside help, but make sure that you get the right help. Folks with experience, with sound refences.
  • Realize that these skills are rare and will probably be found with boutique consultancy groups. So do your homework upfront.
  • Have Procurement and the Executive team meet and question the advisors and be comfortable with them. It is going to be an uncomfortable ride, and you will have to get along from the first bat.
  • Experienced advisors should have playbooks to analyze the materiality of the failure, and guide very specifically what the remediation roadmap options are. Don’t accept a statement of “Trust me” without the playbooks. This is crucial.
  • Accept that change is inevitable and make sure that audit reports and remediation recommendations, provide you with different scenarios and recommendations based on risk thresholds and impact to your organisation.
  • Discretion and time-to-act is critical. Make sure that you have a specialist team on board that share your reputational risk concerns.
  • Then lastly: If the advisor is selling technologies, in any shape, they simply cannot be impartial.

Conclusion: Project failures are complex and destroys careers and affect companies bottom line and market risk. Don’t over-simplify remediation considerations, and make sure that you contract Specialist with a proven track record, in developing the insights you are going to need to turn the ship around.

Comments
* The email will not be published on the website.