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
Lab 2: STAT Prototype Product Specification
3
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.
Lab 2: STAT Prototype Product Specification
4
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.
Lab 2: STAT Prototype Product Specification
5
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.
Lab 2: STAT Prototype Product Specification
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.]
6
Lab 2: STAT Prototype Product Specification
7
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
Lab 2: STAT Prototype Product Specification
8
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
Lab 2: STAT Prototype Product Specification
9
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.
Lab 2: STAT Prototype Product Specification
10
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.
Lab 2: STAT Prototype Product Specification
11
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.
Lab 2: STAT Prototype Product Specification
12
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.
Lab 2: STAT Prototype Product Specification
13
Table 1. Stakeholder classifications.
Dormant
Discretionary
Demanding
Dominant
Dangerous
Dependent
Definitive
Non Stakeholder
Power
No Power
No Power
Power
Power
No Power
Power
No Power
No Legitimacy
Legitimacy
No Legitimacy
Legitimacy
No Legitimacy
Legitimacy
Legitimacy
No Legitimacy
No Urgency
No Urgency
Urgency
No Urgency
Urgency
Urgency
Urgency
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
Supportive
Mixed
Marginal
Non-supportive
High
High
Low
Low
Threat
Low
High
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).
Lab 2: STAT Prototype Product Specification
14
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
Lab 2: STAT Prototype Product Specification
15
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.]