SoDIS-By Clive and Carol Boughton Sept 2011

SoDIS
Software Development Impact Statement

Overview By Clive & Carol Boughton
Agenda
SoDIS Why bother? Estimating program value Defining a project Which analysis is needed? SoDIS inspection process Applying SoDIS
SoDIS Clive & Carol Boughton 2
Introduction
Projects, Risks and Stakeholders
All projects involve risk and stakeholders Projects today tend to involve more participants
Having different roles, expectations and needs
Project risks are dynamic Risk is communicated implicitly rather than explicitly Modern project management has to deal with the often competing and conflicting demands of many P.Edwards & P.Bowen: Risk Management in Project Organisations stakeholders
Introduction
Projects, Risks and Stakeholders
Society desires that all projects should be successful, and has become less tolerant to failure. Project managers struggle to deal with many risk and stakeholder situations:
Environment - fauna, flora, people, infrastructure Finance the rich and the poor Health medicines, disease, people Violence animals and people Terrorism peoples and society
P.Edwards & P.Bowen: Risk Management in Project Organisations

Outline
1. Projects 2. Project Management 3. Stakeholders 4. Stakeholder Management 5. Risk 6. SoDIS
Projects
1. Projects
What is a project? Characteristics of projects What is project failure? Reasons for project failure
SoDIS
Clive & Carol Boughton
Projects - 1
What is a project?
A temporary endeavour undertaken to create a unique product, service, or result. (PMBoK)
Characteristics of projects:
Unique undertakings Composed of interdependent activities Create a quality deliverable Involve multiple resources Driven by the triple constraint balancing time resources and technical performance. (AMA-Hbk)
PMBoK: Project Management Body of Knowledge AMA-Hbk: American Management Association Handbook
Projects - 2
Thats pretty obvious even to me! So I now have a definition of a project, but can you help me understand why projects fail?
SoDIS
Projects - 3
What is project failure?
Not meeting planned schedule and/or budget and/or requirements?
Standish Group International 1994 to 2010
Not obtaining repeat business? Not advancing the development or project organisation in the state of the art? Making an overall loss in profit? And many more!
Depends on your perspective!

Projects - 4
Reasons for project failure
Management & requirements issues
Office of Government Commerce (UK) - 2008
Insufficient involvement of senior management, too many requirements and scope changes, lack of necessary management skills
El Emam & Koru - 2008
Poor risk management

DeMarco & Lister - 2003
Lack of user involvement, lack of executive management support, lack of a clear statement of requirements
Standish Group 2004
And theres many more!

Projects - 5
That helps! Looks like there are several, perhaps, conflicting issues to deal with.
I guess some project management might be appropriate! Can you give me a kick start? Please dont bore me. I find it difficult to concentrate for long!
SoDIS
11
A message
IT projects are typically not done well!
SoDIS
12
Project Management
2. Project management
Project mismanagement an immature lifecycle What is project management? Characteristics of project management
SoDIS
13
Project Mismanagement
An Immature Project Life Cycle

Phase 1 Phase 2 Phase 3 Phase 4 Phase 5 Phase 6 Phase 7 Phase 8 Project Initiation Wild Enthusiasm (even night long parties) Dis-illusionment Chaos Search for the Guilty Punishment of the Innocent Promotion of the Non-participants Definition of the Requirements
Futrell, Shafer & Shafer: Chapter 7
Project Management - 1
What is project management?
the application of knowledge, skills, tools and techniques to project activities in order to meet stakeholders needs and expectations from a project. PMBoK
Characteristics of project management:

SoDIS
Scope management Time management Cost management Quality management Human resource management
PMBOK & AMA-Hbk
Clive & Carol Boughton 15
Project Management - 2
Characteristics of project management, contd:
Communications management Risk management Procurement management Integration management
Wow! Thats a lot of management activities! But, I get the impression that these things/beings called stakeholders might need to be managed too!
PMBOK & AMA-Hbk
A message
Project management on IT projects is typically not done well!
SoDIS
17
Stakeholders
3. Stakeholders
The definition of project management includes The PMBoK definition Alternative definition and a better definition Stakeholder groups Stakeholder impact ranking Example exercise - ACTEC RFP Identifying stakeholders Example answer Stakeholders Stakeholder stakes
SoDIS
18
Stakeholders - 1
The definition of project management includes:
in order to meet stakeholders needs and expectations That is a bit vague! So what is a stakeholder?
The PMBoK definition:

Persons & organizations such as customers, sponsors, performing organization & the public, that are actively involved in the project, or whose interests may be positively or negatively affected by execution or completion of the project. They may also exert PMBOK influence over the project and its deliverables.
Stakeholders - 2
Alternative definition
A person, group, organization, or system who/which affects or can be affected by another persons, groups, organization's or systems actions.
Hey! I notice that I might not be a stakeholder! That doesnt seem right to me!
Wikipedia and CVB

Stakeholders - 3
A better definition
A person (or any other being), group, organization, or system who/which affects or can be affected by another persons, (beings,) groups, organization's or systems actions.
Ah! Thats more inclusive! Is there more to know about stakeholders?
Wikipedia and CVB

Stakeholders - 4
Stakeholders have varying levels of responsibility and authority when participating on a project and these can change over the course of the projects life cycle. Their responsibility and authority range from occasional contributions in surveys and focus groups to full project sponsorship, which includes providing financial and political support. Stakeholders who ignore this responsibility can have a damaging impact on the project objectives. Likewise, project managers who ignore stakeholders can expect a damaging impact on project outcomes. Sometimes, stakeholder identification can be difficult. For example, some would argue that an assembly-line worker whose future employment depends on the outcome of a new productdesign project is a stakeholder. Failure to identify a key stakeholder can cause major problems for a project. Stakeholders may have a positive or negative influence on a project. Positive stakeholders are those who would normally benefit from a successful outcome from the project, while negative stakeholders are those who see negative outcomes from the projects success. For example, business leaders from a community that will benefit from an industrial expansion project may be positive stakeholders because they see economic benefit to the community from the projects success. Conversely, environmental groups could be negative stakeholders if they view the project as doing harm to the environment. In the case of positive stakeholders, their interests are best served by helping the project succeed, for example, helping the project obtain the needed permits to proceed. The negative stakeholders interest would be better served by impeding the projects progress by demanding more extensive environmental reviews. Negative stakeholders are often overlooked by the project team at the risk of failing to bring their projects to a successful end. PMBOK
Stakeholder Groups - 1
Project champions
Entrepreneurs Developers Investors Visionaries Clients/Customers Politicians Community leaders
Project participants
Project manager Project team Engineers Constructors Vendors Suppliers Regulatory bodies Legal bodies
John Tuman Jr. Chapter 13A AMA Handbook

Community participants
Community members Special interest groups Religious leaders Political groups Social & ethnic groups Environmentalists
Parasitic participants
Opportunists Activists Causes News & information media

Internal Proj. process affected

SoDIS
Proj. result affected

Internal customer Sponsor Users
Owner Sponsor Project manager Functional managers Financing source Project core team Subject matter experts Employees Stockholders
T. Kloppenborg: Contemporary Project Management

External Proj. process affected

SoDIS
Proj. result affected

Client Public Special interest grps Potential customers
Suppliers Partners Government agents Special interest grps Client Professional groups Media Taxpayers Unions Competitors
T. Kloppenborg: Contemporary Project Management

26
Stakeholder impact ranking

Ranking of potential to impact project success Highest
Activists Media Community leaders Clients/Customers Project management
2nd Highest
Regulators Developers Special interest groups Environmentalists Vendors
3rd Highest
Politicians
4th Highest
Constructors Visionaries
SoDIS
Thinking aloud!
Wow! The only stakeholders Id ever thought might impact my projects were those higher in the pecking order! I think I can see that the information just given can actually help me to identify project stakeholders better. Is there any way I can I try this out now?
SoDIS
28
Example exercise
Australian Capital Territory Electoral Commission Request for proposal for system to manage:
Election setup Electronic voting Electronic counting Data entry
Example exercise
ACTEC RFP
Request for Proposal from ACT Electoral Commission
Would like proposal submissions from organisations possessing the experience / capability to design, construct, install and support a trial electronic voting, paper vote entry, and counting system to be used for the October 2001 ACT Election. The system must run on standard PC hardware which will be supplied by the ACT Government Outsource Agent (InTact). Developed software must support all aspects of the Hare-Clark preferential system currently in place. Internet solutions will not be considered for the short term. Final coded system to be independently audited.
SoDIS
30
Example exercise
ACTEC RFP
An installed trial, electronic voting system that must:

be no less secure and no less reliable than the current paper-based system - tamper proof and secure storage of votes. strongly support voting processes in current paper-based system - anonymity, 1 voter 1 vote, whole paper viewable & readable, Robson Rotation, informal votes. be easy to use for both sighted & (desirably) sight-impaired voters - using keyboard or mouse but not touch-screen. be able to accumulate votes at polling places for transfer to a counting centre after close of voting. automatically sequence selected candidates for voter. provide voting instructions and error messages in 12 ACT-EC chosen languages.
Example
Electronic Voting: "
eVACS - Needs
"
Electronic ballot to be displayed in similar format to paper ballot
Ballots to be displayed in Robson Rotation sequence
Voter to be able to vote informally
Voter must have opportunity to change vote before committing
Voter must maintain anonymity (as for paper system)
No possibility of remote or unauthorised access
No-one able to change committed votes without being detected
Voters able to vote outside of their own electorate
Provision for the blind and vision-impaired
Instructions and messages to be displayed in one of choice of 12 languages
Openness of process

Example exercise
Socioeconomic influences:
ACTEC RFP
Applicable standards and regulations. Cultural influences.

Political. Economic. Demographic. Educational. Ethical. Ethnic. Religious.
PMBOK
Identifying stakeholders - 1
As a contractor a simple brainstorming process can be used to extract obvious stakeholders from (say) a Request for Tender (RFT). It is better to be armed with a list of general stakeholder groups (or types) to increase the probability of identifying those stakeholders that are less obvious. In any case, it is unlikely that ALL stakeholders will be identified at the beginning of a project unless there has been a significant effort to engage with them early.
SoDIS
34
Useful stakeholder engagement techniques
USAID MEASURE Evaluation
Foreit et al. 2006
Stakeholder theory in practice

Bowern et al. 2004
AccountAbility AA1000SES
Stakeholder Engagement Standard 2009
REVIT
Stakeholder Engagement Toolkit 2007
UNDP
Multi-Stakeholder Engagement Processes 2006
SoDIS
35
AccountAbility AA1000SES supports principles of:
INCLUSIVITY
giving stakeholders the right to be heard and accepting the obligation to account to them
MATERIALITY
A determination of the relevance and significance to its associated organisation and associated stakeholders.
RESPONSIVENESS
The formulation of decisions and actions in responding to stakeholder issues.
AccountAbility AA1000SES supports profiling:
Expectations
Establish how a stakeholder views an issue/concern and what they expect of the engager. Determine whether required effort/time is worth it.
Knowledge
Determine who can learn from whom. Make sure stakeholders well know who is engaging them.
Legitimacy of stakeholder representative

The formulation of decisions and actions in responding to stakeholder issues.
Willingness to engage
Investigate unwillingness to engage. Dont assume anything.
AccountAbility AA1000SES supports profiling:
Possible impacts Cultural context
Be fully aware of cultural, language, customs, social interaction and gender issues.
Stakeholders engagement capacity

Dont assume stakeholders will have time/finances to engage.
Relationships of stakeholders with each other

Watch out for competition and conflicts of interest.
SoDIS
38
Might start with the usual suspects Project manager
The person responsible for managing the project.
Customer/user
The persons or organizations that will use the projects product or service. There may be multiple layers of customers.
Performing organization
The enterprise(s) whose employees are most directly involved in doing the work of the project.
Project team members

The group that is performing the work of the project.
PMBOK
Might start with the usual suspects contd Project management team
The members of the project team who are directly involved in project management activities.
Sponsor
The person(s) or group(s) that provides the financial resources, in cash or in kind, for the project.
Influencers
People or groups that are not directly related to the acquisition or use of the projects product, but due to an individuals position in the customer organization or performing organization, can influence, positively PMBOK or negatively, the course of the project.
Additional names & categories of stakeholders
internal and external, owners and investors, sellers and contractors, team members and their families, government agencies and media outlets, individual citizens, temporary or permanent lobbying organizations, and society-at-large.
The naming/grouping of (potential) stakeholders aids in identifying which individuals & organizations view themselves as (actual) stakeholders. Stakeholder roles & responsibilities can overlap (e.g., an IT firm that PMBOK provides auditing tools for a product it is designing).
Example answer Stakeholders

eVACS Stakeholders:
SIPL and InTact ACT Electoral Commission Voters
Sight impaired Mentally impaired Elderly Voting Day Absentees Computer-illiterate
Equipment Suppliers Dogs for blind Election Volunteer Helpers Political Parties Other Electoral Comms System Auditors Local IT Businesses Environment Current ACT Government
Candidates
SoDIS Clive & Carol Boughton
42

eVACS Stakeholder Types
Stakeholder SIPL & InTact ACTEC Sight-impaired voters Mentallyimpaired voters Elderly voters Absentee voters Computer-illiterate voters Candidates Stakeholder Type Performing Organisations Customer, Owner, Sponsor Users, Influencers Users Users Users Users User, Influencers
SoDIS
43

eVACS Stakeholder Types
Stakeholder Equipment Suppliers Dogs for blind & vision-impaired Election volunteer helpers Political parties Other ECs System auditors Local IT business Environment Current ACT Gov. Stakeholder Type External, Vendors External Users, Individual citizens Users, Influencers Gov. agencies External, Influencers External, Users External, Community Influencer
SoDIS
44
Stakeholder stakes
To find out more about a stakeholder (group) ask:
What is their role in the performing, the customer, the owner, the sponsor or other organisation? What will they gain as a result of the project? What will they lose as a result of the project? What do they control, which the project needs? What is their source of power now?
(position/status/resource/expertise/legal/regulatory/customer)
What will be their source of power after the project? What is their attitude to the project?
(strong/weak/positive/neutral/negative)
How are they likely to be influenced?

(e.g. emotional or logic)?
Robert Buttrick: The Project Workout - 2005

45
More thinking aloud!
OK! Now I have a better idea of the characteristics of stakeholders and how to identify them. I think I can see why Robert Buttrick writes: Ignore stakeholders at your peril! Never underestimate stakeholders ability to ruin your best laid plans! What about stakeholder management?
SoDIS
46
A message
Stakeholder identification on IT projects is typically not done well!
SoDIS
47
Stakeholder Management
4. Stakeholder Management
Treated in 1 knowledge area (KA) of PMBoK
Communications management (10)
Stakeholder input required in 2 KAs of PMBoK

Scope management (5) Risk management (11)
SoDIS
48
PMBoK treats stakeholder identification and management within one (1) knowledge area: Communications management (10)
10.1 Identify stakeholders
Stakeholder register Stakeholder management strategy (to increase support)
10.4 Manage stakeholder expectations is the process of communicating & working with stakeholders to meet their needs and addressing issues as they occur.
Change requests Various updates to processes, plans & documents
PMBOK
49
Stakeholder engagement REVIT 2007:
INFORM
Provide objective information to aid stakeholders appreciate the problem, alternatives, opportunities and/or solutions
CONSULT
Obtain feedback from stakeholders for decision-makers on analysis, alternatives and/or decisions
INVOLVE
Work with stakeholders throughout a project to ensure their concerns and aspirations are consistently understood and considered in decision-making processes
COLLABORATE
Partner with stakeholders in each aspect of any decision
EMPOWER
SoDIS
Place final decision-making power with stakeholders

50
Stakeholder Input - 1
The two (2) knowledge areas in PMBoK where stakeholder input is required are: Scope management (5)
5.1 Collect requirements is the process of defining & documenting stakeholders needs to meet the project objective. Collecting requirements is defining & managing customer expectations. Requirements become the foundation of the WBS. The development of requirements begins with the analysis of the information contained in the project charter and stakeholder register.
Requirements documentation. Requirements management plan and RTM.
PMBOK
51
Stakeholder Input - 2
Risk management (11)
11.2 Identify risks is the process of determining which risks may affect the project & documenting their characteristics. Participants in risk identification activities can include the following: project manager, , stakeholders, and risk management experts.
Risk register
Hmmm! So, stakeholders should help determine requirements & risks. But, I cant help thinking that some stakeholders can be risks too!
PMBOK
A message
Stakeholder management on IT projects is typically not done well!
SoDIS
53
Thinking aloud (again)

So, from everything explained so far, it seems that PMBoK and other standards and experts are relatively mature in suggesting ways to identify and describe stakeholders. However, it seems that the analysis of stakeholder risk and impacts might still be maturing. Has there been any progress on stakeholder risk of late?
SoDIS
54
Risk
5. Risk
Project management a risk mitigation strategy Project management of product development Definitions of risk
AS/NZS 4360:2004 & PMBoK Guide 4E:2008
5 steps - AS/NZS 4360:2004

Risk context, identification, analysis, evaluation, treatment
Risk register (example) Risk levels A note on risk tolerance
SoDIS
55
Risk - 1
Project Management a risk mitigation strategy
Scoping WBS Estimating Resourcing Scheduling Monitoring Defining whats in & whats out Detailing tasks of work to be done (detailed scope) Using WBS to make effort & cost estimates Describing necessary resources (human & otherwise) Combine estimates & resources to create schedule Monitoring progress based on schedule
Managing changes Adapting all the above to agreed changes Managing risk Closing
SoDIS
Identify, qualify/quantify, mitigate, monitor Feedback on what went (not so) well & lessons learned
Risk - 2
Project management of product development
Scoping WBS Estimating Resourcing Scheduling Monitoring Includes defining product requirements May be constructed around product components Will be affected by production techniques/methods Need to be aligned with type of product development May be based on incremental product operation Monitoring progress based on schedule
Managing changes Adapting all the above to agreed changes Managing risk Closing
SoDIS
Identify, qualify/quantify, mitigate, monitor Feedback on what went (not so) well & lessons learned
Risk - 3
I understand that project management can be a risk mitigation strategy. But isnt project management like anything that humans do? They can do it competently or incompetently! I presume that poor project management will very likely lead to project failure? Remind me of risk.
SoDIS
58
Risk - 4
Definitions of risk: AS/NZS 4360:2004
the chance of something happening that will have an impact on objectives.
PMBoK Guide 4E:2008

an uncertain event or condition that, if it occurs, has an effect on at least one project objective.
5 steps AS/NZS 4360:2004

1. Risk context
Establish full context of project
2. Risk identification
Identify all possible risks
3. Risk analysis
Evaluate each risk in terms of probability of occurring & impact on project if it were to happen using a qualitative or quantitative comparative framework
4. Risk evaluation
Prioritise risks by risk level & determine which risks need to be treated
5. Risk treatment
Identify the range of options for treating risks
SoDIS
60

Risk context
Internal contexts
Culture Internal stakeholders Structure Capabilities Systems Processes Capital
External contexts
Business Societal Regulatory Cultural Competitive Financial Political External stakeholders SWOT
Causal context change
SoDIS
61

Risk identification
As with stakeholders can use risk types for aiding with identification actual project risks
Public Health Technical Legal Brainstorming Delphi use subject matter experts Interviewing SWOT
Also use techniques like:

SoDIS
62

Risk analysis
Evaluate each risk in terms of probability of occurring & impact on project if it were to happen using a qualitative or quantitative comparative framework Best done with SMEs
SoDIS
63

Risk evaluation
Determine tolerability of risk levels Determine what risk level(s) require no treatment Prioritise risks for treatment based on tolerability determinations Accept the risk
assuming it is tolerable or too costly to reduce
Risk treatment

SoDIS
Reduce the likelihood Lessen the impact Transfer to another party Avoid
Take action to remove cause
Example Risk register

Risk register for eVACS
Risk Data entry errors will cause significant delay to start of counting Politician may disagree with result and want a recount Prob Low Impact Low
Summarises steps 1-5

Mitigaton Reduce size of batches of paper ballots Ensure all politicians are kept informed of eVACS functionality and test results 1. Determine possible options for the interface from the Vision Australia organisation 2. Run workshops to obtain information from potential vision-impaired voters
Low
High
Vision-impaired voters may find the combination of the keypad and audio guidance difficult to use
Med
Med
Risk Level = Probability x Impact

Risk levels
Risk levels are used to help identify intolerable risk
Risk Levels Impact High Medium Low M M Probability High Medium Low M
OK! I know that project managers need to identify both stakeholders and risks, and to analyse them. But how can these important aspects of a project be brought together better?
A note on risk tolerance

Why are these tolerances to death all different?
Chance of motor vehicle death ~ 1 in 7,000 Chance of preventable hospital death ~ 1 in 70,000 Chance of accidental death ~ 1 in 2,500 Chance of aviation death ~ 1 in 4,000,000
People are far more concerned about flying than travelling in a motor vehicle even though the risk of death is ~600 times greater in a motor vehicle.
A message on risk
Risk identification and management on IT projects is typically not done well!

I really dont like hearing that IT projects are not managed well! Do you think that IT project managers may be lacking competence?
SoDIS
6. SoDIS

SoDIS
A sitcom on project stakeholders and risk A synopsis of a project Gotterbarn and Rogerson The SoDIS process (in brief) The SoDIS questions (with examples) SoDIS principles SoDIS questions for principles Applying the SoDIS questions The SoDIS process SoDIS Why bother? Estimating program value
SoDIS - 1
A sitcom on project stakeholders and risk
Stakeholders
Only the obvious are identified Impact on the project is given more emphasis than impact on the stakeholders Stakeholder management is biased toward those with greatest apparent impact
Risk
Typically, only the obvious are identified Little awareness of risk mitigated through good project management Impact and probability often not determined Mitigation strategies often not thought out in depth
Both treated implicitly - disconnected from project tasks

SoDIS - 2
A synopsis of a project
Conducted by undertaking a series of tasks usually planned Diminished project risk is attained by:
Performing the right tasks, Performing the tasks right, Managing the right stakeholders, and Managing the stakeholders right
How?
Find ways to connect and manage stakeholders, risks, and tasks, in unison
SoDIS - 3
Gotterbarn and Rogerson
Created the Software Development Impact Statement
SoDIS proposed in 1998 Elaborated in 2005
The SoDIS process

Expands on risk analysis methods by Explicitly addressing a range of qualitative questions Concerning the potential impacts of a project from Differing stakeholders perspectives
SoDIS
72
SoDIS - 4
The SoDIS questions
Articulate common qualitative issues Are derived from international codes of practice Take the following form:
The fixed part The risk aspect of interest
Might project task issue stakeholder?

A project task from the WBS
Any project stakeholder

73
SoDIS - 5
Example SoDIS questions
Might ensure each voter is provided with a vote summary before committing keep hidden any possible dangers to elderly voters? Might ensure each voter is provided with a vote summary before committing cause foreseeable risks not disclosed to elderly voters?
SoDIS
74
SoDIS - 6
SoDIS principles The SoDIS questions on potential risk derive from a set of key principle issues concerning stakeholders that must be prevented

SoDIS
Prevent project & requirements/tasks risks Prevent risks that cause harm to Prevent risks that unreasonably restrict Prevent risks that involve deception of Prevent risks of conflict with responsibility towards
SoDIS - 7
SoDIS principle: Prevent project & requirements/tasks risk
Focus on the broad impacts that software can have. Software development requires a professional approach. A professional has both:
technical responsibilities (get the job done in the best way possible), and moral responsibilities to not violate human values and, wherever possible, to advance those values.
The software engineer has a responsibility to ensure health, safety and public welfare.
Just like a structural engineer or builder, etc.
SoDIS - 8
SoDIS questions for principle: Prevent project & requirements/tasks risk
Task REQUIRE approval of software that may not fulfill the requirements of the contract? Task CAUSE harm to the user, the public, or the environment? Task FAIL to consider the interests of the employer, the client, or the general public? Task REQUIRE working on a project with infeasible objectives or goals?
SoDIS
77
SoDIS - 9
SoDIS questions for principle: Prevent project & requirements/tasks risk
Task REQUIRE misrepresentation of the products capabilities or reliability? Task REQUIRE the developer to work beyond their ability? Task CAUSE loss of information, loss of property, property damage, or environmental impacts?
SoDIS
78
SoDIS - 10
SoDIS principle: Prevent risks that cause harm to
A central principle is that a project and its product(s) cause no harm, either direct or indirect harm. "Harm" means injury or negative consequences
Undesirable loss of information, Loss of property, property damage, or unwanted environmental impacts.
This principle prohibits use of computing technology in ways that result in harm to:
Users, the general public, employees or employers.
SoDIS
79
SoDIS - 11
SoDIS principle: Prevent risks that may cause harm to
Harmful actions include:
Intentional destruction or modification of software artefacts leading to serious loss of resources Unnecessary expenditure of human resources (e.g., purging computer viruses)
Association of Computing Machinery (ACM):

Well-intended actions may lead to harm unexpectedly. responsible person(s) are obligated to deal with the negative consequences. To avoid unintentional harm, carefully consider potential impacts on all who are affected by decisions made during proposal, design and Implementation.
SoDIS - 12
SoDIS questions for principle: Prevent risks that may cause harm to
Task CAUSE the unwanted modification or destruction of files and programs owned or in use by Stakeholder? Task CAUSE the unnecessary expenditure of the resources of Stakeholder? Task INVOLVE the design or approval of software which may lower the quality of life of Stakeholder?
SoDIS
81
SoDIS - 13
Task FAIL to take into consideration the needs and/or interests of Stakeholder? Task DISCRIMINATE against Stakeholder? Task VIOLATE the privacy and confidentiality of Stakeholder? Task ALLOW unauthorized access or alteration to the data of Stakeholder?
SoDIS
82
SoDIS - 14
Task INVOLVE the design or approval of software that may cause a risk of injury or loss of life for Stakeholder? Task ALLOW the corruption or invalidation of the data belonging to or pertaining to Stakeholder? Task FAIL to offer provision for any disability to Stakeholder? Task FAVOR ease of development at the expense of Stakeholder?
SoDIS - 15
SoDIS principle: Prevent risks that unreasonably restrict
Computer software can restrict the activities or options of users. As a practical example, it is very important to visionimpaired voters to have the same privacy as all other voters. If this aspect of voting had not been addressed in eVACS then it would have unreasonably restricted vision-impaired voters.
SoDIS
84
SoDIS - 16
SoDIS questions for principle: Prevent risks that unreasonably restrict
Task FAIL to offer provision for any disability to Stakeholder? Task FAVOUR ease of development at the expense of Stakeholder?
SoDIS
85
SoDIS - 17
SoDIS principle: Prevent risks that involve deception of
The computer professional must strive to be honest.
Honesty is essential to obtaining trust Without trust an organization cannot function effectively
The honest computing professional:

Does not make deliberately false or deceptive claims about a system or system design Does (instead) provide full disclosure of all pertinent system limitations and problems
SoDIS
86
SoDIS - 18
SoDIS questions for principle: Prevent risks that involve deception of
Task KEEP hidden any possible dangers to Stakeholder? Task REQUIRE dishonesty or untrustworthiness on the part of Stakeholder? Task VIOLATE the intellectual property rights of Stakeholder? Task REQUIRE the use of software that is obtained illegally by/or for Stakeholder? Task CAUSE foreseeable risks not disclosed to Stakeholder?
SoDIS - 19
SoDIS principle: Prevent risks of conflict with responsibility towards
Responsible excellence toward stakeholders
Perhaps the most important obligation of a professional.
Strive to achieve quality

Be cognizant of the serious negative consequences that may result from poor quality in a system.
SoDIS
88
SoDIS - 20
SoDIS questions for principle: Prevent risks of conflict with responsibility towards
Task NEGLECT quality assurance processes and review by Stakeholder? Task PREVENT acceptance of responsibility to Stakeholder? Task MISUSE the computer resources of Stakeholder? Task INVOLVE conflict of interest with Stakeholder?
SoDIS
89
SoDIS - 21
SoDIS questions for principle: Prevent risks of conflict with responsibility towards
Task CAUSE ineffectiveness or inefficiency as perceived by Stakeholder? Task BREAK contracts or agreements with Stakeholder? Task INVOLVE unauthorized use of the facilities of Stakeholder? Task IMPEDE compliance with applicable laws by Stakeholder?
SoDIS
90
SoDIS - 22
Wow! Im simply flabbergasted!! These 31 SoDIS questions really do enable effective connection between risk, tasks and stakeholders. NOT ONLY THAT! They promote professionalism with their use! It kills two birds with one stone! Woops I shouldnt have said that!
SoDIS
91
SoDIS - 23
Applying the SoDIS questions
Might project task issue stakeholder?

SoDIS
By itself a question identifies a potential risk No as an answer suggests extremely low probability of occurring Yes as an answer actualises the risk - suggesting that there is some probability of it occurring Yes as an answer also means treat/mitigate the risk An actualised risk requires further elaboration by one or statements of concern Concerns are treated by describing viable solutions
SoDIS - 24
SoDIS process
Project tasks (WBS) Identify stakeholders
Predefined SoDIS Issues
Form questions
Answer questions Yes Describe solutions

SoDIS
No Perhaps revisit
State concerns
93
SoDIS - 25
I just realised that there will be lots of questions to answer! Being a mathematical duck Ive determined that if there were 100 tasks and 25 stakeholders and 31 SoDIS questions for each task-stakeholder pair, there would be a total of 100x25x31 (or 77,500) questions. You need a tool to help with sort of volume.
SoDIS
94
SoDIS - Why bother?

SoDIS provides a range of benefits:
Significantly improves identification of stakeholderrelated risks and the early treatmengt of those risks Earlier determination of a broad range of stakeholders and potential impacts
they have on the project, and the project on them
Various stakeholder groups in their project roles

Performing organisation Project sponsor Project manager Project team members External stakeholders (users, procurers, non-humans)
Complements best practices in PM and RM

Estimating program value - 1

Software engineering professionals know that:
Early and proper application of IV&V practices
Significantly reduces rework saving on effort and budget Increases quality through end-to-end requirements tracing Provides high Return-on-investment (RoI)
Catching problems late in a project is very costly and can lead to project cancellation Competency is important but not sure of degree Good intra-team and customer collaboration affects successful outcomes but not sure of degree

Some supporting evidence of SoDIS value:
A business case - McHaney (2004)
Details a business case for adoption of SoDIS in terms of a financially-based business case structure Concludes that:
As with other risk management approaches SoDIS needs to be viewed in the same way as a quality assurance program or insurance policy. A relatively small investment upfront can protect an organisation from potentially devastating economic consequences downstream.
SoDIS
97

Keane Inc. - Boston
As a case study for SoDIS - undertook a blind parallel test with a running project Project had passed normal risk assessment SoDIS analysis revealed substantial risks which had not been anticipated Cost to mitigate new found risks was more than executive directors were prepared to pay project was cancelled saving potentially $millions
SoDIS
98

Kwan, Hitchcock, Clear, Gotterbarn & Simpson
SoDIS analysis on a health project with a $NZ 160K budget SoDIS effort constituted 3.8% of overall cost Exposed 16 critical concerns, 106 significant concerns The customer (Eagle Technology) found the exposure of identified risks very surprising and also realised the actual benefit to the success of the project.
Support for SoDIS is growing only slowly

Some users are concerned about the risks that a SoDIS analysis exposes they are inclined to keep such information from other parties for fear of being labeled incompetent!
SoDIS
99
Defining a project
Essential steps for defining a project:
1. Identify the type of project 2. Identify the typical stakeholder roles (types) for the type of project 3. Describe the project in terms of:
Purpose and objectives Intended audience Intended use Intended installations Any unique aspect of the project Other information that could help the analyst
4. Identify stakeholders 5. Describe project tasks

SoDIS Project Auditor - 1

The SoDIS Project Auditor (SPA) is a software tool:
That enhances the SoDIS process
Supports multiple projects Enables Preliminary Analysis as well as SoDIS Analysis Provides context-driven guidance for using the tool Contains default lists of stakeholders Can incorporate new stakeholder roles and project types The core set of 31 issues used to form questions can be extended by incorporation of new risk categories and issues Stakeholders from a Preliminary Analysis can be copied to a SoDIS Analysis and vice versa for the same project Provides five (5) reports for a Preliminary Analysis Provides ten (10) reports for a SoDIS Analysis

Key reasons for development of SPA:
Provide a preliminary analysis using a predefined set of questions to determine project readiness
Questions are constructed so that No answers require
action(s) to be described due date for action to be completed an indication of urgency
Questions cover
1. Project context and plan to ensure basic project requirements are in place 2. Project tasks documented, test requirements, are participants known 3. Project stakeholders are they identified, do they have necessary knowledge, do they need training 4. Project task & Stakeholder relationships

Key reasons for development of SPA:
Set tasks as not relevant to stakeholder Copy stakeholder analysis Copy task analysis Audit ability
Enforcing traceability of answers, entered concerns and solutions Ranking criticality
Display and report

Aspects for which there are concerns/solutions and actions
Provide the SoDIS


SoDIS-By Clive and Carol Boughton Sept 2011

Încărcat de

Informații document

Descriere originală:

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

SoDIS-By Clive and Carol Boughton Sept 2011

Încărcat de

Drepturi de autor:

Formate disponibile

SoDIS

Software Development Impact Statement

P.Edwards & P.Bowen: Risk Management in Project Organisations

Clive & Carol Boughton

Clive & Carol Boughton

Depends on your perspective!

Poor risk management

And theres many more!

Clive & Carol Boughton

IT projects are typically not done well!

Clive & Carol Boughton

Clive & Carol Boughton

Characteristics of project management:

Project management on IT projects is typically not done well!

Clive & Carol Boughton

Clive & Carol Boughton

The PMBoK definition:

Wikipedia and CVB

Ah! Thats more inclusive! Is there more to know about stakeholders?

Wikipedia and CVB

John Tuman Jr. Chapter 13A AMA Handbook

John Tuman Jr. Chapter 13A AMA Handbook

Proj. result affected

T. Kloppenborg: Contemporary Project Management

Proj. result affected

T. Kloppenborg: Contemporary Project Management

Clive & Carol Boughton

Stakeholder impact ranking

Clive & Carol Boughton

Request for Proposal from ACT Electoral Commission

Clive & Carol Boughton

An installed trial, electronic voting system that must:

Applicable standards and regulations. Cultural influences.

Clive & Carol Boughton

Stakeholder theory in practice

Clive & Carol Boughton

Legitimacy of stakeholder representative

Stakeholders engagement capacity

Relationships of stakeholders with each other

Clive & Carol Boughton

Project team members

Example answer Stakeholders

Example answer Stakeholders

Clive & Carol Boughton

Example answer Stakeholders

Clive & Carol Boughton

How are they likely to be influenced?

Robert Buttrick: The Project Workout - 2005

More thinking aloud!

Clive & Carol Boughton

Stakeholder identification on IT projects is typically not done well!

Clive & Carol Boughton

Stakeholder input required in 2 KAs of PMBoK

Clive & Carol Boughton

Place final decision-making power with stakeholders

Stakeholder management on IT projects is typically not done well!

Clive & Carol Boughton

Thinking aloud (again)

Clive & Carol Boughton

5 steps - AS/NZS 4360:2004

Risk register (example) Risk levels A note on risk tolerance

Clive & Carol Boughton