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

• Modeling: Effective Modeling Techniques for Modern-Age Software Development
  
  
• When is a model agile? Pt 1
  
  
• When is a model agile? Pt 2
  
  
• The Object Primer 2nd Edition , by Ambler, S.W. New York: Cambridge University Press, (2001).
  
  
• eXtreme Programming (XP) Home Page
  
  
• Process Patterns Resource Page
  
  

About the author

Comments (Undergoing maintenance)

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• Resources
• About the author
• Comments

Local resources

• IBM Innovation Center - Austin, TX
• IBM Innovation Center - Chicago, IL
• IBM Innovation Center - Dallas, TX
• IBM Innovation Center - San Mateo, CA
• IBM Innovation Center - Waltham, MA
• Technical Briefings in North America

My developerWorks community

Dig deeper into SOA and Web services on developerWorks

Calling all developers

Download no charge Lotus Domino Designer

Special offers