Active stakeholder participation

Why you need it

To succeed, your project team needs the active participation of a wide range of people, including users, management, and other software professionals.

Share:

Scott W. Ambler, Prectice Leader, Agile Development, Rational Methods Group, IBM

Scott W. Ambler is a Practice Leader for Agile Development within the IBM Methods group. He develops process materials, speaks at conferences, and works with IBM clients worldwide to help improve their software processes. Scott is author of several books, listed on his Web site at www.ambysoft.com. Scott is also a recognized Ratonal Thought Leader, whose homepage may be viewed here.



01 May 2001

A project stakeholder is anyone who is:

  • A direct user
  • An indirect user
  • A manager of users
  • A senior manager
  • An operations staff member (or manager)
  • A support (help desk) staff member (or manager)
  • A developer working on other systems that integrate or interact with the one under development
  • A maintenance professional potentially affected by the development and/or deployment of a software project

For the sake of Agile Modeling (AM) (see my previous tip on Agile Modeling), in this definition I exclude developers who are working on the project -- even though developers clearly have an important stake in the projects they work on, for AM the term "project stakeholder" will be used to refer to everyone with a stake in a project except for the developers directly working on it. Hence I refer to developers and project stakeholders as separate groups. (The alternative is to have terms such as developer project stakeholders and non-developer project stakeholders -- yuk.)

AM's practice of Active Stakeholder Participation is an expansion of eXtreme Programming (XP)'s On-Site Customer, which describes the need to have onsite access to people -- typically users or their representatives -- who have the authority and ability to provide information pertaining to the system being built and to make pertinent and timely decisions regarding the requirements (and prioritization thereof). While this level of participation is required to make your software development efforts effective, it often isn't sufficient in many organizations -- particularly those where politics and not reason are the order of the day. Project success often requires a greater level of involvement by project stakeholders:

  • Senior management needs to publicly and privately support your project.
  • Operations and support staff must actively work with your project team toward making your production environment ready to accept your system.
  • Other system teams must work with your team to support integration efforts.
  • Maintenance developers must work to become adept at the technologies and techniques used by your system.

It is clear that in order to be successful, all project stakeholders must actively work with your team to achieve these goals. There are several implications of this practice:

  1. Users, as indicated earlier, must be prepared to share business knowledge with the team and to make both pertinent and timely decisions regarding project scope and requirement priorities.
  2. For senior managers to effectively support your project, they must first understand the technologies and techniques that your team is using, understand why your team is using them, and understand the implications of using them. With this knowledge, their efforts within your organization's political arena are far more likely to be effective at the right times and in the right ways. Senior managers won't be able to gain this requisite knowledge simply by reading a weekly project status report or by attending a monthly project steering meeting. Instead, they need to invest the necessary time to learn about the things that they manage. They need to actively participate in the development of your system.
  3. Your operations and support organization must invest the resources required to understand both your system and the technologies that it uses. Your support staff must take the time to learn the nuances of your system, the implication being that they need to work with your system as it is developed and/or your team will need to provide them with training. Furthermore, your operations staff must become proficient with both the installation and operation of your system. You may choose to include one or two operations engineers on your development team or -- once again -- to invest project resources to train operations staff as required. Regardless of your approach, both your operations and support organizations will need to be actively involved with your project team.
  4. Other project teams need to work with you if your system needs to integrate with other systems. For example, perhaps your system needs to access a legacy database, interact with an online system, work with a data file produced by an external system, or provide an XML data extract for other systems. Integration often proves difficult if not impossible without the active participation of these developers (imagine how difficult it would be to access the information contained in a large legacy database if the owners of that database refused to provide any information about that database).
  5. Maintenance developers need to work with you to learn your system. When the intention is to either partially or completely hand off the maintenance of your system to other developers, it is common to bring in software professionals skilled in maintaining and enhancing existing systems to free up members of the original development team. Your team must work with these people so they can take over the system from you. Even when some original team members are still involved, an effort must be made to transfer the knowledge to the new members of the team.

Your project needs the active participation of a wide range of project stakeholders to be successful. It is critical to understand who your potential project stakeholders are and the potential roles that they will play in your development efforts.

Resources

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into SOA and web services on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=SOA and web services
ArticleID=86969
ArticleTitle=Active stakeholder participation
publish-date=05012001