Building a Mature Business Analyst Practice: Interview with Mark Jenkins

Mark Jenkins and I had the opportunity to chat a few months back while he was Manager, Business Analysis at Websense. He has since taken on a new role on the other side of the country as Associate Director, Business Analysis at KPMG. We initiated a conversation as the result of a Twitter stream [follow Mark on Twitter] about learning and social networks as part of the business analyst’s professional development, but it quickly became clear to me that Mark had a lot more to share. Mark had great ideas to share about being a business analyst manager, building a mature business analysis practice and elevating the role of the business analyst within an organization.

Laura: We started this conversation because you tweeted about a “learning network” and how you encouraged your BAs to be building one. Can you explain to me what you meant by that?

Mark: I learned the term “learning network” from my girlfriend’s educational technology professor who called it a “PLN – Personal Learning Network”. Essentially it means that you build a network of resources and people and bring their ideas into your organization. When I took on the management role in my BA group, I challenged them to first look and see what was out there. I challenged them to bring new ideas to the table about how we could improve our BA practice. There is so much business analysis knowledge available. There was really no need to start from scratch.

Laura: That makes good sense. I was recently speaking with a BA team lead Kym Byron and she made a parallel comment. She said that if a BA does not experience what the role is like outside their organization, their perspective of the role can become very limited. The learning network seems to be a good force to counteract that.

Mark: Exactly.

Laura: Tell me a bit more about your team.

Mark: In addition to project work, business analysts on my team have a business relationship management role. This means that 25% of their time is spent managing IT relationships within a department. They work with business stakeholders from a department on project proposals, business processes, and ideas related to technology. When we can, we assign BAs to the projects for that department, but this is not always possible.

As a BA moving from department to department on different project assignments, one of the challenges I faced was getting back up to speed on an aspect of the business domain. By maintaining continuity and developing an ongoing, consultative relationship the BA stays abreast of what’s going on in a department in the absence of active project work with that department. In my experience, it also allows the BA to move beyond being regarded solely in a project sense and more as a consultant or advisor. It also really helps maintain a solid relationship between the business domains. With a team of BAs acting as a “corporate CIA”, colleagues can alert their designated department of potential downstream impacts from the actions taken within another department.

Laura: That sounds like a great role for your business analysts. How did you justify the resource commitment to your management?

Mark: It was actually fairly easy to justify. The project managers used to have the role, but they were more focused on activities they could manage. So it was easy to bring this responsibility within the BA group. Stakeholders truly value the relationship and my manager gets good feedback from people at his level as well. This justifies the commitment long-term.

Laura: What other improvements did you make within your BA practice?

Mark: The first thing we did was build a requirements process. In the past, each BA tended to do things their own way, with an inconsistent approach and documentation formats.  Stakeholders, as a result, were seeing different documents at different times and the requirements process was taking longer than it needed to. To help resolve this, we focused on building requirements, process, and planning templates that supported our standardized process.

Another challenge we had was giving management and stakeholders input in the early part of the requirements process. In the past, analysts would go into a hole for a month or more and emerge with a requirements document. IT management was not getting feedback and the business users were missing the big picture. So we began to separate requirements and analysis. After 2-3 weeks of discovery, the BA would present the project findings to the larger group, often in the form of high level business requirements and process flows. This happened before the detailed requirements were written. This allowed stakeholders across the organization to redirect the project if necessary and provided a good turning point for the project manager to get involved and start actively managing the project execution.

Laura: It sounds like your team is in a great place. I am sure they will miss you. Good luck in your next venture. Thank you very much for your time today.

Mark: Thanks Laura, I really enjoyed talking with you. One of the things I love most about the BA community is the willingness to share ideas and work together to improve what we do. I think this is a really exciting time to be a BA!

>>DefineYour Business Analyst Process

Join us for the BA Essentials Master Class. You’ll learn a step-by-step business process that you can customize to meet your organization and project situations.

Click here to learn more about the BA Essentials Master Class