We help a lot of clients with system implementations. They are always complex, hard on end-users and driven by one thing: the Go Live date.
Like the chicken and egg conundrum, Go Live date discussions circle around the polarized arguments of if we change it, the project will never get done and if we don’t change it the project won’t get done properly. In many cases, steering committees have these discussions at the start of the project and set a philosophical course right off the bat, something everyone can align to. If the date becomes sacred it becomes a beacon that everyone on the project team can centre on, a constant ‘true north’ that can always be relied on in a time of much uncertainty. The other option of achieving a specific set of success criteria, no matter the date, provides an alternate approach that establishes a completely different mindset.
Let’s break both of these down.
Option 1: Set the Date
When designing a solution and project plan the Go Live date is the pot of gold at the end of the rainbow. The message is: we will launch this system on the Go Live date, no matter what.
Pros:
-
the Go Live date is the light at the end of the tunnel. End users are always worn out nearing the Go Live date (they do two jobs while the system implementation is happening) so they look to the date where things can start to get back to normal.
-
it provides a cut off for scope changes
-
it helps teams ruthlessly prioritize what they really need over what they want
-
it sets a baseline for third party service providers, budgets and resource plans
Cons:
-
it doesn’t allow for significant changes to the project plan
-
it can become a source of stress rather than a beacon of hope, especially when nearing the final weeks before Go Live and the items on the list are still incomplete
-
it can limit the development of the system so the functionality falls below the minimum viable product
-
it can put your success as a company at risk
-
it can mean that testing and user training don’t happen at the level they should, or at all before the system is launched
Option 2: Set the Criteria
When designing a solution and project plan the achievement of key success criteria dictate the Go Live date. The message is: we will Go Live only when the system functions the way we need it to.
Pros:
-
it puts the integrity of the system over a date
-
end-users have confidence that the system will meet their needs
-
end-users feel much more engaged in the project and know their feedback on functionality is more important than the budget
-
it takes some pressure off end-users, meaning they have the opportunity to provide feedback, test extensively and train their staff before the system is launched
Cons:
-
it risks the project going on for a long time, it will usually take longer than anticipated
-
it doesn’t inherently force the project team to prioritize functions
-
it requires a very diligent steering committee to keep control of the scope
-
it requires extremely tight definition of success criteria
-
any external service providers don’t like it because they base quotes off of dates
In reality, there is always an estimated Go Live date for this option. It’s usually communicated in terms of months, not a specific date, and is how the steering committee plans and executes the project. It is secondary to function.
In our experience, the clients who wind up with Option 2 start at Option 1. The beginning of the project is a different time than the months and weeks before the looming Go Live date, but they choose function over schedules. It’s more expensive, it introduces uncertainty, but ultimately we’ve seen the end result is a better functioning system.
Some things to consider when you’re establishing your own philosophy:
-
when thinking about scope, time and resources, which are you willing to sacrifice?
-
how much of an impact does a longer project have on your business and your team?
-
how much risk are you willing to take? What is the impact to your customers, staff and corporation if you are missing functionality when the system is launched?
Most importantly, if your future revenue relies upon a successful project, consider holding success criteria above a date. It’s a bold choice, and one that has to be managed properly but ultimately results in a better, more functional system.