Getting folks to pay heed to risks in time , is hard

I recently finished a coaching gig with a leading agriculture industry org here in Christchurch. My key responsibility was to coach their internal Test Lead to ,

a) frame a Test strategy for their multi year change management programme

b) provide on going coaching service as the strategy is delivered for initial phases of the programme.

The coachee were an extremely talented and knowledgeable business user and from an engineering+lab testing background , but were new to enterprise software Test management.

Yesterday, I had a catch up with them several weeks after I had finished the engagement . The focus of the discussion was on their experience of Test management so far and how could we as a “test strategy” Team have done better?

One of the things that they raised in the retro really captured my attention as something that I need to personally improve, here is how the conversation went

Coachee :: “Looking back at my first Test management project, one of the things I really I wish I could do better was to persistently advocate risks”

Coach :: “Fair point . However we did have a process to register all programme and project related risks in the risk register and had a process to discuss/escalate them on a regular basis . Didn’t that process work?”

Coachee :: ” Umm,the process was there  but I did not advocate testing risks as often I should have ”

Coach :: “Why was that ?”

Coachee :: “Because they were project related risks and part of the PM’s realm of responsibility”

Coach :: “Let us re-frame that….they are testing related risks that have a project impact , so are inherently your responsibility too?”

Coachee :: “Yes but over time they stopped feeling like testing risks to me”

Boom …pivot….this suddenly changed the whole dynamic in the conversation, I suddenly felt this rush of regret that I had missed a trick in coaching them on risk advocacy. And that I needed to get to the bottom of this !

Coach :: “Could you elaborate on what you mean by stopped feeling like testing risks over time ?”

Coachee :: “See, as you know this is my first software management project,while I could understand how the risks impacted the project I could not accurately gauge how  would those affect my ability to manage testing for the programme ! Due to this they did not bubble up often and high up enough on my list of things to worry about, hence I did not advocate them with senior leadership as often as I maybe should have? Over this long drawn programme I just left them as some-else’s job . However a lot of those risks materialized  and bit me  ”

Imagine these two articulation of risk ::

Example 1 :: We dont have a complete and good set of requirements . This is a critical risk to the project because if we dont have requirements we can not build and test the new features that the client is asking by this date . And that means that the project will slip it’s delivery date or would not be delivered at all

Example 2 :: I have reviewed the current set of requirements from a test-ability prescriptive. As per my analysis the requirements are neither complete nor can be reliably used as a basis for writing effective tests to critique what we are delivering . This will  hinder the ability of the test manager to estimate and the Team to complete design and execution phases of the project , which in turn puts the current delivery date at risk.

If I were a test manager reading the risk register with the above risk(s) in it or if I were a test manager hearing a tester articulating those risks

— am I more likely to advocate and bubble up the first or the second risk ?

Why ?

As throbbing sapient beings we all have a cognitive limit and biases towards what we let occupy our mental space (both for the good and the bad).

In complex , enterprise level projects this space gets filled very quickly.

And it is by no means selfish to admit that we worry more (and often) about things that affect us directly  , that are visceral to us ,that might impede execution of our personal roles.

Now revisiting the two examples again and comparing the text in red 

Example 1 :: We dont have a complete and good set of requirements . This is a critical risk to the project because if we dont have requirements we can not build and test the new features that the client is asking by this date . And that means that the project will slip it’s delivery date or would not be delivered at all

Example 2 :: I have reviewed the current set of requirements from a test-ability prescriptive. As per my analysis the requirements are neither complete nor can be reliably used as a basis for writing effective tests to critique what we are delivering . This will  hinder the ability of the test manager to estimate and the Team to complete design and execution phases of the project , which in turn puts the current delivery date at risk.

The message in red,in the second example is more personal. It answers the question , “how does the risk impact me/us?” , explicitly than example 1.

My mistake was to under-emphasize the importance of articulating how those risks could hamper the coachee’s (audience of the risk advocacy in this case) ability to execute their own role.

I was the victim of my own experience as I was seeing the so called bigger picture (of the impact on the project and the programme and beyond ) but missed the obvious, i.e. to start with how that risk impacts the coachee first .

This was a critical miss because I did not my advocate’s heart and mind on board.

Learning –

1.While coaching, always remember that I am serving the coachee first before their project /programme.

2.While advocating risk, in addition to articulating what the project/programme/commercial impact of the risk and articulate how that risk will impact the decision maker’s role and responsibilities that they are accountable for.

And if you do it well, irrespective of whether they are the Test Manager or the CEO , they will listen