Seilevel
Seilevel Home
Back to Blog Home - Requirements Defined

Monday, October 26, 2009

An example of Blueprint in Use on an Agile Project

I attended a talk by folks from BluePrint and Lexis Nexis at BAWorld on Tuesday at BAWorld: Boston called "Requirements Definition for Agile Projects". The first bit of the talk was just an intro to agile and why it is useful on the projects. The part that I found most interesting was from Kathleen McGoey who owned business analysis on lawyers.com - she effectively gave a verbal case study of their team using agile and Blueprint to deploy this site. This was refreshing because she was brutally honest about the state of their organization 2 years ago, some of her dislikes about other tools, and their experiences with agile not going well. However, she also then talked about how their culture is changing now and what is working really well. This talk was great because it was effectively a great sales-pitch for Blueprint, but it was given by an actual user....and you could tell she was being honest about it.

Blueprint is meant to be a BA tool. They are closely partnered with HP and it integrates to Quality Center for QA use as well. From a quick glance of things she mentioned or showed, it looks like it allows you to manage the list of features in a backlog, low-fidelity wireframes, diagrams that look a lot like visio, export to Word, and import from Excel. We are still using Borland's Caliber happily, but I'm obviously always looking at all the tools on the market to see what people are really liking and/or disliking, what new features are coming about, what's easy to use, etc.

A bit about the lawyers.com project - they were executing 3-12 week sprints and the requirements definition is about 2 weeks ahead of sprint cycles. She made a very wise comment - templates and processes are good to an end, but only if the BA knows what they are doing already. She spoke of junior analysts who are given templates and when you look at their work products you think “Oh no! what are you doing!”. I think we’ve all probably seen that. You can use the templates and processes to train them, but they aren’t enough, but they aren’t enough.

Another neat thing she briefly mentioned was the idea of doing something like pair-programming, but where the pair consists of a BA and a user experience expert – so together they are designing the wireframes. I haven’t tried it, typically our individuals are doing both activities.

Anyway, it was good to hear the “how it works” story from Lexis Nexis. And I haven't used Blueprint myself, but I am certainly interested to hear others' experiences with the tool, so please comment if you have used it.

Labels: , , , , , , ,

Requirements Defined Newsletter Bookmark and Share

Thursday, October 22, 2009

Creating BA Competency

As part of our Live from BAWorld: Boston series, I just heard a talk from Karen McKay at Doreen Evans Associates (DEA). She discussed building a BA competency in your organization. Her talk was focused on the high-level need for such a model and what the components of it are. I think a next level of discussion that would be interesting is tactics you could use to create one yourself - which specific tools and tactics work.

At DEA, they use a model that is very similar to the CMM, with five levels of competency: initial, repeatable, defined, managed, optimized and have helped build this at a handful of organizations. We do something similar to build BA maturity in organizations, but I haven't actually seen it laid out next to the CMM model quite like this. At the requirements process level, they use requirements models which I applaud - context diagrams, org charts, use cases, process flows, DFDs, etc. This talk further validated what I'm seeing in industry - alas, models are really the current state now. So if you write your requirements in plain old text, I fear that is really seen as out-of-date "technology" and you need to look at visualization techniques.

Something interesting that she did with her slides was to describe parts of their competency models using requirements models. For example, there is a swimlane diagram to show the BA role - clearly showing how BA activities relate to IT and PM functions. I haven't done much of this recently and think it's a great idea that I will use.

Anyway, this is a topic that I'm definitely interested in as we try to help customers build their competency around requirements as well. It seems like organizations are really recognizing the value of BAs now!

Labels: , , , , ,

Requirements Defined Newsletter Bookmark and Share

Monday, October 19, 2009

Live from BAWorld Boston

This week I find myself at Project Summit & BAWorld: Boston for about a day and a half.

This morning I presented our talk, "If you Build It, Will They Use It? Leveraging Business Objectives to Deliver Successful Projects". One thing I like about the BAWorld symposiums is that they make the slides available electronically to everyone, they are reviewed by a committee before you can present them, and they insist that the speakers provide learning objectives so you know what you are getting. So to that point, here are the learning objectives for my discussion:
  • Understand how Business Objectives are vital to businesses
  • Understand how to elicit and write good Business Objectives
  • Understand how to use Business Objectives to assess measurable value of individual features
I had a blast with the audience here - great participation in some of my games (yes, we do them in presentations, not just our training classes!).

If you haven't been to one of these conferences, I recommend it if you are a practitioner doing Business Analysis, Requirements Engineering, or Product Management. Everyone else here is also practicing the "art" of BA and looking for new tips and techniques to take back to their organizations.

Anyway, I attended a few other talks of interest today that I'll blog about shortly!

Labels: , , , , , ,

Requirements Defined Newsletter Bookmark and Share

Wednesday, July 30, 2008

How to Select Software Requirements Training (It's not just about the BABOK)

So it’s time for your organization to select requirements training for your business analysts, product managers, project managers, even developers. Here are some suggestions on what to look for!

The obvious things to look for:
  • Course Agenda – make sure the agenda is published and the topics seem relevant to your group. For example, if you do not use RUP, do not select a RUP-based class. If your team is good at the basics, consider a more advanced class, for example focusing on elicitation.

  • Training Costs – these are relatively consistent across courses, but typically you can expect to pay anywhere from 600-1500 per day per student.

  • Time Commitment – make sure you sign up for a course you are willing to commit to. Typically industry courses are run in full or half day increments. Make sure your people know it’s a priority to attend once you’ve signed up. Also, I prefer courses that are done in smaller increments, for example a series of 4 classes at 2 hours each, because the students can take time to think about and practice the concepts between classes. This resembles the teaching method used in universities, but it is very hard to find in industry.
The less obvious but more important:
  • An Engaging Experience – the materials used during course must be engaging, as to not bore the students to sleep. As a rule of thumb, most learning happens in practice not lecture, so look for a course that has at least 50% of the time doing practice exercises.

  • Competent Instructors – be sure that the instructors will be interesting to listen to. This may be tough to evaluate, but you could try calling them ahead of time. In addition, they need to be credible. My personal favorite is to find instructors who are also practitioners, having actually done the thing they are teaching. They will use more real-life stories in their teaching, which help put the lecture in context.

  • Your Expectations - Be realistic yourself about what you will get out of the training and what you won’t. Referring back to the Kirkpatrick model, most training only measures levels 1 and 2, satisfaction and immediate recall of the material respectively. If you are looking for level 3 and 4, behavior change and impact to the organization, then recognize that most training alone will not give you those, and certainly is not likely to measure that they did happen. Typically mentoring in addition to or instead of training will help you get to level 3 and 4 in the organization.
Sadly, I have seen disappointed students coming out of all kinds of training experiences, and typically it is because their expectations were wrong going in.

Labels: , , ,

Requirements Defined Newsletter Bookmark and Share

Wednesday, April 09, 2008

The BABOK Ate My Laptop

I was doing some research to gather various industry opinions on a topic. So like any good requirements person, I thought I would check the BABOK! I headed out to the IIBA website to open it. I opened it online and remembered it was 329 pages, so I saved it to my hard drive, thinking that would be better for performance. And while it might have been “better”, it was far from usable.


I had to quickly jump into the document to get what I needed and close the PDF so that I could actually do other things on my laptop again. I checked my system resources and it was using 88% of my CPU and about ½ a gig of memory! And what should have taken about 2 minutes, took me 15 minutes.


This is my primary issue with the BABOK - usability. There may be fantastic information in it, but it’s so hard to find it, that I’m completely resistant to do so. The irony is that I think we all know how unusable 300 page requirements documents are. And we know how important it is to understand how your user will use a product in writing the requirements. Are we the shoemaker’s kids here? If you are going to have over 300 pages of “how to” data, surely there is a better representation of that than a flat file. For example, a navigable wiki-site would be more easy to use. It could be more of a tree-like implementation that allows varying views of the data and fast paths to get down into the details.


Now all of that said, I’d hate to just complain and not try to help fix the problem! The BABOK version 2 is coming out end of March for review, and so I hope to be able to provide my input if this has not been improved.

Labels: ,

Requirements Defined Newsletter Bookmark and Share