IT projects - are our change management efforts caught in the middle?

Projects are a big business. Estimated to represent 34% of the German annual GDP (GPM-IPMA: Makroökonomische Vermessung der Projekttätigkeit in Deutschland 2015); and the global project market is estimated at 3-6 trillion a year (Gartner 2017, Flyvbjerg 2016), it is evident that a lot of money and resources are spent on projects throughout the world every day.

However, projects are not only big business, they also represent big impact. 80% of UK public policies are implemented through projects. Projects are the key vehicle to implement strategy. Unsurprisingly, the number and the strategic importance of projects has increased in the last decade.

As a result, project managers and scholars are slowly changing the conceptualisation of what a project is. Away from the task to deliver the defined scope set out in a project initiation document to thinking about projects as more open and important temporary organisations. The hot topics of (1) moving closer to the customer through agile approaches and (2) thinking more like the business through benefits management not only improve project performance (Budzier & Flyvbjerg 2014) but also show the strategic importance and the importance of strategy in projects. The project debate has shifted from efficiency to effectiveness.

Research has identified the key success factors to effectively deliver IT projects. A meta-review (Mills & Mercken 2002) synthesised the research into 49 success factors. In our ongoing research, we are focusing on IT-enabled change: Are these factors, among others, drivers of project performance and success?

In our first and very preliminary results, we observed two interesting patterns that we will discuss here. The first questions the relationship between projects and top management. Is active ownership and support from top management actually seen and how does this affect the success of the projects. Following this, we present a discussion on end-user involvement and whether projects are moving closer to the end user. Questions are raised for both topics with the purpose of providing food for thought and shaping the research going forward.

Top management initiating projects, but not following through?

Our preliminary results show that 58% of all projects have a dedicated budget for change management activities and that in average this amount equals 14% of the total project budget. 70% of all projects have dedicated resources to carry out change management activities. This shows the right intentions from top management in supporting the projects setting aside budget and resources to change management. However, our first results indicate that the ambition of obtaining real ownership from top management is still not happening.

We asked on a scale from 1-10 (1 = not at all and 10 = to a very high degree): “To what degree did top management …”:

• … support the project? Average: 8.1
• … actively promote the project? Average: 6.8
• … take ownership of the project? Average: 6.3

The emerging trend seems to be that top management and their project managers might have the right intentions, but that top management is more likely to support the project than to take actual ownership of the project.

Passive support rather than active ownership

The support from top management consists primarily of communicating the vision and strategy behind the project and funding the projects at project start. The pattern from the research indicates a “fire and forget” behaviour meaning that top management starts projects, but does not continuously take real and active ownership. Even communication is, in many cases, limited to announcements in newsletters, quotes for email blasts and the occasional short statement at meetings.

The preliminary results show that top management ownership increased the perceived success of the project (by top management) and also increased the probability of the project achieving the intended impact.

Project and change management theory has for many years talked about the needed behaviour from top managers leading towards more and more involvement since projects are at the very strategic heart of the company in implementing strategy. However, based on the responses we have received, we see that top managers focus on the following tasks in their project support:

• Participate in steering committee meetings
• Present project and project vision at town hall meetings
• Perform other communication activities
• Review the programme status on a monthly basis

These activities seem to not indicate a true active ownership role, but merely advocating or supporting the projects. It is way too early to draw the conclusion that the level of top management ownership should change – though the emerging pattern raises a question that needs to be answered in the future. How come that the actions from top managers do not move in the direction of taking active and engaging ownership, when most literature and research point to the need for this?

Top management focus on communication does not reach end users

Another interesting finding is that many of our interviewees reported that top management is focusing on communication as their primary way of supporting the projects. Yet, our current results yield an interesting miscorrelation between this and who the end users perceive as the key communicator. Only 15% perceive that top management is taking the role as key communicator whilst 36% perceive the project as the key communicator.

This further raises some interesting questions, such as who should be the key communicator to ensure project success? Why is the middle and first-line/ business unit management not used more actively? Is top management doing enough in regard to communication?

Interestingly enough, the ownership vacuum does not seem to be filled by middle or line management either. Middle managers are mostly supporting but not actively promoting or owning the project. Line managers show a more even distribution, yet below the average levels of top management.

What should the role of the different managerial layers be in IT projects? How can they be used best in the change management efforts?

Projects focusing upwards

As demonstrated, our preliminary results show a limited active involvement by top management, in particular for taking ownership. This means that top management in effect is there to authorise the investment and needs to be kept informed about what is happening. When supporting the project, the activities of top management primarily focused on communication. But what other actions could top management perform to help the projects even more?

The limited active involvement could be due to time constraints and other highpriority tasks in the company. Top management is perceived by our respondents as the people with the money. They used their power to bring the project into existence and withdrawing their approval of the project would stop it. Hence, project managers spend considerable time on delivering status updates, detailed analyses, updated forecasts and projections and decision papers to top management. In the end, because they are keeping the money tap open.

This setup introduces a power imbalance towards spending more time keeping the project sponsor up to date than to interact with the end users. We can see the fruits of this work in the results of the survey. The reported trust between project manager and key stakeholders in top management scores on average at 7.2: a high degree of trust. However, the level of trust of end users in the project is lower with an average 5.9. We know from our research that on average projects spend 10-15% of the total cost on project management resources. Is this the best way to use the money and resources for the project?

Typically, top management has their eyes on the long-term sustainable growth for the entire company or organisation. This could be in contrast to the end-user perspective focusing more on day-today work, local view and cost/resource concerns when participating in project work.

These, at times, conflicting views leave the project manager and the project caught in the middle with the ambition of translating vision and long-term benefits into the reality of the end users who are not necessarily motivated to change by nature. At the same time, the project needs to understand and fulfil the needs of the end users whilst keeping the overarching vision and organisational benefits in mind. This is not a trivial dilemma, but it requires an ability to comprehend and act in accordance with both perspectives. In the next section, we will focus on the relationship between the project and the end users.

End users – do projects need to be close to them?
More agile project delivery approaches, with a high degree of user focus and involvement, have become increasingly popular in recent years. Despite this tendency, our preliminary results do not seem to indicate that projects are moving any closer to the end users – in fact, the opposite seems to be the case. At least if we look at how the project communicates and what it communicates about as well as when end users are involved.

The first emerging pattern we see is that the communication between project and users is more comparable to a one-way broadcast than to a dialogue.

Delivering information rather than dialogue

Communication seems to be quite inside-out with a tendency to focus on the project itself and less on the users and their concerns. We asked what projects communicated about, and the results so far are:

• 48% of projects communicated future roles
• 79% of projects communicated the new processes
• 76% of projects communicated about the change
• 76% communicated the benefits at the organisational level
• 73% communicated the current project status
• 85% communicated about the new system

Approximately 8 in 10 projects communicated what the project was intended to do by explaining the outputs whereas only 5 in 10 projects also communicated what this meant for users in terms of future roles. A relevant question is if the users are actually able to relate to the message then?

This is also interesting seen in the light of a correlation between how successful the end users perceived the project and the effectiveness of the communication effort. So our preliminary data suggest that an effective communication effort increases the chance of perceived success among end users. How can we then ensure an effective communication effort? Should we focus more on the needs of the end users?

Reason for change and end-user understanding

Another interesting finding which could indicate a distance between the project and the end users is found in the data, where our interviewees described how the project defined the overall reason for change. They rated their projects on a scale from 1 to 10 (1 = not at all and 10 = to a very high degree) on four questions regarding the reason for change:

To what degree …:

• ... was the reason for change defined as a burning platform? Average: 6.7
• ... did the project have a clear vision of the future you wanted to reach? Average: 8.0
• ... did the project have an appealing vision of the future you wanted to reach? Average: 7.7
• ... did the end users understand the reason for change? Average: 6.5

An interesting observation is that the more a project talks about a burning platform, the better the understanding of the reason for change. Burning platforms are seemingly easy to communicate, but many practitioners today prefer using a vision-driven approach. Maybe we need to remember what we are moving away from and why this is necessary or at least desirable.

In the section on reason for change the understanding among the end users of the reason for change scores lower than any of the other questions. Again, it seems that the message is not reaching and/or convincing the recipients. Whilst we may have a burning platform or a clear and appealing vision of the future, it seems as if we are not able to deliver this in an effective manner. So maybe more user dialogue is needed to convey the message?

Actual dialogue with end users increased the likelihood of perceived project success. Our interviewees report that actual dialogue is difficult to achieve. 1 in 2 projects agreed to have engaged in dialogue to a high degree. Yet when we asked the interviewees, it became clear that often this simply meant regular project updates, that the project is a standing agenda item in meetings, and that dialogue, if any, happened in user group meetings and was tightly constrained. Multiple interviewees pointed out that actual dialogue inevitably resulted in scope and requirements changes.

Informing and/or involving end users

The second pattern we see is that there is a gap in time in regard to when the users were first informed about the project to when actual involvement happened. 3 in 4 projects informed their users during the initial phase of the project but on average did not involve them before testing.

(Again on a scale from 1-10):

• System design: Average: 6.3
• Process design: Average: 6.5
• Testing: Average: 7.9

Thus, we seem very keen and eager to inform the users about the project, but actual involvement happens quite late in the project. It is interesting to understand if this has any implications on how the project is perceived. Should we instead wait with the project information up until right before users get involved? Or should we involve more actively earlier in the project? We see that project success, in the perception of the end user, increases the more end users are involved in systems and process design and testing.

Training as a success parameter

Another perspective of user engagement is training. Half of the projects involved users to some degree in the planning and design of training. Three quarters of the projects involved users in the training, i.e. through train-the-trainers and facilitators, and nearly 1 in 3 projects relied heavily on users in the training.

Whilst we do see that involving users in design increased the training effectiveness, involvement of users in planning or in delivery of the training did not make a difference. Does this indicate that we should be involving users earlier and maybe more intensely, i.e. in training design?

The training content mirrors the patterns seen in the project communication above. We tend very much to focus on the project deliverables such as the system and new processes, but not on much more than that. Our preliminary data show the following:

• 91% of projects included training in the new IT system
• 85% of projects included training in process changes
• 48% included changes in roles
• 33% included changes in needed competences
• 45% included the mindset

Again, projects focus on their own deliverables and outputs and to a lesser extent on what it means for the end user. However, just as mentioned above with regard to communication, there is a correlation between the perceived success of the project by the end users and the effectiveness of the training:

Overall, we see indications of a substantial distance between the projects and the end users. Most of our interviewers reflected that dialogue and getting close to the users fell short due to time and workload constraints. This has surprised us somewhat as the role of change management in IT projects is often explained as bridging the gap between project and the end-user community. Maybe the gap is wider than we thought? What can be done to get even closer to end users? Will this actually increase the likelihood of success?

Spanning bridges to both sides

Our results, so far, seem to put the spotlight on two key relationships that we know are crucial to deliver strategically important change: the projects’ closeness with (1) top management and (2) the end users.

Top management funds and initiates the projects, but quickly move on to other endeavours. Apart from occasional communication, we do not see top management taking real ownership or being actively involved in the increasingly important IT projects. What can we as projects do to create the right relationship to top management?

The end users are often a diverse group, and maybe they cannot be easily involved due to resource constraints within either the project or their own organisation or maybe due to geographical boundaries or other reasons. But how can we overcome this and increase involvement and understanding among end users?

As IT projects need to deliver solutions which fit the entire organisation, not only top management, we do consider these preliminary results quite interesting. We cannot help but ask ourselves if being closer to the end users or at least line management would result in better IT implementation projects? How should we go about ensuring a proximity to both management and end users? Hopefully, our continued research will provide some answers to these questions.