Category Archives: Management

Major Projects Part 1

Some years ago I posted about the comments made by Sir Edward Leigh in regard to the conduct of major projects when he retired as Chairman of the UK Parliaments Public Accounts Committee.

It would seem that the comments made then are still pertinent today, perhaps even more so. My memory was jogged by the recent report from the Taxpayers Union of the apparent massive blowout in a new IRD computer system to handle changes to child support. Then I read the articles in The Dominion Post this morning regarding the transformation project underway at IRD.

The objectives of the changes are not unreasonable, what concerns me is the scale and potential complexity of the project.  In particular this comes at a time when IRD are looking at a massive project to replace existing and aged systems.

I intend to look at the issues around major projects in a series of posts over the next few weeks. My intent is to start with what appears at first sight to be a major blow-out, but on review may come up with a number of different questions requiring answer.

As background I have linked to Sir Edward’s letter, Edward_Leigh_Letter_28_March_2010 and to the IRD report on the child support system  Taxation Annual Rates for 201516 Research and Development and Remedial Matters Bill. In addition there is a link as well to a relevant McKinsey Quarterly article,  Delivering large-scale IT projects on time on budget and on value.

Advertisements

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.

 

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

GreatManagersDo_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.

Improving Assurance over ICT in Government

I attended an interesting presentation at lunchtime today. The presenter was  Alison Schulze the recently appointed Director of ICT Assurance at Department of Internal Affairs. Ms Schulze reports via Tim Occleshaw, Deputy Chief Executive –  Service and System Transformation, Government Chief Technology Officer  to Colin MacDonald, DIA CEO and Government Chief Information Officer. The remit of Ms Schulze is across government and not confined to just DIA.  

Initial indications from the session today are that government is, at long last, making serious efforts to get to grips with the issue of assurance based on a business perspective, not just an IT one. However, it is as stated today very much work in progress.

I hope to be able to write in more detail on this in the near future.

Attending IITP Conference 2013

Later this week I will be attending the 2013 IITP Conference in Tauranga. This conference is focused on Innovation as one of it’s key themes.

Sessions I am looking forward to include the keynotes and a governance presentation. I am keen to understand how others see governance supporting and enhancing innovation.
More on the conference soon.

Governance – Getting your all your ducks in a row for Shared Services Success

Earlier today I gave the presentation embedded below to the Conferenz conference on Shared Services in Wellington.

I thought some of my readers might wish to see it as well.

Video

Telecommuting

A video piece by James Surowiecki, of The New Yorker,  looks at telecommuting. this is complemented by a column at the New Yorker.

Novopay # 8 – Deloitte Review – Some Thoughts #1

The Deloitte Review found amongst other matters the following, see Pages 8 & 9:-

  • in some areas systems functionality does not adequately support business processes

  • user input issues and lack of data validations contribute to processing errors

  • school management visibility and control is limited by reports that are sometimes poorly presented or inconsistent

  • data quality has been affected by system issues, raising the risk of future errors

  • quality controls on data entry have not adequately prevented errors

  • a high degree of customisation in high impact areas has made on-going development more difficult

  • aspects of the application architecture make customisation difficult

  • service support processes have struggled to manage the volume of issues

Frankly, based on my past experience with projects which have gone off the rails, I am not surprised. Given some of the media comments and observations on various websites I was expecting some other findings, but these are perhaps more likely to surface in the forthcoming Ministerial Review Report.

Then as one goes through the Deloitte report there are a considerable number of other disturbing findings and observations.

I will be commenting one the above findings and other elements of the Deloitte Review in more detail over the next little while.

However, one initial comment I would make, is that given the time spent on this project the fact that system functionality does not fully support business processes is particularly disturbing and leads me to wonder just where the underlying cause of a number of the problems being experienced does in fact lie.