It was during this discussion on business requirements a student asked about requirements to use SAP or Oracle or a certain type of system as a business requirement. The student expressed concern about the requirement coming from the business was one they had to account for in the business requirements document. The actual requirement was something to the effect of “the business requested we use SAP to log payments” Technically, according to the Business Analysis Body Of Knowledge (BABOK), a business requirement is defined as “…higher-level statements of the goals, objectives, or needs of the enterprise…” Based on this definition, the business defining SAP as a requirement does not fit. It is not a goal or objective. The need comes in the reason behind the request to use SAP. It could be the business wants all payments on a central platform because they are experiencing duplicate (and error-filled) data and want to reduce it. But SAP becomes a solution and where it’s really categorized is as a constraint. It’s a limitation imposed upon the solution you create within business analysis to solve the problem or achieve an objective.

I used an example from IKEA to illustrate. There’s a big sign in the store that says the “…designers create the price tag first.” Why? The thought is they constrain the solution to fit into that price target. Their business goal is make the furniture affordable. The price tag constrains the solutions to fit within a certain budget. So IKEA says, “We need to increase our sales of outdoor furniture” as an objective (they will further put metrics to make the objective SMART, but that’s for another blog). The first thing they do is figure out the profitability surrounding an outdoor chair, and then create the price tag. By constraining the price, the designer has to work within the boundaries of the price, and while he/she may want to use the finest Swedish wicker on the chair, that design choice is too costly to fit within the constraint given at the beginning.

So whether it’s a price tag handed over to you, or a limitation on the design, the business may be handing you constraints along the way to which you have to react. While you can certainly question the constraint to understand the motivation or reasons behind it, just understand that a Requirement from the Business is not necessarily a Business Requirement.

I became number 901 in March, 2010. So, by the end of March 2013 I have to reapply. I started looking ahead to figure out what I needed to do in order to meet the qualifications prior to the actual date. Really, my quest for recertification started as soon as I became a CBAP. A great place to start is on the IIBA website, upon which I downloaded the CBAP recertification package. That gave me instructions on what I needed to do.

Reading the handbook, it identified several tasks one needed to do in order to recertify, but the most daunting one was the Continuing Development Units (CDUs). These units ensure that you, as a BA, stay current with your experience and stay up to date on the latest trends. Keeping track of them was going to be another matter. While ultimately they need to be reported in the official CDU reporting form which is submitted to the IIBA, there was nothing that prohibited me from creating my own tracking tool and using it in order to calculate my running totals. And what better tool to use than the BA’s favorite number-crunching tool, Excel.

1. I created the spreadsheet with four columns: the Activity, the Date when I performed the activity, the Category the activity fell under, and finally, the actual CDUs that the activity generated. On the right-hand side of these four columns, I have a running total of the amount of hours applied to each of the categories, as well as the maximum hours I can apply to recertification in each category. You can download and use the spreadsheet for your own use here, CDU Tracking Spreadsheet .
2. Then, as I went about my business analysis life after taking the CBAP exam, each time I performed an activity, I would record the hours and the category under which they fell. This way, I had a running total of my BA activities.

A BA must achieve at least 60 CDUs during the three-year period, so the running total showed me how close I was to attaining my goal. According to the IIBA, you may carry up to 20 CDUs into the next 3-year recertification cycle, but only if they were accumulated in the last year of your 3-year cycle. More information is contained in the handbook. In fact, any questions about recertification and the handbook is the final arbiter.

One final note – the IIBA requires you to keep a personal recertification folder supporting the claims of your CDUs. The spreadsheet helps with that to show the dates and activities performed on those dates, including a contact name. I feel if I am ever audited, I can easily access what I did on a particular date.

On Mar 20, the IIBA accepted my recertification, so you should be good to use the methods I used as well. Please share your stories of recertification and how you went about it!

Consider this: I had just finished teaching the concepts of an ERD (Entity Relationship Diagram) to a group performing business analysis. They even went through and practiced the skills to prove they knew how to relate entities and think through the model. During the debrief, one of the participants said, “Yeah…but so what? We don’t do this around here.” I asked him why they don’t have to deal with data in the organization to better understand his concern. It turns out his team was implementing a COTS (Commercial Off The Shelf) ERP system and the database was already built. Therefore, he had no reason to learn about documenting entities and relationships because he was not involved in the creation of the diagrams. Where the information was relevant was in being able to read the information in order to convey it to his stakeholders (ironically, so he wouldn’t get the “Yeah…but so what?” from them). He needed to know the information about the ERD not so much so he would be able to create one, but he needed to know it in order to be able to read and understand the COTS tool data model.

By being able to understand the data model, he could analyze the data relationships and determine if a business request could be met or not met based on the data model. Then, that understanding could be used to explain it to the business stakeholder giving the business stakeholder the answer to the “so what?” question. Once he understood the relevancy of the ERD for his situation, it became clear why he needed to know it, and that was the “what” answering the “so what?” part of his statement.

When communicating information to your stakeholders, make sure you know the answer in context, that is, how is what you are telling them relevant to their situation or their understanding. Looking at what you are explaining to them from their viewpoint, you are able to explain why they would need to care about something and why it is important.

What situations have you been in when people have responded with “so what?” and you had to switch gears and explain it taking into account its relevancy to your audience?

I was at the Castillo de St Marcos in St Augustine, watching a historical demonstration of 18th-century fort defense. Part of that was cannon, part was infantry. It was the infantry that attracted and piqued my BA skills. The infantrymen gave a demonstration of how they fired their flintlock muskets. The stated time for the entire process was 1 shot fired every 15 seconds. Now keep in mind the soldiers had to: clean the barrel, drop a charge into the musket barrel, ram it in with the ramrod, drop the musket ball into the barrel, fill the flash pan with gunpowder, cock the hammer, aim the weapon, and only then, fire. 15 seconds? I would be lucky if I could do it in one minute. However, the more I looked at it, the more I realized how they looked at the process to improve it.

First, they drilled constantly so the soldiers would not have to think about it. It became “muscle memory” to them. Over and over again. They didn’t think about the processes, they just did it. The correct amount of gunpowder was not estimated, the necessary amount was carefully packed into a paper cartridge which was opened and poured into the barrel at the appropriate time. Same with the musket’s flash pan (which the flint struck to create the spark). The commander would call out the commands, but in most cases, the infantrymen already knew the next step. Why?

Simple. They had made the process repeatable and removed as much inefficiency as possible. Repeatable in that the soldiers knew exactly what needed to be done. One of them fell due to combat? Another knew the drill and could take his place immediately. Efficient? Sure. The soldiers did not have to measure the amount of gunpowder. The measuring had already been done prior to the battle, and the exact amount was packed into cartridges. Efficient and repeatable

When looking at your processes, how can you take what the infantry developed and apply it to your organization? If you concentrate on just the pre-measured powder packets, you can see how they were using those to prevent mistakes. By taking out decisions in the process, you can forget about having to fix errors in the process because you PREVENT errors from happening in the first place. Just like pre-measured gunpowder packets prevented incorrect measurement, error prevention in your processes ensures you don’t have to design a second process to correct them later. Have employees entering expense accounts? Make sure they have a predefined list of categories to choose from, instead of entering them. Instead of having an accounting associate validate the entries later, build in controls that don’t allow incorrect entries to come in during process execution.

Now I’m not saying that your business area is a combat zone, but what can you learn about your processes from the 18th century militia with flintlock muskets?

How has such a great communication tool allowing us to reach across geographical boundaries and time been a major problem for BAs all over? It’s because it has the potential to overload us with information. I’ll give you some successful techniques to manage your email communication. While I can’t say that I am at “inbox zero,” I currently have only 13 email messages in my inbox. 4 are from two weeks ago, 6 from last week, 1 from Sunday, and 2 from yesterday.

Why are there emails from two weeks ago? Because I think I’m going to do something with them. But am I really? This is a time-waster many of us fall victim to every day. We read the email and decide we are going to act on it. But we don’t do something about it just then. We keep it in our inbox as a reminder. Then re-read it later. Then look at it next week and re-re-read it. Then it’s two weeks old and we re-re-re-re-read it.

• Delete your email first. I’m not talking about deleting everything, but if you arrive in the morning, and there are 50 unread email messages, there are probably some that you don’t have to do anything with. Stores sending you sale links, notifications that so-and-so wants you to be their friend on Facebook, and someone retweeted a Twitter message. You don’t have to act on any of those things. Get rid of them, including the one from Nigeria wanting to share millions of dollars with you provided you send a small start-up fee.
• Let your computer do the work. This springboards onto what was mentioned in the previous bullet point. If you are getting inundated from Twitter notifications, create a rule on your computer to delete those message upon receipt. It’s one more email stream you don’t have to manage. If you’re active on Twitter, or Facebook, or Linkedin, you’re going to see those notifications anyway when you navigate to the site.
• If you are not going to deal with the email immediately, file it in a “to-do” folder. You can go back when you have time to the ToDo folder and complete some of those tasks. If it’s critical, you have to deal with it immediately, but if it’s not, why store it among the incoming messages in the inbox.
• Use a Two-Minute rule. This is an interesting technique I read about and adopted. If it will take you less than two-minutes to deal with the email RIGHT NOW, do it. Then get rid of it. You have acted on the email and now you don’t have to worry about it later on. To keep the action under two minutes, don’t spend too much time writing long paragraphs. Think in concise terms. What is the essential message you need to convey? Think about it and write that and nothing more.

Basically, when you receive an email, you can only do four things with it: delete it, read it, act on it, or file it for action later. So, when it comes in, process it in that order: If it’s of no value to you (simply a notification that you don’t need), delete it immediately. If not, read it, and then decided on acting on it right now (using the two-minute rule), or filing it away in a ToDo folder for later. Done.

I’ll discuss other techniques in a subsequent blog post and document how email can actually be a barrier to communication. Meanwhile, what are some successful techniques you have used to manage your inbox?