Tag Archives: Project Failure

We Have Met the Enemy – He is Us

This was the title of my presentation at the #ITx2014 conference yesterday.

I have embedded the slideshow. In the next few days I will try and put up a version with an audio commentary reflecting what I said on the day.



The ITx Conference – Auckland – 8-10 October 2014


This conference will soon be upon us. I have been fortunate enough to have a paper selected for presentation.

The programme is here and my offering is here.

You can register here

What is ITx?

Established in 2014, ITx is three conferences in one; combining the successful IITP and CITRENZ national conferences with the re-launch of the Computer Science Association’s conference; establishing the broadest and largest non-vendor general IT conference in New Zealand.

ITx focuses on innovation, technology and education and brings IT professionals, decision-makers, leaders and academics together under one roof. This is a conference like no other: where industry, academia and government come together to network, learn and engage.

ITx will run every second year in either Auckland, Wellington or Christchurch.


The Institute of IT Professionals NZ (IITP) is the professional body of the IT sector and is the largest IT representative body in New Zealand. IITP has run conferences for almost 50 years, although there was a large hiatus prior to the 2010 50th Anniversary Conference. IITP2013 was held in Tauranga and attracted hundreds of IT professionals and thought leaders.

Computer and Information Technology Research and Education New Zealand (CITRENZ) is the representative body for the IT departments of New Zealand’s Institute of Technology / Polytechnic sector. CITRENZ has been running successful annual conferences for 27 years.

Computer Science Association of New Zealand (CSANZ) is the forum for the University Computer Science community. CSANZ has been active for many years and 2014 will see the return of the popular CSANZ conference as part of ITx.

Aspects of Project Failure – The Seven Deadly Sins

Yesterday I posted an item on 10 Things Great Project Managers Do. This post popped up on Facebook, as do my other posts, and a friend and former colleague Andy Cawston responded. We entered into a brief discussion as to how various human factors impact on projects.

Andy had made the observation that the list did not include Risk Management, to which I responded:-

Sure and in one sense all of the 10 are about Risk Management, with a focus on the people aspects, often seen as the ‘soft options’, yet in fact people are in many ways the hard options and in my view looking back over several decades ‘people’ are in fact one of the root causes of project failure. Indeed depending on the criteria being used to assess failure one might argue that ‘people’ are the primary cause of project failure and that successful project management is more about people management than anything else. At which point all sorts of people emerge from the woodwork to decry the proposition.

Andy then went on to expound an interesting concept:-

I’d be inclined to support that proposition. To my experience the primary causes of project failure tend to be people-related. For example, scope creep = people wanting too much, too soon, for too little. <— that’s Greed (Avarice), in a nutshell.

You could take each of the 7 Deadly Sins and similarly map them against the causes of project failure. All of them.

Wrath, sloth, pride, lust, envy, and gluttony could each similarly be mapped against primary causes of project failure, and as such could be managed as project risks.

Bloody brilliant!

I can recall one project in particular where Sloth was the primary cause of a project nearly failing. I was assigned to drag the project back, and we ended up delivering properly. It was hard work!

I can recall another project where Pride and Envy played a huge part in the bid process. Our team had been selected to develop a Partnership with the client. Our PM resented the presence of an external consultant driving the project, fought him tooth-and-nail, and we nearly ended up getting booted out of the account. Only a Mutiny by our team against the PM saved us…

Indeed the more I think about it, the situations we find ourselves in so often on projects do mirror the 7 Deadly Sins. Further, I think that more and more I am coming to the view that people are the primary cause of project failure, which goes a long way to explaining why we continue to see project failures year after year with causes of failure the same or similar to those encountered decades ago.

What do others think?

10 Things Great Project Managers Do

I came across this slideshow on 10 Things Great Project Managers Do today whilst browsing some online newsletters I subscribe to.

Whilst they may seem a little motherhood and apple pie to some,  it is when the basics are executed right that we get success. All too often we neglect the basics at our peril. There is a reason that the basics are called the basics.; it is that they are the building blocks for success.

One that resonated with me particularly was Number 10


The reason being that all too often in the past I have had occasion to ignore this basic. When I have it has often not turned out like I would have wished. Being a hard charger as the Americans say, is all very well, but you need to pace the charging. That knowledge often comes only with experience and after learning why the basic is a basic and not a namby pamby HR idea.

Of course there are other things, but these 10 encapsulate much of what is required for success. They do not guarantee success but they will go a long way to reducing project failure due to project management. Note though that other factors are often as influential, if not more so in project failure than project management.

The role of procurement in software project failure

The Institute of Information Technology Professionals is conducting a very brief survey of IT procurement in project failure. Please, if you have relevant experience take part in the survey. Details are below:

Gmail - The role of procurement in software project failure (2)The survey can be accessed here http://www.iitp.org.nz/spsurvey

It is very concise so please assist us in this research effort.

As many of you know I have a long held interest in the causes of project failure, so I look forward to seeing the results of this survey.

Why IT Projects Fail?

Michael Krigsman blogs on a recent ITSMFAustralia conference where he took part in a discussion on IT Project Failure, presented in the form of a simulation. There is a link to the simulation at Krigsman’s blog.

Interestingly there is a strong NZ connection as Rob England, blogger, author (The IT Skeptic) was involved in developing the seesion and led it.Well done Rob.

The session repays study.

I have always found the use of hypotheticals/simulations an excellent way to communicate issues and highlight areas for focus.

Some Thoughts: Storm Warnings in projects

Over the course of my career I have spent a considerable amount of time reviewing projects, proposals for projects and related aspects of the lifecycle.. In a number of instances this has led on to examining the causes of problems and trying to find ways of resolving issues. Consequently I was interested to read a post by Michael Krigsman  about early warning signs of Project Failure.

He wrote:-i

Managers often express surprise upon learning their project will run late or over-budget. Nonetheless, we frequently ignore early warnings signs that indicate a project faces trouble.

For an academic article on this subject titled Early Warning Signs of IT Project Failure: The Dominant Dozen, two researchers collected data from 19 experts and 55 IT project managers. The researchers discovered an important lesson: “significant symptoms or ‘early warning signs’ of trouble” often are present long before a project actually fails.

This grabbed my attention, because some years ago whilst running the Project Quality Office for a major vendor my team and I spent considerable time and effort on seeing if we could identify flags which might indicate trouble. I christened them ‘Storm Warnings’

The article ,referenced by Krigsman, describes twelve warning signs, divided into people-related risks and process-related risks:

People-Related Risks

  • Lack of top management support
  • Weak project manager
  • No stakeholder involvement and/or participation
  • Weak commitment of project team
  • Team members lack requisite knowledge and/or skills
  • Subject matter experts are overscheduled

Process-related Risks

  • No business case for the project
  • Lack of documented requirements and/or success criteria
  • No change control process (change management)
  • Ineffective schedule planning and/or management
  • Communication breakdown among stakeholders
  • Resources assigned to a higher priority project

Continued high rates of failure suggest that most organizations ignore these early warning signs.

I don’t disagree with the above at all. In fact there are a number of other items I would add to the lists. Of which more another day.

Some Thoughts:-

What struck me though when I looked at these factors was how they interlinked with and exemplified a number of other matters I have commented on recently.

For example the issues raised by Professor Mary Gentile on Voicing Values in the Workplace. The factors identified above raise a number of flags in my mind as to the nature of governance in an organisation where some or all of the above may exist. In addition I wonder about the underlying values within the organisation.

In addition, one factor that stands out from looking at the issues identified from the research cited is the question of value. Why, oh why are projects being undertaken where the value to be derived is either weakly derived, if at all, and success criteria are non-existent to poorly defined. As I noted here, a critical element in successful delivery is understanding value creation. Again governance at the enterprise level is critical.

So yes, the factors identified in the research posted about by Michael Krigsman are relevant, they and others provide ‘Storm Warnings’. Yet, as well they should be prompting greater concerns about the enterprise as a whole and not just a particular project.

These 4 concerns relate to:-

  1. What, if any. governance framework is in place?
  2. How does the enterprise assess and manage risk?
  3. How does the board discharge it’s responsibilities?
  4. Why executive management do not appear to be fulfilling their role?

I say this, because when you look at and consider the People and Process related risks identified in the research it is my contention that the existence of these risks flows directly from weaknesses/failings relating to the 4 four concerns, which reflect critical elements of governance. In turn weaknesses here will result in a failure to create value.

After problems in one project are likely to be symptomatic of problems in others.

I am interested to see what others think.

Defining IT Project Failure

Vodpod videos no longer available.

more about “Defining IT Project Failure“, posted with vodpod

I came across this at Michael Krigsman’s IT Project Faliures blog as I did some research for my Friday presentation.

I found the video interesting.

It would be interesting to hear/read what others thought.