All you want to know about Stakeholder Management

Alec Satin of the "Making Project Management Better" weblog has a brilliant list of links to Stakeholder management resources.

From his explainatory text:

In this list are articles to get you thinking about some of the less obvious issues in pleasing stakeholders. Primary selection criteria: (a) quick to read, (b) good value for your time, and (c) of interest whatever your level of experience." Markup is mine.

Enjoy!

11 Rules for Prioritizing Features in a Customer-Oriented Organization

Name: 11 Rules for Prioritizing Features in a Customer-Oriented Organization
Type: Rules
Status: final
Version: 2008-04-11

Gist: While prioritizing features, people people quite often take a ranking approach in order to balance different stakeholder's perspectives. This really may prevent satisfied stakeholders (or a shot time to market), and may lead to a mediocre release plan. Why? The math used in most ranking approaches is wrong. Here are 11 Rules for proper prioritization.

Source: http://tynerblain.com/blog/2008/04/09/improved-prioritization, thanks to Scott Selhorst for yet another great idea. Go there if you need a more visual explanation. I added my bits and pieces.

Prerequisites:
E1: You have a list of features gathered from various stakeholders.

E2: Your stakeholders are of different importance. ' maybe one represents the customer of your product, another is development/manufacturing, yet another is some governing technical department. Read about Finding Key Stakeholders.

E3: Each stakeholder has ranked all features, with smaller numbers for the more important ones.

Rules:
R0: Make sure you have a proper understanding of the goals (read Specifying Goals and Decomposing Goals) of the project or product. Make sure you understand your set of stakeholders in the light of the goals.

R1: Ignoring E2 above, the simplest approach would be to add the ranks for each feature and - voila - the features that are ranked best on average win.

R2: Not ignoring E2, don't make the mistake to give each stakeholder a weight and multiply the respective ranks with the weight before you sum the rank-numbers. This only works if you have lucky numbers.

R3: You can do like R2 suggests, but then you have to reverse the ranking numbers of E3, giving large numbers to the more important features.

R4: You should think hard what the stakeholder's weights represent. If you have one stakeholder that is more important than the others, it's paramount to make him happy, at least not to upset him. Do this by delivering his important features first, and only after that you think of features for the other stakeholders.
Note: Take the example from E2. I bet the purpose of your business is to make the customer happy.

R5: Make sure you do a Kano analysis in order to find features nobody thought of in the first place. This may be your advantage over competitors.

R6: If confronted with a large (> 20 items) list of features, let the stakeholders break it down into importance classes first. It's virtually impossible for the average stakeholder to truely rank so many items.

R7: Don't give in if your stakeholders say they need to know the costs before they can rank the features. You want to know what they want to have! You can always work out things to be cheaper, especially if your features are real (business) requirements, not solutions disguised as requirements. Bear in mind: "If you don't know the value of a feature, it does not make sense to ask what it costs ". (Tom DeMarco)

R8: If your features are Use Cases, go here.

R9: if all the above does seem to simple, revert to Karl Wiegers (First Things First), Alan Davis (The Art of Requirements Triage), Don Firesmith (Prioritizing Requirements), Lena Karlsson (An Experiment on Exhaustive Pair-Wise
Comparisons versus Planning Game Partitioning), or QFD.

R10: Read Mike Cohn (Agile Estimating and Planning).

10 Principles for UI Design

Title: 10 Principles for UI Design
Type: principles
Status: final
Version: 2007-09-03

Gist: to support good user interfaces. These principles can be used in an attempt to test UI very efficiently without doing usability studies.
Note: In one of my projects we designed a user interface for a handheld device running Windows Mobile. It seemed apparent that it is not useful to mimic a Windows-like UI with windows, tabs and long lists. After the fact I read a lot of 'our' ideas in Jakob Nielsen's article. Thank you!

Source: Jakob Nielsen, thanks to Scott Selhorst


P1 interacting: Does the system provide information about its status? [”Please wait while the system is updating”]
P2 familiar: Does the system use terms and language that are familiar to the user?
P3 oops-tolerant: Can mistakes easily be undone? [”Undo” and “How do I get back to where I was from here?”]
P4 consistency: Does the system use controls (buttons, links, words) to enable actions consistently [”Yes” vs. “OK” vs. “Apply”]
P5 error preventing: Does the system help prevent common user errors?
P6 obvious: Is it easy for users to see what they can do, versus being forced to remember what they can do?
P7 user differentiating: Are there ways for expert users to be more efficient than novice users?
P8 minimal information: Are users forced to filter out irrelevant information (minimalist design)?
P9 useful on errors: Do error messages help users to resolve the errors?
P10 documentation: Is the documentation searchable, task-centric, and precise with “how to” steps?

Kick-ass or at least suck-less Design

Title: Kick-ass or at least suck-less Design
Type: principles
Status: final
Version: 2007-09-03
Gist: to explain how to design kick-ass products (or at least suck-less products)
Source: Michael Shrivathsan, with some minor addition on my side. Thanks to Scott Selhorst for bringing me this stuff.


P1: Start With the User Interface - because this is the only thing your user will see.
P2: Work Closely With UI Designers - because of R1
P3: Pay Attention to Details - because it's part of the success of Apple Computers :-)
P4: Simpler is Better - because more features are worse
P5: Be Brave - because you need something that differentiates your product from the rest
P6: Be passionate about your own product - because if you're not, chances are nobody is.

Means and Ends again

Title: Means and Ends again
Type: citation
Source: Kathy Sierra

What good does it do to master a tool if we haven't understood (let alone mastered) the thing we're using the tool for?

Humane Interface Design

Title: Humane Interface Design
Type: Principles
Status: final
Version: 2007-08-22
Gist: guiding you in making decisions when designing a user interface.
Source: An article on Shmula on humane interface design. I stole it completely because I like them so much. Did not add anything.

P1) It's not your fault.
P2) Simple things should stay simple.
P3) Fewer choices mean fewer worries.
P4) Your data is sacred.
P5) Your train of thought is sacred.
P6) Good interfaces create good habits.
P7) Modes cause misery.

Clear Conceptual Writing

Title: Clear Conceptual Writing
Type: Process
Status: final
Version: 2007-07-15
Gist: To explain how to amplify skills for writing information texts (not fiction or poetry). You can apply it to the introductory or explaining parts of requirements and design specifications.
Source: Michael Covington and my own experience.

S1: Planning: Decide what to write about. It's not important to have a very clear idea about the subject yet. It will evolve.
S2: Planning: Decide, for whom you are writing. if you don't know much about your audience, go and find out first.
Note: Writing is about transferring ideas. Although it can be used as a thinking tool for yourself (like this blog), it was invented to express ideas for others to read. Keep in mind that your writing tells something about you, whether you make it easy for you or easy for your audience.
S3: Planning: Every section has a purpose.
S4: Drafting: Write everything down. So you don't have to juggle with ideas in your head.
S5: Drafting: Concentrate on the what, not the how. It's okay if only you understand what's on the paper.
S6: Drafting: Get to the point. Say the main point of every paragraph in its first sentence, then provide the reasoning that leads to the main point in the following sentences.
Note: Mark Twain once said "Establish the facts first! You can mess them up afterwards."
S7: Revising: Make your text as easy to read as possible. Use someone who does not know about the topic to find out if it's understandable. Your kids or your gandparents should be able to understand what you say.
S8: Revising: Shorten your sentences. Then shorten them again.
S9: Revising: Think of ways how your sentence can be misunderstood, e. g. by reading it aloud several times and stressing different words in each pass.
S10: Editing: Fix the grammar, spelling an punctuation.
S11: Formatting: Keep it simple and standard, avoid meaningless variation.

Finding key stakeholders

Name: Finding key stakeholders
Type: Process
Status: Draft
Version: 2007-05-24
Gist: How to find the stakeholders who should be treated special.

S1: Brainstorm all possible stakeholders
S2: Find the stakeholders who will be the greatest in number.
S3: Determine the 1-5 stakeholders who will impose the highest risk of rejecting the product.
Note: The product may be good, but stakeholders can still make your product development a failure. See this formula.

User-Centered Development / Personas

Name: User-Centered Development / Personas
Type: Rules
Status: finished
Version: 2007-05-07
Source:
www.disambiguity.com/yes-you-should-be-using-personas/
www.evolt.org/article/Practical_Persona_Creation/4090/56111/index.html

Gist: support the concept of user personas for requirements definition and for getting rid of the elastic user
Note: You can also use your personas {for prioritizing tests, to evaluate new ideas for features, for requirements triage, for writing the user manual] (not a complete list).

R1: User personas should be created to find the "edge cases", use cases that make a difference within the product. Wipe out featuritis with your personas.
R2: Personas should be created with the help of stakeholders.
R3: Don't overdo it (1-3 sentences). Don't define too many (2-6).
R4: You need a complete buy-in on the personas from people who are supposed to use them
R5: Do *some* creative writing when creating personas. Small details matter.
R6: It helps putting a name and a face to the personas. Go out and take photos or cut out magazine pictures.
R7: Group personas as 'primary' (the majority, the most important) and secondary (very different from the primary personas but still very important)

Principles of Clear Thinking

Type: Rules
Status: Draft
Version: 2007-12-20
Quelle: Principles of Clear Thinking. <- Blog on http://www.blogger.com/www.gilb.com 2007-03-27 (R1 to R10); rest: own thoughts
R1. You have to have a clear set of objectives and constraints, to evaluate proposed solutions or strategies against.
R2. You have to have a reasonable set of facts about the benefits and costs of any proposed idea, so that you can relate it to you current outstanding requirements.
R3. You have to have some notion of the risks associated with the idea, so that you can understand and take account of the worst possible case.
R4. You have to have some ideas about how to test the ideas gradually, early and on a small scale before committing to full scale implementation.
R5. If there are more than very few factors involved ( 2 to 4) then you are going to have to use a written model of the objectives, constraints, costs, benefits, and risks.
R6. If you want to check your thinking with anyone else, then you will need a written model to safely and completely share your understanding with anyone else.
R7. You will need to make a clear distinction between necessities (constraints) and desirables (targets).
R8. You will need to state all assumptions clearly, in writing, and to challenge them, or ask ‘what if they are not true?’
R9. You will want to have a backup plan, contingencies, for the worst case scenarios – failure to fund, failure for benefits to materialize, unexpected risk elements, political problems.
R10. Assume that information from other people is unreliable, slanted, incomplete, risky – and needs checking.
R11. Assume that you models are incomplete and wrong, so check the evidence to support, modify or destroy your models.