12 Things to Fertilize Your Business Analysis Career - Addendum

Jacqueline Sanders wrote a wonderful article that was posted on the modern analyst site, I highly recommend you read it. In it she writes briefly on the background of the Business Analyst field and several pointers for becoming a better and therefore more distinguished Business Analyst.

I have a few suggestions for some of her points.

1. Associate with Other Professional BA's. Great point. This should extend to networking in general with a focus on BA organizations and individuals. There are numerous organizations that host local networking events and seminars. They don't have to be regarding product managing or business analysis. Door64 and Austin Tech HH offer many events where you can socialize with the people you will be interfacing with the most in your job, not other BA's, but developers, SME's, and managers. More importantly, while it is good to be part of the in crowd of BA's, if you are trying to land a job or help secure a deal, you've got to know the people with the projects.

2. Seek the Body of Knowledge (BOK) / Become Certifiable / Talk Like a B.A. Learn up on your BABOK, get certified where applicable, and know the language. Its challenging enough to translate business speak to functional requirements, no need to toss in BA's with different communications. There is no substitute for BABOK and certifications. However, it is not enough to talk like a BA. I highly recommend subscribing to news feeds / blogs / articles to get all the recent traffic and best practices. Don't just do this for business analysis based information, get into feeds for the space you are working in as well as development information. When you start talking like a BA and someone else starts talking like a developer, you should be able to quickly translate and ensure the same page was landed on.

3. Tools of The Trade. As Jacqueline says, MS Word, Excel, and Visio are not enough. I can almost guarantee you that SharePoint will be involved. You should get to know and love this tool (unless you are provided with another one, in which case you probably shouldn't mention SharePoint). It will be imperative to use the shared task, communication, and document capabilities of this tool. As for getting to know other tools, if you have the free time, go out there and look up requirements management software and get a hold of all the free trials you can. Get to know any of the lists that inform you about which software offers what values.

4. It's Hard to be Soft. Just like you would carry around a portfolio of your accomplishments, try to keep in mind your experiences that played out based on your soft skills. Jacqueline states it perfectly," hard skills will get an applicant an interview, but soft skills will get that person a job." Be ready to tell an interviewer how you were able to reject the project sponsor's features without causing a political debacle and making sure they were alright with the decision based on the business needs. These experiences are just as important as your 14+ years of Visio usage.

5. Know You are Not. Jacqueline points out that we Business Analysts are not people who satisfy simple tasks. That we are not just a middle man in getting the information from the fax machine and giving it to the engineers as one lovely movie puts it. We are devoted, business-minded professionals. Everything we do should be an ROI based thought process because that is what we do. If someone doesn't understand your role, it might even be hard for you to describe. I make sure sound business decisions are executed. I make sure that products meet project needs. I ensure that business needs are met with new or changing processes. I write high level, common and excruciatingly detailed documents. I am the facilitator of meetings to make sure we didn't waste the entire leaderships day of work. I am the discoverer of everything everyone else forgot to mention. At this rate, I may also be Spartacus.

Our role is diverse and requires dedication to execute well. I find it funny how I never knew this type of job existed growing up, if you recall the silly aptitude tests growing up. I would like to reiterate that this is just a list of some of my personal thoughts regarding some of Jacqueline's points. Please go read her article. Is there anything you feel we are missing out on?

What's My Name Again?

Monthly Sales Revenue Generation... no

Monthly Sales Group Rev Production... no

Sales Revenue Performance by Month... no

Sales Revenue by Month for Overview... maybe... yes, that one was it.

Speaking from experience, trying to document vital business information when it all is named with generic operational mumbo-jumbo will slowly cause your brain cells to rebel against you throughout the day. If you haven't given in to their demands by the end of the day, your brain could retaliate by making you forget vital information like your name, favorite color, or the air speed velocity of an unladen swallow.

Concerns for your own health aside, the business is put at risk when vital documents or business processes are not identified correctly. Loss of documentation can lead to costs for replacing it, failed process attempts, legal actions, and bad requirements for projects.

To prevent that from occurring, a system to easily identify information correctly is needed. In the strictest form, the information you are working with should have unique ID's (not like the ones at the beginning of the post though). If you use requirements management tool like Caliber, then your entries should be given unique IDs. If not you will have to come up with some system yourself.

A combination of letters and numbers work well to prevent ID overlap. I tend to favor a 2 to 3 letter prefix that is some sort of abbreviation for the information such as 'RO' for report object or 'IPD' for InfoPath Document. This will help add much needed meaning to an identifier without having so many words to say so in the first place. It also serves as a code that is easier for machine side recognition if applicable to your project.

Now we have our lovely hybrid id. What do we name our document? Some people like to use summaries (which unfortunately, in my opinion, are informative mostly based on how you see things.) I try to use a generic name that describes the overall purpose of the doc such as 'Sales Dashboard' or 'Customer Credit Registration'. Those types of names will most likely be commonly accompanied with dates relevant to the creation of the document. Try to append the date in a manner that is friendly to alphabetical sorts (i.e. 2009-08-26).

Now the part that some of us will not like (I am looking in your general direction agile extremists), write down in a list that all these documents exist. Descriptions, owners, and change management rules for these documents will prove invaluable later. While other BA's are telling stories about how this one employee quit 4 years ago and the sales process is relying on a SQL database running off of an old laptop that person setup which they are now trying to bypass, you will be quickly identifying which documents need to be migrated to the new system and being confident you got all the relevant organization's buy-in.

Live from RE'09: New Ideas for Requirements Activities in Distributed Teams

Olly Gotel from Pace University presented work she has done with colleagues from around the world in a paper titled Distributing Responsibilities to Engineer Better Requirements: Leveraging Knowledge and Perspectives for Students to Learn a Key Skill. Olly started this talk by telling us that she had done something crazy with this project, and then went on to explain how they had essentially five different teams working on a project from five locations around the world. They were each supposed to write requirements for a software development competition, with requirements teaching and coaching help along the way from professors and experienced students. As she went on to describe the experience, many of us from industry chuckled with her out of empathy – her experience is so similar to our worlds today where the teams are distributed worldwide and chaos ensues!

There are a couple concepts from Olly’s course design that I think would be great to replicate in industry – either from a training perspective or project execution. The first one is related to creating competition to improve results. In past iterations of this learning experience, Olly explained they had issues with the students not understanding the value of producing quality requirements, which naturally resulted in poor results. So this time they had the teams compete with one another by creating the same deliverables and having the client choose which solution was best. As expected, the competition significantly increased the quality of their work products. We have done this with our training courses – introduced friendly competition through game playing and I’ve been pleased with the level of engagement. However I think there is something interesting to think about here with respect to injecting a different type of friendly competition into project execution in industry. Fundamentally the big turn-off to this idea in industry is that there are five times the costs to create the single project – so it's a lot of throw-away work. But, if we think outside the box a bit, perhaps we can divide projects into chunks (or just use multiple projects) and have the requirements sub-teams compete on quality of specifications, requirements issue resolution speeds, project success rates, etc.

In this course, they used an apprentice model with coaches who were students that had previously completed the requirements engineering classes. Now I think this is something that absolutely applies as-is! You can just have mentors who are more experienced people mentoring the more junior resources in requirements activities – ideally pairing them up on the same projects.

Live from RE’09: Taking Distance Requirements Training to a New Level

Didar Zowghi gave one of the most interesting talks at REET'09 I’ve heard in awhile titled Teaching Requirements Engineering to the Baha’I Students in Iran Who Are Denied of Higher Education. She was asked to teach a distance learning course on requirements engineering to these students from Australia to Iran.

She basically runs the course by teaching lectures using audio and displaying the lecture slides using Skype or LiveMeeting. However, they ran into issues with everything from bad audio connections, students who couldn’t see the visual slides, and even power outages. One improvement made eventually was to record her lectures so students could download them to play if they couldn’t hear for some reason during the live presentation. As a bonus, Didar said she learned of things she could work on by listening to herself lecture for the first time!

She had assignments for the students as well, but specifically she had a project where they had to interview a stakeholder to elicit and document requirements. She had a Teaching Assistant located in Iran who played the role of stakeholder – sometimes in person, sometimes by phone. She had the students use Karl Wieger’s templates since those were also easily downloadable.

Didar also makes time to chat with students – they might Skype her for example to find a time to chat verbally. I like to think of these as virtual office hours!

I found Didar’s talk to be so interesting based on the circumstances behind it – a great culture lesson that I thank her for. But I also find it quite relevant as we work to roll out global training programs. I am sometimes overwhelmed by the idea of how we will possibly have successful training with people on the other side of the world, but the reality is – you just make it work.

Live from RE'09: Contextual Requirements Experiences within the Software Enterprise

Kevin Gary from Arizona State University presented Contextual Requirements within the Software Enterprise at REET’09. He discussed their approach in having a multi-year project-based engineering course sequence, allowing for iterative exposure to all concepts - but particularly of interest: requirements engineering. This very much fits with popular learning theory – the idea we need to put concepts in front of students repetitively for them to really learn them. For their projects, they reach out to industry to find candidate projects so the students get to work with real subject experts to solve real problems, ultimately producing real deliverables. What I like about his style is that he is less interested in whether the company gets their perfect solution out of this work and instead he is more interested in whether the student is learning the concepts. But in reality, it sounds like the companies are getting a lot of value out of it!

One of the challenges Kevin spoke to involves how you assess students in courses like these. One thing I do like that I haven’t seen often is that he tries to check in with industry managers that hire his students to see if they are coming out of the ASU program more prepared.

So what I like about Kevin’s discussion first of all is that assessment of students is hard! We see that too and it was a big topic in an REET panel later in the week at RE’09. But I really think it’s great to see universities with programs really aimed at setting the students up for success in industry after graduation. And the final point I’ll make is that he’s absolutely right about needing students to practice the lessons lectured and hear them more than once. I think this is a major flaw in much of the requirements training offered to industry right now. We send students in for a class and then expect them to get it all - typically without revisiting the materials again.

REET’09 Went Off Without a Hitch!

Monday was the Requirements Engineering Education and Training (REET) workshop that I co-chaired with Ljerka Beus-Dukic. I’m always nervous about how these things will go – there are so many unknowns with the environment, the presentations, and the timing. However, I’m absolutely thrilled with the end result! We had 6 papers presented and it varies from a normal conference in that we had big blocks of discussion to really dive into some of the commonly shared issues in this field.

We had a lengthy discussion mid-afternoon around how do you really teach anything about requirements to students in a semester long class (or less!) and where does requirements training fit in the overall teaching of the software lifecycle at a university level. The thought is that most people learning about requirements in industry aren’t brand new to software development, they already understand a bit about coding and verification, so they understand the value and context for requirements. Yet trying to teach it to a freshman class would leave the students thinking “why do I need to know this?”

Another key point that is important at all levels is repetition in the lessons they receive. It came up again in the context of academia, where they may teach it to freshmen, and then they need to re-teach it throughout in other classes. This isn’t specific to requirements certainly, just a basic principle of good training.

We also talked quite a bit about how you assess the students in and after training. This is a long standing BIG problem across academia and industry. One issue with assessing whether any behaviors changed in an academic environment is that you teach it and they may use it on a project, but then you never see the students again. One participant actually tries to talk to industry contacts who hire the students to see if they see better results from his students. In industry, it’s very hard to isolate whether results are attributed to training. We can look for modified behavior, but this requires a dedicated resource to do so. I’ll probably talk about this more in a day or so, since we have a panel related to this on Thursday!

We then ended the day with 3 different sets of training activities presented with the intent on getting any participant feedback on the activities, but also leaving the workshop participants with the opportunity to take the exercises back and reuse them. At the very end, we played one of our Seilevel training games: Bet on Yourself Pictionary – it was fun because I was working with a group of people who are already familiar with requirements models in some form and so they could play our game – which basically enlists 2 “students” to act as analysts drawing requirements models for a specified scenario, trying to get the rest of the class to elicit the requirements from them. Oh and they had to do all of this without speaking. It was great fun and if nothing else, a lively way to end the day!