Month: September 2010

One-Way Risk and Robustness of IT Projects

The Agile Manager has a great post on One-Way Risk and Robustness of IT Projects.  It calls for “more robustness in risk management” within IT projects.  However, it’s critical of risk management that is “limited to maintaining a ‘risks and issues’ log, so it’s never more than an adjunct to our plan”.

I like the implication that risk management should be conceptually equal to the project plan within the management framework.  The reasoning appears to be that the project plan is necessary but not sufficient for the success of IT projects because of inherent uncertainty in these types of projects.  In particularly there is reference to project plans being treated to as “point projections – as opposed to probabilistic projections – of what we will do, when we will be done and how much it will cost”.

I would never criticise the concept of schedule management but we shouldn’t see risk management as just an ‘adjunct to our plan’ but rather something that should be managed as robustly as the schedule elements that are embedded in the plan.  Incidentally, project management says this in theory too – but the practice is sometimes lacking.

Of course, I would also include architecture at the same level of schedule and risk management and not place architecture management as just an ‘adjunct to our plan’.

(Via The Agile Manager.)

Note to self: do ERP vendors benefit from the sunk cost fallacy and asset specificity?

I’ve never really been very interested in ERPs – so I likely don’t know what I’m talking about…

But over the years there have been many times I’ve heard organisations saying they need to “leverage their investment” in their ERP.  This is usually after they have spent far too much money implementing it in the first place so whenever I hear that phrase I can’t help but hear “we don’t have the expected benefits from this yet so we should invest more in it because we’ve already invested too much not to get any benefits from it”.  This is clearly the sunk cost fallacy at work.

There has been talk of the end of ERPs for some time, and there are certainly many web-based alternatives, much-hyped redesigns, as well as web based versions of classic ERPs.  But at the same time ERPs aren’t going away.  Certainly the companies themselves are far too clever to not evolve.

But I’m more interested in why the benefits aren’t realised.  Because from an enterprise architecture perspective there are certain elements of the ERP value proposition that make perfect sense.  If you think of enterprise architecture as primarily being about finding the capabilities, services, and processes that you want to further integrate or standardise across your organisation (and I haven’t found a better definition) then taking disparate payroll, HR, procurement (etc, etc) processes and standardising them should delivery value.

I’m going to make a leap here and say that ERPs actually do deliver value.  In fact, any critic that suggests otherwise probably has a skewed view of why we use information technology in our organisations in general.  The problem with ERPs isn’t that they don’t deliver value – it’s that they are incredibly overpriced.

Given that organisations pay that price I have to wonder how ERP vendors are able to extract value from organisations so successfully.  Going back to my limited experience with ERP implementations I see three ways ERP vendors extract value from organisations:

1) ERP people are over specialised.  While development and support for software packages from mid-sized vendors, or custom software development can be implemented with a variety of method, tools, and resources, a SAP implementation for example must be staffed with ‘SAP people’.  There are no business analysts, developers, or project managers.  There are instead SAP Project Managers, SAP Developments, SAP Business Analysts.  This of course creates a scarcity of quality resources and the subsequent high price of those resources.

2) ERP vendors force their customers to follow an Ideal Realised Strategy which says your implementation will be simple if you don’t customise your implementation.  However, by virtue of the fact the everybody customises their implementation this doesn’t seem like a feasible strategy in practice.

3) ERP implementation partners take control of both IT change and business change.  However, rather than take the approach that business change is about delivering benefits and increased productivity they appear to take the approach that ‘business change’ is all about making sweeping changes to work practices rather than making small changes to the product.  i.e. by owning business change they are using it to the vendor’s advantage not the client’s advantage.

Long-overdue rant complete.

Powered by WordPress & Theme by Anders Norén