How to be an Effective "Stake Holder"

Part 1- Introduction

Every software project has "Stakeholders". There are other terms used for this role such as "Internal Customer", "Steering Committee Member", "Department Head", "Boss", "Sponsor", "Champion", etc. Sometimes stakeholders are formally identified (usually by assigning them to a project directly) but there are also lots of informal stakeholders as well.

While the context for these articles is software development projects, in my experience being an effective Stakeholder is consistent across all projects and the same guidelines apply consistently for other projects as well, e.g. marketing projects, facilities projects, etc. As a Director of Information Technology, I play the role of Stakeholder on some projects and been on the delivery side on other projects. I've worked on projects that are internally delivered as well as worked as an external consultant. So I have seen the Stakeholder role from a number of different angles.

This introductory post gives you an introduction to the role of the Stakeholder and what is expected from you if you have been assigned as one. In future posts, I'll provide some specific techniques, guidelines and suggestions for managing and influencing project teams for Stakeholders.

Your Boss Comes to You with a New Project...

Here are some really bad but unfortunately typical ways that Stakeholders get assigned:

• Your boss has been assigned the role and doesn't want to do it. So he or she delegates it to you. You can continue to delegate down if you choose to do so. I've actually had this happen to the point where the original stakeholder was the VP of Marketing and by the time the project had started a junior copy editor showed up saying, "I was told that I'm to represent marketing on this project"!
• You're in a role of authority and someone on the project thinks you should be consulted. For example, you're the Director of Marketing and someone in HR decides that they want to change the web site to have job postings. You get roped in because you've issued the policy that no one changes the web site without your input. You're now a Stakeholder!
• The project is half way through and someone realizes they need your input. This happens to Operations teams a lot - 80% of the way through development, someone on the team realizes that they need 10 more servers! As the person owning this non-budgeted purchase you're now a Stakeholder!
• You're asked to join or are already part of a committee that regularly meets to discuss general issues. For example, many organizations have branding committees, privacy committees, project review committees, etc. Sometimes projects will make the entire committee a Stakeholder. I had this experience once working on a project building a government web site - there was a permanent "web committee" with 7 members on it who had to meet on every issue and come to consensus on every change. The entire committee was a Stakeholder.

If you find yourself getting labelled as a Stakeholder in any of these scenarios, beware! They are high risk and put increased risk on the project.

Recommendations

Here are some recommendations on when to sign-up to be a Stakeholder.

• Be empowered and qualified to be a stakeholder. The primary role of a Stakeholder is to make decisions and provide input. If the project is expecting a VP level Stakeholder and they get the VP's secretary, they're not getting a stakeholder who is qualified or empowered to make decisions.
• Avoid Stakeholder proxies. Stakeholder proxies are people who show up to all the meetings, collect a lot of notes but then cannot make decisions on their own. If the answer to questions asked of you is typically, "Well I need to ask my boss whether we're allowed to do that" then tell your boss that the project really needs the boss to be the Stakeholder, not you.
• Be prepared to commit a minimum of 2-3 hours a week to the project. If you cannot commit to the time, then having you in the loop just creates additional communications overhead for the project team.
• If you are primary stakeholder or if you are providing extensive documentation, business expertise, or testing support then expect this time commitment to be considerably higher. For example, we had a project to deliver a new B2B order entry system. One of our stakeholders was the person who ran the B2B business. During requirements gathering, she was involved in the project about 20-30 hours a week. During development, she was involved about 10 hours a week to clarify requirements, approve changes, etc. During testing, she was involved 40-50 hours a week to help test key functionality, provide clarification on missing requirements, facilitate testing with other people in her department, etc.
• Stakeholders should be established up front and given ample warning of expectations. You should know you're on a project from the beginning even if you won't be needed until further down the line. In addition, you should have a context for the entire project and not just be isolated to your area.
• Beware of people randomly assigning you as a Stakeholder through conversations in the hall, informal emails, etc. It may come back at you if the project turns south.
• The inverse of the above is don't assign yourself as a Stakeholder simply because you're in a position of power. Simply inserting yourself into a project is not an effective way to be a Stakeholder. In addition, don't take credit for projects where you just went to a single meeting - that's not being a Stakeholder!
• If you work in a traditional departmental structure, switching to a project based model will require radical changes in how department heads interact with project teams. Many Directors assume that if a single resource of their department is on any project, they automatically get to have a say in every project decision. Even worse, some Directors simply reserve the right to sit on the sidelines and snipe at the project teams at any time at random. You'll see this in emails coming from Directors that start with, "I noticed this project is trying to use MY resource (equipment, people, brains, etc.) and before I ALLOW YOU to do so, I must REVIEW AND APPROVE this project". Don't assume that just because you're a Director you're automatically a Stakeholder on every project!
• Avoid projects where there are many Stakeholders, especially if there is no Stakeholder hierarchy or specific areas of ownership. Here is a good sign of too many stakeholders - if there are more stakeholders than project team members!
• Try to be on projects where you have a personal interest in their success. This creates investment, accountability and passion. Part of your role as a Stakeholder is to be a champion, so having a personal stake in the success of the project makes a huge difference for you and the project team. If your career is on the line because of a project, do you think you're going to be a great Stakeholder and do what it takes to be responsive? Lesson to executives - make your Directors bonuses tied to project targets, goals and successes and not just the running of the department.

Depending on where you work, you will more or less control over the projects in which you are responsible. However, all this means is that the techniques you use are more or less political There are lots of ways to get on and off a project - some of them explicit and some of them implicit (More on this in future posts). In addition, if you have no choice but to be the Stakeholder for a project then there are things you can do to improve your contribution to the project and ensure a greater chance of success.

Stay tuned for future posts for more recommendations on how to be a better Stakeholder...