IT talent needed for SMBs

1410454581_skillsAn article on the McKinsey site recently discussed the issue of developing and retaining IT talent, especially the key skills it believes are necessary for organisations planning to become a digital enterprise. For an enterprise to become digitized it needs to implement transformative IT-oriented projects, and without the necessary IT knowledge and experience, projects often overrun on budget and time, and don’t deliver value. However, being McKinsey, the article is targeted at large organisations, whereas I am more interested in how small or mid-size businesses (SMBs) can apply their advice.

McKinsey highlights three IT roles which companies should keep in-house.

  • IT program manager

needs to oversee the project, understand both the business context and the technology involved, and have strong management capabilities. He or she must also be able to talk about technology and business decisions in a language that business managers understand.

  • Business change leader

responsible for ensuring that the organization adopts the new solution. This role requires strong communication skills and an understanding of the full amplitude of the transformation and its implications for the business side, including required organizational, process, and mind-set changes.

  • Lead IT architect

responsible for reviewing and challenging technical proposals and deliverables such as solution design and IT architecture. He or she needs to understand the current IT architecture and also have a good view of the transformation journey to ensure that decisions fit with the architecture road map.

Why could this not apply to SMBs? Because SMBs typically have staff with multiple or overlapping responsibilities, while larger companies tend to have more specialised, narrow roles. SMBs also dont’ usually have the budget to hire such specialised staff.

Therefore I would modify the McKinsey article for SMBs. Here are three existing roles in an SMB which could take on the responsibilities mentioned above.

  • CFO or Financial Director – IT program manager role

In most SMBs I have dealt with, the overall responsibility for IT has been with the CFO or FD. Therefore this dual role should not pose a major problem for most SMBs.

  • Human Resources Manager – business change leader role

This is the dual role that could be controversial. In some SMBs, the HR manager role can be mainly administrative, however unless the CEO wants to take on this responsibility, HR would seem to be only only other option.

  • IT manager – lead IT architect role

A non-brainer in my opinion. The only manager in an SMB with the background and skills to do the IT architect role is the IT manager.

I would be interested to hear if any alternatives are suggested.


Four tips for starting an ERP project

Cross-posted from SYSPRO SmarterERP blog

There has been a post on the SYSPRO blog on how an ERP system can help a business, and also some suggestions on how to select an ERP solution. But if you have read some of the stories about ERP project problems you might wonder if it is worth the risk. The answer to this is twofold.

  1. The reports on ERP project failure mainly refer to large organizations implementing fairly large projects, and are not representative of projects undertaken by small- and mid-size businesses.
  2. It’s how you approach the implementation that is a significant determinant of success or failure.

So where and how do you start?

The lead up to an ERP project is a good time to consider Eli Goldratt’s Theory of Constraints Thinking Processes, which is a set of tools to help organizations identify what can be done to significantly improve any business system. By the time you start the project you should have dealt with the question “Why change?” Now you need to look at the other questions:

  • What to change?
  • What to change into?
  • How to cause the change?

A number of organizations might think that all they need to change is their business system, when in reality they will probably also change and streamline processes, and realign roles and responsibilities. Therefore I recommend the following steps.

1. Do a business process blueprint.

To answer those “what” questions you need to understand the processes that operate in the business. A process blueprint provides a graphical view of the way processes work, who is responsible for the processes, and the interaction between different roles.  It also helps by creating a view of the business that both IT and business can understand and discuss – a common, visually-based language. From the blueprint you can see more clearly what might need to change (e.g., in terms of streamlining processes), and with a decent blueprint tool you can try out different changes to see what might be most appropriate. The blueprint enables you to identify solution gaps and define integration points between IT solutions.

2. Check that the key project issues are covered

Evidence from many projects shows that there are four main factors that create project problems, and so mitigating them will improve the chances of project success.

Main causes of project problems How to mitigate them
Unclear objectives and poor focus Focus on strategy, involve stakeholders and define project teams responsibilities and accountability
Changes in project scope Ensure project team and all affected staff are aligned to work towards common project goals
Lack of appropriate skills Ensure appropriate skills are available
Unrealistic schedules and poor planning Have a good project manager

3. Plan the project in phases

The implementation project plan describes how the transition from current state to envisaged future state will occur – it addresses “how to cause the change?” Plan the project in phases and implement over time, for several reasons.

  • It’s easier to estimate and manage the budget for a smaller set of tasks than it would be for a ‘big bang’ type of approach
  • It restricts the impact of the change to a smaller number of people, which means disruptions to everyday work can be minimized
  • Showing rolled-out wins will keep people motivated

4. Make sure change management is included
Forrester-change management
The biggest cause of failure in IT projects is not software, it’s ‘wet-ware’ (people). Resistance to change can block even the most perfect plans, so building active consensus and buy-in is crucial. Forrester Research offers the following steps.

Lastly, although you may have undertaken a thorough business process analysis, and done the proper project planning, be prepared for unexpected complications that occur during roll-out. This is especially true for manufacturing businesses with complex processes, and where integration with other manufacturing applications is needed. If, however, you have done the upfront work, you will be in a position to handle these complexities without seriously impacting the project or the business.

What is your experience with starting an ERP project? Have you got any other tips to add?

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:

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.

ERP erosion1

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.

ERP erosion2

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 – 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? (

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.