For software development projects, at what point do you feel comfortable giving your client a go-live date that you think your team can deliver?
My non-software development projects tend to be easier to plan and manage since we know exactly how long a task will take and know the risks that are involved. The on-time delivery rate for these tasks is pretty high.
My software development projects are harder to provide a go-live date since many things can change in a 3-month span. I have one project that has a small amount of remaining task items that need to be completed before the system can go live. If I didn't have any outside dependencies, I would feel comfortable saying the project could go-live in about 2 months.
But, the customer wants to plan for beta & pilot testing, which can either make or break my schedule regardless of how much buffering I include in the schedule. For example, I may plan for 2 or 3 weeks to make any changes that the Beta testers provide, but I'm also aware in reality, it may only be 1 week of changes or 4+ weeks of changes.
I am curious to hear how other PMs manage their client's expectations with go-live dates and some strategies you have found that work for you. Saving Changes...
Sort By:
Wade HarshmanScrum Master| GDITIndianapolis, In, United States
It sounds like the onus is on the customer. Beta testing is often a good idea for major releases, but if they want to run some acceptance testing then they'll have to own that. Get an expected testing duration from them and then tack some extra time to the end of their testing, in case they find something they want changed. (You might want to add a "duck" first. See https://en.wikipedia.org/wiki/Law_of_trivi...nd_formulations )
I know this is frustrating because you're expected to manage dates, but it's actually a fairly comfortable thing to be able to tell the customer that you're ready to go live anytime, pending their decision to do so. This is especially true if you're already setup in some sort of Beta or UAT environment. Just make sure your team has a good release plan and you can flip that switch at the customer's convenience. Saving Changes...
Sergio Luis ConteHelping to create solutions for everyone| Worldwide based OrganizationsBuenos Aires, Argentina
The important thing is not the Go Live date. The important thing is the previous that you can call Final Preparation. Final Preparation are all the activities neeed to be closed before Go Live. Then it is the way to help client to undertand that is not about you only. On the other side, software is not different to other products talking about change. The problem is most of the people do not understand how to manage change, mainly when things like estimation review are critical success factors. Saving Changes...
Drew CraigSr. Agile & Product Coach| VanguardPhiladelphia, Pa, United States
There is a distinction b/t code complete and customer testing / beta / pilot responsibilities.
A recommendation I can offer is to set a schedule for code complete and project team QA, etc. with an availability date for the client to begin their testing or pilot activities. In short, the customer should be driving the go-live date.
There are various ways to do this, and certainly be cautious of the potential true bug fix needs, parking lot items, potential enhancements, etc. and potential CR's. This will challenge those scope management skills!
Have you explored using an adaptive life cycle for these projects - would your customer be open to closer collaboration and participating in short feedback loops so there is less risk of rework and schedule overruns?
If a predictive life cycle is the only choice, perhaps you can build a fixed duration for client-side activities into the contract and baselines such that increases to those would be eligible for change control.
I can tell from experience that software development projects very rarely go as planned. They are almost always late to deliver and even worse in many cases you need follow up projects to fix the mess that was done in the original project.
Realistically the only thing you can do is to try to add as much buffer as you can and convince the client to pay. Saving Changes...
Have you included an MVP into your product roadmap? This would give you a better idea of the end product delivery time, and some customers may be ok with firming up the "go-live" after they have seen the MVP. Otherwise, ensure that your "must haves" list is as short as possible, and some, if possible, converted to "should haves", while keeping your "nice to haves" list long, so you have room to play with. Saving Changes...
Somebody is always asking for dates, and it starts before you've even defined the problem you need to solve. I try to be clear, from the beginning, that it's about targets and estimates, especially when software testing is involved. An experienced team can do a fair job estimating development tasks, but I've yet to find a foolproof way to estimate how long it will take to 1) know, in advance, the issues that will be found, 2) replicate the issues, 3) determine root cause, and 4) test and implement solutions.
I'm comfortable giving a firm commitment to a go-live date once the go/no go decision is "go".
This has a few implications:
- The go/no go decision date is planned and communicated well in advance
- Criteria for go/no go are well-defined and approved by the sponsor/customer
- Plans and preparations for go live are nearly complete, if not complete, before the go/no go decision, including steps to adjust the plan in case of "no go". Saving Changes...
Community Champion
