BAs: What is the Most Important Relationship you Have?

In all of our business analysis training classes, we usually cover the importance of relationships in doing BA work. They are key to us delivering products that the business values and can put to use.

Quick – which is the most important relationship you have in your work as a BA? The PM or Scrum master? Perhaps, since this is an important relationship to be sure. But not the most important. Your sponsor? Maybe if you are a PM, but not as a BA. And the same goes for any one end-user. Granted, without a good relationship with the business, a BA will not elicit complete business needs and requirements. But, none of these is as important a relationship as you must have with the developer or development team for your project.

Why? It is because so much gets lost in translation when requirements get turned into code. It could be when an app or program is designed. Or when coding starts and problems surface that developers must solve such as technical constraints that affect functionality. If communication suffers or is not regular, then developers are forced to guess at solutions. Often those guesses are wrong. Two recent projects convinced me of the importance of the business analyst and developer relationship.

Painful Example

As an example, during development of our internal Training Management System, we did not hold regular stand-ups with our developer. (That was a constraint of the fixed-bid contract we signed and is not a mistake we’ll make again.) As a result the developer made several decisions for us that we had no idea he was making. He was eventually fired by the company he worked for and replaced with a more responsive and capable tech. When we started testing we discovered many but not all of these decisions and the replacement developer fixed the problems he could.

We only discovered some obscure but impactful issues after going live and had to fashion work-arounds for them. Some we have since fixed, but we are still living with a few of the work-arounds 1.5 years after implementation. They are not code defects which the development company fixed under their warranty. They are functional, business-oriented problems we have with the system. Because of the fixed-bid contract, the system is more COTS than custom. However, a few features of the system that were customized are where we have concerns with the system. Better communication would have solved that. A better relationship between the business analyst and developer would have led to better communication (which we now have I’m glad to say). Still, it was a painful, expensive lesson.

Better Example

A more productive example to offer is based on the development of our Online Study Exam System. After exploring SaaS options for online exam simulators, we found them all lacking. So we decided to build our own and are immensely glad of it. Our exam interface more closely matches the real CBAP and Project Management Professional (PMP)® exams. And, we give explanations to both incorrect as well as correct answers, which the SaaS options at the time could not provide.

I served as the BA on the project and worked with a single developer, a friend of mine named Chuck to build it. We already had a good relationship so it was easy to bounce ideas off one another. We had daily stand-ups for each iteration of the product, which took us roughly three months for our “minimum viable product.” It would have been faster had Chuck and I devoted full time to our sprints, but we couldn’t afford it. (I know, a common Scrum-but.”)

Neither of us was afraid to challenge the other, which made a better product. Chuck was intellectually interested in the system we were building. If he hadn’t been I was prepared to educate him on its importance. My user stories made sense to him. But, my use cases were not getting me very far with him, so I learned early on to use visual prototypes for the screens. An Entity Relationship Diagram I developed was hugely important to communicate the data requirements to Chuck. It was that or face the reality that he would treat any written requirements superficially. Those prototypes became essentially “logical designs” of what we needed and gave Chuck the insight he needed to build the right product. Being able to quickly prototype using PowerPoint was a must for me. As were the daily standups we had to discuss the intent and purpose of our requirements.

The written requirements were not completely wasted I am glad to say (even though they were wasted with Chuck). I was able to turn them into acceptance criteria which helped with user acceptance testing. The outcome of the project was a success and we still communicate with prototypes for enhancements and new features. In fact, a recent conversation we had was what prompted me to write this.

Conclusions

While it is essential for a BA to have good relationships with business stakeholders, it is imperative to have a good relationship with developers. We need to:

• Work on building a relationship with developers. For example, go to lunch or coffee, share personal information, and show interest in them.
• Discover how technical staff want our requirements or design inputs and then adapt our outputs to best communicate with them. Work towards using visual renditions of requirements rather than lengthy written documentation.
• Educate our developers on business needs so they understand the intent on what is being built.
• Participate in daily standups, whether or not using a Scrum approach.
• Get advice from them on ramifications of requirements or design decisions. I always ask Chuck how difficult or complex a certain feature is before assessing whether to adopt it or not.
• Show courage and challenge developers when they say it is too difficult or complex to do what the business wants. Seek to find alternatives. Don’t be afraid to ask questions like “you are not hard-coding that are you? (That in itself may be the source of another blog.)
• Stand up for your logical models, such as a normalized ERD. Know the difference between a logical design construct and a physical one.
• Be prepared for work-arounds if you don’t have a close relationship.

What thoughts do you have about the BA-developer relationship? Can you share success or horror stories?