Lab1: Stat
CS410
May 9, 2013
Ezra Reeves
Version 1
Table of Contents
1. Introduction............................................................................................................................................1
2. Case Study..............................................................................................................................................3
3. Stat Product Description........................................................................................................................3
3.1 Key STAT Features and Capabilities.......................................................................................3
3.2 Major Components..................................................................................................................4
3.3 STAT Walk
Through................................................................................................................5
4. STAT Product Prototype Description....................................................................................................8
4.1 Prototype Testing4.1 Prototype Testing...................................................................................8
Glossary.....................................................................................................................................................9
References.................................................................................................................................................9
List of Figures
Figure 1. Stakeholder Analysis and Management Process......................................................................2
Figure 2. STAT Rough Mock-Up.............................................................................................................5
Figure 3. Classification Diagram.............................................................................................................5
Figure 4. Action Chart.............................................................................................................................6
Figure 5. Influence Screen.......................................................................................................................6
Figure 6. Relationship Map.....................................................................................................................7
Figure 7. Management Plan.....................................................................................................................7
1. Introduction
At the heart of every project there is a problem that needs to be solved. To solve this problem
people and organizations that are involved or both directly and indirectly affected need to be aligned to
work in a single direction for a common goal. These people and organizations are what we call
stakeholders.
According to R. Edward Freeman, a well known scholar on stakeholder analysis, these are the
people who “can affect or are affected by the achievement of the organization’s objectives” (qtd. in
Hester, 2012 p. 226). The larger a project is and the more stakeholders a project involves the harder it is
to create a strategy to meet stakeholders individual wants and needs while engaging the stakeholders
that have the power and influence to drive the project in the desired direction. Without a clear
understanding of the stakeholders involved a project is likely to fail.
The mentors for the STAT project, Patrick T. Hester and Kevin Mac G. Adams, have created a
solution to this problem of stakeholder analysis combining the work of Ronald K. Mitchell and Grant
T. Savage which consist of the following steps.
1) Brainstorm stakeholders
2) Classify stakeholders
3) Evaluate stakeholder attitudes
4) Determine stakeholder situation influence
5) Develop a stakeholder management plan
6) Manage stakeholders
The solution that they have created is outstanding, however it creates a new problem. That is
even when using Dr Hester and Dr Adams solution one must devise a method to track stakeholder
attitudes and attributes by hand or in an excel document and then draw diagrams by hand or by using
an application such as Microsoft Visio. The problem with this is that it does not produce consistent
results and is error prone. Imagine giving two different people the dimensions of a house and asking
them to independently draw the house. What you would end up with is likely to be very different
houses that might have errors introduced in the drawing process. Another problem with this is that
the stakeholder analysis process is iterative as shown below in Figure 1.
Figure 1: Stakeholder Analysis and Management Process
What this iterative process means is that for every iteration one must update the stakeholder
data, re-calculate the data, and then redraw the diagrams all by hand. All of this multiplies the chance
for errors.
STAT is a software solution that looks to alleviate the currently primitive methods of stakeholder
analysis. This tool will encompass identifying, prioritizing, and analyzing stakeholders in a practical,
visual environment.
With STAT the user will get consistent accurate diagrams and graphs that are updated whenever the
stakeholder information is updated. This will greatly reduce both time and errors when preforming
stakeholder analysis. It will also better allow the user to see how information changes the dynamics of
the management plan. If you are creating the graphs by hand you would be much less likely to redraw
the diagrams for each change because it would take to much time and be overly cumbersome. With
STAT those considerations are completely done away with as the computer does not mind.
2. Case Study
To give a real world example of the importance of stakeholder analysis consider the following
story.
In a water front area in downtown Norfolk a developer decided to build a new apartment
building on the water. The developer identified the local residents as not having much power over the
situation and thus did not engage them. However the residents were strongly against the development
project and banded together to go to the local government and successfully stopped the project
altogether.
If the developer had the situational awareness to identify the potential threat of the local
residents they could have been engaged and the problems worked out.
3. STAT PRODUCT DESCRIPTION
STAT will be a standalone application written in Java. Java was chosen for several reasons but the
main reason is that it is cross-platform. This means that the STAT application can be used on all major
operating systems and most less common including Windows, Mac, and Linux.
3.1 Key STAT Features and Capabilities
Figure 2 below is a rough mock-up of what STAT will look like when completed. As you can
see, at any time the user can access any step of the iterative process of stakeholder analysis this means
seeing the changes immediately after entry and represents a huge advantage over the way stakeholder
analysis is traditionally done.
Users will be able to export all graphics from STAT as well as a comprehensive report that
shows the data as well as the graphics all in one PDF.
3.2 Major Components
The 3 major components of the STAT application are:

The GUI

Stakeholder analysis and management logic

The XML project files
The GUI will be swing based which will allow quick and simple development. The choices of
Java GUI frameworks came sown to Swing or AWT as these are the Java standards and the feeling is
that SwingX is shiny but not quite ready. Swing was the final choice as it is less outdated than AWT.
The brains behind STAT is the Stakeholder analysis and management logic supplied by Dr
Hester and Dr Adams. These are the equations that will ultimately manifest into the graphics and
management plan that STAT outputs for each step.
The XML project files are where all project and stakeholder data is stored. The reason XML
was chosen over an embedded database or some home grown format is to allow other applications in
the future to easily implement an import of STAT project files.
3.3 STAT Walk Through
On the main dashboard screen (Figure 2) the user enters the stakeholder information which
correlates to the brainstorming step of the stakeholder analysis process. The grid view allows the user
to
Figure 2: STAT Rough Mock-Up
quickly add stakeholders and their criteria.
After at least entering the Power, Legitimacy, and Urgency columns the user can view the
classification diagram which visually shows where each stakeholder falls in a Venn Diagram as shown
in Figure 3.
Figure 3: Classification Diagram
After entering the threat and cooperation attributes on the main stakeholder dashboard the user
will be able to view the action chart as shown in Figure 4.
Figure 4: Action Chart
This view shows the user if stakeholders are Latent, Expectant or Definitive as well as what the best
action to take with each stakeholder.
The user will now be able to access the Influence screen shown in Figure 5.
This is where the user shows which stakeholders have influence over other stakeholders and how
strong the influence is. The matrix view allows for quick an precise entry.
Figure 5: Influence Screen
The next screen is the Relationship Map shown in Figure 6. This view shows at a glance key
information from the all previous screens combined into one intuitive graphic. Each stakeholder is
represented by a circle. The size of the circles show whether the stakeholder is Latent, Expectant or
Definitive. The color shows the stakeholders attitude. The arrows show the direction of influence and
the width of the lines connecting the stakeholders show how strong that influence is. If there are too
many stakeholders to show on the screen only the most important stakeholders will be shown. There
will also be pan and zoom functionality on this screen to allow more stakeholders to be shown or less
stakeholders.
Figure 6: Relationship Map
The next screen is the Management Plan shown in Figure 7. This is the final output of STAT
and
is the report that would ultimately end up in the hands of the management. The key aspects of this
report is the priority ranking and the action plan.
Figure 7: Management Plan
4. STAT Product Prototype Description
The goals for the STAT application development are the following:
Implement all stakeholder analysis steps – This is a must. If any of the outlined stakeholder analysis
steps are missing the application will not function. Each step builds on the previous step.
Security – The XML project files will optionally be encrypted using an industry standard encryption
algorithm. This will prevent unauthorized access to potentially sensitive information.
Interoperability – As stated previously XML was chosen to allow easy implementation of importing
STAT project files.
Portability – As stated previously this is one of the major reasons for choosing Java over other
languages.
4.1 Prototype Testing
Testing will take place in two ways. First project plans with data supplied by Dr. Hester and Dr.
Adams will be used to populate project files. STAT will then generate the graphics which will then be
examined to ensure proper output. Data will also be generated in order to stress test the application. It is
important that limits are discovered early and if the limits are too low worked around or set as
maximums.
Data will also be entered in through the interface to ensure there is no data loss and also to test
both the GUI and the XML files.
Glossary
Stakeholder - Anyone with interest in the project or that can affect the project. A stakeholder can be an
individual or an organization.
Project - A collaborative effort to accomplish a common goal.
Latent - Capable of becoming important to the project although currently not important.
Expectant – Almost an important player in the project but perhaps are not operating at full potential.
Definitive – A definite important stakeholder.
Power – How much authority a stakeholder carries.
Legitimacy – An assumption that actions taken by the stakeholder are proper with in the project.
Urgency – How immediate a stakeholder needs attention.
References
Hester, Patrick T., Joseph M. Bradley, and Kevin MacG Adams. "Stakeholders in Systems
Problems." International Journal of System of Systems Engineering 4th ser. 3.3 (2012): 225-32. Print.