Written by Ryan Downing
Part 2 – Setting a Go Live Date.
You can read previous articles in this series here.
In this series, my goal is to bring to light several common project management practices that I feel are forced on projects because they are assumed to be best practice. However, there are plenty of scenarios that would dictate a different approach. I hope that as project managers read these articles, they are challenged into examining the projects they manage so they can determine the best way to approach each unique project – even if that approach is different than what they use for most of their other projects.
#2 – Setting a Go Live Date
After spending over a decade working on software deployments, the first question I get from the customers when a new project is started is when they will be live on the software in a production environment. I understand the reasoning behind this as the company has just invested a lot of money into the software solution and want to know when they can start seeing some ROI.
Here is where the project manager will play a pivotal role in setting the correct expectations for the successful completion of the project. I have seen too often that project managers will provide new customers with a go live date at the very beginning of the project. If that date is not met, it will often lead to disappointment with the customer and have the potential to sour the vendor/customer relationship.
In order to avoid this, I tell the customer that I cannot give them an exact date that early on in the project. I let them know that there are too many variables that are yet unknown before committing to a project conclusion. Since the software I have implemented has always been very configurable for a variety of operational needs, I stress to the customer that my team of consultants need to first meet with them to understand unique business requirements before knowing when the project will realistically finish.
In the book Implementing Lean Software Development by Mary and Tom Poppendieck, they discuss deferring commitment, one of the seven principles of lean thinking. In the book they are quoted as saying “in the face of uncertainty especially when it is accompanied by complexity, the more successful approach is to tackle tough problems by experimenting with various solutions, leaving critical options open until a decision must be made”. I have applied this principle to complex software implementations where ending go live dates are being asked for prior to having all of the information needed to fully develop the solution.
During the business requirement gathering, I stress with my team to not only be looking for their operational needs to see how well they will fit into the core of the software, but also into the customer’s project team makeup. Having a customer with complex system needs that may have to be customized will certainly extend out a project timeline. However, even if their requirements are simple, if they do not have a competent project team with high level organizational backing, the project will probably also lag.
That is why, only when the business definition sessions are finished and me and my team can fully analyze both the customer’s requirements and project team makeup, will I ever try to determine an end date for the project. I can remember one customer that as we went through the project definition process we uncovered many usability gaps and they had to spend more on customizations to the software than they did on the original software package. That project took much longer than a typical implementation.
Too many project managers commit to a deployment date very early on when they lack the full knowledge needed to make an informed decision. Most of the time, the dates that are chosen are ones with the best case scenario in mind – a customer with straightforward needs and a dedicated project team. By doing this, those project managers are setting the stage for problems in the future. If that customer’s project will be very complex or they do not have a team with a lot of dedicated time, it will require much more time than a standard implementation.
Rather than giving the customer unrealistic expectations before knowing all the variables that could impact the project outcome, project managers need to tell their customers that they will only be able to provide them with a project timeline with estimated go live date after the team has been able to analyze the customer business processes and team. Then when you are able to come up with a schedule, everyone involved will have a lot more confidence in being able to successfully go live in the agreed upon timeframe.