IPMA International Project Management Association
27 October 2017 / 6:43

4 Fallacies of Typical Project Management Thinking (Part 2)

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.

5 Comments

  • Jackilyn says:

    I think this is great. “Go Live” dates or project deadlines can be very tricky while in the early stages and I myself have fallen victim to unrealistic deadlines to ever changing and ever growing projects. I think that setting a soft deadline would be the best way to go about this, and i love the idea of not being able to provide the customer with a specific due date or go live date.

  • Stephanie Larson says:

    Great post! It was informational and knowledgeable for future projects in mind. Not giving a set date and time that a project, or in this case, software, will be done doesn’t disappoint or anger anyone.

  • Stephanie Larson says:

    Great post! This gives me information on future projects! This gives me an idea on how to not disappoint my customers. Thank you!

  • Samuel says:

    This was so insightful, and so true! Such a common mistake that I see so many young project managers make.

  • William R. Duncan says:

    It depends on what you mean by “the start of the project.” If you are pre-requirements, then I agree 100%. If your project “starts” after the product design has been completed, then you should be able to commit to a go-live date.

    This is basically what the project lifecycle is for: you should commit phase-by-phase. If you can’t commit phase-by-phase, then you have no business calling yourself a project manager.

    Important, as well, to note that this applies to software development only, not to all types of projects.

Leave a Reply

Your email address will not be published. Required fields are marked *

Sandra Misic

Author of this post

Sandra currently works as Assistant to the IPMA President and Executive Director. Since joining IPMA in 2012, Sandra worked in FMCG sector for Procter&Gamble. She holds Master in Economics from Faculty of Economics and Business, University of Zagreb. After graduation she continued at the same University the doctoral programme in Business Economics. Her particular research interest is behavioral economics.

CATEGORIES

TOPICS OF INTEREST