Ready, Set, Fail

You’re a test manager in a waterfall-style solution delivery project. UAT is coming; it’s in the project plan and the delivery team is working hard to get the solution ready for it. Really hard. The project manager from the humungous-company vendor is coming down hard on them.

The test environment, the test data, the master test data, the people lined up ready to test, the scripts written and distributed. You’ve done your part.

If UAT goes well, you’re the hero of the day.

If UAT uncovers issues, well, you’re telling bad news to a large audience that doesn’t want to hear it. No one wants to hear it. Not the delivery people, not the implementing company, and certainly not the project manager. The aggressive, classically-trained, command-and-control project manager.

They fight to lower the issue severity. They challenge your evidence that the issue isn’t new but rather re-introduced in the rush. They censor your status report and work hard to make sure you are isolated and shielded from the project stakeholders. A subtle censure, sometimes not so subtle. You feel terrible, you feel like a failure for having caused so much trouble.

It’s go-live. Cutover to production. The deployment script is run, the users are notified, stakeholders sign off. And then there are issues. Issues that come in all sizes of pyjamas and none of them can be easily put to bed.You are certain that those scenarios were tested, you know it. You have the evidence. And yet there are issues, some subtlety that wasn’t checked or some difference between the test environment and production got exposed or some scenario varies from what was trained. You feel terrible, you feel like a failure for having caused so much trouble.

--

You’re a test manager on a traditional, waterfall-style delivery project with a command-and-control project manager. You will feel terrible, you will feel like a failure for having caused so much trouble.

Unless.

Unless you know this is coming and prepare everyone, including the project manager, for those issues. Scrap the scripts and replace them with checklists built by people that know the business and convert the checklists into information radiators for those not close to the project. Lower the barriers to issue resolution by avoiding root cause analysis in lieu of finding the fastest route to the individuals that can resolve the issue. Don’t think deployment is done.Use an information radiator for issues that everyone can access and update it daily. Publish the link so that anyone, everyone, can see it from anywhere.

Transparency is the only way to get around the censure, and if you set that up from the beginning, it will be embraced by even the project manager. I’m willing to bet that the project status report will ultimately contains parts of or links to the information radiators you set up.