Course review: Business Analyst Boot Camp (ASPE Tech)

Training Day
Computerworld's editor, Don Tennant, wrote a couple of interesting editorials last month. In one, he took IT workers to task for not being more active in developing their skills to stay competitive with the global marketplace. Actually, he's done that several times in the last few years. However, he was also good to follow up that editorial with some of the feedback he got, and agreed that companies that are quick to outsource ought to also be fair enough to also assist in-house resources with training. This article dovetailed nicely with some of the things I'd been saying earlier in the blog about companies not investing in internal staff, and how some of this might be due more to impatience than to cost. More on that in a future rant.

Provider
The subject at hand is the Business Analyst Boot Camp offered by ASPE Technology. ASPE sent me a brochure about the class and I was pleased with the breadth of subjects it covered. I was especially pleased with the course materials; more on that in a moment. The company offers courses across the spectrum of software development and project management. I won't go into further details on the offerings, you can visit the web site for a course list and pricing.

ASPE appears to work like most third-party training providers I've seen, meaning that they don't staff a set of full-time employees as instructors that continuously learn and teach a specific product. My impression is that ASPE handles the administrative overhead of developing the course syllabus, selecting the materials, and organizing the marketing and scheduling. The instructors are more like contractors that plug into areas of demand depending on their qualifications, locations, and course demand.

Logistics

• The course is four days long, 8:30am to 4:30pm. Due to some of the class leaving early to catch flights we finished in just under four and sped up the last day's subjects.
• My course had ten students and was in a dedicated training facility.
• Students came from various parts of the US and 80% were from the energy industry. Seven were business analysts, one was an IT manager, and two were developers.
• The course is recognized by both the International Institute of Business Analysts (IIBA) and the Project Management Institute (PMI) and is worth 28 development units toward certification in either of those organizations.

Instructor: Mini Kirtane

Kirtane is a former developer that moved to the business analyst (BA) role and now teaches both project management and BA courses. She still does contract BA work for various clients. She's quite personable and entertaining, but I really appreciated that she was able to speak to both the theory and practice of the materials. She has her Certified Business Analyst Professional (CBAP) qualification. She often quoted from her experiences with both public and private institutions. She also teaches other courses for ASPE.

She communicated well and did a good job of fielding questions. She's comfortable with the course materials. We could occasionally get off track but she kept pretty close to the course guide and schedule. I liked that she did not get into heated debates about classic vs. agile approaches and recommended that students use what works for them.

Course
There was a lot to cover in the four days. Key subjects:

• Foundations of Requirements Development - BA skill set, term definitions
• Project Initiation - Identifying project scope and stakeholders and goals, using a context diagram to identify actors and goals and high-level data flows
• Eliciting Functional and Non-functional Requirements - Using various process analysis tools, interviewing techniques, data definition, taking into account the need to process CRUD functions (Create, Retrieve, Update, Delete)
• Documenting Requirements with Use Cases - Information and exercises on writing and refining Use Cases
• Creating and Presenting the Requirements Specification - Sample formats of requirements documents, some discussion of thorny issues like traceability, discussion of communication

Each day contained several topics, generally presented in the format of theory followed by exercise. Students worked individually and also in groups.

I liked that the first day did a nice job of identifying the responsibilities of a typical BA and Kirtane made sure one of the themes of the course was that BAs are not "order takers." When a party presents an idea for a system ("We'd like a new system that runs on gold-plated portable devices because that would really be cool") she was very clear on the point that a BA's first job is identifying the business needs and goals because the idea may not be salient given business risks and resource limitations.

Another excellent point that I appreciated as a developer was the identification of how a good BA delivering good requirements can save maintenance hassles down the road. This slide from the class says it all.

Another benefit is the course's awareness of the PMI and IIBA. There is information in the course relating the BA work to specific phases of the PMI's project management process.

Time is spent also studying the sources of requirements data BAs must work with and how to use techniques and tools to give the requirements shape. Everything from interviewing to using various diagrams. The class discussed ways to disarm reluctant subject matter experts and how to channel the ideas of more enthusiastic ones without without letting them compromise the bounds of their role.

New for me was the work on things like context diagrams and Use Cases. There were several tools presented for identifying requirements; no one tool is the answer and often a combination is needed. I was looking forward to putting together the requirements document, but unfortunately our rushing a bit at the end meant we only reviewed this information. However, I still have the course materials to refer to. The exercises were also helpful in reinforcing ideas and showing that getting requirements isn't any easier for a BA than it is for a developer.

I also liked the course concepts of functional versus non-functional requirements. Strangely, when I went back to the course guide to look up this section there was little to identify it in the section where it is named. We did discuss it in class, but in the guide I had to go to the sample requirements document in the course guide to get some details on what a non-functional requirement is.

I'd done some requirements as a developer before and one of my goals coming into the class was to learn how to use a mixture of graphics and text to more concisely capture requirements detail without creating a huge document and without losing the speed of just typing text. I don't know that I met this goal because we discovered in the class that with requirements you could keep going into more and more details. My experience has been that the more detailed the requirements document can be, the better the information is for the developer. Yet, time constraints often limit the detail, and I'm still trying to reconcile how to be both detailed and agile. The Use Cases may help as they use text in a semi-structured way and with brevity as a goal. But as you expand a Use Case to handle exceptions, it can grow to be as complicated as pseudo-code. Cockburn advises against getting too detailed because the document then becomes unwieldy, a point he doesn't have to make twice to anyone.

This issue of being able to determine the appropriate level of requirement detail is one I struggled with in the class and will continue to work on. However, the context diagrams and activity diagrams and Use Case diagrams may all serve me well in my work.

Traceability, the concept of being able to reference the requirements at a later date and keep them updated for changes, fascinated me. Sadly, this is almost as hard as keeping code updated. There are expensive professional traceability solutions out there, but it appears that with regard to conventional documents the best traceability tool is still a human being.

Materials
This is an area where I felt ASPE distinguished itself. All the third-party courses I've taken include a custom course guide that is essentially a collection of the slides used to navigate the course and may include some additional worksheets for the in-course exercises. This is provided in the BA Boot Camp and still works as a useful way for the student to follow along and take notes.

The BA Boot Camp also came with some additional texts for students to take home.

• More About Software Requirements by Karl Weigers
• Writing Effective Use Cases by Alistair Cockburn
• The Software Requirements Memory Jogger by Ellen Gottsdiener

For what it's worth, all of the books are rated 4 stars or above in the user ratings on Amazon.com. Even if they weren't, Cockburn's name is a respected one in the world of agile development.

Each of these provided detail and reference for future use. This is especially important because BA Boot Camp covered the gamut of BA work from the project initiation all the way to the delivery of a requirements document. A four day class isn't long enough to delve into all the details, so the inclusion of critically regarded books is a big plus. There are clear links in the course guide back to the external texts. This is very handy for future reference.

Finally, all necessary peripherals were included: binder, worksheets, pens and pencils.

Facility
The Texas Training and Conference Center was great and is well designed for courses. There's an antechamber for each classroom that contains a set of phone cubicles and a serving area. The antechamber and classroom are separated by a door so when it's closed students can make calls and the TXTACC staff can work in the serving area with minimal disturbance to the class. Each class has ample seating space, desk space, and accouterments such as a projector, easels, and whiteboards. The staff is accommodating and responsive. If we ever had technical issues, someone quickly addressed them. Each day the staff kept the serving area stocked with beverages, a continental breakfast, and an afternoon snack.

Summary
I learned much but still had some questions at the end. I definitely gained knowledge of Use Cases, gained a better definition of the BA role, learned several new tools to help illustrate issues and derive requirements, and I have some fine books to continue my education with.

I enjoyed the class and found Kirtane's insights and tips that weren't in the course materials good to have.

The Vanguard

Giving Props to the Business Analysts
I am taking a slight change in direction and will be reviewing a recent class I took. I'm fortunate to be working for a company that is willing to invest some funding into developing its people. I attended a Business Analyst Boot Camp offered by ASPE Technology. To preface that, this entry is to pay some respects to the business analyst (BA) world and explain why I feel developers can benefit from learning BA skills.

In the class, I received exposure to several aspects of business analyst work. I've been primarily a developer most of my professional life, but I will give my first employer, EDS, some credit for trying to teach us budding systems engineers BA skills. I've since worked with several companies and many different BAs. BAs are like developers: there are many out there, but only a minorty are outstanding. And when you find a good one, he or she is worth keeping.

At the Starting Blocks
Business analysis is where it all starts when it comes to a software application. It's the tip of the sword and while good work at this stage can be compromised by deficiencies in development, testing, and change management issues, bad work here will almost certainly lead to problems in the overall effort. Only the presence of experienced developers and project managers might be able to still guide such a project to a successful end, and they would do this by willfully partaking of some of the BA duties. In fact, this has happened on many of my past projects and it was when the developer was willing to hash out the business issues and processes rather than make assumptions that downstream pitfalls were avoided.

That leads me to describe my past experience with BAs. Some had decent domain knowledge and were good communicators and had helpful attitudes. Some even had technical skills and that could be a boon. But I've worked with more than my share of people that probably shouldn't have been in IT, much less BAs. I've met a few that simply were non-factors; they didn't participate, they didn't provide timely answers for developer questions, weren't too hot on requirements documentation, didn't get involved in testing or user training, and didn't forge relationships with stakeholders. In effect, if they at least had a helpful attitude, they were glorified secretaries that organized meetings.

That is why I as a developer took this course. The BA skillset includes things like requirements definition, interviewing, conflict resolution, project initiation and elaboration, meeting management, and a whole host of both written and verbal communication skills. All of those things are valuable skills even if you're not formally a BA. A developer, even with the assistance of a good BA, will still have to be able to elicit requirements. There are always going to be missed gaps and unforseen issues, especially on complicated systems. Remember, making software is easy, but making it right is hard. Being able to perform these duties just makes a developer more rounded. In the agile development methodologies, this is even more important because there might not be a BA; the developers and functional owners are co-located and work together in real-time.

Quality is Everybody's Responsibility
Not to belittle a good BA, but most of the BA skills are ones that can be harnessed by anyone that wants to participate in the role (in fairness, I earlier wrote that anyone can become a programmer too). So I took the class because my experience has proven that when a developer is materially involved in the requirements research, it leads to less risk that the software will fail to meet those requirements. This is one of the points that defines software quality.

Some developers would not like this. They would say, "I don't want to document the requirements, I'm a developer." What they really mean is that they'd prefer not to document anything and they would rather just hack away.

For the developers that get outstanding requirements handed to them by either a BA or a developer willing to do BA duties, fine. But at least in the US, conventional wisdom is that code-only developers will become rarer as companies look at offshoring models. And the reality is that most of the time, there isn't a tight requirements document handed over. So, to uphold some measure of quality, good business analysis must be done and it doesn't really matter if it's done by a BA, a project manager, a developer, a functional owner, or a raccoon. If it's done, and done well, it makes a difference. Quality is everybody's responsibility.

In the next entry, I'll write about the class.