Live postings from RE'09 next week!

It's one of my favorite times of year, time for the IEEE Requirements Engineering conference! RE'09 is just around the corner, starting next week in Atlanta, GA.

I'll be co-charining the Requirements Engineering Education and Training (REET'09) workshop on Monday and then attending the main conference the rest of the week, with 2 panel appearances that should prove to be interesting.

And as always, I'll be blogging LIVE from RE'09! I hope to see some of you there, find me if you are attending this year!

Mission Elicitation - Phone Meetings

The site is security restricted, there are subject matter experts in other buildings, and the developers are in another country. Your mission, should you choose to accept it, is to gather the requirements for a gap analysis of your clients software implementation. Your meeting will self destruct in 3 days. You have a phone, a scribe, and a computer to complete your task, good luck.

I have a feeling that most meetings like this fail to meet their real goal, identifying the majority of gaps. A major implementation that requires gaps to be identified often have one big kickoff meeting where you were able to get all the important people to free their schedules. Of course, they couldn't be all in one place, so you have to meet over the phone. This can be disastrous. Not only does everyone over the phone lose context around presentations and discussions, but the people forget who is on either side of the phone. White boarding turns into phone charades. Scribes miss out on who said what. To-Dos are lost in the background noise.

Okay. Take a moment and breath deep. Think of pleasant things, like pre-existing documentation, SMEs that agree on the existing and future business processes, and meeting notes that make sense when you go back to read them.

Relaxed now? Alright, lets make sure we prevent as much of this as possible. There are several steps to mitigate as much trouble as possible. If at all possible, get a tablet pc for the meeting. If that is not going to happen, make sure you have access to a process mapping tool such as Visio. Secondly, make sure you have an online collaboration tool such as Go-To-Meeting, WebEx, or MS Live Meeting. If you don't have one of these tools, get a trial or find an open source (read: free) solution. The ones I mentioned would be ideal since your client will most likely have them already installed which means that there is less of a chance that the first 15 minutes of your meeting will be people discussing which button someone should have clicked instead during the install. Finally, find a scribe. If you do not have someone on your team who can help you, you might have to ask a participant to help you scribe while you try to facilitate and elicit.

Alright, you have your basic tools. First order of business, send out the meeting invite. Don't make this the standard meeting invite you see everywhere else, subject line and no description. Make sure that you include the objective of the meeting and the rough agenda. Step two, make sure everyone is introduced over the phone. Always good to go over who is in attendance and the role they are playing in the meeting. While introducing everyone, it is wise to have the meeting objective and agenda displayed on your projector and online screen sharing tool of choice. Make sure that you are located close to the phone so that you can repeat what was asked or stated and by whom.

While the meeting is going on, be sure to bring up a notepad or word doc on the screen to jot down any action items that come up. Be sure to write down who owns the task and their contact information if you do not already have it. Just having the task title isn't a nice thing to come back to and try to figure out, so add some context. Simply writing down "Get everyone's buy-in" is tempting, but please include the people involved in 'everyone and on what document/process the buy-in is needed on. At the end of each day, send out your notes to all the participants along with the list of to-dos to the owners. You might have to keep track of the to-dos and make sure their owners complete them.

When a white boarding session strikes, pull out your tablet pen or Visio program and start tossing up a copy so that everyone is involved. Much easier than describing which line connects to which box that resembles something more of a rhombus. Doing this will allow for the people over the phone to quickly understand the topic being discussed and add in their knowledge to the debate. True kudos if you are actually able to secure or setup a webcam that will allow you to broadcast the white boarding, removing the lost in translation possibilities.

These are just some basic pointers to holding elicitation meetings over the phone that can save headaches and money for your project. Do you have any phone elicitation pointers or standard operating procedures?

ProductCamp Austin is this weekend!

ProductCamp Austin is just around the corner! It's this Saturday from 9am-3:30pm. I unfortunately am out of town yet again for it, but Tony Chen will be representing Seilevel at it this summer. Hope to hear great stories back from everyone attending!

A Product Manager By Any Other Name...Still Writes Requirements

When I was younger, I used to care a great deal about people's titles. Maybe it was my little brain's way of organizing people like I organized my Tinkertoys (teachers go over here, doctors are over here, mommies are in this section...). In any case, I believed that a person's title told you all that you needed to know about him or her. I had grand plans for my own title when I grew up. I decided to be a "Professional." "A professional WHAT?" I'd often get asked, and I'd simply reply, "Oh, I don't know yet -- but whatever it is, I want to be a PROFESSIONAL at it." The work didn't matter, but the title did.

Many people, as I did, place a great deal of emphasis on titles. On the Seilevel message board there are multiple threads discussing the differences between Business Analysts, Requirements Analysts, Product Managers, Project Managers, Systems Analysts, and even humorous entries like Requirementers, Information Vigilantes and 'Shall'icitors. In my career I've held the titles of Program Manager, Requirements Analyst, Manager of Requirements Management (say that three times fast), Business Systems Analyst, and Product Manager. I've done pretty much the same work in all of those jobs. Instead of worrying about what my business card says, I focus on doing my job well.

A recent example shows how other people may not share my perspective. During lunch a few weeks ago, a friend was describing someone he works with. "She's a 'Product Manager,' whatever the heck THAT is," my friend chuckled. But did she do her job well? Did she help build great solutions to difficult problems? I don't know, because my friend "checked out" once he got to her title. To him, the title might have sounded silly, or been unfamiliar, or been tainted by previous experiences with sloppy Product Managers, but it was all he knew of her. By focusing on her title, he had lumped his co-worker (and me, although he didn't know it) in with the rest of the silly or sloppy people he knew.

So what DOES a Product Manager (PDM) do? Product Managers outside IT typically focus on understanding their marketplace and seeing that successful products are developed and released to that marketplace. Within IT, a PDM has a similar role. He or she is responsible for the end user adoption of and satisfaction with a product. The PDM is also responsible for the return on investment of that product.

In IT, a product may be anything from shrink-wrapped software to customized tools created for use within an organization. The PDM defines or identifies the scope of the program, project or release by understanding it in relation to the related business objectives. The PDM elicits, models, defines, documents, reviews and baselines requirements. She or he also manages changes to the requirements, supports and often participates in user acceptance testing, and supports product rollout and adoption activities.

All of these responsibilities help ensure that the product released meets both the business objectives and the users' needs. Given the wide range and financial impacts of a PDM's responsibilities, what does it mean to do that job WELL? To me, the most important aspect of being a great PDM is taking ownership of and pride in your product. If you believe and act as though you will personally make this product a success, you will do a good job as a PDM. If others are getting frustrated with your constant involvement, your probing questions, and your unwavering focus on product success, you're on the right track!

Whether you're a PDM, Business Analyst, Requirements Analyst, or some other flavor of requirements professional, don't let the debate over titles distract you from doing a fantastic job. After all, it's your work that matters, not your title.

Who Does Your Consultant Work For?

There is an interesting article by Robert Cringely at pbs.org about IT consultants. I disagree with the categorization of types of consultants however the article is interesting because he mentions the following case:

"What led me to write this column were the troubles of a local company here in Charleston -- American LaFrance, the storied maker of fire engines. American LaFrance was last year spun off from Freightliner, the big truck manufacturer, which agreed to maintain the company's computer systems for a few months while the new American LaFrance bought its own systems with the help of a big IT consultant that rhymes with I-B-M. At the time of the cutover the project was months late and millions over budget. The company suddenly had no idea where it stood in any part of its business and today is in bankruptcy likely as a result."

He then goes on to suggest that the issue was primarily one of bad requirements. The story reminded me of a presentation that I attended by a turnaround specialist. He made a living going into trouble companies and fixing them. He said that he could find all his customers by just following around PeopleSoft (or any large ERP vendor's) salespeople.

Wherever they sold their software, the failed software implementation would take down the company!

He said that the primary reason that the software failed was not because the software was bad, but because management wasn't willing to force the business users to change their processes to accomodate the off the shelf software.

As a result, the IT team had to accomodate every whim of the business.

Sound familiar?

What Oprah Can Teach You About Software Requirements

My wife's a fan of the Oprah Winfrey Show (yes, I've been known to watch it from time to time myself). A few days ago, my wife told me about a woman who was on the show. The woman was telling Oprah about her philosophy that people only ever have good intentions, even when they're doing something that's infuriating to you.

Somebody cut you off in traffic? Maybe they were trying to get home to a sick child. Somebody else tell you that you can't take that training class you were promised earlier this year? Maybe those savings will let your office-mate keep his job. If you're willing to look for them, you can usually find a possible good intention behind people's actions. But why should I care about their reasons? I'm hacked off!

The speaker's point wasn't that we should be nice to other people because of their intentions. Instead, it was that we'd all be much happier if we assumed the best of others' intentions. Rather than getting mad because Sally is out to get me, or Tom is just plain mean, or Jack is a jerk, you can be happy because they're each trying to do something good. Sound a little too Bobby McFerrin? A little too "turn that frown upside down," or "buck up little camper?" It certainly did to me.

But, given my rather nasty mood one day, I decided to give it a shot. It couldn't make me feel any worse, plus it would get me brownie points at home. For the past week, whenever someone has done something that annoys me, I've looked for a possible reason why they did what they did (I'm not actually asking anybody why, just pondering possibilities). And it's working.

For example, when I thought about why somebody was driving so fast, or tailgating me, or zipping in and out of traffic, I wondered who they were in such a hurry to see. That simple change of perspective made a huge difference in how I perceived their actions (and by proxy, them as people). And then I thought about the people I'd be in a hurry to see, which led me to think about my friends and family, not about the reckless driver.

Before you ask, "And this has what, exactly, to do with product management?," (unless you already have), I'll get to the point. In our work, we deal primarily with people, and dealing with people is hard. It's easy to let someone else's actions (or inactions) frustrate me. But now I have a tool to help me reduce that frustration. And more importantly for my customers, asking, "Why did she do/say that?" is a great way to discover the real requirements hiding just out of sight.

Go on ... give it a try. Hopefully it'll surprise you, too. And if not, I'm sure Oprah would love to hear from you!

Are UI Requirements Software Requirements?

User Interface design is often assigned responsibility for look-and-feel. While I understand the importance of UI design, I am highly dissatisfied by its reliance on "heuristics" and, frankly, the uneven quality of those who profess expertise in the subject.

I submit that UI needs a haircut -- that we should limit the scope of what falls into the realm of UI. I think look-and-feel might be a better overarching category, but even that is too broad. The underlying flaw is that practical UI is rarely formally tested and less frequently permanently linked to business objectives.

The next revolution in requirements will be traceability or -- as I prefer to say -- connectivity. To me, traceability implies a one-way progression from objective, to requirement, to specification, to development, to test, with each transition as a one-way gate, during the passage through which one must abandon all hope of returning. Connectivity, on the other hand, is the continuous, two-way link between

• Business Objectives


• Marketing Objectives


• Functional Requirements


• Development


• Testing


• Usage

Such that any shift in one puts pressure on the others. It is connectivity that provides for not only rapid development, but presents the possibility of instantaneous development. Being able to modify a product this way depends wholly on being able to pick up the thread and see where it tugs. Before this was left to intuitive judgments, which were imprecise and incomplete leading the product into an inevitable "slow drift" away from the original business objectives.Imagine that you wanted to capture a certain "feel" as a marketing objective...

Why? Well, let's say that you believe "slippery" is the feel that would increase sales for a certain segment (amphibian programmers, say). If you can make that testable connection, even if it proves that there is no correlation, you have created an underlying framework to test your inference.

Even the softest requirements should be "connected" to business goals. If creating such connections seems like too much trouble for the requirement, chances are you're not dealing with a requirement in the first place.

Is Your Product Knowldege an Asset or Liability?

There was recently an interesting post by John Mansour on the Austin PMM Forum (registration required) discussing whether Product Knowledge was an Asset or Liability to product managers.

The author makes several claims about how product knowledge is a liability:

"In a nutshell, the more product knowledge you have, the less product
management you're doing because your product knowledge gets you sucked
in to a plethora of non product management issues."

"Furthermore, too much product knowledge leads to micro management - the kiss of death for anyone in a leadership role."

"Detailed product knowledge = liability because you can't see the forest from the weeds."

"Detailed product knowledge = liability because it forces you more into 'how' features should work instead of 'what's needed and why' from a business perspective."

"The more you know about your product the more difficult it is to position its true value. "

I have to disagree with Mr Mansour that these are true liabilities, in the sense that the absence of product knowledge doesn't truly mitigate the liabilities. Good product management is fundamentally about good product management.

It's your job as a good product manager to avoid running down the ratholes that you could run down as a result of your product knowledge.

Secret Skills and Qualities of a Great Product Manager

I was giving some thought to what it meant to be a good product manager. There are many good posts written about the typical analysis skills found in a product manager, so I wanted to think a little outside the normal box. Here's what I came up with:

• Thinking on their feet – We spend a lot of time in front of busy users, project managers, and developers, who are smart and know their business well. At times, they are intense. They will ask tough questions of us, and probably even more challenging than that, they will state things that we need to be able to understand quickly and ask questions back intelligently. Too many blank stares, uncomfortable silences, and “uh, I don’t know”s will help us lose your credibility fast.


• Thoughtful – We are interviewers often, and so with that we must be willing to listen and think about what they say. This is different than quick thinking, but rather truly deep thinking. It will require some skills of empathy and understanding when the teams are frustrated. It will require just being someone that cares (and not faking it!).


• Likeable – I hate to say it, but we have to be likeable. We work with so many different people through the course of our work, and we really need these people to want to help us get information from them. People enjoy helping people they like, so be likeable.


• Must like people – Again, we work with so many different people who believe in us, trust us with their products. So complimentary to the last point, we must like the people we are working with. We have to want to talk to them, to tell them how it’s going, to ask them questions – simply put, we must be willing to engage in conversations. While being an introvert is very helpful to the analysis work that must sometimes be done quietly alone, being an introvert all the time will not lead to successful product management.


• Passionate –We have to love things! It sounds silly, but passionate people can feel things, both positive and negative about products around them. We can recognize and engage passion in the users we are working with. It shows itself as excitement, which can be addictive in a group.


• Excellent Reviewer – Not only must we elicit and document requirements, we have to self-review and peer-review the work. Being able to find missing items, or inconsistent requirements across volumes of data is not trivial. There are models and tools to help this, but so far, none of them completely take the thinking out of it. I have found that this is one of the most challenging skills to teach someone to do.
  

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.

Know Thy Product

I read a post recently in the Austin Product Managment Yahoo Group stating that Product Managers should not know their products. The author's theory is that PdM's who know their product will not be able to effectively manage their product.

"In a nutshell, the more product knowledge you have, the less product management you're doing because your product knowledge gets you sucked in to a plethora of non product management issues."

I disagree with his underlying premise that product knowledge and product management are incompatible. I think a good product manager does need to know their product, but as important, they need discipline. As it turns out, the author partially agrees with me.

"Product managers need to know their products, but not so well that they mortgage their ability to lead others, influence key decisions and articulate value."

However, he appears to believe that once a PdM has too much product knowledge, the discipline needed to perform the duties listed above is lost. While it may make being a PdM harder, it doesn't make it impossible. In the end, a PdM with strong knowledge of their product and discipline to excute their responsiblities is a winning combination.