Implementation

Top 10 barriers to an IWMS implementation

Bas ten Hove / September 29, 2021 / 5 minutes read

Many organizations implementing IWMS are naive about what is required for success. They understand the core capabilities of an integrated solution that supports Project Management, Corporate Real Estate (CRE), space management, maintenance management and environmental sustainability, but they are often unsure about the purpose and value of a configurable platform or a workflow engine. To address this knowledge gap, EBUSINESS STRATEGIES recently conducted a “Top 10 Barriers” Webinar. To prepare for the Webinar, 110 upcoming participants were asked about major challenges associated with their IWMS implementations. Based on these responses the Top 10 barriers were collated and addressed in both the Webinar and this article.

Working through implementation barriers

Barrier No. 10: “We bought it all, we want it all.”

Users face a twofold dilemma. One, as vendors entice them with technological wizardry, what’s really needed? And how much can users realistically absorb without an overload virtually guaranteeing failure?

The answer is to determine what actually should be automated, plus which modules/components of the total package best meet immediate needs. Start with some “easy wins” to bolster user confidence. In short, “Simplify, simplify, simplify.”

Additional features can always be added.

Barrier No. 9: “Differentiating between platform & solution.”

Surprising but true, there aren’t any genuinely bad solutions in today’s market, but a lot of bad implementations. Users must pick the right tool for their organization’s unique requirements, differentiating between platforms and solutions. Platforms are highly configurable products that are intended to be adapted to specific processes of the implementing organization. In contrast, solutions are products that should be used as delivered with minimal setup. Both are viable but not equal.

For example, if a user only needs a back office tool to support tactical services, why buy a system that requires significant effort to align it with the business? In this case, pick a solution that does the core services well out-of-the-box (OOTB) and adapt the organization to using it. However, if the organization is trying to drive best practices in support of a strategic initiative, a platform is needed both to empower the processes and to drive enabling automation.

Barrier No. 8 is a major advisory: “Do not fixate on costs” but heed the difference between cost and value.

Specifically, what’s the business problem to be solved utilizing new technology and what’s the solution’s value, including hard/soft costs?Of course, the value proposition does not override everything and the vexing question remains: “Can we afford this system?” If a system costs $100,000 and delivers no dollar benefit, $100,000 has been wasted. Yet, if it costs $1 million but actual annual cost reduction is $10 million, the larger outlay was profoundly better.  So, look outside pure costs and towards value-enabling process transformation.

Identify cross functional opportunities, examine other implementation models and weigh cost versus value over the entire investment lifecycle. Then get business buy-in at the outset, not later.

Barrier No. 7 is “Believing the demo.”

The vendor’s business is to sell software and the demo is their best weapon. So, a good vendor will always demo its product in its best light. Therefore, it’s up to the buyer to step back and fully understand what they need and what the solution must do to be successful. Then, instead of leaving it up to the vendor, script out what is required to meet the organization’s  needs. Have the vendor present against these scripts and don’t get sidetracked by the “sizzle.”

Also, references frequently ring hollow. Do due diligence. Ask about the specific modules of key interest to a successful implementation. Ask about issues with implementation, functionality and user adoption. Then, understanding the business requirements in play, only choose software based on genuine business needs and reputable feedback.

Barrier No. 6 is “Assuming it’s all about the technology,” which brings to mind the axiom, “The tools are cool but processes rule.”

Assuming technology will solve all the organization’s problems will just automate the mess. Similarly, make sure the decision is not by techies or managers but by people actually having the issues requiring resolution. A good system that actually works beats a great system that doesn’t.

Why the emphasis on business processes?
It’s all about one of hardest lessons for companies: technology is an enabler and not the solution. So it’s critical to engage users in defining and addressing issues the new technology is supposed to resolve.

Barrier No. 5 is “Abdicating control.”

A new system should logically be a solution owned by the user. Sometimes, however, when “technology” comes into play, CRE groups avoid the hard business decisions by abdicating control in one of three ways:

  1. They just give it to their outsourcing partner. Though it sounds good on the surface, invariably, this abdication locks companies into proprietary software they cannot get out of.
  2. Upon hearing “technology,” the task business hands the solution off to their IT group. This abdication is destined for failure because IT does not understand real estate so the user gets a tool not a solution.
  3. Expect the vendor to implement “best practices.” All products have good and bad functional areas, and the vendor is motivated to sell, get in and get out.

The key for all three of these areas is that the business must stay engaged and drive a solution that meets their short and long term needs.

Barrier No. 4: “Assuming OOTB will do the job,” which is a costly myth.

According to an industry expert, “There’s not an IWMS system that works OOTB the way it’s demoed.” Even while assessing what’s good, as contrasted with “good enough,” remember that configuration is almost always necessary. OOTB is not a solution paradigm. Though good to avoid configuration where there is no value add, configuration cannot be avoided completely. Users should pick a tool that gets them close to their goal, but they should expect to spend effort aligning the tool to the business.

Barrier No. 3 is “Planning to fail by default,”

has a simple solution – basically being Project Management 101. Companies are still buying technology, thinking that upon buying the tool the job’s done; they could hardly be more wrong.

First, develop a concept of what implementation success will look like, plan appropriately (both time & budget) to accomplish necessary tasks, assign team roles, manage risk and control Scope Creep. Too often companies buy into the sales cycle of a “quick install” or the OOTB promise and they miss key – – and time-consuming — activities around integrations, data migration, setup, testing, training, etc. Plan the implementation as with any other project and manage it the same way.

Barrier No. 2 is “Putting the system ahead of the data.”

Remember that accurate data is king. Too many organizations put together comprehensive budgets, technical requirements and integration points yet omit key ingredients such as data entry/migration/cleansing, never even assessing data quality. Perfect processes and questionable data equal a worthless solution. Look at the real cost of turning on a system, which may be onerous in time and dollars but critical to the project plan’s success.

And Barrier No. 1 is “The friction of change,”

which generated the most Webinar questions from participants saying “We did all these things but still failed.” In fact, they did not do everything; they did not prepare the people for change. Change Management is not a governance issue but instead it is about actively engaging people through organizational preparation for business change.

Although communications is part of Change Management, too many people think it is all that is needed – but it is only one component.  It also requires a coaching and counseling component for ultimate buy-in and best possible outcome for diehard resisters.

Conclusion

Implementing an IWMS project is not rocket science but it does require planning and follow-through. Pick the right solution, know what’s needed, build a professional team, focus on value, invest in processes and always include Change Management.

###

This guest post is written by Phil Wales, CEO of Houston-based eBusiness Strategies (www.askebiz.com)

eBusiness Strategies LLC, Implementation, IWMS