System Testing Roadblock: Project Timeline

One of the biggest and often self imposed roadblocks to complex core conversion projects is the timeline. Most core vendors will push for a 12-month timeline without any further due diligence or consideration to the unique aspects of their client or the project itself. Core vendors assign arbitrary timelines based on meaningless factors such as asset size or a standard timeline that they’ve used since the beginning of time. The quoted timeline typically accommodates a core only change but this is rarely the full project scope. Clients will often sign up willingly for a short timeline like 1-year or even demand for shorter deadlines without a second thought besides “They (the vendor) do this all the time! They wouldn’t say it if it can’t be done”. Well yes they run these projects all the time and that is exactly the point. They’re incentivized to bringing their clients live on the new system and they can support these short timelines because it is their daily jobs to run these projects; however, when their clients get into the heart of the project they quickly realize they cannot keep pace resulting in short cuts, changed dates or poor quality. Ultimately this effects the overall utilization of the final configured system leaving many missed opportunities to leverage the platform your company has made a significant investment in. However, completing a core conversion project successfully in a short timeline is possible depending on many factors. I always advocate for my clients to “Right Size” the timeline to optimize quality of the end product. Two of the key factors to right sizing your project timeline are size of your team and project scope and complexity. Let me explain further:

Size of your internal team

The size of your internal team should be a key factor. If you have limited resources to work on the project and they’re not fully dedicated to this project then 12 months may not be adequate to do a quality job of all of the tasks plus do their daily jobs. What occurs is there are decisions on what tasks the team works on and the vendor deliverables will take priority to keep their stated timeline. What gets left off that list is a comprehensive testing program. The vendor will advise and instruct your team to test but their expectation is 1) validation of data and 2) high-level testing without real test scripts. Sometimes the vendors even prescribe the testing scenarios, which is convenient for them but not any clients that are interested in the software supporting their processes.

Project complexity

The project complexity and scope can vary significantly between clients. I often hear “Rip and Replace” or “Core Only” often thrown around at the beginning of these projects meaning we are not changing anything but the core. The assumption is that all processes will remain the same, which is an unfortunate misconception. In reality these types of projects don’t really exist. Processes have to change to some degree and interfaces to other platforms will change because the core is changing. I do agree that changing only the core and merely interfacing to existing platforms reduces scope considerably but you still need to establish interfaces and test them fully. More often clients will choose to replace multiple platforms at the same time and if this is the case then you need to really assess if the core timeline is going to be enough to fully implement all of the systems and deploy as a big-bang methodology.

In summary keep in mind the vendor’s do this work everyday and your team does not. If there is an imbalance of either team size or project complexity then the team and the project quality will suffer as a consequence. Short cuts will be taken to get the vendor tasks done as simply as possible. Short cuts are often taken in the form of writing test scripts, document current state, and collect testing results to name a few. Your team can take the path of least resistance in the beginning and hope for the best but if your team assesses these two areas honestly and set a realistic timeline to complete all needed tasks your customers/members will have a smoother experience at go-live. How do I know this to be true? I’ve seen my clients against my advise resist the hard work of developing a solid test plan and the results have been over-run calls to the service center for months, exhausted staff who are not fully trained, limited team-members who understand the new system enough to assist front-line staff quickly. The short of it is chaos.  If you do not have enough time given the current schedule, then recognize that now and adjust. Give your team the time to work through the proper steps in developing your test plan and execute it well. You will have a stronger team and stay in good standing in your community.

Project management triple constraint dictates that all three Time/Schedule, Cost/Resources and Schedule must be aligned. If schedule is constrained then resources and scope must adjust to right the imbalance.