ArgonDigital - enterprise automation experts

Share This Post

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 1×1 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 – Stakeholder Analysis Discussion

More To Explore

AI to Write Requirements

How We Use AI to Write Requirements

At ArgonDigital, we’ve been writing requirements for 22 years. I’ve watched our teams waste hours translating notes into requirements. Now, we’ve cut the nonsense with AI. Our teams can spend

ArgonDigital | Making Technology a Strategic Advantage