SoDIS-By Clive and Carol Boughton Sept 2011 (1)

8/2/2019 SoDIS-By Clive and Carol Boughton Sept 2011 (1)

1/103

OverviewBy

Clive & Carol Boughton

SoDISSoftware Development Impact Statement


2/103

AgendaSoDIS Why bother?Estimating program value

Defining a projectWhich analysis is needed?SoDIS inspection processApplying SoDISSoDIS Clive & Carol Boughton 2


3/103

IntroductionProjects, Risks and Stakeholders All projects involve risk and stakeholders

Projects today tend to involve more participantsHaving different roles, expectations and needs

Project risks are dynamic Risk is communicated implicitly rather than explicitly Modern project management has to deal with theoften competing and conflicting demands of manystakeholders

SoDIS Clive & Carol Boughton 3

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


4/103

IntroductionProjects, 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 andstakeholder situations:Environment - fauna, flora, people, infrastructureFinance the rich and the poorHealth medicines, disease, peopleViolence animals and peopleTerrorism peoples and society


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


5/103

Outline1. Projects2. Project Management3. Stakeholders4. Stakeholder Management5. Risk6. SoDISSoDIS Clive & Carol Boughton 5


6/103

Projects1. Projects

What is a project? Characteristics of projects What is project failure? Reasons for project failure



7/103

Projects - 1What is a project?A temporary endeavour undertaken to create a uniqueproduct, 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 timeresources and technical performance. (AMA-Hbk)


PMBoK: Project Management Body of KnowledgeAMA-Hbk: American Management Association Handbook


8/103

Projects - 2


Thats pretty obvious even to me!

So I now have a definition of a project,

but can you help me understand whyprojects fail?


9/103

Projects - 3What is project failure? Not meeting planned schedule and/or budget and/orrequirements?

Standish Group International 1994 to 2010 Not obtaining repeat business? Not advancing the development or projectorganisation in the state of the art? Making an overall loss in profit? And many more!

Depends on your perspective!SoDIS Clive & Carol Boughton 9


10/103

Projects - 4Reasons for project failure Management & requirements issues

Office of Government Commerce (UK) - 2008 Insufficient involvement of senior management, toomany requirements and scope changes, lack of

necessary management skillsEl Emam & Koru - 2008

Poor risk managementDeMarco & Lister - 2003

Lack of user involvement, lack of executivemanagement support, lack of a clear statement ofrequirementsStandish Group 2004

And theres many more!SoDIS Clive & Carol Boughton 10


11/103

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!


12/103

A message

IT projects are typically not done well!



13/103

Project Management2. Project management

Project mismanagement an immature lifecycle What is project management? Characteristics of project management



14/103

Project MismanagementAn Immature Project Life Cycle

Phase 1 Project InitiationPhase 2 Wild Enthusiasm (even night long parties)Phase 3 Dis-illusionmentPhase 4 ChaosPhase 5 Search for the GuiltyPhase 6 Punishment of the InnocentPhase 7 Promotion of the Non-participantsPhase 8 Definition of the Requirements


Futrell, Shafer & Shafer: Chapter 7


15/103

Project Management - 1What is project management?

the application of knowledge, skills, tools andtechniques to project activities in order to meetstakeholders needs and expectations from a project.PMBoKCharacteristics of project management:

Scope management Time management Cost management

Quality management Human resource management


PMBOK & AMA-Hbk


16/103

Project Management - 2Characteristics of project management, contd:

Communications management Risk management Procurement management Integration management


PMBOK & AMA-Hbk

Wow! Thats a lot of management activities!

But, I get the impression that these things/beings

called stakeholders might need to be managed too!


17/103

A message

Project management on IT projects is typically notdone well!



18/103

Stakeholders3. 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



19/103

Stakeholders - 1The definition of project management includes:

in order to meet stakeholdersneeds andexpectations

The PMBoK definition: Persons & organizations such as customers,

sponsors, performing organization & the public, thatare actively involved in the project, or whose interestsmay be positively or negatively affectedby executionor completion of the project. They may also exertinfluence over the project and its deliverables.


PMBOK

That is a bit vague!

So what is a stakeholder?


20/103

Stakeholders - 2Alternative definition

A person, group, organization, or system who/whichaffects or can be affected by another persons,groups, organization's or systems actions.


Wikipedia and CVB

Hey! I notice that I might notbe a stakeholder!

That doesnt seem right to me!


21/103

Stakeholders - 3A better definition

A person (or any other being), group, organization, orsystem who/which affects or can be affected byanother persons, (beings,) groups, organization'sor systems actions.


Wikipedia and CVB

Ah! Thats more inclusive!

Is there more to know about

stakeholders?


22/103

Stakeholders - 4Stakeholders have varying levels of responsibility and authority when participating on a projectand these can change over the course of the projects life cycle. Their responsibility andauthority range from occasional contributions in surveys and focus groups to full projectsponsorship, which includes providing financial and political support. Stakeholders who ignorethis responsibility can have a damaging impact on the project objectives. Likewise, projectmanagers who ignore stakeholders can expect a damaging impact on project outcomes.Sometimes, stakeholder identification can be difficult. For example, some would argue that anassembly-line worker whose future employment depends on the outcome of a new product-design project is a stakeholder. Failure to identify a key stakeholder can cause major problemsfor a project.Stakeholders may have a positive or negative influence on a project. Positive stakeholders arethose who would normally benefit from a successful outcome from the project, while negativestakeholders 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 bepositive stakeholders because they see economic benefit to the community from the projectssuccess. Conversely, environmental groups could be negative stakeholders if they view theproject as doing harm to the environment. In the case of positive stakeholders, their interests arebest served by helping the project succeed, for example, helping the project obtain the neededpermits to proceed. The negative stakeholders interest would be better served by impeding theprojects progress by demanding more extensive environmental reviews. Negative stakeholdersare often overlooked by the project team at the risk of failing to bring their projects to asuccessful end.


PMBOK


23/103

Stakeholder Groups - 1Project 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


24/103

Stakeholder Groups - 2Community participants

Community members Special interestgroups Religious leaders Political groups Social & ethnic groups Environmentalists

Parasitic participants Opportunists Activists Causes News & information

media




25/103

Stakeholder Groups - 3InternalProj. process affected

Owner Sponsor Project manager Functional managers Financing source Project core team Subject matter experts Employees Stockholders

Proj. result affected Internal customer Sponsor Users


T. Kloppenborg: Contemporary Project Management


26/103

Stakeholder Groups - 4ExternalProj. process affected

Suppliers Partners Government agents Special interest grps Client Professional groups Media Taxpayers Unions Competitors

Proj. result affected Client Public Special interest grps Potential customers


T. Kloppenborg: Contemporary Project Management


27/103

Stakeholder impact ranking

Highest Activists Media Community leaders Clients/Customers Project management

3rd Highest Politicians

2nd Highest Regulators Developers Special interestgroups Environmentalists Vendors

4th Highest Constructors Visionaries


Ranking of potential to impact project success



28/103

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 justgiven can actually help me to identify project

stakeholders better.

Is there any way I can I try this out now?


29/103

Example exerciseAustralian Capital Territory Electoral Commission

Request for proposal for system to manage:

Election setup

Electronic voting Electronic counting Data entry



30/103

SoDIS Clive & Carol Boughton

Example exercise ACTEC RFPRequest for Proposal from ACT Electoral Commission Would like proposal submissions from organisations possessingthe experience / capability to design, construct, install andsupport a trial electronic voting, paper vote entry, and countingsystem to be used for the October 2001 ACT Election. The system must run on standard PC hardware which will besupplied by the ACT Government Outsource Agent (InTact). Developed software mustsupport all aspects of the Hare-Clarkpreferential systemcurrently in place. Internet solutions will not be considered for the short term. Final coded system to be independently audited.

30


31/103


An installed trial, electronic voting system that must: be no less secure and no less reliable than the currentpaper-based system - tamper proof and secure storage ofvotes. strongly support voting processes in current paper-basedsystem - anonymity,1 voter 1 vote, whole paper viewable &

readable, Robson Rotation, informal votes. be easy to use for both sighted & (desirably) sight-impairedvoters -using keyboard or mouse but not touch-screen. be able to accumulate votes at polling places for transfer to acounting centre after close of voting. automatically sequence selected candidates for voter. provide voting instructions and error messages in 12 ACT-ECchosen languages.

31

Example exercise ACTEC RFP


32/103

Example eVACS - Needs


Electronic Voting: ""

Electronic ballot to be displayed in similar formatto paper ballot Ballots to be displayed inRobson Rotationsequence Voter to be able to vote informally Voter must have opportunity to changevote 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 outsideof their own electorate Provision for the blind and vision-impaired Instructions and messages to be displayed in one of choice of12

languages Openness of process


33/103


Socioeconomic influences: Applicable standards and regulations. Cultural influences. Political.

Economic. Demographic. Educational. Ethical. Ethnic. Religious.

33

PMBOK

Example exercise ACTEC RFP


34/103

Identifying stakeholders - 1As a contractor a simple brainstorming process can beused to extract obvious stakeholders from (say) aRequest for Tender (RFT).It is better to be armed with a list of general stakeholdergroups (or types) to increase the probability ofidentifying those stakeholders that are less obvious.In any case, it is unlikely that ALL stakeholders will beidentified at the beginning of a project unless there hasbeen a significant effort to engage with them early.



35/103

Identifying stakeholders - 2Useful stakeholder engagement techniques

USAID MEASURE EvaluationForeit et al. 2006

Stakeholder theory in practiceBowern et al. 2004

AccountAbility AA1000SESStakeholder Engagement Standard 2009

REVITStakeholder Engagement Toolkit 2007

UNDPMulti-Stakeholder Engagement Processes 2006



36/103

Identifying stakeholders - 3AccountAbility AA1000SES supports principles of:

INCLUSIVITY giving stakeholders the right to be heard and accepting

the obligation to account to them

MATERIALITYA determination of the relevance and significance to its

associated organisation and associated stakeholders.

RESPONSIVENESSThe formulation of decisions and actions in responding to

stakeholder issues.



37/103

Identifying stakeholders - 4AccountAbility AA1000SES supports profiling:

ExpectationsEstablish how a stakeholder views an issue/concern and

what they expect of the engager. Determine whetherrequired effort/time is worth it.

KnowledgeDetermine who can learn from whom. Make sure

stakeholders well know who is engaging them.

Legitimacy of stakeholder representativeThe formulation of decisions and actions in responding to

stakeholder issues.

Willingness to engageInvestigate unwillingness to engage. Dont assume anything.



38/103

Identifying stakeholders - 5AccountAbility AA1000SES supports profiling:

Possible impacts Cultural context

Be fully aware of cultural, language, customs, socialinteraction and gender issues.

Stakeholders engagement capacityDont assume stakeholders will have time/finances to

engage.

Relationships of stakeholders with each otherWatch out for competition and conflicts of interest.



39/103

Identifying stakeholders - 6Might start with the usual suspectsProject manager

The person responsible for managing the project.Customer/user

The persons or organizations that will use theprojects product or service. There may be multiplelayers 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


40/103

Identifying stakeholders - 7Might start with the usual suspects contdProject management team

The members of the project team who are directlyinvolved 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 toan individuals position in the customer organizationor performing organization, can influence, positivelyor negatively, the course of the project.


PMBOK


41/103

Identifying stakeholders - 8Additional 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 whichindividuals & organizations view themselves as (actual) stakeholders.Stakeholder roles & responsibilities can overlap (e.g., an IT firm thatprovides au diting tools for a product it is designing).


PMBOK


42/103

Example answer StakeholderseVACS Stakeholders:

SIPL and InTact ACT ElectoralCommission Voters Sight impaired Mentally impaired Elderly Voting Day Absentees Computer-illiterate

CandidatesSoDIS Clive & Carol Boughton 42

Equipment Suppliers Dogs for blind Election Volunteer

Helpers

Political Parties Other Electoral Comms System Auditors Local IT Businesses Environment Current ACT Government


43/103

Example answer Stakeholders

Stakeholder Stakeholder Type

SIPL & InTact Performing Organisations

ACTEC Customer, Owner, Sponsor

Sight-impaired voters Users, Influencers

Mentallyimpaired voters Users

Elderly voters Users

Absentee voters Users

Computer-illiterate voters Users

Candidates User, Influencers


eVACS Stakeholder Types


44/103

Example answer Stakeholders


Stakeholder Stakeholder Type

Equipment Suppliers External, Vendors

Dogs for blind & vision-impaired External

Election volunteer helpers Users, Individual citizens

Political parties Users, Influencers

Other ECs Gov. agencies

System auditors External, Influencers

Local IT business External, Users

Environment External, Community

Current ACT Gov. Influencer

eVACS Stakeholder Types


45/103


46/103

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?


47/103

A message

Stakeholder identification on IT projects istypically not done well!



48/103

Stakeholder Management4. 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)



49/103

Stakeholder ManagementPMBoK treats stakeholder identification andmanagement within one (1) knowledge area:Communications management (10) 10.1 Identify stakeholders

Stakeholder registerStakeholder management strategy (to increase support)

10.4 Manage stakeholder expectations is the processof communicating & working with stakeholders tomeet their needs and addressing issues as theyoccur. Change requestsVarious updates to processes, plans & documents


PMBOK


50/103

Stakeholder ManagementStakeholder engagement REVIT 2007:

INFORMProvide objective information to aid stakeholders appreciate

the problem, alternatives, opportunities and/or solutions

CONSULTObtain feedback from stakeholders for decision-makers on

analysis, alternatives and/or decisions

INVOLVEWork with stakeholders throughout a project to ensure their

concerns and aspirations are consistently understood andconsidered in decision-making processes

COLLABORATEPartner with stakeholders in each aspect of any decision

EMPOWERPlace final decision-making power with stakeholders



51/103

Stakeholder Input - 1The two (2) knowledge areas in PMBoK wherestakeholder input is required are:Scope management (5)

5.1 Collect requirements is the process of defining &documenting stakeholders needs to meet the projectobjective. Collecting requirements is defining &managing customer expectations. Requirementsbecome the foundation of the W BS. Thedevelopment of requirements begins with the analysisof the information contained in the project charterand stakeholder register.Requirements documentation.Requirements management plan and RTM.


PMBOK


52/103

Stakeholder Input - 2Risk management (11)

11.2 Identify risks is the process of determining whichrisks may affect the project & documenting theircharacteristics. Participants in risk identificationactivities can include the following: project manager,, stakeholders, and risk management experts.Risk register


PMBOK

Hmmm! So, stakeholders should help

determine requirements & risks.

But, I cant help thinking that some

stakeholders can be risks too!


53/103

A message

Stakeholder management on IT projects istypically not done well!



54/103

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 onstakeholder risk of late?


55/103

Risk5. 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



56/103

Risk - 1Project Management a risk mitigation strategy


Scoping Defining whats in & whats out

WBS Detailing tasks of work to be done (detailed scope)

Estimating Using WBS to make effort & cost estimates

Resourcing Describing necessary resources (human & otherwise)

Scheduling Combine estimates & resources to create schedule

Monitoring Monitoring progress based on schedule

Managing changes Adapting all the above to agreed changes

Managing risk Identify, qualify/quantify, mitigate, monitor

Closing Feedback on what went (not so) well & lessons learned


57/103

Risk - 2Project management of product development


Scoping Includes defining product requirements

WBS May be constructed around product components

Estimating Will be affected by production techniques/methods

Resourcing Need to be aligned with type of product development

Scheduling May be based on incremental product operation

Monitoring Monitoring progress based on schedule

Managing changes Adapting all the above to agreed changes

Managing risk Identify, qualify/quantify, mitigate, monitor

Closing Feedback on what went (not so) well & lessons learned


58/103

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.


59/103

Risk - 4Definitions of risk:AS/NZS 4360:2004

the chance of something happening that will havean 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.



60/103

5 steps AS/NZS 4360:20041. Risk context Establish full context of project2. 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 orquantitative 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



61/103

5 steps AS/NZS 4360:2004Risk context

Internal contexts Culture Internal stakeholders Structure Capabilities Systems Processes Capital

Causal context change


External contexts Business Societal Regulatory Cultural Competitive Financial Political External stakeholders SWOT


62/103

5 steps AS/NZS 4360:2004Risk identification

As with stakeholders can use risk types for aidingwith identification actual project risks Public Health Technical Legal

Also use techniques like: Brainstorming Delphi use subject matter experts Interviewing SWOT



63/103

5 steps AS/NZS 4360:2004Risk analysis

Evaluate each risk in terms of probability ofoccurring & impact on project if it were to happenusing a qualitative or quantitative comparativeframework Best done with SMEs


5 steps AS/NZS 4360:2004


64/103

Risk evaluation Determine tolerability of risk levels Determine what risk level(s) require no treatment Prioritise risks for treatment based on tolerabilitydeterminations

Risk treatment Accept the risk assuming it is tolerable or too costly to reduce

Reduce the likelihood Lessen the impact Transfer to another party

Avoid Take action to remove cause


Example Risk register


65/103

Risk Prob Impact Mitigaton

Data entry errors will causesignificant delay to start ofcounting

Low LowReduce size of batches ofpaper ballots

Politician may disagree with

result and want a recountLow High

Ensure all politicians are keptinformed of eVACSfunctionality and test results

Vision-impaired voters mayfind the combination of thekeypad and audio guidancedifficult to use

Med Med

1. Determine possibleoptions for the interfacefrom the Vision Australiaorganisation

2. Run workshops to obtaininformation from potentialvision-impaired voters


Risk register for eVACS

}

Risk Level = Probability x Impact

Summarises steps 1-5

Risk levels


66/103


Risk LevelsProbability

High Medium Low

Impact High M

Medium M

Low M

Risk levels are used to help identify intolerable risk

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


67/103

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 amotor vehicle even though the risk of death is ~600 timesgreater in a motor vehicle.


A message on risk


68/103

Risk identification and management on IT projectsis 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


69/103

6. 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


70/103

A sitcom on project stakeholders and risk Stakeholders

Only the obvious are identifiedImpact on the project is given more emphasis than impact on

the stakeholders

Stakeholder management is biased toward those withgreatest apparent impact

RiskTypically, only the obvious are identifiedLittle awareness of risk mitigated through good project

management

Impact and probability often not determinedMitigation strategies often not thought out in depth

Both treated implicitly - disconnected from project tasksSoDIS Clive & Carol Boughton 70


71/103

SoDIS - 3


72/103

Gotterbarn and Rogerson Created the Software Development Impact Statement

SoDIS proposed in 1998Elaborated 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 - 4


73/103

The SoDIS questions Articulate common qualitative issues Are derived from international codes of practice Take the following form:

Mightproject task issue stakeholder?


The fixed part

A project task from the WBS

The risk aspect of interest

Any project stakeholder

SoDIS - 5


74/103

Example SoDIS questionsMightensure each voter is provided with a votesummary before committing keep hidden anypossible dangers to elderly voters?Mightensure each voter is provided with a votesummary before committing cause foreseeablerisks not disclosed to elderly voters?


SoDIS - 6


75/103

SoDIS principlesThe SoDIS questions on potential risk derivefrom a set of key principle issues concerningstakeholders that must be prevented 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


76/103

SoDIS principle:Prevent project & requirements/tasks risk Focus on the broad impacts that software can have. Software development requires a professionalapproach. A professional has both:

technical responsibilities (get the job done in the best waypossible), and

moral responsibilities to not violate human values and,wherever possible, to advance those values.

The software engineer has a responsibility to ensurehealth, safety and public welfare.Just like a structural engineer or builder, etc.


SoDIS - 8


77/103

SoDIS questions for principle:Prevent project & requirements/tasks risk Task REQUIRE approval of software that may notfulfill the requirements of the contract? Task CAUSE harm to the user, the public, or theenvironment? 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 - 9


78/103

SoDIS questions for principle:Prevent project & requirements/tasks risk Task REQUIRE misrepresentation of the productscapabilities or reliability? Task REQUIRE the developer to work beyond theirability? Task CAUSE loss of information, loss of property,property damage, or environmental impacts?


SoDIS - 10


79/103

SoDIS principle:Preventrisks 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 technologyin ways that result in harm to:

Users, the general public, employees or employers.


SoDIS - 11


80/103

SoDIS principle:Preventrisks that may cause harm to Harmful actions include:

Intentional destruction or modification of software artefactsleading to serious loss of resources

Unnecessary expenditure of human resources (e.g., purgingcomputer 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 duringproposal, design and Implementation.


SoDIS - 12


81/103

SoDIS questions for principle:Prevent risks that may cause harm to Task CAUSE the unwanted modification ordestruction of files and programs owned or in use by

Stakeholder? Task CAUSE the unnecessary expenditure of theresources of Stakeholder? Task INVOLVE the design or approval of softwarewhich may lower the quality of life of Stakeholder?


SoDIS - 13


82/103

SoDIS questions for principle:Prevent risks that may cause harm to

Task FAIL to take into consideration the needs and/orinterests of Stakeholder? Task DISCRIMINATE against Stakeholder? Task VIOLATE the privacy and confidentiality of

Stakeholder? Task ALLOW unauthorized access or alteration to thedata of Stakeholder?



83/103

SoDIS - 15


84/103

SoDIS principle:Preventrisks that unreasonably restrict Computer software can restrict the activities oroptions of users.

As a practical example, it is very important to vision-impaired voters to have the same privacy as all othervoters. If this aspect of voting had not beenaddressed in eVACS then it would have unreasonablyrestricted vision-impaired voters.


SoDIS - 16


85/103

SoDIS questions for principle:Prevent risks that unreasonably restrict

Task FAIL to offer provision for any disability toStakeholder?

Task FAVOUR ease of development at the expense ofStakeholder?


SoDIS - 17


86/103

SoDIS principle:Preventrisks that involve deception of The computer professional must strive to be honest.

Honesty is essential to obtaining trustWithout 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 systemlimitations and problems


SoDIS - 18


87/103

SoDIS questions for principle:Prevent risks that involve deception of

Task KEEP hidden any possible dangers toStakeholder?

Task REQUIRE dishonesty or untrustworthiness onthe 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 Clive & Carol Boughton 87

SoDIS - 19


88/103

SoDIS principle:Preventrisks of conflict with responsibilitytowards Responsible excellence toward stakeholders

Perhaps the most important obligation of a professional. Strive to achieve quality

Be cognizant of the serious negative consequences that mayresult from poor quality in a system.


SoDIS - 20


89/103

SoDIS questions for principle:Prevent risks of conflict with responsibilitytowards

Task NEGLECT quality assurance processes andreview by Stakeholder?

Task PREVENT acceptance of responsibility toStakeholder?

Task MISUSE the computer resources ofStakeholder?

Task INVOLVE conflict of interest with Stakeholder?


SoDIS - 21


90/103

SoDIS questions for principle:Prevent risks of conflict with responsibilitytowards

Task CAUSE ineffectiveness or inefficiency asperceived by Stakeholder? Task BREAK contracts or agreements with

Stakeholder? Task INVOLVE unauthorized use of the facilities of

Stakeholder? Task IMPEDE compliance with applicable laws byStakeholder?


SoDIS - 22


91/103


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 - 23


92/103

Applying the SoDIS questionsMightproject task issue stakeholder?

By itself a question identifies a potential risk No as an answer suggests extremely lowprobability of occurring

Yes as an answer actualises the risk - suggestingthat there is some probability of it occurring Yes as an answer also means treat/mitigate the risk An actualised risk requires further elaboration byone or statements of concern Concerns are treated by describing viable solutions



93/103

SoDIS - 25


94/103


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 and31 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 - Why bother?


95/103

SoDIS provides a range of benefits: Significantly improves identification of stakeholder-related risks and the early treatmengt of those risks Earlier determination of a broad range ofstakeholders and potential impacts

they have on the project, andthe project on them

Various stakeholder groups in their project rolesPerforming organisationProject sponsorProject managerProject team membersExternal stakeholders (users, procurers, non-humans)

Complements best practices in PM and RMSoDIS Clive & Carol Boughton 95

Estimating program value - 1


96/103

Software engineering professionals know that: Early and proper application of IV&V practices

Significantly reduces rework saving on effort and budgetIncreases quality through end-to-end requirements tracingProvides high Return-on-investment (RoI)

Catching problems late in a project is very costly andcan lead to project cancellation Competency is important but not sure of degree Good intra-team and customer collaboration affectssuccessful outcomes but not sure of degree




97/103

Some supporting evidence of SoDIS value: A business case - McHaney (2004)

Details a business case for adoption of SoDIS in terms of afinancially-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 orinsurance policy.

A relatively small investment upfront can protect anorganisation from potentially devastating economic

consequences downstream.




98/103

Some supporting evidence of SoDIS value: Keane Inc. - Boston

As a case study for SoDIS - undertook a blind parallel testwith a running project

Project had passed normal risk assessmentSoDIS analysis revealed substantial risks which had not been

anticipated

Cost to mitigate new found risks was more than executivedirectors were prepared to pay project was cancelledsaving potentially $millions




99/103

Some supporting evidence of SoDIS value: Kwan, Hitchcock, Clear, Gotterbarn & Simpson

SoDIS analysis on a health project with a $NZ 160K budgetSoDIS effort constituted 3.8% of overall costExposed 16 critical concerns, 106 significant concernsThe customer (Eagle Technology) found the exposure of

identified risks very surprising and also realised the actualbenefit to the success of the project.

Support for SoDIS is growing only slowlySome users are concerned about the risks that a SoDIS

analysis exposes they are inclined to keep such informationfrom other parties for fear of being labeled incompetent!


Defining a project


100/103

Essential steps for defining a project:1. Identify the type of project2. Identify the typical stakeholder roles (types) for thetype of project3. 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 stakeholders5. Describe project tasks


SoDIS Project Auditor - 1


101/103

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 aSoDIS Analysis and vice versa for the same project

Provides five (5) reports for a Preliminary Analysis Provides ten (10) reports for a SoDIS Analysis




102/103

Key reasons for development of SPA: Provide a preliminary analysis using a predefined setof 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 cover1. Project context and plan to ensure basic project

requirements are in place

2. Project tasks documented, test requirements, areparticipants known

3. Project stakeholders are they identified, do they havenecessary knowledge, do they need training4. Project task & Stakeholder relationships




103/103

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 (1)

Documents

Transcript of SoDIS-By Clive and Carol Boughton Sept 2011 (1)