Skip to main content

Author: Jeannette Olson

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.

 

Advertisement

 

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.

RISE – Requirements Improve Solution Effectiveness

Prior to coming on-board as an application analyst at GLWA, I would spend 20+ years helping organizations define requirement strategies and requirements for applications that we built. 

Now that I have “driven” out of the automotive industry and “dove” into the wonderful world of Waste Water Recovery where solutions are predominantly purchased, I’m finding that teams report on similar problems with their procured applications. 

Requirements elicitation is, as often as not, treated as a necessary evil. Stakeholders feel forced to spend time completing this work upfront to check off a task on a project plan. The work is treated as though it was not important enough to impact the design, development, test, and launch activities and timeline. 

One can imagine the results of elicitation are often mixed at best, as unpredictable as throwing a handful of candy up in the air in front of a group of kindergarteners; you never know what you’re going to get.  Finger pointing ensues, with quite a few internal and external bruises to show for it. 

We don’t plan to do it right, but we have time and money to do it twice?
~anonymous


Advertisement

Some common problems with lack of solid requirement processes are:    
 

BUILD

BUY

  • Missing requirements
  • Requirements not matching test cases
  •  Design, Build and Test rework
  • Support problems
  • Customer dissatisfaction
  • Missing functionality
  • Functionality not matching test cases
  • Implementation rework
  • Support problems
  • Customer dissatisfaction

 

When a company builds an application off of the results of a poorly defined requirements process, costly issues are quickly resolved regardless of the implementation methodology used (waterfall or agile) –  blame is assigned and money is found to address the issues raised.

However, when a company buys a solution, the situation is quite different as there is a total reliance on the product vendor and their development path. In some of the worse cases, the organization has to start the vendor selection process over completely when the solution fails to address the needs.  More than the budget can be damaged in these cases. 

The risks are arguably greater when purchasing vs. building an application, but the underlying fault in both cases is frequently the same.

Too often solutions are determined prior to understanding Business Requirements

For both built and purchased applications, project initiation often happens before discovery, putting the cart before the horse.  Would an architect allow construction to begin on a building before every plan was drawn, reviewed, and approved?  No, but often companies are influenced by what they are familiar with, such as the applications employees have used in the past or by what an employee hears is the next best tool/toy.  In the world of purchased applications, companies often select the design/tool and then attempt to make their business needs fit the solution.  They want the requirement process to be quick and easy, but they are really just setting themselves up for disappointment. 

Making a conscience effort to elicit requirements prior to selecting a solution enables identification of the following:

  • Problems to be solved
  • True business needs
  • Organizational impacts
  • Goals and objectives
  • CARD considerations (Constraints, Assumptions, Risks, Dependencies)
  • Feasibility
  • Cost

Requirements, for applications both built and purchased, should feed the business case, which in turn informs the purchase, contracts, project charter, project plan, test plan, test cases, implementation, and project closure needs.  When requirements come first, the rest of the project deliverables are executed more smoothly, with fewer errors and increased customer satisfaction.  Reduced rework and lower cost positively impact a company’s budget and resources, but more importantly improves its ability to address other business problems within the organization faster.

 

Quality requirements enable IT to focus more on project delivery and support, which in turn nurtures IT/Business and customer partnerships.

Guiding an organization toward a more efficient requirements process does not happen overnight.  The IT PMO, working hand-in-hand with IT and the business customers can get us there given enough support, time, and patience introducing:

  • A defined project intake process (with full Business Requirements)
  • Accepted elicitation techniques (process flows, use cases, etc.)
  • Accountability for requirements through the procurement and project management lifecycles
  • The use of tools, such as an enterprise requirements management tool to facilitate ongoing collaboration on the requirements

In short, Requirements Improve Solution Effectiveness, therefore RISE to the Occasion!