Prototyping for Business Analysts: Q&A with Aaron Whittenberger

How prototyping helps streamline software development lifecycles, according to Bluegrass IIBA’s Aaron Whittenberger

In this week’s Q&A, Justinmind is talking to Enterprise Business Analyst Aaron Whittenberger. Aaron has almost 30 years’ worth of tech and IT experience, 15 of those as a Business Analyst, so we thought he’d be the perfect guy to answer all our questions about how prototyping can help BAs do their job more effectively.

But that’s not the only reason we interviewed Aaron. In his spare time he’s also Vice President of Professional Development in the Bluegrass IIBA Chapter way down in Kentucky. Check out Aaron’s tips on requirements management, streamlining software development lifecycles and overcoming his biggest BA challenges.

What made you pursue a career as a business analyst?

I started my career in accounting.  After a couple years of being a Corporate Accountant, the CFO of the company noticed I enjoyed working with the computers so when they decided to go to a midrange computer system they asked me to head up the project.

After two years of getting the company up on the new computer system, management wanted reports that weren’t available in the system.  So I learned programming to provide those reports.

After a 20 year programming career – some as an internal employee, some as a consultant – the consulting firm I was with gave me the opportunity to attend a Business Analyst Boot Camp training class.  So I researched what it means to be a business analyst (what does a business analyst do, what is their role in the organization) and that ignited a passion within me.

So I started to drive my career in that direction.

What’s your average day like as Business Analyst at Cincinnati Insurance Companies?

Currently, I am juggling three projects; fortunately, they’re in different stages of the project lifecycle.  One project is deep in the development stage and I support the development and quality assurance testing efforts.

The second project is ending the analysis phase and about to start development.  So I am finishing up requirements, working with business and technical team members to ensure we have all requirements and full understanding of our future state.

The third project just started the analysis phase.  It is a third-party package implementation.  We did an RFP process and are now in vendor selection.

Here at CIC we have a BA Center of Excellence (BACoE), and I am involved in developing standards, best practices and internal education for our BA community.  So I work with some of our more seasoned business analysts to define how we wish to deliver our business analysis services to our enterprise.

Where do you fit into the design-development team structure?

I am the collaborator.  I lead the design effort. We have Enterprise and Business Architects that have great input in the design, as well as developers and other business and technical team members.  I bring the people to the table and bring out their opinions on the design.

Then if that design is handed off to a developer who was not involved in the design process it is my job to ensure that developer sees that design the same way as those who built the design.

Can you tell us about your requirements elicitation and management techniques?

Requirements elicitation is done on a project-by-project, situation-by-situation basis.  I can use any of the 50 techniques in the BABOK^® Guide.  I almost always use requirements workshops or interviews, but have used brainstorming, observation, data modeling and prototyping, and others.

How do you use prototyping tools? What makes a prototyping tool BA friendly?

I personally use prototyping in a couple of different ways.  In designing a new UI I develop a prototype of that UI to give the stakeholders (business and technical) a picture of what we are designing.  In that designing process I use the prototype as a communication tool.  I continually modify the prototype as we uncover new requirements for the UI from the business team.

Then I use the prototype to communicate the business requirements and desires to the technical team to build the new UI.

I have also used a prototype as a proof of concept.  This is sometimes building a semi-working prototype of a new interface to prove that it can work the way the project team desires.  This can be used to gain approval to move the project onward.

As for making prototyping tools more useful for BAs, anything that helps the communication value through the prototyping process makes the tool useful.  The more intuitive a tool is to both the business analyst and the stakeholders that create the prototype increases the value of the prototyping tool.

What’s your biggest challenge as a BA and how do you overcome it?

There are a few different perspectives from which I can answer that question.  For me personally, here at Cincinnati Insurance we have been working to make the project manager, business analyst and architect as a three-person leadership team on every project.  All three persons are assigned to the project at the same time, early in the inception phase of the project.

This is very different than even two years ago.  Even though we have this perspective there have been meetings that I should have been involved in to which I was not invited.  These are meetings in which that design or requirements for the project may change.  So ensuring that the whole project team knows when the BA should be involved in activities and tasks is sometimes a challenge.

From a global BA community perspective, I certainly would like to see more BAs rolling into that Strategic BA role within organizations. We as BAs need to articulate to business decision makers the value of putting BAs in that strategic role…how that will help the organization achieve its strategic goals.

What are your tips for getting clients and developers to see eye to eye?

A picture is worth a thousand words!  A diagram or prototype helps ensure that everyone sees the same picture, and can speed up the design phase of the work effort.

When there is difference of opinion, the business analyst needs to understand the conflict, all the points of view, the points of contention, and then try to get each person to understand the other points of view in the discussion.

You’ve been in software development for almost 30 years? How have things changed for BAs over that period?

Well 30 years ago there wasn’t the role or even the concept of business analyst.  The first time I ever worked with someone with the Business Analyst job title was in the very early 2000s.  He got involved in projects at the end to test solutions or enhancements before they were promoted to the production environment.

In the early stages of the development of the discipline we saw organizations utilize business analysts very differently.  We still see that today, but not as widely as even five years ago.  Today, business analysts are reaching into that strategic role of assisting organizations achieve their strategic goals.

Can you tell us about your involvement with Bluegrass IIBA Chapter and why you guys chose to work with Justinmind on a webinar?

I am Vice President of Professional Development for the Chapter.  I organize the educational programs for the chapter.  I am on the Board of Directors, who determine the strategic direction and look after the sustainability of the Chapter. Xavi, your President, reached out to our President, Terry Sundy, with a relationship proposal.  We investigated your company and prototyping tool.

We clarified the proposal with Xavi and Victor.  Realizing the prototyping is right up the wheel-house of the business analyst; and business analysts, yours truly included, rely on prototyping quite often in delivering business analysis services to their clients, it was a natural fit for us to introduce your tool to our community.