Identifying and Engaging Stakeholders

  • View
    216

  • Download
    0

Embed Size (px)

Text of Identifying and Engaging Stakeholders

  • 8/2/2019 Identifying and Engaging Stakeholders

    1/7

    108

    PART II THE PROCESS OF SOFTWARE ARCHITECTURE I

    We explained that a good way to visually represent aspects of the scope isto use a context diagram. Production of such a diagram is a good way to beginyour work with the stakeholders.We explained that stakeholder concerns may be specific and measurable 9in which case. we call them requirements) or may be vague and looselystated but n onetheless still important to your stakeholders. We described howto effectively document your stakeholders' concerns.We defined an architectural principle as a fundamental statement of belief. approach. or intent that guides the definition of an architecture. We explained how principles are extremely useful in creating a framework forarchitecture definition and showed how you can use principles to trace backyour architectural decisions to business drivers and goals.Finally. we considered various types of architectural constraints. such asstandards. guidelines. strategies. and policies. You must take all of these intoaccount when designing your architecture.

    FURTHER READINGMany software architecture books discuss the process of setting the scope ofthe system; examples include Garland and Anthony [GARL03]. which describes a Context viewpoint. and Bosch [BOSCOO]. which describes how to define the system context at the start of the architectural design process.A number of requirements engineering books also discuss scoping systems. A particularly good example is Sommerville and Sawyer [SOMM97],which presents a clear set of guidelines around requirements capture. presentation. and ratification. Each guideline is accompanied by a cost/benefit analysis and practical suggestions on how it can be implemented.

    IDENTIFYING AND ENGAGINGSTAKEHOLDERS

    A s we saw in Part 1, the people affected by a system are not limited those who use it. Systems are not just used: They have to be designand built; they have to be operated; they may have to be repaired; they ausually enhanced; and. of course, they have to be paidJor.Each of these activities involves a number-possibly a significant number-of people distinct from the users. Each of these groups of people has own requirements. its own interests. and its own needs from the system. Wrefer collectively to these people as stakeholders. In Part 1we defined a stakholder as follows.

    DEFINITION A stakeholder in a software architecture is a person. group. entity with an interest in or concerns about the realization of the architecturCorrectly identifying stakeholders and gaining their commitment is oof the most important (yet underrated) tasks in software development. Tconcept of architectural stakeholder is clearly explained in the IEEE standaRecommended Practice Jor Architectural Description. and our discussibuilds on theirs.

    SELECTION OF STAKEHOLDERSIt is. in our experience. a subjective choice whom you select to populate yocommunity of stakeholders. We have found, however, that casting your nmore widely at the beginning is important in the long term (although in th

  • 8/2/2019 Identifying and Engaging Stakeholders

    2/7

    110 PART II THE PROCESS OF SOFTWARE ARCHITECTURE .pr. "c ' CHAPTER 9 IDENTIFYING AND ENGAGING STAKEHOLDERS,tshort term, it may make your life more difficult because you will have more po tentially conflicting requirements to reconcile). If you don't take stakeholders'concerns into consideration at the beginning of your development project, youcan be sure that they will complain at the end, when making changes is muchharder-and making architectural changes may be practically impossible.

    STRATEGY The selection of stakeholders is a subjective activity; b ut in general, the wider the s takeholder community, the better you r chances of delivering a successful product or system.

    [IDUnfortunately, there are no purely objective criteria for determiningwhether you ha ve correctly identified your stakeholders. Whom you select depends on a range of factors including the goals of the system, organizationaland political considerations, availability of resources, and cost and timescaleconstraints.(We sometimes find, for example, that stakeholders are consulted in aspirit of openness, to demonstrate a desire to reflect a wide range of concerns, rather than an absolute need to take account of their views. There isabsolutely nothing wrong with this, as long as it contributes to the success ofthe architecture.)Drawing up your list of stakeholders, therefore, is a collaborative activity

    that sets the tone for the future direction of the project, and it is essential thatyou get this right. As well as ensuring that your stakeholder list is complete(we explore this issue further in the next section), there are four criteria tohelp make sure your list is right.

    PRINCIPLE A good stakeholder in an architecture is i'lformed, committed, authonzed, and representative.We explain each of these criteria in Table 9-1.

    TABLE 9- 1 CRITERIA FOR A GOOD STAKEHOLDER

    Criterion Description- - ' " - - ~ . , - , , - - , - , _ . ~ - , ~ - - _ . _ - , - ~ - - - ~ - - ~ - ~ - , - _ . __ ..._-__ .".Informed Do your stakeholders have th e information, the experience,and the understanding needed to make the right decisions?

    - - - - - - - --,- ,.--- --- . -.._ ,. , " , . _ . _ , . _ ~ ~ - - - - ~ _ . ~ - - - ~ Committed Are your stakeholders willing and able to make themselves

    TABLE 9- 1 CRITERIA FOR A GOOD STAKEHOLDER (CONTINUEO)Criterion DescriptionAuthorized Can you be sure that decisions made now by your stakeholdwill not be reversed later (at potentially high cost)?Representative If a stakeholder is a group rather than a person, have suitarepresentatives been selected from the group? Do those repsentatives meet the above criteria for individual stakeholde

    CLASSES OF STAKEHOLDERSIn Table 9-2, we classify stakeholders according to their roles and concernsMost system development projects include representatives from mosnot all of these stakeholder groups, although their relative importance will oviously vary from project to project. However, if you do not at least consieach class, you will have problems in the future.

    Widening your set of stakeholders leads to a tradeoff-the larger group, the more difficult it will be to reach a consensus. Part of the architecrole is to ensure that large stakeholder communities do not become an obsta

    TABLE 9- 2 STAKEHOLDER ROLES

    Stakeholder Class Description. " ..Acquirers Oversee the procurement of the system or product

    .... -,. .._._-,-

  • 8/2/2019 Identifying and Engaging Stakeholders

    3/7

    12 PART 1/ l THE PROCESS OF SOFTWARE ARCHITECTURE i CHAPTER 9 ' IDENTIFYING AND ENGAGING STAKEHOLDERSto making progress. This requires you to actively manage the decision-makingprocess and have a clear understanding of the relative importance of the needsof each stakeholder group. Doing this will help you defend your architecturaldecisions when challenged by stakeholders who feel that their needs havebeen ignored.STRATEGY If you have a large stakeholder group, you need to actively manage it to ensure that its size does not impede progress. In particular, you needl!J to balance and prioritize the needs of the different stakeholder groups, so thatwhen conflicts occur, you can make sound, well-reasoned decisions.

    It is also worth noting that, although we don't consider the architect'sneeds explicitly, when acting in that role you are also an architectural stakeholder. (We assume that you can represent yourself adequately to ensure thatyour views are taken into account!)PRINCIPLE The architect must ensure that there is adequate stakeholder rep resentation across the board, including nontechnology stakeholders (such asacquirers and users) and technology-focused ones (such as developers, system administrators, and maintainers).

    Let's define the stakeholder classes in a little more detail.

    AcquirersAcquirers oversee the procurement of the system or product. Acquirers typically include senior management, which provides or authorizes funding forproduct or system development, and may also include the purchasing and legal departments, which represent the commercial interests of users in negotiations with third-party suppliers.In a system development project, acquirers are often referred to as business sponsors, and for a product development, acquirers are likely to be senior executives from the sales, marketing, and technology groups. There mayalso be investor representation in this group if specific external investment isrequired to fund the project. In seniority terms, acquirers are usually yourmost important stakeholders.Acquirers' concerns typically center around issues such as alignment withstrategic objectives, return on investment, and the costs, timescales, plans,and resources involved in building and running the system. Their goals areusually value for money and efficient expenditure of resources during delivery and operation.

    AssessorsAssessors oversee the system's conformance to standards and legal regtions. Assessors may come from the organization's own internal quality trol or conformance departments, or they may be external legal entities.Assessors' concerns are focused around testing (to demonstrate confoance to requirements) and on formal, demonstrable compliance.

    CommunicatorsCommunicators explain the system to other stakeholders. Internal or putrainers provide training for support staff, developers, maintainers, and soand technical authors create manuals for the users and administrators ofproduct or system. In the case of a product, the marketing department needcommunicate its key features, strengths, and benefits to potential customeCommunicators' interests lie in under