Measuring progress closely post go-live is key to ensure you’re meeting or heading towards your exit criteria.
We call it Measure because it’s tight, it’s intense. You’re measuring against those agreed rules, the RACI, the exit criteria and all that good stuff. You’re measuring, reporting and getting decisions made. You’ll also be looking at your exit criteria very closely and the frequency of that will probably have increased. It’ll be used as an input towards your meetings, which are probably also more frequent than usual for a temporary period.
Just like we did in Build in our weekly status reporting, the same principles apply here too. You might be reporting more frequently or meeting with your stakeholders more often. You might reduce that frequency as you get a few days/weeks after Go-Live, depending on confidence levels and numbers of open incidents.
Instead of progress versus plan, it’s post go live reporting instead. You’re showing your progress towards your exit criteria.
It’s also quite normal to start talking about first occurrences or first instances, as they happen and provide confidence.
For example:
That sort of information is a key first occurrence. It’s a big deal because that’s the whole point of launching our new app in the first place.
Then we have our issue management. The potential blockers to you being able to wean yourself away and show success. No one wants to be left with a load of problems and that’s why issues are a key part of Measure.
Lastly, we have change control. There will be things you just didn’t know about. Things that you couldn’t have foreseen, or just new good ideas that come up after go live. Changes might be good but they could add to time and costs. So, you won’t just suck them in without some governance and control first.
Sometimes the Sponsor might agree these changes are good ideas and to implement them as a ‘fast follower.’ That just means, once the product and the people are in a nice steady state, you build up a list of good ideas. It’s often called a product backlog. Now you can see your product in action, it’s common to want to make some improvement. Don’t lose these juicy nuggets. Be a good project manager and surface them but remember you need governance and you can’t add to scope and time without getting permission to do so.
In the red box, there’s a reminder of the customer exit criteria. This is a key part of your measurement and progress. You can’t go until you’re done. You can see a reminder of the exit criteria with the red box around it, just here. Those were all the standards that we wanted to reach after we’d communicated and launched this to our customers.
Maybe if it’s just a week or so after go-live, you’ll be expecting an improving uptake in this measure. But this measure goes on for 16 weeks, that’s going to take a while. This might be one of the measures that you hand over to the business to own. It’s unlikely that you’ll be supporting the business for 16 weeks after go live. But you’ll start it off, and then someone in the business will carry on measuring it.
You might be reporting on this one every four hours in the first few days, because you’ve got a lot of existing customers to get onto that app to achieve that success criteria. Again, you’re just trying to chip away at it. It’s a measure that you hope to close down in the first week of go live.
This is another measure that’s likely to go on for longer. You’re likely to dent this one in the first few weeks after go live. But like the first measure we talked about in the customer, self-serving, it’s probably one of those measures that you’ll hand over to the business when post go live support is over. So you’ll start the measure, then you hand it over and then they’ll finish it.
You’re doing all this good measurement, so you’d better write it down and do some reporting.
This is like the status report in Build.
In the example above, here you are, 2 days after launch. You’re looking at how your training is going, complaints, issues, progress general. You’re measuring against the goals that you set at the beginning. And more importantly, how you are supporting the achievement of those goals.
On the top left hand side, you’ll see a date and a timestamp. That’s quite important because in terms of record keeping, you could be doing this report every four hours for the first five days. That probably sounds quite heavy but it’s not unusual to be reporting at that frequency.
Initially it might feel like you finished the last report and you’re about to write the next one. But a lot can happen in four hours, new incidents for example. It will soon come around.
You’ll apply the same rules here and give a fact based view of where you are and whether or not you are meeting your exit criteria or getting there.
In our status here, we are amber overall. The reason that we’re amber, is because we’ve got a hard-hitting issue, or sometimes what we call in the trade, a sev-one (severity one) incident. These are usually a very serious, break-the-business, negative press attention, many colleagues, many customers, impacted scenario.
That sort of issue is a big deal but the good news is that you know how to fix your issue. You’ve got to get some code written to fix it. Then it’ll need testing before it’s put in to live. Once that fix is in, you can return to green.
You can see from the report that we’re doing OK on the rest of our exit criteria. We’ve completed some of our training, the Ops team have already spotted some improvements they can make in the wording on the app store.
Do you spot the change request to recommend improving the script on the app store description of our app? We’ve put in a recommendation for the CR, although you’ll note that we are recommending that that is implemented as a fast follower. We’re not rushing into getting that done straight away, but we do want to capture these good ideas.
