INCOSE 2007 - Stakeholder Analysis Techniques

I mentioned in another post a talk on Using stakeholder analysis to define the problem in systems engineering by Tim Trainor and Gregory Parnell. In this post, I’ll summarize some of their points, but keep in mind these are just the highlights.


They talked about the following techniques for stakeholder analysis:

• Interviews
• Focus groups
• Surveys

They were quick to say that you are almost always going to use a combination of these techniques for the best success. Here are some highlights from each of the stakeholder analysis techniques.



Interviews:

• Make it a conversation, not just a set of questions and answers
• Engage the stakeholders to think out of the box about the future
• Be flexible and expands on interesting things as they come up
• Watch their body language – if they signal they are done, close and move on

Focus groups:

• Can be anything from 1 hour to 1 day
• Send out notes to the group after the session to share what you collected
• Thank each of the attendees individually afterwards

Surveys:

• Should take the participants only 5-20 minutes
• When you need quantity a larger quantity of responses
• Best for more junior stakeholders, not senior members of the team

They also touched on ideas for analyzing survey results, including grouping responses by questions or ideas to find redundancy, find the “golden nuggets” in the responses that aren’t repeated and summarize findings by question.

INCOSE 2007 - Stakeholder Analysis Discussion

I attended a talk at INCOSE called Using stakeholder analysis to define the problem in systems engineering by Tim Trainor and Gregory Parnell. This talk couldn’t have been any more perfect for me right now because I’m improving our elicitation training, so I was able to find some inspiration here!

They talked about the following techniques for stakeholder analysis – interviews, focus groups and surveys. I may summarize the actual content in a later post, but for now, the Q&A for the session was interesting. I’m paraphrasing the questions and responses here, as well as my own commentary.

Q - If you are doing interviews, what do you do if there are conflicts across the responses?

A – Bring the people back into a focus group to work through it.

My thoughts – You might be able to work out simple problems with going back to the people individually. If that does not work, then get them in the same room. It may not require a full blown focus group though. Though in some cases, it absolutely will be the main content in your focus groups.

Q – How do you gauge truthfulness of the replies, particularly in interviews?

A – Check them out! Do some research if there are conflicts or indications it might not be right. That said, people usually tell their perspective truthfully.

My thoughts – I agree, people don’t lie typically. However, they may have an incorrect perspective. Our job is to look at the problem space from different directions to uncover the correct view and requirements. By the way, if you find out someone was incorrect, it’s nice to talk to them 1x1 to let them know what you learned, so they do not look foolish down the road. But do this delicately so they don’t feel foolish in that moment either!

Q – How do you stop game playing in focus groups?

A – This is a big problem. Many times people are sent to a focus group to represent an organization, instead of attending to find what is best for the greater organization. As a facilitator, put the focus of the session on value instead of organizational segments’ needs.

My thoughts – I agree with this in principal. Honestly I don’t see a lot of this. But when I do, I like to try to focus in on the people with issues, without putting them on the defense. Rather invite people to open up and let the rest of the group help sway them.

Q – Senior leaders think they know what the user wants, but the requirements morph into a senior level perspective and context. However, reality is different. What techniques do you use to deal with this?

A – Senior leaders typically want you to talk to the users! They don’t see this problem very often.

My thoughts - I would agree with this, however add that you may need to sell senior management on the value of talking with the users and then assure them you will minimize their time.

Q - What if we are using spiral model and not waterfall, how does the interviewing work because you can’t talk to everyone?

A - You focus on a few people in the first iteration. Then expand to talk to other stakeholders in the next iteration. Just repeat this.

My thoughts – That most certainly is appropriate if you have a lot of people. You also should expect to have to talk to some of the same people again each iteration. Instead of scoping just by people for each iteration, you scope around specific functional areas and talk to whoever is required each time. Maybe some of your “interviews” turn into “prototype reviews” with people you didn’t get to interview in the prior iteration.

INCOSE 2007 - opening session

I’m at INCOSE 2007 this week, and yesterday I wrote this post while listening to the opening key note - Kuldeep Kumar Gharatya from the London Underground gave a fascinating talk called Mind the Gap: Applying SE to Address the Delivery Challenges of London Underground Programmes.

He is the head of the systems engineering and human factors organization ...so he works on many projects for the Tube! He has started an "unparalleled level of upgrade work" on The Tube. Clearly this is an example of a very complex project with many moving parts and suppliers which very well demonstrates the need for systems engineering as part of the delivery. And of specific to interest to me, he touched on the need for good requirements. I love that he started his talk by stating the basic business objectives for their project.

• Reduce journey time
• Increase capability
• Increase reliability

He quickly ran through them, so it’s not entirely clear what their measured improvements are (though I’m sure they have them!). However, we all know the 2012 Olympics are coming which clearly drives many of the objectives. As a side note, he made a funny point for project managers - this is one very large milestone date that is not moving!

Some examples of business requirements that map back to those objectives - faster trains and all of the stations will have no steps. As energy prices increase, they are also looking for ways to recycle energy from the heat the trains.

And an interesting challenge that is pretty common to many projects – they must keep the system running over the next 5 years while they upgrade and grow it. They make a comparison to open heart surgery. This is relevant to most of our requirements projects. The business needs to keep doing business. That doesn’t mean they won’t flex and allow for new approaches - just don’t disrupt their ability to do business.

I think we could all take a lesson from them on how they are reaching out to other industries. He is looking to the defense and aerospace industry for guidance on how to tackle new challenges. They are also working with the New York City Transit Authority to share ideas. There are many non-obvious commonalities across businesses. Processes we could learn from, design ideas, etc.

He ended with an interesting quote by Einstein - “We can’t solve problems by using the same kind of thinking we used when we created them.” I like this. It reminds me why at least in requirement work, we need really smart and creative people to do the business analysis.

Templates for Requirements Documents

Most organizations have come to a realization that they need to apply more process to their requirements gathering efforts. One of the common first steps in support of this is to develop common templates to be used for each document. The templates contain subheadings that are associated with many common groupings of requirements, and are designed to ensure that each type of requirement at least gets thought about.



So why do many projects that use good templates still fail?



Projects still fail because the templates are often used as a substitute for good requirements analysis training. Requirements analysis is more than just thinking about the different categories of requirements. One of the leading causes of project failure is missing requirements. Templates help make sure you don't miss a category of requirements, but do almost nothing to ensure that the requirements within a category are complete.

Categorizing requirements

I mentioned in a prior blog post that at the RE 06 conference I attended a session where the academic leaders in requirements assembled to try to hammer out a consistent nomenclature for requirements. I say try because even this group of esteemed experts made no progress on this effort. From my point of view there were two main blocks, the semantics of the actual categorizations themselves and the why behind categorizations. In this post I will focus on the second.


Since we create requirements for a living it is natural to ask why for everything. In this particular case, why categorize requirements, what is the purpose of segmenting requirements into categories, what are the use cases?


There are two very practical reasons for categorization, the first is to aid in training new people how to think about requirements, the second is as an aid in the discovery/review of requirements.


The most common nomenclature divides requirements into functional and non-functional requirements. Some call the non-functional requirements quality of service requirements. Regardless of the name, the non-functional requirements are further divided into a host of specific types of requirements such as reliability, availability etc. These subcategories are actually reasonably good at guiding a designer as to what types of requirements are missing. However the catch-all category of functional requirements is almost useless. When we do audits of requirements documents, inevitably this area of functional requirements causes the most trouble as no one seems to know what goes here.


Unfortunately I don't have the answers, but I do recognize that the gap exists. Please go over to the messageboard and participate in our discussion of types of requirements.

Suface Computing = Way Cool Computing!!!

Here is a link to a video showing Microsoft's new "Surface Computing" interface. Take a look -- this is bound to spark all sorts of ideas about how we might use it in the requirements process. Enjoy!!

Link from Popular Mechanics, of all places! ;-)

http://link.brightcove.com/services/player/bcpid932579976?bclid=932553050&bctid=933742930

Regards, Ned

Role playing scenarios to elicit requirements

I read an interesting article that is based on some research involving gathering requirements from children. The article is titled Child’s Play: Using Techniques Developed to Elicit Requirements from Children with Adults, by N. Millard, P. Lynch and K. Tracey at BT Laboratories in the UK (article found on IEEE).

The researchers used newly developed techniques to gather requirements from children and then applied those to sessions with adults. Their techniques are very interesting with regard to how you get people to think of ideas they are not conscious of, which is often the case with requirements for a new system.

Some assumptions the article is based on:
• “Work is not simply a process of data manipulation…it is a social artifact.” The thought is you cannot just automate a person’s tasks, but you must look at the requirements in the context of the “social context” and how that might change in the future.
• Requirements do not necessarily already exist, at least at a conscious level for most people. If you just ask them what they want, they will have a hard time anticipating the needs and thinking in an innovative way.
• Children inherently have a hard time expressing their needs freely, so new techniques are needed. They do have a greater ability to imagine, but it is within an experience they already know. And, they do not stay focused on a single thing for a long period of time, so they need to be interesting and dynamic.

In this research, they did a significant amount of role playing of scenarios. This took the pressure off a requirements analyst to pre-determine questions and pressure off the child to think up creative answers on the spot. Instead they put the children in context for the scenario, and let them act out the stories. They found that visual and graphical props for the role playing were valuable for helping the kids imagine the scenario. Once they acted out the scenario they would follow up with a brainstorm discussion, inspired by the ideas generated during role playing.

The premise for this is that it is not sufficient to ask people their opinions on what they want some technology to do. Instead, you put them in a model that lets them act out the scenario and imagine things they would never have just thought up by listing out requirements.

After working through it with children, they then applied this technique to adults. They presented specific scenarios that described social context, and had small groups of adults envision how a specific scenario might impact their job function. The group had to present their response back to the larger group in a form of role playing and storyboards. Again, they got better results from this, than from just sitting down to brainstorm ideas, because they forced the people to be context.

Now it did provide pretty extreme ideas at times, but that just provided more ideas for discussion about the realistic requirements. You can also control the extremeness by developing focused scenarios for the topic and appropriate social context for the project. The output of these role playing episodes, storyboards and brainstorm discussions should be realistic detailed scenarios that put the requirements in a useful context for design and development.

In the end, I’m intrigued enough by this that I’m going to make some attempt at using it in my role at Seilevel to come up with some new ideas. I’ll report back on how that goes!

Risk Management for Product Managers - Part Two

In my last post I gave an overview of risk and a risk management approach. In this post, I’ll discuss five common risks from a requirements perspective.

Perhaps one of the largest risks that we consistently see on projects is around business objectives - either not developing them or a lack of consensus among stakeholders. This should be at the top of your list of areas to examine for risk. This is an area that is sometimes difficult to develop risk responses for - if stakeholders don’t believe they need to develop or agree upon business objectives, how do you convince them? Education can help, but (unfortunately) so can experience.

A second category to check is scope creep. This is closely aligned with business objectives, since making sure you align your requirements with business objectives is the preferred method to ensure that you don’t get gold-plating in your requirements.

Another area to look out for schedule risks. How realistic is the schedule? Does it allow sufficient time for analysis and synthesis of the requirements you gather? Is there time to ensure proper requirements validation? What are the potential impacts to quality and project success if not?

Another category is particularly common for the requirements team - organizational risks. There could be several areas to check - resource availability, political, funding, and prioritization of projects. Resource availability is perhaps the biggest problem Product Managers run into, since unlike the Design team (for example), we cannot do our jobs by ourselves.

The last category of risks to consider is quality. Since we all know that getting requirements right is a critical success factor for project success, ensuring the quality of the requirements is key. What pro-active steps will you take to guarantee the quality of your deliverables?

Hopefully these ideas will serve as a start for you to begin thinking more about risks. Please feel free to comment on the message board about additional ideas you have.

Risk Management for Product Managers - Part One

You’ve probably heard about risk management before. It’s that thing the project team or project manager goes through at the beginning of the project and then forgets about, right? Well, hopefully not. Good risk management is something that needs to happen throughout the entire project lifecycle. Product Managers are in an excellent position to offer unique insight into project risk. In this post I’ll define risk and briefly discuss a process for risk management. In my next post I’ll examine some common risks from a requirements perspective.

A general definition of risk is the possibility of suffering a negative impact to the project, whether it be decreased quality, delayed completion, increased costs, or project failure. The flip side of risks are opportunities, which you can think of as potential impacts to the project than can improve quality, speed up completion, decrease costs, or otherwise increase the chance of project success.

In general risk management approaches are cyclical in nature. Here is the cycle I usually follow:

During risk identification potential sources of risk and potential risk events are developed. There are many sources for risk, so consider things like previous projects/lessons learned, input from team members and stakeholders, audits/reviews, status reports, scope change requests, etc...

During risk analysis, each risk should be analyzed for the probability that the risk will occur, and the impact if it does. Impacts can be measured quantitatively or qualitative - whichever method you select, be as precise as possible.

During response planning, strategies and plans are developed to minimize the effects of the risk to a point where the risk can be controlled and managed. Higher priority risks should receive more attention during response planning than lower priority risks. Every risk threat should be assigned an owner during response planning. Common methods for responding to risks include avoidance, transference, mitigation, or acceptance.

Risk monitoring is the part that many projects forget to do. It includes: looking for new or changed risks, tracking identified risks to see if they have occurred yet, reviewing the effectiveness of the execution of risk responses, and ensuring that proper risk management policies and procedures are being followed.