Author: Aaron Whittenberger

‘Twas the Night before Implementation

Written by Aaron Whittenberger on December 21, 2022. Posted in Articles.

‘Twas the night before implementation and all through the warehouse

not a program was working, not even a browse.

The programmers hung by their screens in such despair,

with hopes that soon, a miracle would be there.

The users were nestled all snug in their beds,
while visions of working systems danced in their heads.

When out in the snow there arose such a clatter,

I sprang from my desk to see what was the matter.

Away to the window I flew in a flash,

tore open the shutter, and threw up the sash.

And what to my wondering eyes would appear,

but a Senior Business Analyst with a six-pack of beer.

His resume glowed with experience so dear,

I knew in a moment; the miracle was here!

More rapid than the programmers could consume, his requirements they came,

and he shouted and clamored and called them all by name:

“Now Update! Now Inquiry!

Now, Create and Delete!

On Batch Job! On Interface!

On, Closing and Functions Complete!

To this programmer! and to that programmer!

Now code away! Code away!

Code away all!”

He was dressed in a tux, from his head to his foot,

and his clothes were bright, all glowing and afoot.

His eyes—how they shined! Fingers nimble and lean,

from weeks and weeks in front of the screen.

His cute little mouth was drawn up in a smile,

and his hair, every strand in place as he worked a mile.

He stopped only to take a swig of his beer,

as the work ahead circled in the atmosphere.

He worked so fast, and smiled aware of his self,

and I looked upon his work with dismay, in spite of myself.

A wink of his eye and a twitch of his head,

soon gave me to know I had nothing to dread.

He spoke not a word, but went straight to work in great affair,

turning out specs and models with such flair!

And laying his finger upon the “Enter” key,

and giving a wink, the system came to life to a tee!

The updates updated, the deletes deleted,

the inquires inquired and the functions completed!

The testers tested each whistle, and tested each bell

with nary an abend, all had gone well!

The system was finished, the tests were concluded,

the users’ last changes were even included.

And the client exclaimed with a snarl and taunted,

“That’s not what I asked for, but exactly what I wanted!”

–Aaron Whittenberger

Business Analysts…Quit Asking Questions

Written by Aaron Whittenberger on January 22, 2019. Posted in Articles.

I won’t take full credit for this article, as I got a reminder while reading an IIBA Whitepaper authored by Kupe Kupersmith on Empathizing with the Real Customer.

In his whitepaper, Kupe proposes a few newer, non-traditional elicitation techniques, not covered in the BABOK®, business analysts should work into their BA toolkit…one of which is Story Prompts.

What Are Story Prompts?

Story Prompts is an elicitation technique used as an alternative to asking a series of clarifying questions or the 5-Why technique. Instead of questions, prompt your stakeholder to tell you a story about…

As a business analyst you are taught to ask a lot of questions; however, there is a time and place for asking a lot of questions and a time to listen to a story. There is a tendency for stakeholders to feel that you are controlling the conversation when you ask a series of questions; have them follow your train of thought. As an alternative, allow the stakeholder to tell their story in their words and in their train of thought. This may help you to better understand the needs, desires, pains and wants of your stakeholders.

In the whitepaper, Kupe sites the book Business Storytelling for Dummies by Lori L. Silverman and Karen Dietz, PhD:
“Story Prompts have two parts: the front end of the statement and the closing to the statement. The front end starts with a phrase such as, ‘Tell me about. . . ‘. With certain individuals, it may help to say, ‘Tell me about a time when. . .’, or “Tell me about an experience with…”. The word ‘about’ is key in this statement. If you leave it out, all you’re doing is turning a question into a statement (as in Tell me how you . . . or Tell me what you . . .).”

“The closing portion of a Story Prompt is as critical as the front piece of the statement. Avoid being general. Phrase it in such a way that the person recollects only one or a few memories. This will make it easier for the person to select a story to share with you. For example, instead of saying, “Tell me about that new project you’re working on”, rephrase it as “Tell me about an unforgettable situation that happened to you recently on that new project you’re working on.”

When to Use Story Prompts

There really isn’t a bad time to use Story Prompts. It may be most useful during the early stages of an initiative when definition around the true problem is still vague. Stakeholders may be discussing the solution rather than the problem we are trying to solve or the desired outcome. Then you may want to try “tell me about how you concluded we need that solution.” Or if no solution is being discussed yet, try “tell me about how this problem was identified.”

Making it Work

The key is to listen intently once you have prompted your stakeholder for their story. There are two things different about listening to stories and asking questions:

Focus on listening to the story, not taking notes. This may go against your natural instincts as a business analyst, but can you recall any great stories your grandmother told? Did you take detailed notes while she was telling her story? I am guessing not. It is amazing how much you remember by just sitting and listening to a story. You can write down detailed notes after the stakeholder has left.
Never interrupt. Again, this may go against your natural business analyst instincts; but let the stakeholder tell the story in their words, without interruption. If you are listening well you will remember the important details of the story. Later, you can determine any follow-up questions you want to ask and schedule a follow-up session with the person.

Conclusion

There is still a time and place for asking a series of questions or using the 5-Why technique. However, every once in a while, try prompting your stakeholder for their story instead of asking a lot of questions. It is a way to show the person that you value them and their point of view. Prompt your stakeholder to tell their story…hard telling what you may learn.

The Power of a Deadline

Written by Aaron Whittenberger on August 9, 2018. Posted in Articles. 2 Comments on The Power of a Deadline

History has proven that there is nothing as powerful as a steadfast deadline to get people to accomplish a goal.

The most famous steadfast deadline in recent history was Y2K (year 2000). Midnight, January 1, 2000 was coming on time whether you wanted it to or not, whether world-wide systems were ready for it or not. No matter what role you played in the software development life cycle (SDLC); business analysts, project managers, testers, but especially developers knew that systems would not work in the new millennia due to the six-digit date embedded in most systems. SDLC professionals also knew Y2K was on the horizon and it was up to them to get systems Y2K compliant. The fear was that people would get stuck in elevators, hospital systems would stop working correctly, and government services would discontinue to be delivered. However, if you remember January 1, 2000, the stock market did not come crashing down; and businesses around the world continued to bill customers, order material, manufacture their products and pay their employees. SDLC professionals got systems ready in time.

Take this life lesson to your goal of obtaining your IIBA® certification. As soon as you are approved to sit for the exam, schedule your exam date; translated to mean set your deadline. Now you know when you have to be ready to take that exam, so make a plan to be ready.

How much time you need to get ready depends on how much of a priority in your life you will make this goal. If you are single and have no other life commitments, then you can devote a lot of time daily to studying. If you are married and a parent, then can your spouse take some of your family commitments for a short time to give you more time to study? This helps you determine whether you need three months, twelve months or some time in between to prepare for the exam.

Another element of your plan should be what method of study will you use to prepare for the exam. IIBA chapter study groups and Endorsed Education Provider (EEP®) courses are popular ways to prepare for the exam; however, some prefer self-study. Whichever study method you plan to use, put it and the time needed in your plan.

I speak from experience, back in 2008 I was fortunate to be with a consulting firm that sent me to an EEP Business Analysis Boot Camp class. Upon research, I knew this was the direction I wanted to drive my career, so I made obtaining my CBAP® certification a priority. I prepared my CBAP application and had our administrative assistant mail it to IIBA as I was sitting in the final day of the boot camp class (yes, this was back in the day before online application). When I was approved to sit for the exam, I immediately set my date. This was also back in the day before computer-based testing; my options were to go to Louisville, KY to take the paper test, or wait until computer-based testing became available in six months. I opted for computer-based testing and set my date for September 8, 2008. I had study material, from class and other material I found, to keep myself immersed in the material for that six months.

As you can see from the letters following my name, this was an effective plan for me. I highly recommend to everyone who wishes to obtain IIBA certification: 1) make a plan to achieve this goal, and 2) set your date as soon as your application is approved.

CBAP® Gave Me a New Career!

Written by Aaron Whittenberger on March 30, 2017. Posted in Articles. 2 Comments on CBAP® Gave Me a New Career!

Did you know that you could be a Certified Business Analysis Professional™ (CBAP®) before being a Business Analyst? Would you like to know how I did it?

Like most business analysts I had a career before my business analyst career. Like some of those business analysts, I came up the developer career path.

I actually started my career in Accounting, which is what I have my degrees in. After three years of being a Corporate Accountant, my manager (the Chief Financial Officer) noticed that I liked working with the company’s computers. So when they decided to go to an IBM midrange system, he asked me to head up the project.

I spent the next two years learning a new computer system, learning a new software package, writing a training manual; and then I traveled to eight locations to install computer equipment and train each location’s staff on the new system and software. When that was all done, management wanted some reports that were not available in the system; so I learned to program.

Now fast forward several years in a successful programming career encompassing a few internal and consulting positions. In 2008, I found myself with a great small consulting firm, and in an industry that was rapidly drying up. This wasn’t anything new; I had been through a couple of dry spells in the industry, where new clients or programming jobs were hard to find.

This consulting firm gave me the opportunity to attend a Business Analyst Boot Camp class offered by ASPE Training. Now to this time in my career I had worked in only one company in which I worked as a business analyst. That business analyst had tested changes to applications before they were promoted to the production environment. In fact, in that company when the largest system enhancement project came along I was named the project manager. As the project manager, I facilitated meetings with stakeholders all over the country to discuss their requirements for the system enhancement…with the business analyst sitting in the room.

So you can imagine when I was told I would be going to a business analyst boot camp class that my impression of a business analyst was what we consider today as a quality assurance tester. I will also point out that I have to this point in my career have never held the job title “Business Analyst,” or any derivation of that job title. However, being the naturally curious person that I am, I decided to confirm my understanding of business analysis by researching what it means to be a business analyst. My research uncovered what a business analyst really is supposed to do: perform the tasks, techniques, and skills of business analysis.

“It’s not who I am underneath; it’s what I do that defines me.”
Batman (in the movie Batman Begins)

Now, remember, I had not ever held the job title “Business Analyst.” I had been a “Programmer/Analyst” or “Team Lead,” but never a “Business Analyst”…well at least not in name. As I continued to read and research, I kept saying to myself “I have done this stuff most of my career.”

My research led me to the International Institute of Business Analysis (IIBA®), where I learned more about what it means to be a business analyst. Then I learned about the Certified Business Analyst Professional™ (CBAP®) certification designation. Seeing that it required 7,500 hours of business analysis experience, it was now time to start documenting my career. I was fortunate that a great deal of my career was as a consultant, so I had old time sheets that helped jog my memory on what I was doing each year. Those times that I was an internal employee, I had artifacts that I had written that jogged my memory and allowed me to put work experience in proper time frames. I was able to go back nine years in my career and document 9,000 hours of business analysis experience. I put all 9,000 hours on my CBAP application; I was daring IIBA to reduce my hours enough that I wouldn’t qualify for the certification. The one thing I needed to qualify for the CBAP certification was 21 Professional Development Hours, which the business analyst boot camp class would give me. Now you had to be qualified for the certification before you could apply for it. So I put my application together, included all the work experience documentation, got my two references in sealed envelopes (that is the way we did it back then), sealed it all up, addressed it to IIBA, and sat it on our Administrative Assistant’s desk with instructions to mail it on Friday. So on the final day of class, while I was finishing getting qualified for the certification the package was on its way to IIBA. I waited six months to be one of the first to take the CBAP exam on a new computer-based testing platform.

At this point, I had not held the job title “Business Analyst.” Realizing that just obtaining the CBAP certification would not make me “sellable” as a business analyst, I then looked at my resume. I rewrote my resume highlighting tasks when I collaborated with stakeholders. That time that I facilitated requirement elicitation sessions (as a project manager) for a large system enhancement is the type of work experience I highlighted. Even though I highlighted my analysis work experience on my resume, the CBAP certification really proved to prospective clients that I had the business analysis experience. This allowed the consulting firm to get me “gigs” as a business analyst instead of a programmer.

My research into business analysis showed me what it meant to be a business analyst. I knew from that research that this was the direction that I wanted to drive my career. Obtaining the CBAP made that transition easier and quicker. I only had a couple more “gigs” as a programmer after attending the business analyst boot camp class and obtaining the certification.

Using Scope Models to Manage Solution Scope

Written by Aaron Whittenberger on August 17, 2016. Posted in Articles. 1 Comment on Using Scope Models to Manage Solution Scope

Organizations launch change initiatives (projects) for the purpose of delivering a benefit to the organization.

One thing that may cause those change initiatives not to deliver those expected benefits is scope creep. Scope creep is the unexpected and uncontrolled expansion of a project’s scope. This can occur when the scope of a project is not properly defined, documented, or controlled. Scope creep generally negatively impacts the project’s budget and/or schedule. Increasing project scope can also increase solution scope.

One way of defining and documenting solution scope is by the use of scope models. I do caution that this is not the only way of documenting solution scope, and multiple ways of defining and documenting scope should be used for every change initiative undertaken. Solution scope should be defined and documented in the way that allows the project stakeholders to understand the scope. Scope Models should create a shared vision of the solution scope amongst the stakeholders.
I am going to show you six scope models I use. There are definitely more models that can be used as scope models, but I find these to be the ones I use the most. Which models you use depends on the type of change initiative you are undertaking and what will describe the solution scope to the stakeholders the best.

Related Article: Using Feature Trees to Depict Scope

A Functional Decomposition depicts a subject and the breakdown of that subject into smaller buckets. This breakdown can be in multiple levels; meaning break down the subject into the highest level components, then break down those components into small components. This can be done to three or four levels. Functional Decomposition can be done on a feature basis or work basis. Using the feature basis, you would take a system and break it down to its highest level functions, as shown below. Using the work basis, you would take a work initiative and break it down to its highest level pieces of work; then break each of those pieces of work down to smaller chunks of work. This is useful to create a work breakdown structure and estimating work effort.

The Context Diagram depicts the system that is under discovery, the focus of your change initiative, and the external entities that interact with that system. These external entities can be systems, databases, websites, or business units (people). This model also identifies the data flowing between the external entities and the system under discovery, and depicts the direction of flow for each piece of data. One limitation of this model is that in only depicts external entities that directly interacts with the system under discovery.

A Process Flow illustrates high-level processes and the entities involved in those processes. A common process flow diagram is called a swimlane diagram. The swimlane diagram shows processes in a row, or lane, entitled by the entity that performs those processes. Several lanes are depicted in a swimlane diagram so that you can see the interactions and dependencies within the process, as shown below.

A Use Case Diagram is a representation of a user’s interaction with a system that shows the relationship between and the different use cases (functions) in which the user is involved. A use case diagram can identify the different types of users of a system and the different functions those users perform using the system.

An Ecosystem Map shows the system under discovery and the systems which send data to or receives data from that system. The major difference between this model and a context diagram is that the ecosystem map will show systems that do not interact directly with the system under discovery; that is upstream and downstream systems. As shown below, a website order entry system sends the customer order to the order fulfillment system, which sends product data to inventory system and purchasing system. The inventory system sends the inventory transactions to the accounting system. The accounting system also receives purchasing transactions from the purchasing system. Even though the order fulfillment system doesn’t interact directly with the accounting system they are both exist in the ecosystem; and therefore, are shown on the ecosystem map. The system(s) under discovery will be shown with a bolder outline than the other systems in the ecosystem map.

The Feature Tree is a fishbone diagram showing the features within the system. Much like the functional decomposition, the feature tree breaks higher level features into lower level features. Level 1 (L1) features are the highest level features and branch off the horizontal line of the diagram. Level 2 (L2) features are lower level features which branch off the L1 features. There is no reason to go beyond three levels of features. You can use color coding of the features to show what is in scope, out of scope or features in future releases. This is an excellent model to show executives, as it is a very easy picture that allows for a very quick understanding of the features being looked into.

It may be necessary to use multiple scope models to ensure that all stakeholders understand the solution scope of the change initiative. By using these scope models, as changes to scope are suggested you can determine if the change being requested is within the model. If it is not, you can caution the stakeholders that this may cause scope creep that will impact the project scheduled and/or budget.