Home Affairs IT project failure

Michael Krigsman makes a living from the subject of of IT project failure. There are a number of issues he discusses on project failures:

• early warning signs of project failure
• the Devil’s Triangle
• bad leadership

There was report in the South African Sunday Independent on 18 April 2010 which highlighted a number of the issues Michael has covered. The report concerned the bungling of the multi-billion rand contract awarded by the South African Department of Home Affairs to black-empowered IT company Gijima AST. (Note: The Sunday Independent only gives access to articles online for subscribers of its print version).

In a memo by the consultant whom Home Affairs contracted to manage the project, some typical IT failure issues were mentioned.

1. Lack of project ownership by the client (Home Affairs), leaving Gijima to determine and drive the project deliverables, and making project governance difficult.
2. Lack of involvement and support from the client executive sponsor.
3. Poorly defined business case, little budget commitment and continually changing project priorities. Points 1 and 2 create this situation.
4. Low level of capability in the client making it difficult at the IT level to get agreement on technical architecture and design specifications, as well as at other levels.
5. Lack of end-user skills in the client to enable the project to achieve objectives.

Reading the article made me sympathise with the project manager, who I once worked with at one of South Africa’s big banks.

The question some South Africans are asking is how and if Home Affairs and Gijima can patch things up and get the project going again. From this South African’s perspective, however, one question is how would you go about reviving this project. A place to get ideas would be from Glen Alleman’s  discussion on Project Disentanglement. The other question would be, for such a high profile and high risk project, who would be prepared to take on the project management role.

How would you go about getting such a big government project back on track? And would you even want to?

Preventing entropy in ERP applications

In my experience of ERP implementations, I’ve noticed how a major ERP application, to which a company has committed significant budget and resources, starts losing its value in the organisation sometime after the system is implemented. I call this application entropy (after the thermodynamic effect that energy degrades to heat, or noise); SYSPRO calls it ‘application erosion’.

The process works like this. When an ERP project starts, people are often keen, committed and involved. But not long after implementation, those ideals and attitudes begin to diminish until a point is reached when the comments start: “ this ERP isn’t giving us value anymore, why are we still using it?” This eventually kicks off an ERP evaluation or re-implementation project, and the process begins all over again.

When executives invest similar large amounts in capital equipment, however, they are usually insistent that the equipment is used optimally and people are properly trained and kept up-to-date. When it comes to enterprise software, that drive is not applied with the same vigour. It seems that continual training on IT-related aspects is not often company policy in many businesses – people are supposed to “get it”, absorbing knowledge and expertise by osmosis, usually from others. This approach commonly leads to the growth of poor practices.

What are the solutions?

One is training – obviously. It probably needs only 1-2 days training per year per person for a typical user to keep up-to-date and proficient on a particular area of an ERP system.

Another solution is to make IT part of the executive board’s responsibility. In South Africa, The King III code of corporate governance seeks to make IT a mandatory item on the board’s agenda. King points out that IT is now essential for the modern business and the board should understand the issues and strategic importance of IT. The recommendations include that the board be responsible for:

• strategic alignment of IT with the business,
• improving the value of IT,
• optimising knowledge and IT infrastructure.

This leads to a third solution – what SYSPRO calls the “Seeker of Value”. The role of the Seeker of Value is to prevent the disconnect that occurs in the ERP system of an organisation. This person, or group of people, is identified as being responsible for bridging the gap between the ERP supplier and/or implementer, and the organisation, thereby reducing costs, optimising ROI and giving the organisation greater control over its destiny. The kind of issues that a Seeker of Value should take responsibility for are:

• having some knowledge, and keeping up-to-date with, the ERP;
• balancing and scaling the software;
• aligning the ERP with the strategy of directors and management to prevent disconnect between the high-level business processes and operational processes, and to ensure the software is meeting the strategic business requirements of the organisation;
• ensuring the board is aware of new business models that the software could accommodate;
• using the ERP system to improve or implement methodologies such as Six Sigma, Lean and Balanced Scorecards.

Getting value from an ERP system is never going to be one of those activities that can be left to proceed automatically. In order to keep entropy (or erosion) from occurring, continual intervention is required. Individuals and groups in the organisation need to make a conscious decision to ensure this happens. As Elliot Ross points out:

anything you have implemented, but have never revised is probably an obsolete silo that is sucking the life out of your organization.

Like so many IT projects, success or failure does depends more on people issues than technical ones. If your organisation managed to avoid ERP entropy, what are the policies and factors you dealt with to combat the erosion of value?

Update: I should have checked, but it has been brought to my attention that this topic has also been covered by TechnologyEvaluation.com – Application Erosion: Eating Away at Your Hard Earned Value and Application Erosion: More Causes and Cures.
Other links related to this subject: The Problem with Mature ERP Systems (ComputerWorld)
What Does a “Successful” ERP Implementation Actually Mean? (CIO.com)

A sign that social business is growing up

Michael Fauscette made some wise comments about a new company, Pragmatic Enterprise 2.0, that announced itself recently:

without a methodology, a risk mitigation approach, the correct skills and change management a project is doomed. Businesses need enterprise class, scaleable social tools, social processes and knowledgeable assistance to pull off this level of business transformation.

Earlier this week some colleagues announced a partnership that is both good news for businesses that want to do social transformation projects but also an indication that social business is growing up.

I think Michael is right.

I also had a discussion with one of the founders, Michael Krigsman, on Twitter that their product diagram looked like it was designed by a committee and was difficult to understand. I am looking forward to how things develop on that front.

Project Communication

A couple of posts on Paul Rasmussen’s blog prompts me to make my own comments about communication between members of a project team. In The Problem of Communication in Project Management Part 2, Paul discusses the types of communication currently used, which are meetings, phone calls and emails. In Part 3 he mentions new communication technologies – smart phones, wikis and social networking.

Having just been through two projects, I have found that the old ways of communication, particularly face-to-face, are the best for project communication. As we all know, more than 50% of our communication is non-verbal (ie, body language, voice tone), and also as we know, projects success is highly dependent on communication. So as in the case of one project manager, most communication was by email, then mis-understandings can happen. Our company has now instituted a directive that email is not considered adequate communication.

We have tried collaborative tools, such as Basecamp, to help with dispersed team members, but there seems to have been some reluctance to try these new tools. I find that interesting, considering we expect our clients to adopt new tools in the form of ERP solutions. So whether we would benefit from new communication technology is up for debate.

Email can be used to confirm and document facts and issues, however in my opinion, nothing replaces personal contact when it comes to communication.

Why are ERP consultants needed?

In a blog on the ITtoolbox site, Steve Phillips comments that companies are moving away from using external ERP consultants in favour of using in-house expertise – Why ERP Software Consultants Cannot Save The Day.

His view is:

The ownership philosophy is about controlling your project destiny and built on some fundamental principles. … 1) It is possible to take internal responsibility for project management. 2) It is possible to develop and/or acquire internal software expertise to the point outside application consultants are rarely needed. 3) It is possible to become much more educated and less reliant on the false sense of security an army of consultants can bring. 4) It is possible to realize ERP benefits by developing better software and business process solutions with fewer outside consultants. 5) It is possible for internal personnel to do up to 70% of what many pay consultants to do.

Except for item 4, in my experience, I haven’t found any companies that can do what he suggests. I suspect it is a function of certain factors – a primary one being the size of the organisation. But I also believe that business maturity, and the availability of knowledge and experience play a significant part.

In the South African market, most businesses fall into the small-to-medium (SMB) category. Employees in SMB companies tend to take on more than one role (debtors and creditors, pre-sales technical and sales, production planning and management) which leaves them little time to focus on issues which are not directly relevant to the job they must do. So finding time to acquire software expertise is difficult or requires after-hours learning. In time, and if a person stays in the same job, they might become “more educated and less reliant.” However, given their time constraints, it is highly unlikely that people will have the time or knowledge “to do up to 70%” of what a consultant will do.

Also skills and expertise are in short supply in this country, so someone who develop technical skills may easily find themselves moving out of their business job and into a technical or consulting role. Similarly, project management requires experience and time to spend on it, which senior staff in SMBs (e.g., finance managers and directors) rarely have. Companies will tend to have a less senior person overseeing the project, but all the details and work that goes into project management has to be done by someone with the background and time allocation to do it – in other words, a consultant.

In the South African context, therefore, most average companies (not large ones over 1000 people) do not have the people, skills or time to take on an ERP implementation themselves. The cost of bringing in consultants outweighs the risks of failure in trying to do the project in-house.

Truths About IT Costs

A Harvard Business Review article The Truths About IT Costs lists seven ‘truths’ about IT costs. These are:

1. Enhancements often don’t deliver results commensurate with their costs.
2. Projects are often too big and take too long, partly because unnecessary functionality is built into applications.
3. Previously purchased applications and infrastructure technology are often underutilized.
4. Project failure rates are too high.
5. Tech teams do not have sufficient incentive to achieve high quality, and quality is often not measured.
6. Managers don’t know enough about the systems that support their areas.
7. IT is too risk averse: “No one ever got fired for buying IBM or Microsoft.”

The article reads like some consultants’ reports – addressing problems at a high-level, with a few key recommendations; but when you think about it for a while you wonder how to practically implement the recommendations.

Update: see also Michael Krigsman’s critical blog

ETO vs Project Manufacturing

In the ERP manufacturing space, the term ‘order fulfillment‘ refers to the process that manufacturers follow to make goods for customers. The options are:

Make-to-Stock (MTS) The product is built against a sales forecast and put into stock, from where it is sold to customer; e.g., the retail sector.

Make-to-Order (MTO) The product is based on a standard design, but component production and manufacture of the final product is linked to a customer’s order specifications; e.g., high-end motor vehicles.

Assemble-to-Order (ATO) Similar to MTO but the product is comprised of modular components and is built  to customer specifications from a stock of existing components; e.g., the Dell approach.

Engineer-to-Order (ETO) The product is designed and built to customer specifications; this approach is most common for large construction projects and one-off products

Accepted practice with these processes is that a material requirements plan is put together using the Bill Of Material (BOM – the components, production operations, inventory and lead times) of the product, following which a master production schedule (MPS) is developed from the order, inventory and production information available.

The company I work has, for a number of years, been growing its experience and expertise in the custom-production areas of the order fulfillment process; what some would call ETO. We have been finding that although ETO-type manufacturers never build the same product twice, and may have many unique orders being built simultaneously, they consider it sacrilege to go against the concept of a BOM; even though a BOM is only really applicable and useful if you can re-use it.

I have encountered manufacturers who think that they have to a BOM to make their products. But when you probe deeper you discover that what they make is unique (ie, project-driven) and therefore requires a new BOM everytime.

A few companies, however, are starting to follow a new practice – what we have called for the moment, Project Manufacturing (PM).

As Frank Scavo pointed out in his blog:

“For organizations that are project-based … there is a great need to integrate project management with ERP … the project schedule is (or should be) the master production schedule. Requirements for material, labor, outside services, and other resources are directly tied to the work breakdown structure. ERP systems based on a traditional MRP approach simply do not work. Project-based organizations are relatively under-served by enterprise system vendors.”

These project-oriented manufacturers follow the PM approach – using project management software applications to do their detailed manufacturing planning, rather than an MPS. The labour and material allocations that conventionally are done via the BOM are managed via the work breakdown structure (WBS) of the project plan. Frank’s comment that these types of manufacturers are ‘under-served’ is an under-statement. None of the standard and well-known ERP vendors provide this type of functionality.

We have had the privilege of working with a few leaders in the PM space in South Africa, and help them to develop the integration of project management and ERP. It can be quite a culture shock for someone coming from a standard manufacturing process to adapt to the PM approach, and in my case it took over a year to develop a deeper understanding of the processes and technology involved.

The purpose of this blog article is to introduce the concept of PM, and find perhaps a better acronym. In later blogs I will go into more detail about how PM differs from the other order fulfillment options, how to allocate labour and materials in the WBS and then link it to the ERP system, how it works from a software and process perspective, and what it involves for project implementation. In the meantime, comments would be most welcome.

Does high project failure require "professionalising" IT?

Two recent blogs by Michael Krigsman discusses how high IT project failure rates are, and some of the key reasons.

Study: 68 percent of IT projects fail
Requirements and failure: Interview with CA’s SVP of IT Governance

I am friends with a number of professional engineers – civil, mechanical and electrical – and I don’t believe they would dare to operate if the failure rates of their projects was anywhere near as high.

Michael identifies issues relating to lack of skills, knowledge and competency as the key factors leading to failure. Skills, knowledge and competency are what training and education programs are supposed to develop. People go to university to acquire skills and knowledge. But for professionals like doctors (my wife being one) and engineers, a university degree only starts the process. The engineering companies I know expect to train young engineers for several years before they are ready to be let loose.

But when it comes to IT, customers often think they have the in-house capacity to for projects. I think many people also look at software like Microsoft Office and think that implementing and using software is easy.

Many years ago in South Africa, there was a debate in the Computer Society about whether IT should become a profession. At the time, the proposal was defeated. After reading Michael’s blog, I am wondering whether we should re-look at the proposal. The next step would  be where do you start, and would IT vendors, consultants and users see this as beneficial?

In engineering, aircraft engineers must be a relatively recent addition as a profession. So how did they go from being a bunch of techies to having their own professional status?

BTW, I suspect that the information Michael uses comes from projects in the more well-resourced developed economies, so I wonder how the projects perform for those of us in developing countries?