I was recently talking with a project manager who insisted every BA must be a business domain expert. I disagreed, suggesting a strong BA can learn the business by asking the right questions and studying the work. As we discussed this further, he agreed the BA should learn the specifics of the business and doesn’t necessarily need to be hired with industry knowledge. We realized our disagreement was really over WHEN the BA learns the business. For the project manager, he expects the BA to come to the project with the knowledge already in hand. He expects business requirements are already understood and the collecting of requirements (PMBOK® task) will be very straightforward. He does not have money or time in his project budget for the BA to learn the business. He wants the BA to immediately begin the Product or Solution scope and functional requirements.

At another company BAs are also expected to learn the business before their project work begins but when I asked if they are given time outside a project to perform this analysis the answer was no. All of a BA’s time must be allocated to a project. They expect BAs to learn the business in their spare time or on their own time.

I believe these attitudes reflect a lack of understanding of the complexity of our business domains. When an IT manager thinks a BA can learn a business area in his or her spare time, the manager assumes the business processes are simple or straightforward. Very few are. As BAs we need to constantly be educating our management (supervisory and project managers) about the sophistication of our business users and their work. We need to help the IT organization appreciate both the complexity of the business areas and the importance of capturing this complexity in business models. Only our deep understanding of the business will assure our projects deliver true business value.

Learning the business and representing it in business models and requirements is a critical success factor for every project. Business models are reusable, increasing productivity on future projects. They also need to be updated as the business changes. I would recommend an IT cost center for BAs to spend time learning business domains outside projects rather than within the context of a specific project. BAs who spend time with the business people on a regular basis also see opportunities for improvements and may suggest new projects.

When are you given time to learn your business?

I attended a panel discussion on The Developer’s View of the Value of the BA. Daren May from aspenware pointed out several important behaviors of BAs which improve the entire development process. As Brits often do, Daren used a couple of great phrases: BA’s maintain “solution neutrality”, making sure that the business needs are met while being open to various architecture/platform options. He also appreciates the fact that BA’s ask the difficult questions, without alienating anyone and that they are “absorbed in  the culture” of the business so they really understand the impacts of software changes to the business.

Tony Chen of Sielevel gave a great presentation on Agile which included a Lego Helicoper build exercise! He gave each group different requirements and we all saw the various results. My team got a textual description of how to build the helicoper and failed miserably!!

Afternoon sessions included BI, business case development and relationship topics. I am on my way to Day 2 so I’ll write more later . . .