Jonathan Babcock

RSS Feed Homepage

Articles: 1, 2

It’s Good to be a Business Analyst II
2008-05-16 03:29:00
I’ve said it before, and I’ll say it again: It’s good to be a business analyst! Not long ago, CIO.com ran an article entitled, Why Business Analyst s Are So Important for IT and CIOs. The article has apparently piqued the interest of many business analysts as I’ve seen it mentioned in various blogs and discussion groups. It is exciting that reliable research firms like Forrester are producing reports such as this that acknowledge the value of the BA role and provide such a positive outlook. I wanted, first, to point out the article to those of you who may not yet have read it; second, to share some of my own commentary on passages that I found particularly interesting. So, here we go: What is clear: The most successful business analysts are the ones who blend the temperament and communications savvy of a diplomat with the analytical skills of an intelligence officer. And business analysts are a hot commodity. I found the comment on the mix of skills interest...
More About: Good , Business Analyst

Documentation is No Substitute for Interaction
2008-05-14 04:56:00
I’ve long been of the opinion that involving as many stakeholders in the project as early as possible is a key to successful business analysis, and, more importantly, to successful projects, and have said as much in a few of my posts on this site. Jim Highsmith, in the book Agile project management : creating innovative products, thinks that the reason projects tend to have so much documentation and so few results is that: [T]here is a fundamental flaw in many people’s understanding of documentation—documentation is not a substitute for interaction. When a customer and a developer interact to jointly develop specifications and produce some form of permanent record (documents, notes, sketches, feature cards, drawings), the documentation is a by-product of the interaction. When the customer sits down with a product manager and they write a requirements document that gets sent to a development group, then the document has become a substitute for interaction. In the first sce...
More About: Documentation , Interaction

More on User Stories
2008-05-08 05:45:00
I must admit that I am not as knowledgeable as I’d like to be when it comes to some of the agile methods. To remedy this, I’ve been doing some research to learn more about user stores and to determine how they are different from use cases and from traditional requirements. Here are some of my recent findings of interest that I wanted to share in case others of you may be in the same boat. Martin Fowler specifically addresses the question, “What is the difference between UseCases and XP’s stories?“: Use cases organize requirements to form a narrative of how users relate to and use a system. Hence they focus on user goals and how interacting with a system satisfies the goals. XP stories… break requirements into chunks for planning purposes. Stories are explicitly broken down until they can be estimated as part of XP’s release planning process. Because these uses of requirements are different, heuristics for good use cases and stories w...
More About: User

Weekly Digest - 8-17
2008-04-30 05:38:00
Here are some links to interesting articles and information I’ve found during the past week. If you’ve ever doubted the need for requirements elicitation for an ERP project, you need to read this. Apparently a company is suing an ERP software vendor because the software it was expecting to work in a promised date did not work even more than one year late (shocking!). It’s a very interesting read. Among other things, the plaintiffs refer to prototypes or mock-ups as a form of deception by demonstrating “fake software.” In any case, the moral of the author’s story is that, “even when buying a COTS system (an ERP is a big COTS), you do need the expertise of requirements engineers.” While on the legal theme, have you heard that the State of Indiana has made use of a waterfall methodology a criminal offense? “Waterfall software development lifecycles have terrorized technology projects in this state for too long,” Governor Mitch...
More About: Digest , Weekly

Weekly Digest - 08-16
2008-04-28 16:29:00
Here are some interesting items I’ve come across over the past week or so that I’d like to share. I read a though-provoking article the other day by Tony Lock on why IT is still not communicating well with its business counterparts. Per Lock: [F]ew organisations have formally established and monitored service levels reporting in terminology and language with which business users will be comfortable… But when it comes to measuring and reporting on IT’s contribution to either overall business goals or top line business value, the number of organisations with formal reporting processes in place drops to only one in five or even lower. However, communication isn’t just about metrics and reports. He concludes, The biggest benefits to the entire business and to IT departments themselves will come not directly from establishing and formally reporting on these matters in business terms but in establishing expressive two way communications between business and ...
More About: Digest , Weekly

New Tools - and Their Implications
2008-04-22 04:12:00
On this blog we’ve talked about the imprecision of natural language and the problems it can present in drafting requirements. Forget requirements - what would you think of a tool that could turn natural language into software code? Sounds crazy, doesn’t it? Well, there is already such a tool in the works, although it’ll probably still be a while before they’ve ironed out all the wrinkles. Writing software has been relatively difficult since people began programming computers in the mid-1900s. Although programming a computer is eminently useful — it gives you fine control of a powerful tool — it requires learning a programming language. Researchers from the Massachusetts Institute of Technology are aiming to remove this requirement. They have taken a step toward that goal with a language-to-code visualizer dubbed Metafor. The visualizer uses natural language instructions to sketch the outlines of a program. It can be used as a programming learning ...
More About: Tools , Implications

Looking the Part
2008-04-03 00:36:00
Ever heard the expression that you should dress for the job you want, and not the one you have? I read this interesting little passage a few weeks back and just thought I’d share. Today in business, “looking the part” has definitely resurfaced as a priority in the eyes of many decision-makers. Perhaps that’s why so many organizations are encouraging their employees to wear “business ready” attire. Dressing in a “business ready” mode means wearing clothes that ensure that you are one of the first individuals to come to mind when your manager realizes he or she is double-booked and needs an instant replacement for that upcoming meeting. “Business ready” means never having to say you’re sorry for how you look during a meeting. In short, “business ready” attire means dressing for the position you want rather than for the one you have. It’s the best (and most lucrative) approach to business attire, and it’s one you should adopt whatever formal style guideli...
More About: Part

Corporate Strategy and the Business Analyst
2008-04-01 04:09:00
What is your company or client’s strategy? Do you know? Has it been formalized? Some recent articles I’ve read and training that I’ve received has taught me how important a clearly defined business strategy is to meeting organizational goals. What’s more, it’s now plain to me how important the corporate strategy can be in helping to make business and technology decisions. Here’s a quick and (probably overly) simple example I made up to illustrate the point. Strategy As a Point of Reference An internet host has built a strong market presence as a low-price, highly reliable provider. In fact, the “quick and dirty” articulation of their strategy was that they would provide the highest rate of server uptime at the lowest price in the market. Their success was based on their ability to do just that. They arrived at this strategy as a result of competitive analysis of the market that indicated that they had competitive advantages that c...
More About: Business , Corporate , Analyst , Business Analyst

Random Observations from the February Atlanta IIBA chapter meeting
2008-03-06 21:27:00
Random observations from the February, 2008 Atlanta IIBA chapter meeting.These are not overly important or surprising, I just found them interesting. There were between 50-60 attendees. At least a quarter of attendees were attending a chapter meeting for the first time. It was mentioned that there are approximately 100 members in the Atlanta chapter of the IIBA. When asked for a show of hands, Approximately half of the group indicated that they currently use cases to expresss user and functional requirements. Approximately half of the group does UML modelling other than just for use cases (activity & sequence diagrams, etc.). Very few - I estimate less than a quarter - use a requirement management tool for traceability. Of the group, there were probably 6-8 CBAPS in attendance. Originally posted at: Jonathan Babcock Random Observations from the February Atlanta IIBA chapter meeting ShareThis
More About: Random , Chapter , Meeting

IIBA Atlanta Chapter Meeting & Requirements.net
2008-03-04 04:20:00
I’ve blogged recently about participating in the business analysis community, and felt like I should get involved in what is going on in my local Atlanta IIBA chapter. Well, I went to the chapter meeting this past Tuesday and thought I’d share a few of my notes and impressions. First off, it was a good time. I went with a co-worker, and we arrived fairly early. Showing up early gave us an opportunity to meet and visit with chapter president Jonathan Kupersmith (aka “Kupe”) and a few other BA’s. I’m a longtime fan of his company’s business analyst blog, and it was nice to be able to discuss the business analysis and blogging for a few minutes with Kupe. After food (quite a bit, actually) we heard an interesting presentation by Keith Barrett of the Sky IT Group. He presented a formula for accelerating the requirements lifecycle. The gist of the presentation was that for the past several years, companies have been focusing their resources on ...
More About: Chapter , Meeting

Going to the Atlanta IIBA Chapter Meeting
2008-02-22 17:56:00
I just RSVP’d to attend this coming Tuesday’s Atlanta IIBA chapter meeting. This will be my first time attending, and I’m really looking forward to it. I know of one or two readers in the chapter that have happened by this blog, so for you and any others who may have happened by, I look forward to meeting with you on Tuesday. For those of you in the area, here are the details as I know them: When: Tuesday, February 26, 6:30 PM Where: UPS 55 Glenlake Parkway NE, Atlanta Sandy Springs, GA 30328 RSVP by February 22, 2007– events@atlanta.theiiba.org Cost to attend – Free for Greater Atlanta Chapter members, $5 for non-members Topic: “Redefining the Requirements Equation: RLA = T3.” Speaker: Keith Barrett, Business Development Manager, Sky I.T. Group I get my information on IIBA happenings in Atlanta from the chapter website, and the IIBA Atlanta Yahoo Group. Originally posted at: Jonathan Babcock Going to the Atlanta IIBA Chapter Meeting ShareThis

Happy 1st Birthday, Blog!
2008-02-21 04:26:00
Actually, the true 1 year anniversary was on the 9th, but I thought I’d do as I do for most other birthdays, and forget it completely until a week or so has passed. So, we’ve been at it for a little over a year, and I think it is an appropriate time to thank all of you who have stopped by to read and comment on my posts. Thanks for subscribing to my feed and occasionally bookmarking my posts. I’d probably blog just for my own benefit anyway, but it sure is more enjoyable when you get to exchange ideas with other respected and accomplished practitioners of the trade, and benefit from their experience and expertise. I have more to say, but first here are a few fun facts about jonathanbabcock.com’s first year (thanks to the productologist for the idea). Number of visitors: Approximately 12,300 unique visitors. I can’t give the exact number because 3 tracking mechanisms each return slightly different results. Ok, I’m not breaking any records, but it...
More About: Blog , Happy , Birthday

On Business Analysis in an Agile Setting
2008-02-06 07:11:00
  I’ve noticed a recurring discussion around various business analysis-oriented websites of late concerning the relevance and value of the Business Analyst, especially in an agile environment. Some argue that with agile, “business analyst” responsibilities are carried out by software developers or technical architects, eliminating unneeded layers of communication (read; BA’s). Karl Wiegers, one of my favorite reads on software methodology, addresses the topic briefly here. One of the points he makes, and with which I agree is that we can “[t]hink of the analyst function as being a project role, not necessarily a job title. This role can be performed by various people on the project who have the skills, knowledge and temperament for it.” That’s where I think the IIBA may find peace with certain agile evangelists (see the comments section - link requires registration). Depending on the environment, developers could certainly be call...
More About: Analysis , Agile

Onshore vs. Offshore
2008-02-06 05:52:00
Matt Lockhart of Magenic Technologies, Inc. posted an excellent article at TechLinks a while back on things that need to be considered when determining whether development work should be done on or offshore. Among others, Lockhart draws attention to topics such as budget, relationship management, onsite travel, CMM considerations, the risks of miscommunication, and economic and political risks that need to be carefully weighed out before deciding to go offshore. The way I see it, offshore outsourcing of IT work - chiefly development and QA - is not going away. Those of us stateside will have to learn to adapt and thrive in this new type of environment in order to remain marketable. For many of us, retooling may be necessary. From a business analyst’s perspective, I’m not so naive as to think that my role couldn’t possibly be performed overseas, but I don’t think that the role of the onshore BA is going away anytime soon. I’ve alluded elsewhere on thi...
More About: Offshore

With requirements, discussions matter most
2008-02-01 16:45:00
This post is based on a quote I read and liked from the article, “When Requirements Go Bad: Part II” by Kurt Bittner. The article is available from Dr. Dobb’s Requirements Development e-zine (free subscription required). According to Bittner: We need to banish the practice of writing requirements that we can “throw over the wall” to developers or testers and instead pursue a more open, communicative approach. What is important to realize is that requirements are what motivate discussions, but it is the discussion that matters most. Well said. While I’ve taken an occasionally rocky path to get there, my experience as a BA has led me to the same conclusion. Tough Lessons Learned I’ve worked projects in the past in which we would spend 3-4 weeks of requirements analysis with various users and stakeholders and then bring what we considered to be, for all intents and purposes, a “finished product” to be signed off by the desi...
More About: Matter

A couple new features at JB.com
2008-01-30 22:18:00
Just wanted to let you know that I’ve added a couple new features to my blog at JB.com. Bookmarks I’ve added a few pages of links that I’ve collected on topics relating to business analysis. Currently, the categories are business analysis, communication, methodology, requirements and use cases. Many of the bookmarks are for articles to which I’ve referred in blog posts. Some I just enjoyed and wanted to keep handy for reference. You can find my bookmarks on the navigation bar at the top of the blog under “JB’s Bookmarks.” Anyway, I thought that some of you may find them useful or interesting, so go check out the links pages when you get a few minutes to spare. Asides Often I’ll have a quick thought and would like to post it on my blog, but I don’t want to clog it (and my feeds) with overly brief or non-substantive posts. I’ve recently discovered a trend where bloggers will compose more brief posts termed as “a...
More About: Features , Couple

A Call to Participate!
2008-01-29 06:37:00
The “Junto” For some reason, last week I picked up and began reading from Benjamin Franklin’s autobiography. In it, he mentions a mutual improvement society that he and several of his acquaintances founded in colonial Philadelphia to compare ideas, to critique each other’s publications, and to gather sociably. They called it “Junto.” The idea behind Junto was that in gathering like-minded individuals with a common cause for civil discourse, all participants stood to benefit. From Wikipedia: Franklin organized a group of friends to provide a structured forum for discussion. The group, initially composed of twelve members, called itself the Junto (Latin for meeting). The members of the Junto were drawn from diverse occupations and backgrounds, but they all shared a spirit of inquiry and a desire to improve themselves, their community, and to help others. That association drew me to think about our day, and about the field of business analysis. W...
More About: Call

All About Agile
2008-01-27 03:03:00
I really, really like Kelly Waters’ blog All About Agile . Originally posted at: Jonathan Babcock All About Agile ShareThis

Finding a Home for Business Analysts
2007-07-24 00:12:00
Is the role of business analyst an IT role, a business role, or both? How can the BA role be used to the greatest benefit of the organization? This post is a follow-on to one in which I entertained the question of whether a Business Analyst ’s (BA) requirements work is fairly labeled “requirements engineering”. I tend to favor the notion that it’s not. And not because I am a stickler for semantics, but because I would like to see the BA role become increasingly involved in business case development, and less exclusively as an information technology (IT) role. Business Analyst as an IT Role Today, the BA role seems to be joined at the hip with IT. My notion of why this is, is that IT sees the most immediate and conspicuous value-add. IT really feels the pain when business need is not communicated clearly. Numerous studies show that requirement inaccuracies that are corrected early on in the project can cost a mere fraction of what it costs in time and budget ...
More About: Home , Sine

Is “Requirements Engineering” a Misnomer?
2007-07-18 23:54:00
James Robertson questions use of the term “Requirements Engineering ” on the Yahoo Requirements Engineering Group . It is not engineering. It became known as “engineering” because some academics wanted to be seen practicing a discipline that was a “hard” science. However, talking to stakeholders, understanding what they want, reading between the lines of what they say, inventing features, persuading developers to build the specified product are not engineering subjects. When I first read his comment, I thought, Roberts was being a bit nit-picky and that it is basically just a question of semantics. Granted, this isn’t the type of topic that will help you do your job better, but, given some more thought, I chose to post about it because I think it’s interesting from a philosophical perspective. […Continued…] Share This
More About: Erin

Business Analysts: SME’s or Generalists?
2007-07-18 06:28:00
I’ve been involved in some interesting and spirited discussions over the years as to whether a Business Anal yst (BA) is most effective when also a subject matter expert (SME) in the technology and systems in use, or whether the BA need only be disciplined in the general principles of business analysis; chiefly, how to identify customer need, and be an effective facilitator of knowledge transfer. Personally, I don’t think there is a single “right” answer, and I’ve argued from either side at one time or another. What I hope to do here is to list some points/counterpoints that may help you think through your position, or even evaluate how your technical/systems knowledge helps or hinders your performance as a BA. To get started, allow me first to provide just a little bit of context on my professional background. With a previous employer, I worked in the same area for a number of years and got a shot at just about every role in our IT shop before being ask...
More About: Business Analyst , Sine

Recommended Link for July 1st
2007-07-03 18:41:00
Just linking a good read on communication; particularly conversations. The Practice of Leadership - Blog Archive - Resolving stuck conversations.. - Conversation creates involvement, which generates the commitment. It’s commitment that ensures aligned action and an effective end result. Therefore, getting the conversations right is of critical importance. Share This
More About: Link , July

Excellent Resources for Business Analysts
2007-06-28 19:11:00
Thinking of trying your hand at business analysis? Already a BA, and want to find information that will help you hone your skills? Just wondering what in the world a Business Analyst is, and what he/she does? If so, I hope you’ll find this post helpful. There are lots of great Web resources available to BA’s and those with similar interests. Below is a list of just a few of my current favorites, in no particular order: Seilevel Software Requirements Messageboard - This is a gathering place frequented by “newbies”, day-to-day professionals and seasoned experts alike. Scott Sehlhorst, Roger Cauvin and even Karl Wiegers are participants. I learn something new every time I visit the Seilevel board. The blog is also top-notch. “Nexus“ - the Tyner Blain powered repository of select articles is quickly becoming a solid networking and social bookmarking center for folks interested in systems and product development. The Tyner Blain blog is also one of ...
More About: Resources , Sources , Business Analyst

You Know It’s Getting Deep When..
2007-06-23 00:36:00
I really enjoyed Chris Woodill’s collection of “weasel words” that IT delivery folks will use to buy time, deflect responsibility, or describe a situation as much rosier than reality. The intent isn’t to be particularly humorous, but as I read it, I couldn’t help but remember that funny “this is what she says, but THIS is what she means” e-mail poking fun at male-female communication. Now, I’ve never met Chris, but having read through this list, I’d almost swear we must have worked on the same projects with some of the same people! Here are a few of my favorites: It should work: this usually means that it doesn’t. It also means that it was probably not tested properly as the result is current[ly] undetermined. The word “should” should be taken out every developer’s vocabulary - it either does or it doesn’t. Almost done: this is also a weasel word. When a developer tells you things are “almost ...
More About: Deep

Links for 2007-06-22
2007-06-22 13:08:00
Jonathan Miles: Fingerjig Typing Game Fingerjig is a 6 minute game that tests your typing prowess. Words are randomly chosen from a dictionary of over 70,000. You must try to type them as quickly and accurately as you can! The average score for Fingerjig is 476,983. If you can beat this then (tags: hu) David’s Software Development Survival Guide: Undreamt Requirements Interesting insight into 3 distinct types of requirements: Conscious Requirements - Problems that the new system must solve; Unconscious Requirements - Already solved by the current system; Undreamed of Requirements - Would be a requirement if we knew it (tags: requirements requirements-gathering management analysis) Better communication through better listening Nearly every aspect of human life could be improved by better listening.This article lists eight common barriers to good listening, with suggestions for overcoming each. (tags: communication management relationships) Share This
More About: Links

McDonald’s Burgers and High-Quality Business Analysts
2007-06-22 04:48:00
The instructor of a training session I recently attended used an analogy that I liked. He asked whether we thought of McDonald’s as a high-quality restaurant. The question drew a few chuckles and, of course, most of us replied that we did not. He then went on to explain that, in fact, McDonald’s is a high-quality restaurant, and here’s why: Quality is consistency. McDonald’s is not high-quality because it is considered a premium product, but because it consistently satisfies customer expectations. If a customer wants a quick, tasty meal in 3 minutes for about 5 bucks, then they know that’s exactly what they’ll get at McDonald’s. For the purposes of playing out the analogy, I submit these definitions: Value is provided by meeting or exceeding a customer’s expectations for a price they are willing to pay. Quality is providing value consistently over time. Why is consistency the key? If the next time you went to McDonald’s and pai...
More About: Business , High , Burgers , Analyst

Links for 2007-06-21
2007-06-21 13:00:00
Modern Analyst | The Community for Business & Systems Analysts Modern Analyst is a community and resource portal for the business analyst, systems analyst, as well as other IT professionals involved in the business analysis or systems anaysis activites of software engineering. (tags: businessanalyst) Meeting Management Made Easy This article presents some useful tips for sound meeting management as well as providing references for where to find more help in managing your meetings better. (tags: meetings management) Share This
More About: Links

Links for 2007-06-19
2007-06-19 13:08:00
Better Projects: Ethics in project management Craig Brown discusses ethics in project work & encourages reflection on personal core values as well industry standard values and how they align with one’s project work. (tags: ethics management) Change is Bad? Mistakes are Worse | Tyner Blain Scott Sehlhorst takes on CNET over an article implying in a roundabout way that the reason Microsoft’s new Live e-mail platform has fizzled is that change is inherently a negative thing. He argues “[t]he whole change is bad argument is a red herring. The (tags: analysis) Share This
More About: Links