BluePrint Tool

I attended a talk by folks from BluePrint and LexisNexis at BAWorld on Tuesday. 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 someone 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

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.

Out of Scope Out of Mind

Be wary the out of scope feature pile. Sure it is a quick and easy way to kill off an entire new project's worth of work, but did you kill it the right way? Make sure that when moving requirements to an out of scope status that the reasons for the decision are recorded and who made those decisions.

The best case will be where the feature has been mapped against a business objective that will not contribute enough to the organization's end goals. Can't argue when someone's favicon didn't make the cut since it would provide an estimated 2 cents to the yearly income from bookmark recognition.

The worst case will be a project's funder coming to you asking why his requested feature to save sales proposals in the system didn't make the cut while you stare blankly at your documentation looking for anything.

Controlling Changing Software Requirements

The CCB (Change Control Board). It is their responsibility to oversee and approve any proposed changes to your software project. They're officially in charge of moving the cheese around - or approving completely new cheese.

Once they get to work, your nice, safe plate of Pepper Jack could morph overnight into something rich and strange, like English Farm Cheese with Dried Currants.

Project changes happen, but they aren't always easy to deal with. And they don't just affect Development (Nacho Cheese Doritos(tm)) or QA (Swiss Cheese).

It's critical that CCBs recognize that scope changes also affect documented requirements and the people who manage those requirements.

Scope Changes Affect Software Requirements Tasks

Changes approved by the CCB may generate requirements-related tasks, such as:

• Identify all requirements impacted by the change (requirements traceability will make this much easier)
• Update impacted requirements documentation and related models
• Manage review and approval of changes to existing requirements
• Elicit additional requirements to supplement or replace existing requirements
• Communicate all changes to impacted parties

Keep Business Analysts in The Loop

All impacts of a requested change must be identified and agreed upon so that informed decisions regarding the request can be made.

Even seemingly small or simple requests can easily become big changes when all of the related activities are considered.

Be aware, actively participate in controlling change on your project, and when your CCB hands you a wedge of Vieux-Boulogne (the world's smelliest cheese), you won't even blink.

ProductCamp Austin Is Almost Here!

ProductCamp Austin is coming in a couple of weeks - it's a "collaborative un-conference/workshop on Product Management and Marketing topics."

It's free to attend!

Seilevel will be sponsoring the event and offering up a volunteer to photograph the event! We'll put the pictures on Flickr for everyone to see after.

My personal thought about it all - Austin has a lot of outstanding people in the space of product management (anecdotally evidenced by the fact I read more product management blogs written by people in Austin than anywhere else!). This event is a place to get those minds all in one place and have really interesting discussions! Unfortunately I'm unable to attend as I'm going to be on my way to the International Symposium of INCOSE 2008. However, I encourage you all to attend and write about it after!

Is Your Halo Blocking Your (Requirements) Vision?

There is a correlation between projects that meet documented needs (but not the business needs) and the ‘Halo Effect’.

The Halo Effect, as defined by the American Heritage Dictionary, is "an effect whereby the perception of positive qualities in one thing or part gives rise to the perception of similar qualities in related things or in the whole". More practically speaking, it is when someone who is an ‘Expert’ on a subject area is appointed as the project manager because of that expertise. However, being a Subject Matter Expert (SME) does not automatically make someone a Good Project Manager.

One of my first project management experiences came when I had asked our company to address a customer service issue that was affecting the operation of my department. Being the person closest to the problem, I was assigned as the PM and sent on my way.

I started off listing all of the things that I thought were requirements in as much detail as possible. I then had my team look at everything and off we went. The project team worked really hard and we completed my project on time and on budget.

Once completed, the problems started. We were only able to address part of the original issue that we set out to fix. We had fixed my side of the problem. The rest of the issues were still there. I was appointed to the PM position because I was the expert, but that ended up hurting the project. I had failed to get other experts involved because I thought I knew it all.

While I have learned my lesson, I have seen this same scenario play out over and over again. Time after time, subject matter experts are put into PM positions because they know “what’s best”. Many times the projects requirements turn into being all about the SME’s opinions rather than company needs.

The next time you think you have it all figured out, perhaps you should stop and make sure to evaluate whether or not the full realm of expertise had been explored". It just might make a difference.