Prototype Product Specification for STAT › ~cpi › 411 › bluef13 › labs › ... · Lab 2:...

Running Head: Lab 2 – STAT Prototype Product Specification

Prototype Product Specification for STAT

Prepared by: Christian Oakley, Blue Team

Date: 22 October, 2013

Version 1

Lab 2: STAT Prototype Product Specification 2

Table of Contents

1. Introduction ................................................................................................................................. 3

1.1 Purpose .......................................................................................................................... 4

1.2 Scope ............................................................................................................................. 4

1.3 Definitions, Acronyms, and Abbreviations .................................................................. 4

1.4 References ..................................................................................................................... 5

1.5 Overview ....................................................................................................................... 6

2 General Description ..................................................................................................................... 7

2.1 Prototype Architecture Description .............................................................................. 7

2.2 Prototype Functional Description ............................................................................... 11

2.3 External Interfaces ...................................................................................................... 14

List of Figures

Figure 1. Manual stakeholder analysis example. ............................................................................ 3

Figure 2. STAT prototype MFCD .................................................................................................. 7

Figure 3. Classification Venn diagram example. ............................................................................ 9

Figure 4. Recommended action chart example. .............................................................................. 9

Figure 5. Stakeholder relationship map example. ......................................................................... 10

Figure 6. Stakeholder management plan example ........................................................................ 11

Figure 7. The STAT process flow................................................................................................. 12

Figure 8. Stakeholder relationship selection mock-up. ................................................................. 14

List of Tables

Table 1. Stakeholder classifications. ............................................................................................. 13

Table 2. Stakeholder attitudes. ...................................................................................................... 13


1. Introduction

Stakeholder analysis has been around for decades and is often practiced by project teams

starting at the analysis phase of the development life cycle. Stakeholder analysis methods may

vary from very complex to very simple with some much more in depth than others. Regardless of

the method, it is common practice to perform stakeholder analysis manually (P. T. Hester).

Project teams will brainstorm together and put their thoughts on paper (Figure 1). Stakeholders

and their information are written down, analyzed, and organized to portray their relationships

with one another and the influence they have on the project. Unfortunately, stakeholders in

systems problems seldom stay the same. Attitudes towards the project may change and levels of

influence fluctuate frequently. New stakeholders may also be identified throughout the project

duration. These changes may prove to be difficult to reflect in a physical stakeholder analysis

method without sacrificing organization and information consistency. Any discrepancy, even the

slightest, in stakeholder analysis could be disastrous to a project.

Figure 1. Manual stakeholder analysis example.


1.1 Purpose

The National Center for Systems of Systems Engineering (NCSOSE) has commissioned

an electronic version of their stakeholder analysis methods to be developed. This tool named

NCSOSE’s Stakeholder Analysis Tool (STAT) will incorporate their comprehensive methods of

analysis while also alleviating many of the problems associated with the currently popular

practice of manual stakeholder analysis. STAT will provide a dynamically changing visual

environment that can be accessed from a basic client computer. The design will be non-linear

and create a workflow where identification and attribute editing will not compromise project

precision. Most important of all, STAT will implement the stakeholder analysis research of

NCSOSE that will feed into a proprietary algorithm and determine a stakeholder’s overall

influence on an individual project.

1.2 Scope

The STAT prototype will exhibit the NCSOSE method of stakeholder analysis in its

entirety. The five steps (identification, classification, attitude, relationships, and management)

described in the NCSOSE research will be the main focus. Small changes in analysis will have

an effect on all portions of the program to support a dynamically changing environment. The

program will be able to handle projects anywhere from low to high complexity without losing

accuracy.

1.3 Definitions, Acronyms, and Abbreviations

Attributes: Qualities that describe the stakeholder. In the NCSOSE methodology stakeholders

attributes are power, legitimacy, urgency, potential cooperation towards a project, and

potential threat towards a project.

NCSOSE: National Center for Systems of Systems Engineering

Project: A collaborative effort to accomplish a common goal.


Relationship: The manner in which two entities are associated.

SAM: Stakeholder analysis and management.

SRM: Stakeholder relationship map.

Stakeholder: An entity who can affect or is affected by the achievement of the organization's

objectives.

STAT: Stakeholder Analysis Tool.

User: Potential operator of the STAT software.

Visuals: Graphical representations of information.

1.4 References

Hester, P. T. "STAT development meeting 2." 26 April 2013.

Hester, P. T., Adams, K. M. "STAT development meeting." 2 April 2013.

Hester, P. T., Bradley, J. M., & Adams, K. M. "Stakeholders in Systems Problems. File last

modified 3 April 2013." 2013. Microsoft Powerpoint File.

Hester, P. T., Bradley, J. M., & Adams, K. M. "Stakeholders in systems problems." International

Journal of System of Systems Engineering, 3(3/4) (2012): 225-232.

Mitchell, R. K., Agle, B. R., & Wood, D. J. "Toward a theory of stakeholder identification and

salience: Defining the principle of who and what really counts." Academy of Management

Review, 22(4) (1997): 853-886.

Oakley, C. K. "Lab 1 - STAT Product Description." 2013.

Savage, G. T., Nix, T. W., Whitehead, C. J., & Blair, J. D. "Strategies for assessing and

managing orgainizational stakeholders." The Executive, 5(2) (1991): 61-75.


1.5 Overview

This product specification provides the hardware and software configuration, external

interfaces, capabilities and features of the STAT prototype. The information provided in the

remaining sections of this document includes a detailed description of the hardware, software,

and external interface architecture of the STAT prototype; the key features of the prototype; the

parameters that will be used to control, manage, or establish these features; and the performance

characteristics of these features in terms of inputs, outputs, and user interaction.

[This space intentionally left blank.]


2 General Description

In addition to implementing the NCSOSE stakeholder analysis methodology, usability is

another focus of STAT development. The design of STAT will allow aspects of a project to be

visualized with the click of a button. Attributes of stakeholders will be analyzed with different

views that may be able to reveal faults in the project’s initial analysis. The graphic user interface

(GUI) will allow organization maintainability with even the most extreme amounts of editing or

re-analysis.

2.1 Prototype Architecture Description

STAT will be a Java based program that can be used on any personal computer that can

run the latest version of Java. No other hardware will be needed to use the program. The

software will be comprised of two main parts: the GUI front end and NCSOSE research based

algorithms running in the background. For the prototype, extra testing functions will be built in

to ensure the reliability of STAT’s design.

Figure 2. STAT prototype MFCD


The algorithms of STAT are used to accomplish the five steps of NCSOSE stakeholder

analysis (refer to section 1.2). The classification identification function uses the stakeholder’s

attribute inputs to determine which classification the stakeholder will be labeled. The attitude

identification function will also use a stakeholder’s attributes to identify a stakeholder as having

a certain “attitude” towards the project. The relationship analysis algorithm will analyze all of

the relationships a stakeholder has with other stakeholders and produce a value to represent the

stakeholder’s relationships among the project. Finally, the project influence algorithm will use

the outputs of the previous three engines to determine a stakeholder’s overall influence on the

project.

The STAT GUI will consist of six main selectable views (tabular format) that will each

visually represent a portion of the stakeholder analysis process. Three of the tabs will require

user input while the other three tabs will provide different visualizations of the information in the

current project. Although the tabs are in a recommended order that correspond to the stakeholder

analysis and management (SAM) process, the tabs can be viewed and altered at any time. Any

change made in one tab will instantaneously change information in the other applicable tabs.

The first tab will be known as the “identification view” will serve as the default working

location when the program is first accessed. As in traditional methods of stakeholder analysis,

identification is the first step necessary to further analyze aspects of the project and this area will

directly serve this functionality. A stakeholder’s information is entered by the user, including its

classification and attitude related attributes. Stakeholder information can also be edited or

removed from the project in this area.

The second tab will be known as the “classifications view”. Using attributes from the

identification process completed in the identification view, the distribution of classifications will


be visually represented in a Venn diagram format (Figure 3). No inputs are used in this area. This

diagram will be solely for the purpose to help ensure that the attributes of identified stakeholders

have been properly identified.

Figure 3. Classification Venn diagram example.

The third tab will be known as the “recommended actions view”. Matching a

stakeholder’s classification to its derived attitude on a table will reflect a certain action that

should be taken during stakeholder management. The actions are illustrated in figure 4. This area

will also not utilize inputs but simply display the distribution of actions for each stakeholder

identified in the project.

Figure 4. Recommended action chart example.


The fourth and fifth tabs are related to one another and deal with stakeholder

relationships. The fourth tab AKA “influence view” will require user input to depict which

stakeholders have relationships with others. The strength of each relationship must also be

specified when identifying a relationship. The fifth tab is a visual representation of the

relationships between stakeholders. The sizes, colors, and shapes will all have a specialized

purpose in this diagram known as the stakeholder relation relationship map (Figure 5).

Figure 5. Stakeholder relationship map example.

The final tab will be known as the “stakeholder management plan”. This area displays all

of the information that has been derived from the previous analysis steps. Certain inputs will also

be allowed in this area for the purpose of stakeholder management while other areas will not

allow user input. The four columns on the right (Figure 6) will be empty until the user fills in the

cells. The rest of the columns will all derive their content from previous steps throughout the

analysis process and not allow direct editing from this view. The information can be ordered to

the user’s choosing to conform to his/her management view preference. By default, the

management plan will be in ascending order by a situational influence value that is derived from

the project influence algorithm. Although the value is numerical, they will be summarized into

the categories of high, medium, and low for generalization and aesthetic purposes.


Figure 6. Stakeholder management plan example

Project data will be saved in XML project files for future editing and exportation. These

files will end in a .stat extension to specify exclusiveness to the STAT program. In the prototype

though, test XML files will be created to verify the performance of the project file related

functions. Numerous tests will be “injected” into the background algorithms to ensure STAT will

be a reliable tool for project managers.

2.2 Prototype Functional Description

The information flow of STAT will aim to be as non-linear as possible but due to the

nature of stakeholder analysis, many steps are dependent on previous steps (Figure 7). Once

identified, stakeholders need three types of input to complete the SAM process. These are each

stakeholder’s classification, attitude, and relationships. Only after this information has been

entered, different portions of the project can be edited and viewed at any time. If later areas of

the SAM process are viewed before others, many areas of the project data may display incorrect

visuals and an unreliable management plan.


Figure 7. The STAT process flow.

When a new project has been initiated, the first step is to identify the stakeholders. STAT

will be set up to prompt attributes that link to classification and attitude identification during this

step. This is due to the fact that the “classifications view” and “recommended action view” (refer

to section 2.1) are dependent upon these attributes. Without this information, all of the project

information visuals will be either blank or missing the majority of data.

Three attributes during the identification step relate to classification identification. The

three criteria are power, legitimacy, and urgency and should be measured in relation to the

current project being developed (Mitchell). Either a stakeholder has an attribute or does not have

it. This leads to the possibility of the stakeholder being classified in one of eight different classes

(Table 1). By having classification identification built in to the identification step, this ensures

that the “classifications view” will be populated and portions of the management plan will be

filled in. A stakeholder’s classification is also necessary to determine a recommended action.


Table 1. Stakeholder classifications.

Dormant Power No Legitimacy No Urgency

Discretionary No Power Legitimacy No Urgency

Demanding No Power No Legitimacy Urgency

Dominant Power Legitimacy No Urgency

Dangerous Power No Legitimacy Urgency

Dependent No Power Legitimacy Urgency

Definitive Power Legitimacy Urgency

Non Stakeholder No Power No Legitimacy No Urgency

Two other attributes are included in stakeholder identification. These criterions are based

on the stakeholder’s potential of threat to the project and the stakeholder’s potential of

cooperation with the project (Savage). Determining these attributes as either high or low will

place each stakeholder as having one of four attitudes (Table 2). A stakeholder’s attitude, in

conjunction with a stakeholder’s classification, is the final necessary component to determine a

recommended action (Figure 4).

Table 2. Stakeholder attitudes.

Cooperation Threat

Supportive High Low

Mixed High High

Marginal Low Low

Non-supportive Low High

The last user input needed to complete the SAM process is the identification of

relationships between stakeholders. Relationships are directional and carry a certain magnitude.

These can be entered in the “influence view” which displays a table that lists every involved

stakeholder in the rows and columns (Figure 8). The strength of each relationship can be selected

where the involved stakeholders intersect. Obviously, a stakeholder cannot be in a relationship

with itself nor have more relationships than there are project stakeholders. The determined

relationships combined with each stakeholder’s classifications and attitudes are necessary to

create the SRM (Figure 5) and complete the management plan (Figure 6).


Figure 8. Stakeholder relationship selection mock-up.

With each stakeholder’s classification, attitude, and relationships determined, every

visual representation of the project data can be displayed accurately. Stakeholders can be edited,

added, and removed to conform to the current project file being analyzed. Any change of the

current data will properly change all of the visuals and maintain consistency.

2.3 External Interfaces

As a standalone java program, the only interface will be the user interface. A GUI will

provide the link between the user and the STAT analytical engines. All data fields will be labeled

and potential areas of error will be designed to promote correct data inputs. For the prototype,

inputs will originate from the user or from external test data injections. This test data module will

actually be built into the STAT program to allow the developers to quickly create stakeholders

that satisfy specific areas of testing.

The XML project file is the main output of STAT. For added security, the user will have

the option of encrypting the project file before exportation. The visuals will also be able to saved

as common image files such as .jpg and .png at the users discretion. However, only the XML

project file will be able to be loaded into STAT as the program is unable to read the information


contained in the image files. The encryption and decryption algorithms will be specific to STAT

and will not vary between encrypted project files.

[This space intentionally left blank.]

Prototype Product Specification for STAT › ~cpi › 411 › bluef13 › labs › ... · Lab 2:...

Documents

Transcript of Prototype Product Specification for STAT › ~cpi › 411 › bluef13 › labs › ... · Lab 2:...