The perception of success is where a solution is accepted and readily used by those who it is intended for. It sounds pretty basic stuff, but is too often not fully understood. While the analysis in all its glory and execution may be considered best of breed – even innovative and/or ground breaking or the candidate for a new benchmark for future case studies, if the recipients of the solution think they got a dog, then the work carried out does not have the perception of being successful at all by those using the solution.
Clearly this is not a good situation to be in.
In speaking with a CEO recently, he commented to me that he did not think there were so many good Business Analysts around, and because there were so many terrible Business Analysts, it was a real joy to find a good one. As a Business Analyst myself that’s always a topical one to dodge, especially since I thought he was talking about me!
He said he wasn’t, but did comment that when he used a good Business Analyst, it made his work all the more easy. His bug bear it turned out was twofold. One, it was around lack of clarity in the work coming from the analysts that were then open to interpretation and inadvertently fuelling undesirable outcomes, where the downstream impact was that key targets were missed altogether. Two, this tended to occur because Subject Matter Experts are not Business Analysts even though they might work under the role/job title.
Add in developers who want to put their spin on the resulting functionality and suddenly there was a toxic sludge being mixed and it all too often meant that technical solutions needed serious remedy and re-work.
I suggested to him that a good Business Analysis (and I’m being specific here in that I’m not including a Subject Matter Expert thinking they are a Business Analyst) would have the awareness to engage with his or her most valuable ally on any new technical solution on the day after they start eliciting user requirements for the solution. They would do so because they know how to avoid the problems he had articulated, but also to stock up the right resources at the beginning to ensure that the perception of success would be attained once the dust had settled.
I think the CEO might have tried to hug me at that point. I settled for a second beer instead.
So the big revelation of course was that we were talking about the Business Analyst’s best buddie who is of course the Tester; and how they ought to be working together from the beginning of the analysis phase.
Okay, so that’s probably a bit of a letdown for some, if the truth be known, because readers are probably thinking, of course you’d do that, right?
Right. And any numbers of text books that I have read over the last 20 years or so all said the same thing; engage with Testers at the onset of analysis. Yet all too often, there is no upfront engagement or awareness given to the importance of testing analysis as early as possible at all.
It is fair to say that not all project teams carry a test resource when they kick off, and sometimes the Business Analyst is expected to do the testing as well as the analysis, where budget and money constraints prevent securing a dedicated resource. This is not a situation that I endorse, but it is not a perfect world.
Still the dirty reality should not prevent a Business Analyst from being able to understand who will be the consumers of their work, and what it will be used for. Naturally there are multiple recipients, from Sponsors, Stakeholders, Subject Matter Experts, Developers and, of course, Testers to only underscore the value of the analysis work, and how it needs to be put together to satisfy a diverse range of interested parties.
Where there is no Tester on board, a Business Analyst needs to pretend there is one (yup, just like creating an imaginary friend, as crazy as that might sound) and take the time to understand what a Tester would look for to test and measure against.
Testers, like Business Analysts, have tool boxes of resources that any Business Analyst should have an awareness of whether a Tester is on board or not.
A Business Analyst needs to proactively ensure their work can be tested without ambiguity and needs to ensure that desired outcomes are clearly declared and are measurable.
There are simple things can be incorporated into analysis that don’t take up a lot of extra time to connect analysis with testing with or without the tester on board. The value in doing it is to reach agreement on what outcomes are going to look like. The value in doing this is obvious, specifically because agreeing what outcomes look like early can be carried forward earlier into the all important useability testing with users for acceptance (setting early expectations) for pre-trialling. Hopefully in doing this the likelihood of the perception of success is optimised.
I’ve witnessed first-hand what happens when a Business Analyst and a Developer both chose to ignore the input of their Tester, who in this case was engaged right at the beginning of a project.
Not only did neither recognise the opportunity afforded them in having the tester onboard early, they both saw fit to deliberately belittle the Tester by rejecting their review and/or contribution into their respective work.
The outcome was savage. There was only ever going to be one ‘winner’ given the confrontation that developed, and who ultimately had the power of veto, which neither the Business Analyst or Developer had figured out.
For his part, the Developer simply snubbed the Tester and would not talk with him. The result was predictable. Their code was rejected as it failed to work in accordance with the stated outcomes desired, and had to be re-written.
As for the Business Analyst who prided himself in getting through the work without issue (who proactively engaged with, and actively listened to, stakeholders, and who empathised with users, and carried a solid understanding of the business needs) decided to ignore the review and contributions of the Tester as well and failed to incorporate any of their input into their analysis.
The rationale for ignoring the Tester I believe was that the Business Analyst thought they knew the business and therefore was not going to be told by a Tester to amend their work.
Trouble is (and to their utter amazement) the Tester did not sign-off their deliverables as being able to be tested. The requirements were not measurable, they lacked clarity and were without clear target outcomes; and so it went on. The upshot was that the analysis, without being traceable from end to end on what was a large and complex solution, had to be re-written to better provide what Testers needed to do their work, and to support promises made in the business case which otherwise were unable to be validated or verified.
Both the Developer and Business Analyst were seen to have ‘failed’. The code was wrong, and the deliverables were late. Had the Developer and Business Analyst worked pro-actively with their Tester, and reached a meeting of the minds as early as possible, so much waste (i.e. overspend and longer timeframe) would have been avoided and the deliverables would have included missing content valuable to ensuring the solution would provide what was being asked for.
So while Business Analysts may be the pivot in a Project Team, and nurture plenty of allies around them, it is the Tester who is a Business Analyst’s best friend. They go hand in hand – joined at the hip – so be involved with the Tester (or your imaginary Tester in the absence of a real one) as early as possible, and incorporate what they need without prejudice.
Embrace their knowledge and their expertise into your work and the quality of your analysis deliverables and the resultant business solutions will improve through the roof.
In my mind, the Tester has always been a Business Analyst’s best friend. Snuggle up to them where you can.
Powered by Facebook Comments