The Digital Workplace Is Not an IT Project

 

By some accounts, more than 70 percent of all IT projects fail. Standish conducted a study for Computerworld in which it surveyed 3,555 IT projects between 2003 and 2012 with labor costs of at least $10 million and found that only 6.4 percent of these projects were a success.

 

A failed IT project is usually defined as a project that exceeds its budget, fails to deliver on time, or does not give clients the functions they were promised. Of course, none of these outcomes are good. The Project Management Institute's Pulse of the Profession 2018 report (pdf) found 9.9 percent of every dollar is wasted due to poor project performance — an amount that quickly grows when discussing budgets in the millions or higher. And a 2012 study by McKinsey found 17 percent of IT projects with a budget over $15 million went so poorly they posed a threat to these companies' very existence.

 

Ask Yourself: Are We Delivering Business Value? 

 

However, the definition of a failed IT project says a lot about the predominant view of IT and how misinformed that view is. It tells us the most important thing is to deliver all the ordered functionalities within the set budget and time frame. There is no mention of delivering value to the enterprise, such as increased productivity, customer satisfaction or reduced costs. A project may naturally exceed its budget and schedule, and not deliver all functions ordered, yet still add business value. Conversely, a project that runs like clockwork and delivers everything the purchaser ordered plus a bit extra doesn't mean it adds any business value.

 

We need to approach each project knowing that a new IT system's value is not realized until it is used in the enterprise. It will not create any value at all until it comes into use. All the time and money spent on developing or purchasing the system can be viewed as a sunk cost.

 

The projects also tend to have a heavy bias toward information technology, which can push aside business goals as well as the users’ needs and requirements. The focus is on delivering an IT system with a specific functionality and properties within a set time frame and budget. Consequently, it is accurate to call these projects “IT projects.” Don't be misled into believing they are “business development projects.”

 

The Many Consequences of Ignoring End Users 

 

Additionally, IT projects are often substantial in scope, with long roadmaps and massive deliveries where everything is dumped on the users all at once. This can be compared to slow, overloaded container ships that take a long time to reach port. They have their predetermined routes and experience great difficulty changing course if changes in the surrounding area or other conditions require this. Once they do reach port — if they actually find the right port or even reach it — the expectation is that large-scale changes will immediately be made in the enterprise. However, the organization and the individual employees may not be capable of fully taking in these changes.

 

Last but not least, IT projects rarely involve the prospective users in the enterprise — the employees — until it’s time for them to start using what has already been implemented. This leads to a few highly negative consequences:

 

  • The project missed the opportunity to develop a more profound understanding of the prospective users, their needs and their usage situations, which reduces the likelihood that they developed the right solution and designed it the right way.
  • The employees are not prepared for the change and what is required of them, which drastically reduces the likelihood they will fully take it in and change their ways of working.

 

However, if the prospective users had been involved from the beginning, they could have influenced the development in a direction that actually meets the right needs in the right way. They means they will also become invested in the solution, see it as their own, and will be primed to become ambassadors when it’s time to implement it in the enterprise.

 

Change Is a Process

 

Therefore, let’s remind ourselves what almost all change theories state about change:

 

  • Change is a process, not an event — the process must be established.
  • Change takes time — it requires patience and perseverance.
  • Change is social — the right people can have a major impact on how the change is received in the social environment.
  • Change is made real by what people do — you have to practice what you preach and be a role model.

 

If you develop IT systems and the digital work environment as a whole in a continuous process where employees are involved as prospective users and can serve as role models to their colleagues, you will have also laid a solid foundation for a successful change journey.

 

So is it possible to get out of or avoid falling into the IT project trap? Absolutely. But know, it requires a different way of thinking and working.

 

 

By Oscar Berg

Source: cmswire.com