Managing Change: Don’t Break the “Project Flow”

Today, I was musing with a colleague about the nature of “flow” on a project. We were specifically discussing an ongoing UAT (user acceptance testing) process which, honestly, has:

  1. Been extended for quite some time
  2. Is not going nearly as well as “UAT” should go

I want to talk more about the latter before I consider the former. UAT, for me, should be bell-whistle clean. I know that there is such a thing as a “zero defect” project, and by “zero defect” I mean that it doesn’t go into production with known problems that cause pain and mayhem, and by “I know” I don’t mean I know of, I mean that I’ve personally done one. However, the reality is that more often than not, defects happen and get spread, change requests happen and can’t be met, and that all needs to be handled in some sort of fashion.

Fair enough.

However, the whole purpose for things like “entry and exit criteria” and “test strategies” and “test approaches” is to set the context for which testing will be conducted. If you have loose entry and exit criteria, you will have a loose testing process. If you are unclear about what is considered a critical, high, medium, or low defect, you will spend more time arguing about the criticality instead of fixing the issue. If you are uncertain about what your metrics are and what they mean (or are swayed about by the winds of office politics), you will spend more time debating RAG statuses than using them to help drive and focus your participants and stakeholders.

UAT needs to be clean. To make it clean, the following principles must be ironclad:

  1. Explicitly define and assiduously follow your entry and exit criteria
  2. Test cases, once counted and displayed, can never “disappear” (i.e., I had 40 today but junked 20 and didn’t explain it) – every case must have a status, and your metrics must always be clear and transparent
  3. RAG status is not up for debate – the person who ultimately has his or her neck on the line (i.e., the UAT Manager) gets to set it – save the glad-handing, cajoling, and consensus-making for the campaign trail and town hall meetings

Every time I have given, even centimetres, on any of the above, my UAT process has been scattered, stressful, and trial-some. As a project manager, my job is always to succeed in spite of all of those challenges, but I haven’t made it easier on myself when I’ve budged.

Coming back to the first point, an extended UAT – that reflects on my initial discussion about “project flow”. Investment bankers call it being in the “deal flow”, some people call it being in “the zone”; the idea is that the rhythm – the ebb and flow and focus – have all come together into a series of moments that are serendipitous in nature. It’s when you jump higher and you fly further.

Projects have the same flow and UAT, a major part of that, has it too. One thing that we always forget about UAT is that from a project (and not a product) standpoint, it is the last major phase. Regression and release testing/planning, etc., while important, are fundamentally maintenance or repetitive activities – they are not change activities.

Therefore, when you get into UAT, the idea is that

  1. It should be quick – finally, users get to see and use the finished product
  2. Users shouldn’t be stuck in the middle of endless defect fix cycles (see entry / exit criteria),
  3. Users should be able to do things once and done (see test case metrics and tracking), and
  4. Everyone should have transparency into the overall progress (see RAG Status)

When things drag on, it’s murky and unclear what’s being done and how much longer it will take, you get angry users. And what do angry users do? A sampling:

  1. They dig their teeth in on non-critical change requests (it’s spite)
  2. They start asking questions (and keep asking! interrogating, even) about things they honestly don’t need to know or care about (idle hands)
  3. They start refusing to sign-off even when things are completed (loss of faith)
  4. They refuse to test further (exhaustion)

The response, unfortunately, from change personnel, business analysts to project managers to developers is this:

  1. They dig their teeth in on refusing low-effort change requests (it’s spite)
  2. They start nitpicking at every question, request, metric, or issue (stress)
  3. They start refusing to respond to users (burn out)
  4. They refuse to put full effort in (exhaustion)

Nobody wins, I hope that’s clear, yes? Nobody wins when UAT isn’t properly managed and nobody wins when the project flow is broken.

So, for those of you who are change people, don’t get so buried in the details that you forget both the fundamentals of change management and projects and people. Keep a steely eye on your UAT phase and most importantly–

Don’t break the flow.

I hope you enjoyed today’s article. Please share this with a friend or colleague who you know would benefit from it and also follow me on LinkedIn where I post other items similar to this.

Also, let me know how well the above helped you! Please comment below or send me an email at

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s