Behavior for Internal vs. External Customers
Mentoring my first BA apprentice this year has been challenging and extremely rewarding. It’s provided me with a great sense of achievement but also a renewed love of the craft, I highly recommend it for ‘old hats’ like myself.
Some of the questions an apprentice asks are eye-opening since they are coming from an ‘education first’ posture, and as a mentor, you get to help them put what they’ve learned into practice. As I’m primarily self-taught and only certified four years ago, I’m sometimes taken aback that I’d never asked these questions myself but thinking through the questions I’m thrilled to find I usually know the answer.
For most BA-related questions though, the answer usually starts with, IT DEPENDS.
Also, the BA craft is an art, not a science, and an important trait a BA builds is FLEXIBILITY. Their behavior should change based on whom they are dealing with, and the stage the project is in.
As an IT BA, everyone is a customer, but we need to treat internal and external customers differently, based on the relationships we’ve built with them. If you’ve repeatedly worked with an internal business partner from IT or another part of the organization, your interactions with them can be informal and somewhat friendly, while remaining professional. Interactions with ‘new’ internal business partners should be professional first, and friendly but formal until you’ve proven you can deliver. Trust is earned, not given, playground rules apply.
Turning this idea around for external customers, in my company’s case product vendors, an IT BA should expect to be treated like a customer, as they help ‘guard the gate’ for their internal business partner during product justification, selection, and sometimes implementation project phases. They need to be the product manager in order to evaluate solutions against requirements, arrange for vendor demos, and justify the purchase of new solutions. This can also mean assisting in the delivery of functionality, standing in the business partners’ shoes initially, and ensuring quality and acceptance of the solution.
In essence, IT and business partners ‘subcontract’ product evaluation and selection to the IT BA, who must always act in everyone’s best interest, within existing IT constraints. It’s a complicated dance, while the IT BA needs to be the main vendor point of contact throughout product selection and possibly delivery, they often also need to assist with negotiations for all stakeholders to reach a consensus. This is doubly true if they are also involved in testing. I like to call this zone Switzerland.
I recently helped select a solution provider based on a solid match to our requirements, however, once the contract was signed, we found that there were slight changes to the product that made it a less desirable choice. Partnering with the internal business customer, we successfully negotiated with the vendor to use the original version of the product for delivery, understanding that while they would continue to support this version, future functionality enhancements would only be applied to the new version of the tool. This vendor had tried to take control of delivery early on, attempting to require us to submit to their implementation script, but slowly understood that we needed to be in charge due to extreme resource constraints. As a result, our initial communications were short and sweet, this was how it needed to happen, and they grudgingly complied. By the time we started testing the new application with live data, however, we’d become a team.
Seasoned BA’s can pull this off effortlessly, while a newer BA, especially an apprentice, needs guidance and practice to build the confidence they need to be successful. I think this is true for both waterfall and agile methodologies, I hope this helps.