Underestimated human factor – different perspectives of IT teams members selection.

According to various sources, 55% to 75%¹ of ERP system implementation projects fail². Taking into account the global market value of the ERP systems, which in 2010 reached about $40 billion, the question about the reasons for this condition gains a material dimension. The most comprehensive and at the same time, current research on the causes of implementation projects failure , which the author has been able to reach, was performed by SAP AG in 2010 among 62 companies which has implemented the ERP system.

In ASA380³ training materials, that describe results of the analyses, we can read: “The researches show that 62% of the greatest difficulties in ERP systems implementation projects concern people, where the most important is a matter of a change management⁴”. Similarly, the human factor issue plays a very important role in the reports covering implementation risk that have been prepared by other companies. The report, prepared by K2 Consulting Company, The highest risks in the implementation of ERP systems can be a good example. In this report, among twelve discussed factors as many as five have been directly related to the human factor.

Paradoxically, the reasons for these implementation projects failures seem to be widely known and the solutions have been described in the project methodology. On the other hand, the percentage of projects that do not meet the expectations may indicate the general dissonance between the theory and practice. Following this clue, in the next part of this article author will focus on the various aspects of the project team members selection, this is one of the key elements influencing the effectiveness of the human factor. The aim of the following analyze is to know some constructive conclusions from the confrontation of the theoretical and practical approach to the selection of project team members.

PMI, ASAP, PRINCE2 and project team members selection

In literature devoted to the issue of project management, human resource management plays an important role⁵. However, when analyzing further bibliography positions, it is obvious that the work of project teams, seen through the prism of methodologies, defies analysis and control. The effectiveness of work, but not the progress of the project, is subjected to quality control. That can significantly impede the implementation of preventive actions on time. A Project Manager arranges carefully measured resources (fixed assets, human and capital resources), then creates a schedule to accomplish deliverables of subsequent project phases, on time. The phrase measured resources was used consciously, as in case of project team members selection, the most frequently applied methodologies, i.e. PMI, PRINCE2⁶ and ASAP (Accelerated SAP), omit the psychological aspect and focus on hard competencies, availability and costs. John Nicholas and Gezinus Hidding⁷ call this approach a classic paradigm in project management

ASAP is a methodology created and developed by SAP, which is a worldwide leader in the market of software for large companies (31% market share, in 2010⁸). It is worth mentioning, that this methodology is dedicated to the implementation projects, very much related to the technical solutions of SAP. Its new version, marked with 7.1, was officially released in 2010. Despite the fact, that the meaning of people and the interpersonal relations forming during the project have been emphasized, ASAP does not provide tools or guidance to facilitate the selection of team members or the assessment of their later work, other than through its products.

A similar picture of the situation forms also after you familiarize yourself with literature on the methodology of PRINCE2⁹. In the official introduction to PRINCE2¹⁰ we can read: In the project the right people on the right places, who have the authority and knowledge, are necessary, to take responsibility for making the decisions on time. There, we can also find the descriptions of an example of a project structure division into roles, including the assignment of the responsibilities. In a remarkable majority of publications on the PRINCE2 methodology, the soft aspects of selection and analysis of the project team performance are ignored.

The PMI methodology in this issue presents only a little better. The iconic guide: A Guide to the Project Management Body of Knowledge¹¹, developed by Project Management Institute, determines the following factors that need to be taken into consideration at the personnel selection, by the Project Manager:

• experience - have team members performed in the past such or similar tasks? If the answer is yes, have they managed them well?

• preferences – do team members want to work on the particular project?;

• personality characteristics – will team members work together well enough?

• availability – will team members be available for the project in an amount of time which allows the implementation of assigned duties?

• competences and knowledge – what competences will be necessary for the project team members and at what level?

Unfortunately, also in this case, despite noting the existence of soft factors, such as personality characteristics or preferences, the official PMI guide does not provide any tools, that would allow to their analysis among the project team members ¹².

The soft aspect of management, related to the human factor, in implementation methodologies is usually seen through the prism of activities related to the change management. The guide focuses mostly on team building and communication planning, however, the issue of the team members selection is, practically, omitted in the project methodologies.

Risks and consequences of making a mistake

In companies or departments formed for a project activity, the issue of project team members selection is partially solved by the HR department which, during the recruitment, takes into account the willingness to work under pressure in a constantly changing environment and specific personality features required from the personnel. However, this situation seems to be completely different in companies, where projects are rarity. In ASAP Methodology for Implementation 7.1 the problem is described as following: In implementation projects of mysap.com solutions, the internal personnel is detached from its current role in the company, sometimes it even leads to a change of position. In other cases, an employer may require a scrupulous performing of the previous responsibilities and, at the same time, participating in the project works [...]. Together with the project progress, the initial enthusiasm expires. It happens, mostly, due to the significantly increased workload required to accomplish tasks within the schedule. For the company’s internal personnel, that is not used to project works, it may mean a significant change in an organizational culture and way of working¹³.

Additional responsibility connected with the new tasks, no senior management support and sufficient motivation, can lead to the situation where the internal personnel will not have the willingness to participate in the implementation. The described situation significantly increases the resistance to change and makes it difficult to implement new solutions.

In the face of need to complete the team and also the lack of suitable candidates, the risk of recruiting "from the round-up" significantly rises. This means risk of reversing the question "why this person, at all?" to a question "why not he or not she?" and selecting those with insufficient knowledge, competence or decision-making power. An additional factor that hinders the identification of errors in the selection of team members is the fact, that the consequences of this decision can be seen only after the real start of the work, or a long delay.

How serious may be the consequences of the wrong project team members selection show previously cited studies conducted by SAP. These indicate that as much as 62% of all difficulties in ERP implementation projects are related to people, where 42% of them concerns the mistakes in change management, preparation and training of the internal personnel, as well as work of project team members¹⁴.

Meanwhile, the wrong choice of the personnel can be very difficult to correct, mainly because of the vast amount of knowledge the team members acquire during the whole process. What is more, increasing the number of resources, involved in the project during its lifetime, as evidenced by Frederick P. Brooks in his classic The has mythical man-month: essays on software engineering¹⁵, does not necessarily mean speeding up the pace of work. Not everyone believes that adding resources to the project, in fact, helps. Brooks has created his thesis on the basis of experience from work on an operating system for the IBM 360 series. He recalls that adding resources to a project in its late stage, only delays it. When creating his thesis, Brooks meant only the delays in IT projects, but today it is applied to all types of projects. The thesis is based on the principle, which says that when new members get into the project, people, who had been involved in it, devote their time to teach and introduce to operating standards. This causes that the effectiveness of the project is reduced¹⁶.

Conflict or cooperation?

One of the most interesting views on the selection of project team members and thereby an interesting typology of supporting and inhibiting personality types, have been presented in the book of Harold Kerzner, Project Management - A Systems Approach to Planning, Scheduling, and Controlling. He divided personality types, with regard of their positions in the project teams, into the roles of positive and destructive. Among the positive roles were: initiator, information seeker, informant, motivator, explaining person, coordinator, consensus seeker and tutor. According to Kerzner, the destructive roles belong to: aggressor, withdrawer, dominator, devil's advocate, topic jumper, recognition seeker and blocker.

Picture 1. Destructive project roles

Source: own analysis based on: Harold Kerzner, Project Management - A Systems Approach to Planning, Scheduling, and Controlling, John Wiley & Sons, London 2001, p. 262

The above division is seemingly clear and intuitive. Constructive personality types to should become team members, while the ones with destructive personality types, should be backed off from any works. However, we assume here that both parties understand the need of cooperation and collaboration of all interest groups in the name of the common good. Therefore, the developer- client conflict and the conflict at the level of departments within the company, may cause that instead of cooperation, a conflict/demanding approach will become the dominant one. Surprisingly conflict/demanding perspective makes it seemingly rational to allow people with destructive personality types to become team members.

The table 1 summarizes the interpretation of the selected personality types from, both perspectives.

Table 1. source: own analysis

Conclusions

Thanks to post-implementation analysis and research and an identification of the risks, we have information that allows us to accurately determine the most common causes of implementation projects failures. Problems regarding management of the human factor, especially the change management, are mentioned here as one of the key risk factors.

To say the truth, these issues are discussed in the most popular projectmethodologies such as ASAP, PMI or PRINCE2, however, in most popular books there is no guidance that would allow to put theory into practice.

The reason for this fact seems to be a consequence of the dominance of the current paradigm [...], that defines the project only through the fulfillment of objectives, concerning schedule, budget and delivery of the product¹⁷, rather than the unavailability of knowledge or lack of scientific researches in this topic.

Note about an author

Tymoteusz Radlak (www.radlak.eu) is an SAP Expert Consultant with phd in management. Certified in MM/SD/SRM/LE/WM he participated in numerous SAP implementations as areas team leader, implementation/support consultant, trainer and auditor. In parallel with hard technical skills he develops interests in soft aspects of implementation projects and ERP maintenance including:

• change management,
• quality assurance methodologies and quality control efficiency,
• information system maturity and optimization,
• competence centers organization.

Bibliography:

A Guide to the Project Management Body of Knowledge (PMBOK® Guide), Third Edition, Project Management Institute Inc., Newtown Square 2004.

E.S. Andersen, K. Grude, T. Haug, Goal directed project management: effective techniques and strategies, Kogan Page Limited, London 2009.

ASA380 ASAP 7.1Implementation methodology in details, SAP AG, Waldorf 2011.

ASAP Methodology for Implementation 7.1 - Roadmap WBS 1.2.4 Project Team Building, Team management Guide, SAP AG, Waldorf 2010.

F.P. Brooks, The mythical man-month: essays on software engineering, Addison-Wesley, Reading 1995.

J. Charvat, Project management nation. Tools, Techniques, Goals for the New and practicing IT Project manager, John Wiley & Sons, London 2002.

K. Harold, Project Management - A Systems Approach to Planning, Scheduling, and Controlling, John Wiley & Sons, London 2001.

K. Heldman, PMP Project Management Professional Study Guide, Sybex, San Francisco 2002.

Managing successful projects with PRINCE2, CCTA (Central Computers & Telecommunications Agency), London 1999.

PRINCE2, OCG (Office of Government Commerce), Londyn 2002.

C. Pritchard, The Project Management Communications Toolkit, Artech House, Londyn 2004.

L.F. Terry, C.S. Guynes, V.R. Prybutok, J. Windsor, Maintaining quality in information systems, „The Journal of Computer Information Systems” 1999, nr 5.

P. Wachowiak, G. Sylwester, B. Grucza, K. Ogonek, Kierowanie zespołem projektowym, Warszawa, Difin 2004.

Netography:

E. Kimberling, Lessons from ERP Implementation Failures, http://www.focus.com/briefs/lessons-erp-implementation-failures/.

Panorama consulting solutions, ERP Vendor Analysis, http://panorama-consulting.com/resource-center/2010-erp-vendor-analysis/.

Text references: