I listened to a webinar on high-tech marketing recently in which the Chasm Institute discussed the Technology Adoption Life Cycle (TALC), saying that it is the Pragmatist segment that ultimately decide on the success of a high tech solution.
There has been a lot of talk in recent months about Software-as-a-Service (SaaS), but has anyone agreed where on the TALC that SaaS is?
Where on the TALC do you think SaaS is?
Michael Krigsman makes a living from the subject of of IT project failure. There are a number of issues he discusses on project failures:
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.
- Lack of project ownership by the client (Home Affairs), leaving Gijima to determine and drive the project deliverables, and making project governance difficult.
- Lack of involvement and support from the client executive sponsor.
- Poorly defined business case, little budget commitment and continually changing project priorities. Points 1 and 2 create this situation.
- 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.
- 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?
While I’ve not been a big proponent of Microsoft in the enterprise software space (I don’t believe they really understand it), I’ve always been impressed with their work in the server and development areas (the core areas that the company was built around). It’s in that latter area that I’ve had seen where Microsoft is doing good work – it’s the platform on which SYSPRO built its new Workflow Services product.
With the new version of SYSPRO 6.1 comes a new product, SYSPRO Workflow Services (SWS). Microsoft published a case study this month about it – Global Software Company Cuts Development Time for Workflow Solution by 80 Percent.
Because of our development track record, Microsoft invited SYSPRO into their Technology Adoption Program, which gave our dev team the opportunity to use the beta versions of Visual Studio 2010 and .NET Framework 4 for the development of SWS. .NET 4 included new features in Windows Communication Foundation and the new Windows Workflow Foundation (WF). Without WF, we could not have produced SWS.
What Microsoft did in VS 2010 was to deliver templates which effectively provided a rapid development environment. Project templates contain the project settings, references, and files that are need to begin a certain type of project. Some of the default templates used were:
- Activity Designer Library
- Activity Library
- WCF Workflow Service Application
- Workflow Console Application
- WCF/WCF Service Library
- WCF/WCF Workflow Service Application
The project duration for SWS was about 3,500 man hours, and an in-house development methodology was used, which has elements of agile and scrum. Our Software Arcitect estimated that without the .Net 4 and VS2010 features, the development time for SWS would probably have been tripled or quadrupled.
The product that Microsoft provided SYSPRO to do the development was first class, and it makes me wonder why Microsoft doesn’t focus more on this core strength, an area in which they have long and deep experience. Instead, they get distracted by going into ERP (Dynamics), mobile phones (Windows Phone 7) and music consoles (Zune).
I would recommend that anyone involved in ERP projects or support read Susan Cramm’s insights into why business gets frustrated with IT – Eight Things Executives Hate About IT. In summary, here they are:
- IT limits managers’ authority
- Consists of condescending techies who don’t listen
- Doesn’t understand the true needs of the business
- Proposes “deluxe” when “good enough” will do
- IT projects never end
- Is reactive rather than proactive
- Doesn’t support innovation
- IT never has good news
One of the concluding comments is:
… companies can no longer afford to waste precious resources on IT “investments” sponsored by business leaders who believe IT is not their job – or wish it weren’t.
What’s your experience in IT working with business, or vice versa?
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)