I have been spending quite a bit of time recently working with Axsium clients who are transitioning from selecting a workforce management software solution to implementing it. Recently, one well-meaning client suggested that the implementation timeline could be significantly reduced by leapfrogging over Discovery and jumping right into Design. “After all,” the client said, “the RFP listed our requirements. Why do we have to do any more Discovery?”
Ah, if it were only that easy! A well-structured Vendor Selection phase yields valuable, time-saving inputs into the Implementation phase, but it’s also important to recognize that these inputs have inherent constraints. Here are my top seven reasons why Vendor Selection Discovery can’t replace Implementation Discovery:
1. The Initiative may still be Just a Twinkle in the Sponsor’s Eye
During Vendor Selection, companies typically (and appropriately) choose to make a relatively modest investment of time, money and resources in conducting Discovery work until the Implementation has been green-lighted and funded.
I have seen Implementation projects get shelved for years, even after a vendor is selected, for a broad range of reasons, anything from unforeseen financial difficulties to political infighting amongst stakeholders. Securing large commitments of time from all of the appropriate personnel isn’t possible until buy-in from senior leadership has been established for implementing a specific vendor’s product.
2. The Primary Goal of Vendor Selection is to Gather Just Enough Data to Make an Informed Decision
Axsium’s approach is to match each client’s highest priority requirements with the vendor that is most effectively able to meet those requirements. By intelligently making use of your limited resources, you can arrive at a high quality decision and be very well prepared to launch an Implementation project. Overkill on requirements definition before selecting a vendor can be downright counterproductive.
3. You’ve Select a Vendor with Flexibility to Meet Requirements You Don’t Yet Have
A vendor’s ability to accommodate(and even enhance) your plans for growth, your plans for IT improvements, your compliance with the regulatory trends affecting your business, and anticipated changes in your workforce model are all examples of important business issues that can heavily influence your Vendor Selection decision. However, once you transition to Implementation, time and budget constraints will limit what you can do. As you get down to brass tacks, you’ll focus on how the software can best meet your immediate, high priority requirements. You should realistically expect that some Vendor Selection requirements, even important differentiating ones, will get shelved for future consideration once you begin the Implementation phase.
4. You Don’t Yet Know What You Don’t Know
This one is sort of the flip-side to reason #3. When a company decides to implement entirely new functionality, requirements must be identified and refined through a collaborative and iterative process. This process is more effective after the Implementation phase has kicked off.
One example of new functionality prompting organizations to contemplate requirements they didn’t know they had, is when an organization decides to implement employee self service features. If you are currently dealing with paper-based request processes, you likely have never even contemplated what your exact requirements are for escalating workflows. You need to discuss how the new functionality will fit into a typical manager’s routine and weigh the consequences of all of the new options that are available before refining your requirement.
Taking advantage of new features can often be the key to achieving ROI and other benefits, so it’s critical to spend sufficient time exploring and understanding new functionality in order to make decisions that are aligned with the objectives of the initiative.
5. Decisions are still Pending
Ideally, the large solution scope decisions are pretty firmly established before starting Vendor Selection, but that is not always the case. On top of any big decisions, there are hundreds of smaller decisions that will have to be made through the course of the Implementation project.
A situation we often run into is when an organization moves from standalone systems for scheduling and time keeping to an integrated WFM application. This integration opens up new possibilities for managing time punches that deviate from employees’ schedules. Employees punching in well before or after their scheduled shift start and shift end, or punching in on unscheduled days, have operational and financial consequences that can be very effectively managed with an appropriately configured WFM solution.
There can be fundamental differences in approach to addressing WFM issues. Where a foundational piece of WFM functionality, such as punch deviation rules, is well established with all of the vendors under consideration, it’s appropriate to spend much more time during Vendor Selection assessing the differentiating software features against the more unique client requirements at a very detailed level. For any given set of WFM requirements, the options are myriad and the details vary slightly from solution to solution. You should expect to tie-off these pending decisions during Implementation Discovery and Design.
6. Every Product has Constraints
Different products handle certain areas of functionality very differently. Every product has its strengths and its limitations. During the Implementation Discovery, it is critically important to validate your full set of requirements against the details of the selected product’s functionality and determine how you are going to work within the constraints of the product.
Years ago, I worked with a client who had developed very detailed requirements for how a call-in guarantee would be tracked for reporting purposes prior to Vendor Selection. Although the selected product could meet the requirement to calculate guarantee pay correctly, it could not meet the exact requirement for how the un-worked portion of the guarantee should be tracked. As is often the case, we were able to come up with a perfectly acceptable alternate approach, using out-of-the-box configuration. However, we had to address the issue and find the solution during Implementation because of the dependency on the selected product and the time and resource constraints of Vendor Selection.
7. Timelines are Tight
Sometimes, WFM initiatives languish on the back burner of priorities until an event, for example, an audit report or reaching the end-of-support creates a sudden sense of urgency. At that point, Vendor Selections may need to be made within short timeframes in order to align with budgeting cycles or other key milestones. Because of tight timelines, we tend to use a broad set of high-level requirements with some extra detail for very unique situations within the business. Once the initiative transitions to the Implementation phase, a scoping exercise must be carried out to validate the requirements against the finite time, budget and project resources available for the Implementation.
You Really Do Need to Do Implementation Discovery
There is no doubt a structured and thorough Vendor Selection Discovery is critically important to selecting the right vendor and will significantly accelerate, but it cannot eliminate the need for conducting Implementation Discovery. As you can see from the seven reasons above, the Implementation Discovery yields additional details and decisions that were not possible or relevant during the Vendor Selection Discovery.
These explanations proved compelling to my client, but I’d love to hear from you with any questions or feedback you have on this topic.
