Intended Use

Background:AM’s practice of Active Stakeholder Participation is an expansion of eXtreme Programming (XP)'s On-Site Customer that describes the need to have on-site 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 private support your project, operations and support staff must actively work with your project team towards making your production environment ready to accept your system, other system teams must work with yours to support integration efforts, and maintenance developers must work to become adept at the technologies and techniques used by your system.

How to use

Specific Conditions Treated

Side Effects

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:

Timely decisions. Stakeholders must to be prepared to share business knowledge with the team and to make both pertinent and timely decisions regarding project scope and requirement priorities.

Management requires IT skill and knowledge. 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 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.

Interactions

Inclusive modeling. You need to adopt inclusive modeling techniques, which are based on user-centered design (UCD) and participatory design principles, which stakeholders can easily learn and adopt.

Take an enterprise view. You need to work with other project teams 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 refuse to provide any information about that database. Some initial architecture envisioning will help to drive this.

Precautions

Don't just hand-off to the maintenance team. 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, then 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.

Production staff are involved from the start. 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.