If you are stuck in a daunting IWMS software selection process, or you are about to start one, this post is for you. Like you, I have been there. Over the last two decades I have been involved in many selection processes, and have witnessed approximately every mistake one can make. To prevent you from making these same mistakes as well, over the next couple of weeks, I will write a post series about IWMS software selection processes, and what I have learned from it. But first an introduction in our subject.
Software Selection Processes
Software selection processes have been designed to stimulate openness, fairness, accountability, and impartiality when procuring business software. By following a strict procedure with set milestones in theory, these processes should support your organization in making the best possible choice for the right price. Unfortunately, in practice, software selection processes can have exactly the opposite effect.
In some cases the software selection costs exceed the entire IWMS implementation. To me, this is a complete waste of time and money. Don’t get me wrong, I fully support a methodical approach selecting business software. In fact, selecting an IWMS is impossible without it.
However, occasionally, organizations lose themselves in the process, and confuse the process with the goal; the selection of a system to support your organization.
Analysis Paralysis
One of aspects that can have an extremely negative impact on the IWMS selection process is ‘analysis paralysis’.
The term “analysis paralysis” or “paralysis of analysis” refers to over-analyzing (or over-thinking) a situation, so that a decision or action is never taken, in effect paralyzing the outcome. A decision can be treated as over-complicated, with too many detailed options, so that a choice is never made, rather than try something and change if a major problem arises. A person might be seeking the optimal or “perfect” solution upfront, and fear making any decision which could lead to erroneous results, when on the way to a better solution. (Source: Wikipedia)
Due to the enormous numbers of solutions, modules, functionality, etc. in an Integrated Workplace Management System, over-analyzing is an ever-present danger in the first phases of the IWMS selection process.
Particularly in the RFI,RFP, RFQ phase, organizations tend to include every single aspect they can think of as a requirement. Quite often questionnaires exceed the 750 questions. I have always felt a healthy reluctance against these questionnaires.
Why? Because they are ineffective.
- It takes ages to define your requirements
- It takes ages to fill in the document (with complete, truthful and accurate information)
- It takes ages to analyze / compare the completed questionnaires
And despite all the work, time, money, and resources , in the end, it all comes down to the proof of concept.
Not a single organization has ever purchased an IWMS without either a proof of concept demonstration, or a test-drive pilot.
This automatically leads us to the cure of Analysis Paralysis.
The Cure
You can easily stop wasting a lot of money in the IWMS selection process by adopting a more robust process.
1. Define your core processes which the IWMS needs to support.
Although many IWMS’s can support a wide variety of processes, in most cases you don’t need the full suite. Be specific about your core processes and don’t compromise on those. Cut away the nice to haves. They are not relevant for now.
2. Write use cases that are absolutely imperative for your organization.
Make sure that they cover all core processes. Your functional processes need to include stakeholders (employee, FM/RE team, management, etc.), workflows, approvals, and reports. Also include a use case for system administrators, as they need to be able to maintain the system, unless you want to be totally depending on the IWMS vendor, or service provider.
3. Go online and search for information about IWMS
You’ll be surprised how much information is available on the internet. Solution descriptions, module overviews, case studies, technical information, and other relevant material can be extremely helpful to gather information. Some IWMS vendors have even product videos available.
4. Analyze the material and create a short list
A thorough analysis of the material you’ve collected should enable you to create a short list of IWMS vendors that could fulfill your needs. By matching your core processes, and your use cases to the information collected, you should have a clearer picture by now.
5. Allocate a budget for a pilot.
Instead of spending your pre-implementation budget on a questionnaire you’d rather invest your money in a pilot. In this pilot you can test-drive the system as if it were used on a daily basis in your organization. On average my advice would be anywhere between 10-15% of the total IWMS budget.
6. Define the Purpose, Goals, and Objectives of the Pilot
Why do you want to conduct a pilot project and what should a pilot accomplish? Being specific in terms of purpose and accomplishments ensures a good focus towards the goal. Within IWMS pilots , quite a few people struggle with the concepts of goals and objectives.
“The goal is where you want your IWMS to be. The objectives are the steps needed to get there.”
For my individual goals and objectives I use the SMART(ER) Objectives. SMART is an acronym that is used for setting objectives. According to SMART objectives should be:
S – Specific
M – Measurable
A – Attainable
R – Relevant
T – Time-bound
Of course, you can use any methodology that you feel comfortable with as long as you are able to clearly define your goals and objectives of the pilot.
6. Establish Success Criteria of the Pilot
Without establishing pilot success criteria, you can’t measure the actual performance. You should ask yourself several questions:
- What does IWMS pilot success look like?
- How do I know I’ve completed the pilot?
- How do I know I’ve done a great pilot?
- and finally, How will all this be measured?
By establishing success criteria of the pilot you’ll be able to measure performance.
7. Define the Scope and Duration of the Pilot
Although it would be extremely beneficial to evaluate all key processes in the pilot, in most cases this is not advisable as this is not manageable by the project team. Therefore the scope and duration of the pilot should be limited. You need to be very specific in writing what is included in the pilot, and what is not.
8. Prepare the Pilot
Depending on the scope, the goals and objectives, you need to prepare the pilot. It’s very important to select representative participants, set the time frame, and train the project team in conducting the pilot. What’s also very important is that you prepare / install the IWMS pilot implementation (either hosted externally or internally). Ensure to include the use cases (point 2) in your test scenarios.
9. Conduct the pilot
During the pilot make sure that all information is captured in relation to the objectives and use cases. E.g. If you have defined a 30-second reduction in entering a trouble ticket, be sure to capture the actual times. Also record any usability issues that users experience.
10. Evaluating the Pilot
Evaluation is the most important part of the pilot projectYour evaluation of the system, with recommendations for further configuration of the IWMS should be the blue print for full scale IWMS implementation. Be sure to include qualitative (e.g. interviews), and quantitative analyses (e.g. number of errors) in the evaluation.
A carefully constructed pilot project will make provision for objective analysis of the results and an assessment as to how to proceed with full deployment.
Final Thoughts
In this list I have put forward a process for curing the analysis paralysis in software selections.
Later in this post series, I will deep dive in certain aspects of the pilot itself.
Additional Reading
- Recommended Practice: Developing and Implementing an Enterprise-wide Electronic Records Management (ERM) Proof of Concept Pilot
- Why Irresponsibility And Inefficiency Are Devastating For Your IWMS Selection Procedure
- Why Your IWMS Focus Should Be Flexible And Scalable
- Why You Need To Start Small and Think Big With Your IWMS