There is a very wide range in how long an IWMS implementation will take from as little as a few weeks to as long as a few years. There are a number of reasons for the variances in implementation time frame but I will focus on three that I believe are the most significance: product flexibility, delivered functionality and client requirement complexity. These three issues are actually highly entwined making it even harder for most companies selecting an IWMS to properly assess each one.

Delivered Functionality

When companies look at applications they often make the mistake of basing their analysis of how well the product fits them based on what they are shown in a demo. Even though those demos may be as long as 8 hours, what you don’t know is how long the vendor spent preparing it and how much of what your seeing is real functionality vs. “configuration magic”. Pre-configured product can be a good thing if the items configured are actually truly usable by the client. However what most often happens is the client is shown a demo, let’s say of sample real estate transaction management processes, thinking that what they are seeing is actually part of the delivered product only to find out later that it was a configuration item and they will need to build their own base functionality from scratch. This of coarse means professional services cost to get it done, often in the form of a change order over the initial estimate.

To avoid this ask vendors to first give you and “out-of-the-box” demo before getting the long demo full of “configuration magic”. You will then be able to properly assess what you are and are not getting.

Product Flexibility

There are also products that deliver a lot of out-of-the-box functionality providing clients a better starting point for their implementations but that are inherently hard to change. For example a vendor may have a very specific IWMS product for restaurants or cell towers, delivering a lot of specific features to fit that market BUT when you begin to implement you realize that changing critical system pages, building a simple report or creating a data export requires a software developer immediately extending the implementation timeframe and running up cost.

Ask the vendor to modify a few critical pages during the demo and add, delete and change fields. Ask them to add a page someplace in the menu structure that you identify. Make them create an ad-hoc report on the fly and show how that can be scheduled. All of these items will indicate a level of flexibility that will significantly decrease the implementation timeframe and overall project cost. This level of flexibility can mean the difference between a 2-month project and a 6-month project.

Client requirements complexity

Every client is different and each client always has unique requirements. Applying those unique requirements will require some degree of configuration or, with some less flexible software, customization. As the number of locations gets larger, typically, the complexity of configuration also gets larger. Larger firms not only have more complex business processes they also have many integrations and data conversions adding complexity and cost to any implementation. All of these items will add to the timeline and cost of an implementation project though a large degree of the business process complexity can me mitigated with a highly flexible product.

Shameless Plug

Can an IWMS really be implementing in weeks or a few months instead of a few quarters or years? Lucernex provides a Quickstart® program that can have smaller companies live in two to nine weeks. We have the most flexible product on the market allowing for client or implementation team configuration of nearly every page, wizard, form, workflow or report in the system. The Lx IWMS also is delivered with a huge amount of industry specific functionality out-of-the-box and also comes with many best practices forms, workflows, reports and pages pre-configured. Unlike may other vendors we are doing everything we can to AVOID high professional services fees for implementation by making the product easy to configure without ANY software development resources. It is extremely rare that any of our implementation require any customization.

Definitions

Configuration – adapting a software application to meet unique client needs using tools provided by the software developer; this may or may not require a software programmer
Customization – programming code written by a software developer that impacts either base code or client specific code to meet the unique needs of a small number of clients
Integration – programming code that allows two different software programs to exchange data and/or activities on an on-going basis
Data Conversion – a one-time movement of data from one software application to another usually with the intent of replacing the originating system

Previous IWMS related Blogs

What is IWMS anyway?
IWMS? It’s Location! Location! Location!
The Power of Location Management
IWMS – Why so expensive?
IWMS in the “Cloud”
How Capital Project Management fits in an IWMS

Last week I’ve written a post about Customization and IWMS. By explaining the customization paradigm I have put forward seven reasons why you shouldn’t customize your IWMS.

In this post I’ll discuss the other side of the Customization Paradigm; Configuration.

Configuration is adapting the IWMS towards your processes and requirements without modifications to the source code of the core product.

Configuration of an IWMS has some big advantages:

1. Configuration is relatively cheap
   Since all processes and business logic are predefined you can only do modifications that are allowed within the IWMS. As programming is extremely time consuming configuration will save a lot of time. (= money)

   As tip I would advice you to have a look at the offering you’ve received from your IWMS vendor. Ideally, the ratio between software and consultancy would be approximately 50-50. The more consultancy is involved, the more expensive the entire solution will be. More consultancy services are an indication for functionality not being standard.

2. Configuration is fast
   Programming is time consuming. Even minor changes (such as work flow changes) can take weeks because all rules have to be programmed. Configuration on the contrary is because of its predefined boundaries faster. Limitations are a blessing as long as these are supporting your business requirements.
3. Configuration is flexible
   Although predefined boundaries seem to be limiting the support of your business processes they do not. In fact, IWMS vendors who provide an off-the-shelf product will provide better support of business processes because of those boundaries.

   Implementation of an off-the-shelf IWMS tends to be more organizationally focused than the technically focused implementation of IWMS’s that need to be customized (programmed) to your needs. Focusing on organizational processes will reduce the need for customization because as a side effect the business processes itself will be evaluated and non-performing, inefficient and irrelevant processes will be disposed.

4. Configuration ensures independency
   Since your organization is in full control of the IWMS you will be independent from the IWMS vendor. All changes both minor and major changes can be done by functional administrators of the IWMS.
5. Configuration facilitates upgrades
   Almost in every implementation of an IWMS that I have been involved in customization causes upgrade problems. When configuring a product and not modifying the source code of the core product you will have easier upgrade processes. My advice would be to request the IWMS vendor to provide the following data:
   1. Customers that have been customer for at least 7 years
   2. And that have migrated at least three times (only major releases, not including service packs)

   This will give you a very good indication about the IWMS’s upgrade possibilities.

6. Configuration does not require advanced technical skills
   Most professionals in FM and RE do not have a technical background but need to be able to do modifications to the IWMS themselves. When the IWMS provides easy to use configuration tools you ensure that your experts in the different functional areas of the IWMS can do functional changes.
7. Configuration changes the role of the IT Department
   Since your FM and RE professionals can do modifications to the systems themselves your organization will be less dependent on the IT Department. In fact, their role will change from both functional and technical administrators to only technical administrators.

Your Opinion
So what do you think about customization vs configuration? I’d love to hear to what extend you (dis)agree with me. Please use the comment option below the post to add your opinion.