I read a very good article by Alistair Cockburn (no online link…sorry…dead tree magazine, by subscription only) that discusses the likelihood that many stakeholders use "game boards" to direct their activities during requirements elicitation. Quoting (with proper attribution!):
"[W]e really can't understand what is happening on the project without taking into account the side games that people are playing at the same time."
Better Software Magazine, August 2007, pg. 33
The concept here is that everybody, including and especially stakeholders, use "game boards" that can be predicted using activity theory. As an example, a project sponsor may be (quoting again) "…playing on game boards centered around career growth, relationships with peers, and relationships with other communities (user communities, business partners, etc.). The outcome of the game called build system X is evaluated by the sponsor with respect to how his position changes on all those other game boards."
My question for y'all is, "How often do we move beyond the things we need to know about the project at hand, to understanding what it is that makes our stakeholders tick?"
Thoughts?
Update:
Thanks to Mr. Cockburn for providing an online link to his article in comments .
August 27th, 2007 at 3:49 pm
For me, building up a comfortable relationship with the stakeholder is the best way to get a good enough rapport going to really get at their core requirements. Empathizing with personal issues is always a good way to build a relationship.
Some of my stakeholders have had a bad perception of “IT” as people who come in and install software without any real understanding of the business. I really had to work with them to make them realize that my job function was really to listen to what their requirements were so that IT could design a solution to fit their needs.
September 14th, 2007 at 10:37 am
I agree with Tom about the importance of perception. For each project I have a domain specialist assigned to work with me. This relationship is crucial to the project and I work to make us become a team, what means, sharing the same vision. Most of times, it's my vision that adapts to meet their visions, but it's part of our area's orientation. About games, it's true that their visions are not limited to the project scope and other subjects, most personnel always interfere. It's common for me to have a hidden goal in my projects "help on my partners career growth". Kerber ITBA - Digitro Technology www.digitro.com www.kerber.com.br
November 4th, 2007 at 5:10 pm
I finally was able to put the article online, see
http://alistair.cockburn.us/index.php/Games_stakeholders_play
This way other people can see the article text and discuss it properly.
many thanks — Alistair
November 6th, 2007 at 7:05 am
Wow, that´s cool, Alistair Cockburn writing a post just bellow mine in this great blog. I´ll print and keep it! I love Internet!
Mr. Cockburn, we are assembling a business analysis area in my company (Dígitro Tecnologia, south Brazil) and after we read your book “Writing Effective Use Cases”, a revolution is going on here. People really discovered the power of use cases to define functional scope and for the first time in many years we are closing projects with no problems related to scope definition.
I believe you have seen this before in other companies but it´s great to see people around the area talking in terms of clouds, kites, sea level and fishes, using those icons to define scope and level and really discussing each subject on it´s right level.
I know the book is not new, but for us it was and it was a great help to make the leap.
We learned about your book it in the Howard Podeswa´s “UML for the IT Business Analyst: A Practical Guide to Object Oriented Requirements Gathering”. Your books are the pillars of our product scope documentation and of our culture change.
thanks.
Kerber ITBA - Digitro Technology www.digitro.com - www.kerber.com.br