How to be an Effective Stakeholder - Part 2

The Role of the Stakeholder
Part 1 - Introduction

Stakeholders who are effective on projects understand their valuable role. This post articulates what effective Stakeholders bring to the table.

There are a few different types of Stakeholders:

• Direct Customers: if you're lucky, you get end-users as stakeholders. These are great to have because you know that these users represent actual end users who will use the application on a daily basis.
• Domain Owners: some stakeholders are involved in software projects because of their domain expertise. Software developers are good at building software, but they're usually not domain experts as well (although some will claim to be). So if you're building a financial application, its important to have someone on the project who knows the minute rules on accounting. Not only is it important to have general expertise, but it's equally important to have domain experts who know the specifics of the business. There are dozens if not hundreds of hidden business rules in any business and in many cases they are only learned through oral tradition. Domain owners provide this expertise.
• Customer Group Representatives: if you cannot get direct customers or if your user base is large, then you need to have Stakeholders who can represent the needs of the customer. Be careful about this in that it's important that the Stakeholder is an accurate voice for the customer and doesn't have their own agenda.
• Business Representatives: general Stakeholders that represent the actual business. If the business is selling soft drinks, then it's a good idea to have an understanding of how the actual business works and how your application will fit into and support the business of selling soft drinks. In any business, there are also specific experts who own global business areas such as marketing, security, privacy, branding, and customer service. These horizontal service areas are not specific to any vertical project but cross all projects being delivered.

Regardless of the type of Stakeholder, here is what I'm looking for them:

• Decision Making: a Stakeholder's primary responsibility is to make a decision. Should we charge the credit card before we ship the product or after? Should the name field be 100 characters long? Should the colour of the button be purple or blue? There are hundreds of decisions that a software team must make and your role as a Stakeholder is to make the call when asked.
• Approvals: similar to Decision Making, your job as a Stakeholder is to approve documents, decisions, milestones, etc. When I was a Stakeholder on a project with Accenture, they would send me test cases to review. I would simply reply with a single word, "Approved." Especially with external vendors, teams need a formal mechanism for sign-off before they can move forward.
• Opinion and Feedback: in building web sites in particular, there are lots of subjective decisions on what a web site should look like, how it feels, whether it represents the brand, etc. As a stakeholder, your primary job is to have an opinion that can be translated into actions, revisions and improvements. An example of a poor opinion: I saw a graphic design present a screen design to the Creative Director. His opinion was, "I want exactly what you have, but just bigger and bolder!" How is someone supposed to action that opinion? A good opinion is, "I hate that text - its boring and its too long." It's just as subjective but at least you can action it.
• Solicitation of Feedback Amongst the Broader Community: Most Stakeholders represent their department, a user community or a business unit. Key deliverables should be brought back to this broader community for feedback. As a Stakeholder, your job is to help explain, sell the concepts being presented and capture feedback that can be actioned by the team.
• Be Supportive Externally and Demanding Internally: Stakeholders should be evangelists for the team as it helps boost confidence for the team, helps provide buy-in from the great organization, etc. Internally, Stakeholders should be demanding like a good customer. Stakeholders should be keeping the bar high and making sure that the software team feels that they have to meet a high bar for quality and performance.

What frustrates software teams to no end is when Stakeholders are not doing their job. Here are some examples of where Stakeholders drop the ball:

• Showing up to Meetings Unprepared: if you cannot bother to take 15 minutes to read through a technical document that someone spent 2 weeks writing, what does this say about your level of respect for the team?
• Being Late with Approvals or Feedback: when I manage projects, I put review and feedback periods in the project plan. Stakeholders have deadlines for turn around of feedback. Yet time and time again, I've had Stakeholders miss their deadlines with really lame excuses. If you miss your deadlines for reviewing a document, what kind of commitment can you expect for higher risk activities such as building new algorithms or leveraging the latest technologies?
• Abusing the Team: this symptom seems particularly bad with external teams being managed by internal Stakeholders. There must be something in management training that tells middle managers to treat external vendors abusively in order to squeeze them for another 5-10% in performance. Unfortunately for many smaller and less mature vendors, the practice works which only reinforces the practice. However, in my experience a mature software team won't take abuse and understand the difference between having high expectations and simple bullying.
• Poor requirements: if you're supposed to be a Domain Expert, then you need to be able to know your domain. Ideally, your domain is well articulated through existing documents, manuals or practices. If you're supposed to be providing requirements to the software team, then these requirements should be well defined and articulated. Here is an example of poor requirements: we were supposed to build an online store for a client, but no one had given any thought to basic requirements such as tax rules, catalogue structure, content requirements, fulfillment, inventory rules, etc. When we asked basic requirements such as, "What are you current inventory rules?" the answer we got back was, "Well, we don't really have any rules - what do you suggest?". Argh!
• Us and Them: I would highly recommend for Stakeholders to embed themselves into the team as much as possible. The more that Stakeholders are part of the team, the better the communication. If you find yourself viewing yourself as the "customer" and not part of the team, figure out how to get yourself better integrated. Take the team for drinks, start coming to meetings, and support the team by doing your job. When Stakeholders build credibility with the delivery team, it means that when they actually need to put some pressure on them to deliver they'll have credibility to spend instead of simply crying wolf.

I've been on projects as a Stakeholder, a project manager, a technical architect and a sponsor. When the Stakeholder brings their value and integrates highly into the team, it makes a massive difference in the success of a project. If the Stakeholder is flying in and out, using politics and manipulation to get what they want, or being abusive in order to squeeze the team, it tends to put the entire project at risk. As a Stakeholder, I feel responsible for the entire success of the project and I'm not just there to provide input and walk away from the scene. In addition, I don't view software projects as ordering McDonald's whereby you simply throw in your requirements and drive up to the pick-up window to get your order!