Silver linings to an extended project pause

At NICE our teams own several live services which they maintain alongside the greenfield build work that they do. I’ve written before about the benefits this brings and how the funding works which both touched on the prioritisation of services against each other.

At the point that I wrote those posts, we were just tying up work on the private beta of a service to do some work on a rebuild of one of the live services we support with an external supplier. This is a cross cutting service used by other digital teams, which was difficult to integrate with and difficult to improve. We had also been focusing on the greenfield build for a while, so also had several change requests and issues to address on other live services that had been deprioritised.

Looking back at the roadmaps I was producing at the time, it looked like we should have the rebuild and the change requests tied up by June. Since then, other change requests were prioritised, and the rebuild has taken much longer than expected. All in all, it now looks like we will be picking up the work on the public beta of the service a year after we paused work on the project.

While this has been difficult for the team as we are very invested in the service, there have been silver linings to having an extended break in the project.

The most obvious one is that we have been able to take the time to give some attention to other services we own. While we do some work on these during project work, there are always bits and pieces that get deprioritised. We will be happy going back into project work that our other live services are in good shape.

The other benefits are to the project, and lead directly from the extended break. During the project pause, the service has still been in use by internal teams we rolled out to in public beta. This means they have had a decent amount of time to test it out, and provide plenty of feedback. We have gathered much more public feedback than we would have before building new features too.

We have also had the capacity to on board some more internal teams, and do training for them. We’ve learned a fair bit about the service through these teams, and through the training we’ve provided.

Best of all, teams waiting for public beta due to the limited feature set grew impatient enough to give it a go. Some of these tests worked out ok and others didn’t, but we learned a huge amount about what features were essential. We did take a month to address some smaller specific concerns, but have held off on large feature work.

Due to this feedback and extra testing, our priorities for when we start up again look a lot different to when we paused, and the roadmap is better for it.

We worried about the visibility of the project, and keeping our stakeholders and users engaged. We kept doing showcases but on a monthly rather than fortnightly cadence. Although there hasn’t been build work, we’ve had enough to share about findings that these haven't felt forced, and engagement and turnout is still high.

Overall, while it has been a shame not to get to work on something we all enjoy working on, we are in a better place to go into a strong private beta, and are chomping at the bit to get going again.