SE362 SoftwareProjectManagement

SE362 Software Project Management
Todd L. Veldhuizen Dept. of Electrical & Computer Engineering University of Waterloo Canada Summer 2008
Contents
1 IntroductionWhat knowledge is important to a software professionalWhat is a projectVaguenessProject
ManagementProcrustean methodsIEEE 1058
2 Software Process modelsWaterfallUncertain and volatile requirementsEvolutionary DevelopmentSpiral V-modelVariationsCustomizationScrum 57 3 Process designDo orchestras need conductors?Lightweight vs Heavyweight processesAgile methodsScrum Extreme programming 126 4 PlanningNormal vs Radical DesignSoftware Project Management PlansNominal vs Secondary effects of
planningGoal and ObjectivesScopePlanning fallacyPacked vs unpacked estimationWork Breakdown StructuresEstimationAnchoring 168
5 EstimationPsychology of estimationCommon knowledge effectIllusion of explanatory depthParkinsons

LawStudent syndromeUnder vs OverestimationCone of uncertaintyAccuracy vs PrecisionEffect of project size and typeEstimation techniquesWideband DelphiBiddingCountingPlanning PokerEstimation by analogyCalibrated modelsSchedule estimation 233
6 EstimationCOCOMOSelf-assessment hazardsSchedulingRolling Wave PlanningScheduling tools
324
7 SchedulingTask dependenciesCritical pathsResource levelingPERTProject controlScope controlChange 1
Control BoardsSoftware Conguration ManagementVersion and Revision ControlRelease Management Earned Value Management 368
8 Risk ManagementCommon risksRisk analysisPsychology of RiskRisk denialSoftware Risk Management435 9 MetricsMetrics fallaciesGoal-Question-Metric paradigmGamingPrivacyAutomationModel tting Pareto principlesRoyces Seven 481 10 PersonalityBig Five TraitsPersonality and Job PerformancePersonality and TeamworkGMAExceptional Programmers 527 11 Hiring aka Personnel SelectionInterview designImpression ManagementStructured interviewsRetention
and TurnoverMotivation and well-being at workHappinessDiurnal mood cycleAffect at workMotivation and Goal SettingSelf-efcacy 577
12 Individuals and Small GroupsMotivation and Goal-SettingSelf-efcacyWork groups vs TeamsTrust, Potency, and SafetyTeam DesignBoundary ActivitiesCohesion and BondingGroup DynamicsTransactive MemorySocial LoangIntragroup Conict 634
13 Group Judgement and Sunk CostsGroup Decision MakingCommon Knowledge EffectStructured Decision ProcessesAvoiding Premature ClosureGroupthinkSunk CostsIT Governance Abroad 679 14 LeadershipLegitimacy and LegitimationFull-Range Leadership TheoryTransactional LeadershipTransformational LeadershipShared LeadershipApacheOpen Source LeadershipEmergent LeadershipChemers Recipe 730 15 NegotiationSoft vs Hard StylesWin-winFacilitatedCase StudyNegotiating PrinciplesPsychology of Negotiation 769 Inuence TacticsThats Not All TechniqueLikingDoor-in-the-FaceFoot-in-the-doorTheory W 16 Systems ThinkingHard vs Soft SystemsWicked ProblemsEmergent PropertiesDesign in a Systems Context
Ironies of AutomationSocial costs of ComputerizationExplicit vs Tacit Views of WorkSystems Thinking in Software DesignProblem FramingSoft System MethodsEthnographySoft Systems Methodlogy (SSM) CATWOESystem Diagrams and Rich Pictures 807
17 Intellectual Property ManagementPatentsSubmarinesMonetizationAbuses and TrollsPrior ArtDefensive PublishingInfringementTrade SecretsCopyright 862 18 Software LicensingTransferring Intellectual Property RightsPerpetual vs Fixed-TermPermitted UseExclusivity Derivative WorksReverse EngineeringRerpesentations and Tort LawWarrantiesDisclaimersIndemnities 884 19 Project RetrospectivesPricing of Software LicensesDevelopment ContractsTermination and Breaches 908
20 Open SourceFree Beer LicensesGNU Public LicenseLGPLOther OSS LicensesDual LicensingSoftware Process AssessmentCapability Maturity ModelCMMICMMI vs AgileSPICE 931
Chapter 1
IntroductionWhat knowledge is important to a software professionalWhat is a projectVaguenessProject ManagementProcrustean methodsIEEE 1058
SE362 Lecture 1: Introduction Todd Veldhuizen tveldhui@acm.org
SE362 Lecture 1: Introduction

Todd Veldhuizen tveldhui@acm.org
Electrical & Computer Engineering University of Waterloo Canada
May 6, 2008
1 / 54
Part I Administrative Stu
2 / 54
Objectives
Learn essentials:
Software: deciding what to build, how to build it Project: planning, estimating, scheduling, tracking Management: leadership, recruiting, teambuilding
Get some basic experience with project management tools Improve critical thinking + writing skills
3 / 54
Workload and Evaluation
20%: assignments (3) 30%: midterm (..) 50%: nal (TBA)
4 / 54
Textbook I
Rapid Development, Steve McConnell (1996)

Modest: 650 pages, $47 A book you can read, enjoy, and learn a lot from. Well-regarded in industry, lots of common sense and relies more on evidence (i.e. studies) than most PM textbooks Suitable for small to medium sized projects Optional; I will point out chapters that would be useful supplements to the lecture.
5 / 54
Textbook II
Quality Software Project Management, Robert T. Futrell, Donald F. Shafer and Linda I. Shafer (2002)
Huge: 1700 pages, $80 Based on the Software Project Management (SWPM) certication program at UT Austin Rather encyclopedic; exhaustive to a fault. Not required.
6 / 54
Textbook III
A guide to the Project Management Body of Knowledge: PMBOK Guide, 3rd edition (2004)
From the Project Management Institute, which oers Project Management Professional (PMP) certication Refreshingly brief Very generic: intended for construction projects, software projects, etc.
7 / 54
Web page
http://ubiety.uwaterloo.ca/se362/ Lecture notes & assignments will be posted there. Please dont print out the lecture notes from the 2007 oering. These will be updated. There will be links in the lecture notes to research papers and supplemental materials.
Access password: se362, se362
8 / 54
Format
Lectures covering essentials Readings to supplement lectures (from trade magazine and research articles) Tutorial slots will almost never be used
9 / 54
A bit about me
10 / 54
What will you get out of this course? I
This is primarily a course about project leadership.

You can be play a leadership role in a project without being a project manager.
Learn about people: ability and motivation are the primary causes of productivity.
A successful team needs competent, motivated people How to get competent people, and how to motivate them?
Learn critical thinking skills

A lot of hearsay in SE/SPM writings cultivate a critical eye & a taste for evidence-based decisions.
11 / 54
What will you get out of this course? II
Learn technical project skills: learn how to choose processes, plan, estimate, schedule, track, etc. Learn
What makes projects fail What helps projects succeed How to tell the dierence
These skills will be useful whether you want to become an entrepreneur, a team member, or a project manager
12 / 54
Do you want to be a PMP? I
Roughly, a P.Eng.-like certication for project managers Project Management Institute (PMI)
http://www.pmi.org/ 200, 000 members, 150 countries Project Management Professional (PMP) certication
4500 hours/36 months/3 years experience in leadership-type positions Examination 35 hours of project management education (SE362 counts.) Code of ethics and professional conduct
13 / 54
Part II How does SE362 t in the SE curriculum?
14 / 54
What knowledge is important to a software professional? [1, 2] I
Survey by Timothy Lethbridge, U. of Ottawa 200 software developers & managers surveyed (23% Canadian; 53% USA; 24% non-north-america) Respondents were asked about 75 educational topics.
15 / 54
What knowledge is important to a software professional? [1, 2] II
16 / 54
What knowledge is important to a software professional? [1, 2] III
17 / 54
What knowledge is important to a software professional? [1, 2] IV

Topics that managers know better than the participants at large. 1 Negotiation 50% 2 Management 48% 3 Process standards CMM/ISO 9000 40% 4 Psychology 38% 5 Software metrics 37% 6 Leadership 35% 7 Project management 32% 8 Software cost estimation 31 % (We will cover all of these in SE362).
18 / 54
What knowledge is important to a software professional? [1, 2] V

Topics whose details are perceived to be most important. 1 Specic programming languages 2 Data structures 3 Software design and patterns 4 Software architecture 5 Requirements gathering and analysis 6 Giving presentations to an audience 7 Technical writing 8 Project management . . . 18 20 Ethics and professionalism Leadership
19 / 54
What knowledge is important to a software professional? [1, 2] VI

Topics whose details are perceived to be least important. 1 Chemistry 2 Dierential equations 3 VLSI 4 Robotics 5 Laplace and Fourier transforms 6 Articial intelligence 7 Dierential and integral calculus 8 Analog electronics 9 Philosophy 10 Combinatorics
20 / 54
What knowledge is important to a software professional? [1, 2] VII

Topics for which on-the-job learning was greatest 1 Conguration and release management 2 Project management 3 Testing, verication and quality assurance 4 Maintenance, re-engineering and rev. eng. 5 Object-oriented concepts and technology 6 Requirements gathering and analysis 7 Ethics and professionalism 8 Leadership 9 HCI 10 Giving presentations 11 Process standards CMM/ISO 9000 12 Software cost estimation
21 / 54
What knowledge is important to a software professional? [1, 2] VIII
SE362 is designed to ll in gaps in your education, to teach you things practitioners agree are of daily importance The things we will learn are important for any software engineer to know, not just project managers.
22 / 54
Part III Overview of SE362
23 / 54
What is a Project?
Joseph Juran: a project is a problem scheduled for solution. An objective: clearly dened goal(s) Start and end points. Uniqueness (a one-time thing, not repeated the same way.) Constraints (cost, schedule, quality). Of course the concept project is vague, and we should regard the above as typical attributes of a project, rather than as a demarcation criteria we can use to separate projects from not-projects.
24 / 54
A theme: vagueness I
Where is the boundary between the South Atlantic Ocean and the Indian Ocean?
25 / 54
A theme: vagueness II
(1) A man with no hair is bald. (2) If a man is bald, adding one hair to his head does not make him not bald. Therefore, all men are bald. (Sorites paradox)
26 / 54
A theme: vagueness III

Vagueness: a frequent source of confusion for engineers when encountering material like that of this course In engineering, we are used to concepts that have well-dened edges: true or false, controlled ight or uncontrolled ight, parallel or serial, distributed or localized, etc. Humans deal largely with vague concepts that have fuzzy boundaries In philosophy, a concept is vague to the extent that it admits marginal cases Historically, philosophers fretted about how categories and concepts should be dened so as to exclude marginal cases
Science or pseudoscience? Science or engineering? Art or craft?
27 / 54
A theme: vagueness IV
Much time can be wasted on demarcation problems that seek a criteria that strictly separates e.g. science from pseudoscience It can be argued that many demarcation problems are really pseudoproblems: problems that arise from the use of language and articially constructed concepts, problems that have no basis in physical reality, and cannot hope to have an ultimate answer.1 Nowadays, vagueness is largely regarded as the norm in philosophy: concepts and categories with sharp boundaries are viewed as rare. Most of the concepts we will deal with in this course will be vague: project or not-project? extrovert or introvert? success or failure? design or implementation? manager or developer?
28 / 54
A theme: vagueness V
It is not useful to argue about marginal cases, strict boundaries, etc. Concepts are best regarded as clusters of attributes, and things satisfy a concept to the extent that they have those attributes. As a shorthand, we will often refer to vague concepts as if they exist and have well-dened boundaries.
If you have a small team, its not necessary to have a manager. However, managers are usually necessary for big teams. And huge teams usually use a hierarchical management structure. What about medium-sized teams?
Of course, the problem of distinguishing problems from pseudoproblems is itself a pseudoproblem.

29 / 54
What is project management?
Typical activities: Conceiving Planning Estimating Scheduling Monitoring, tracking progress Managing people, subcontractors Leading
30 / 54
Project Management Skills
Leadership Communications (verbal, written) Problem Solving Negotiating Inuencing the organization Mentoring Process and technical expertise
Need to be an expert in software engineering and project management
31 / 54
Some basic PM concepts

Program: a broad endeavour, encompassing many projects (e.g. the Apollo Program) Project: a unique undertaking to achieve some goal(s), must usually with schedule and constraints. Part of a program. Phase: subdivision of a project, a group of activities and tasks that produces some deliverable Activity: performed during some subinterval of the project duration. Task: low level chunk of the project. Short duration. A fundamental activity in PM is decomposing a project into phases, activities, and tasks: a work breakdown structure (WBS).
32 / 54
Structure of a phase
Source: PMBOK Guide
33 / 54
Work Breakdown Structure
Decomposes the project into a hierarchy of smaller, simpler activities that combine to produce the deliverable Provides an overview of what has to happen, as input to planning, estimating, and scheduling A tree that divides the project into major activities, the major activities into minor activities, ..., and bottoms out into bite-sized work packages Widely regarded by last years class as the most useful planning activity they undertook for their project
34 / 54
Procrustean methods I
35 / 54
Procrustean methods II
Procrustean: enforcing uniformity or conformity without regard to natural variation or individuality. Procrustean solutions in SE: universal methods, best practices, etc. that are adhered to blindly, without taking into account the enormous variation in software projects. The processes & methods we adopt must be chosen and tailored specically for the project. Failing to do this can do more harm than good:
Time wasted on useless, paper-generating activities (process tax) Developers resent process for process sake Iatrogenic eects: harm caused by a purported solution
36 / 54
Procrustean methods III

A smart project manager will view processes as a toolbox of solutions that can be tailored to solve problems that arise in projects.
Not as standards to be adhered to in all cases! Avoid reication fallacy, where a solution is reied as a problem:
Good: We keep missing deadlines because were having trouble prioritizing. (problem) We should plan our releases and schedule our work. Bad: We dont have a schedule. We should make a schedule.
If it aint broke, dont x it.
37 / 54
Procrustean methods IV
38 / 54
Procrustean methods V
39 / 54
Procrustean methods VI
40 / 54
Procrustean methods VII
41 / 54
Procrustean methods VIII

Dierent projects need dierent processes To choose a project management strategy, need to consider
scale (shed or highrise?) level of innovation (highrise or starchitect-phantasm?) endpoint (well-dened or vague?) team (experienced or inexperienced? existing team or new team? xed membership or rotating?) time pressures quality requirements (web site vs. medical device) problem domain (embedded systems vs. user interaction)
The challenge to the PM is to gure out what is the best set of process tools to use, and how much to use them.
42 / 54
Part IV IEEE 1058
43 / 54
IEEE 1058: Software Project Management Plans I
A standard that lays out a generic template for a project management plan. Species what needs to be planned ll in the blanks. Does not specify lifecycles, QA strategies, etc.
44 / 54
IEEE 1058: Software Project Management Plans II
Suitable for large projects that have clear objectives and denable endpoints (e.g., not new product development), undertaken in large organizations, and with long schedules Would be completely unsuitable for short projects done in small groups
One of your assignments will be to ll in an IEEE 1058 template for your SE-1,2,3 project. It will be overkill, but a good learning experience.
45 / 54
IEEE 1058: Project Summary
Purpose, scope, and objectives Assumptions and constraints Project deliverables Schedule and budget summary
46 / 54
IEEE 1058: Project start-up plan
Estimation plan Stang plan Resource acquisition plan (equipment, training, services) Project sta training plan
47 / 54
IEEE 1058: Work plan
Work activities (Work Breakdown Structure) Schedule allocation Resource allocation (who does what) Budget allocation
48 / 54
IEEE 1058: Control plan
Requirements control plan. (Controlling changes to requirements.) Schedule control plan. (How to measure progress and correct slippages.) Budget control plan. Quality control plan Reporting plan (how will project status be communicated?) Metrics collection plan
49 / 54
IEEE 1058: Risk management plan
What are the risks How will risks be monitored Contingency plans
50 / 54
IEEE 1058: Technical process plans
Process model Methods, tools, and techniques (e.g. programming languages, development tools, etc.) Infrastructure plan (establishing and maintaining the development environment.) Product acceptance plan. (Criteria for acceptance.)
51 / 54
IEEE 1058: Supporting process plans
Conguration management Verication and validation Documentation plan Quality assurance plan Reviews and audits plan Problem resolution plan Subcontractor management plans Process improvement plan
52 / 54
Part V Bibliography
53 / 54
Bibliography I
[1] Timothy Lethbridge. What knowledge is important to a software professional? IEEE Computer, 33(5):4450, 2000. bib [2] Timothy C. Lethbridge. Priorities for the education and training of software engineers. Journal of Systems and Software, 53(1):5371, 2000.
bib pdf
54 / 54
Chapter 2
Software Process modelsWaterfallUncertain and volatile requirementsEvolutionary DevelopmentSpiralV-modelVariationsCustomizationScrum
59
SE362 Lecture 2: Process models Todd Veldhuizen tveldhui@acm.org
SE362 Lecture 2: Process models

May 8, 2008
1 / 68
Part I Software process models
2 / 68
Assigned readings
Yes, these will be on the midterm: William Royce. Managing the development of large software projects. In Proc. IEEE Wescon, pages 19, August 1970 [9]. Hirotaka Takeuchi and Ikujiro Nonaka. The New New Product Development Game. Harvard Business Review, JanFeb 1986 [10].
3 / 68
4 / 68
A Waterfall-like process
5 / 68
What purpose do documents serve?

A way for stakeholders to come to agreement about what is to be built, and to agree that they have agreed. Relationship-building: e.g. drafting a requirements document with the client builds a collaborative relationship that sets the tone for future interactions Signing-o, for contract situations; obtaining early and ongoing commitment from stakeholders. Serve as a reference (memory aid) As knowledge codicationmitigate problems caused by turnover The act of writing forces one to do a disciplined, systematic analysis. Documents can be delivered to stakeholders as reports: signs of progress, etc. For archival purposes, e.g., to support future maintenance work.
6 / 68
Competitive negotiations I
If the customer is unsure of their needs, they might start by distributing a Request For Information (RFI) to interested vendors. This document describes the company, its current infrastructures, and what it hopes the project might achieve. Vendors respond with a Statement of Interest (SOI) suggesting what kind of structure they envision for a solution / future relationship / etc. Once the customer has a fairly clear idea of what they want, they issue a Request For Proposals (RFP) that gives detailed information about the project. Vendors respond with proposals (bids, tenders) that detail their proposed approach, team, relevant experience, cost, methods, references from previous customers, etc. The customer evaluates the proposals and awards the contract to one of the vendors.
7 / 68
Competitive negotiations II
In such situations, documents play an important role in avoiding liability. Customers and vendors sign o on documents to establish a legal agreement as to what work is to be done (and how).
8 / 68
Naive Waterfall I
From [9].
9 / 68
Perceived problems with Naive Waterfall I

Big-Bang Integration: integration is slow, major problems discovered late in the process, risks are uncovered late. Requirements up-front
Assumes customer knows what they want. Assumes customer can tell you what they want. Assumes you can understand what theyre telling you.
Can lead to adversarial stakeholder relationships [8].

1. Contractor prepares draft of document describing a deliverable, sends it to customer. 2. Customer has 15-30 days to comment. 3. Contractor incorporates comments and submits nal version for approval.
Consequence: might become a high-stakes game, devolving into mistrust.

10 / 68
Perceived problems with Naive Waterfall II
Too much eort put into documents, which are hard to maintain, and have little lasting value once the project is completed. Barrier synchronization can make it hard to keep everyone busy
11 / 68
Part III The role of uncertainty
12 / 68
Why are requirements volatile? I

Brooks, No Silver Bullet [2]:
The hardest single part of building a software system is deciding precisely what to build. No other part of the conceptual work is as dicult as establishing the detailed technical requirements, including all the interfaces to people, to machines, and to other software systems. No other part of the work so cripples the resulting system if done wrong. No other part is more dicult to rectify later. Therefore, the most important function that the software builder performs for the client is the iterative extraction and renement of the product requirements. For the truth is, the client does not know what he wants. The client usually does not know what questions must be answered, and he has almost never thought of the problem in the detail necessary for specication.
13 / 68
Why are requirements volatile? II

Watts Humphrey [5]: The system will change the operational environment. Since the users can only think in terms of the environment they know, the requirements for such systems are always stated in the current environments terms. These requirements are thus necessarily incomplete, inaccurate, and misleading. The challenge for the system developer is to devise a development process that will discover, dene, and develop to real requirements. This can only be done with intimate user involvement, and often with periodic prototype or early version eld tests.
14 / 68
Why are requirements volatile? III
Malcolm Gladwell:
1. Excerpt from TED talk: 9:5311:35 (Spaghetti sauce, Coee) 2. Excerpt from Blink p. 155 (Coke) 3. Excerpt from Blink p. 174 (Sitcoms)
15 / 68
Why are requirements volatile? IV
Dan Gilbert: Excerpt from TED talk: at 9m47s (Monet prints)
16 / 68
Why are requirements volatile? V
From The construction of preference [6]: The variability in the ways we construct and reconstruct our preferences yields preferences that are labile, inconsistent, subject to factors we are unaware of, and not always in our own best interests. Indeed, so pervasive is this lability that the very notion of a true preference must, in many situations, be rejected.
17 / 68
Why are requirements volatile? VI

Lessons:
Clients lack the technical expertise to communicate what they want (Brooks). Requirements depend on the future state with the operating system, which is dicult to envision (Humphrey). Humans have diculty predicting what will make them happy (miswanting). Peoples preferences are unstable (labile). What people say they want may be very dierent from
What they really want; What they will be content with (synthesized happiness) What will satisfy the operational need (i.e., what will make them more productive etc.)
18 / 68
Why are requirements volatile? VII
People are highly unreliable when it comes to explaining why they prefer one thing to another. People can react negatively to new things, even though they will eventually embrace them enthusiastically. Experts interviewed as surrogate clients can be unreliable when asked to predict what people want or need.
19 / 68
Why are requirements volatile? VIII
If the requirements depend on preferences of some client, a software process must provide a framework for the convergence of:
1. 2. 3. 4. The software design; The clients perception of their preferences; The clients actual preferences, insofar as these exist; What will best fulll the clients needs.
Iteration is the most commonly recommended strategy.
20 / 68
Iteration and prototyping

Iterative approaches are recommended when: When design is driven by client preferences. When there are risks and uncertainties associated with the technology, architecture, etc. that need to be resolved before attempting a full-scale implementation. When the developers are inexperienced in the problem domain or the technologies. When the solution will disrupt the system, changing the requirements. When it is necessary to deliver working prototypes at regular intervals to build stakeholder condence, etc. But not when the requirements are immutable & the developers are experienced.
21 / 68
Part IV Evolutionary
22 / 68
Evolutionary Development I
Aimed at projects where there is a high risk of getting the requirements or user interface wrong Response to these risks: frequent delivery to users, with feedback driving the next phase; small, incremental releases Aim to reduce the number of late changes to the user interface and reduce defects found late Similar to a series of smaller waterfall processes in sequence. Aims to have an almost continuous stream of user input into the process. Tom Gilb [4] was an inuential advocate of this process.
23 / 68
Evolutionary Development II
From [7]
24 / 68
Evolutionary Development III
From [7]
25 / 68
Evolutionary Development IV
Case study from HP [7]:

About two thirds of the way through the project, the rigorous testing and defect xing that had been done during the EVO cycles was discontinued because of schedule pressures. The cost of this decision was quality. With all eorts focused on nishing, developers began adding code at a rate double that of previous months, and over half of the critical and serious defects were introduced into the code in the last third of the project schedule.
Advantages cited of using Evo method:
26 / 68
Evolutionary Development V
Better teamwork with users, more time to think of alternative solutions. (Anecdotal evidence). Despite abandoning rigorous testing, the project still had signicantly fewer critical and serious defects during system testing. (No hard gures given; unclear if this was just a subjective impression.) Increased productivity claimed (but no evidence presented).
27 / 68
Evolutionary Development VI
From [7]
28 / 68
Evolutionary Development VII
Some resulting benets claimed from project postmortem [7]:

Team liked seeing the results of their work often. (morale) Long-term vision broken into short-term steps Early results are a good communication tool both inside and outside the division Early realism about how much can be done
29 / 68
Evolutionary Development VIII
Critical success factors (claimed)

Clear and compelling vision of what the product will be Evo requires more PM eort than traditional waterfall.
E.g., need to arrange so that no developer goes more than two releases without input to a release Work Breakdown Structure (WBS) + dependencies need to be done correctly. Need a technical manager (e.g. lead developer who liases with the project manager, responsible for keeping the project on track) Need a user liason to coordinate user involvement.
30 / 68
Part V Spiral
31 / 68
Spiral model I
Spiral model for software was introduced by Boehm [1]. (Some antecedents in general design community, e.g. [?].) Spiral software process is organized as a number of cycles through the same basic steps; in each cycle the software is elaborated (i.e., understood or implemented in greater detail.) Early cycles aim to resolve uncertainties that are sources of risk by prototyping, rening requirements, simulation, modelling, etc. Entire process is risk-driven. Last cycle ends in detailed design, coding, testing, etc. Each cycle passes through four stages:
1. Determine the objectives for the current cycle: what is to be produced. Identify constraints and design alternatives.
32 / 68
Spiral model II
2. Evaluate the design alternatives, identify and resolve risks. 3. Develop and verify the next-level product. 4. Plan the next phases.
33 / 68
Spiral model III
34 / 68
Spiral model IV
From [1]. RQTS=requirements, RA=requirements analysis
35 / 68
Spiral model I
Each cycle ends in a review (the commitment barrier of the gure.)
All stakeholders participate in reviewing the artefacts developed during the cycle and the plans for the next cycle. Purpose is to ensure that all the stakeholders are content with the artefacts, and approve of the planned for the next phase.
Boehm intended that the Spiral model be general enough to encompass other process models
E.g., if the project is low-risk in terms of technical and user requirements, but high risk if it loses control of schedule/budget, then these considerations drive spiral model toward a waterfall-type model If getting the user interface wrong is the dominant risk, then spiral model morphs into an evolutionary process model
36 / 68
Spiral Model: Example I

Example application of Spiral: TRW Software Productivity System (SPS) [1]. Aim of project: increase software productivity. Round 0: Feasibility Study
Five part-time sta, 2-3 months (total 2 person-months) Objectives: Signicantly increase software productivity. Constraints: reasonable cost; by means appropriate to the corporate culture Alternatives: Management improvements; Personnel improvements; Technology improvements; Facility improvements (oces, communications) Risks: invest a lot of money and then discover the productivity gains are insignicant, or incompatible with corporate culture
37 / 68
Spiral Model: Example II
Risk resolution: internal surveys, interviews of developers and managers; analyze cost models; literature search; analyzing previous projects at the company considered highly productivity Risk resolution results: found it highly likely that signicant productivity gains could be achieved by pursuing an integrated set of initiatives in all four areas (management, personnel, tech, facility). Some candidate solutions were ruled out. Plan for next phase: 12 person-months, produce concept of operation and PM plan for implementing whatever solution was chosen
38 / 68
Spiral Model: Example III

Round 1: Concept of operations
Objective: double software productivity in 5 years Constraints: $10k/person investment; corporate culture; prefer TRW products After analyzing alternatives & risks, arrived at concept of providing private oces, a local-area network, personal terminals Plan for next phase: separate activities to address management improvements, facilities development, and a Software Development Environment
Round 2: Top-level Requirements Specication etc.
39 / 68
Part VI V-Model
40 / 68
V-Model I
Standard for German government/military software development Emphasizes verication and validation
verication: did we implement it right? validation: did we implement the right thing?
Follows a Waterfall-like ow, but diagram is bent in the middle into a V shape, with a pairing between specifying and testing activities Tests are derived directly from their counterparts on the left of the V Emphasizes traceability: can trace a user requirement from its initial specication to whether it was implemented, what tests were performed to verify it, etc. More than a life cycle, species a project management process also.
41 / 68
V-Model II
Source: glemser.com
42 / 68
Part VII Variations on a process model
43 / 68
Domain-specic SLC modications I

Depending on the specic problem domain in which the project is situated, there may be special requirements that inuence the life cycle design:
User interface prototyping, usability studies Safety-critical systems (safety life cycle, formal verication) Real-time systems High-performance systems
Frequently-expressed opinion that performance optimization should be deferred to late in the process is misguided; if performance is paramount, then performance concerns need to be addressed up front, e.g. choosing technologies and architectures that can deliver. The performance ceiling of a system is xed by its language, architecture, hardware, etc.
44 / 68
Subprojects I
Instead of a monolithic project, decompose into smaller projects that can be tackled (and possibly delivered) separately Ideally, subprojects have separate value to the organization, e.g., SOA
45 / 68
Overlapping phases (sashimi) I
[10]
46 / 68
Incremental Model I
Aim to release the software in several stages, with stage 1 having the most critical features, stage 2 having the next-most critical, etc. Delivery of stage 1 gives an reality check: is the system going to deliver what it promises? Can reassess plans for stages n + 1, . . . once stage n has been delivered and is in use. Assumes that delivering a partly-working system is feasible (e.g., word-processor vs. satellite control system) Can be hard to retract design decisions reected in already-delivered stages.
47 / 68
Design-to-schedule I
If hard deadlines are involved, design the development schedule so that features are implemented in decreasing order of importance As the deadline nears, triage: gure out what can and cannot be implemented in the time remaining. Advantage: have a high probability of delivering something.
48 / 68
Fast Tracking I
Many formal life cycles involve review and/or consolidation milestones where (ocially) development work ceases To avoid wasted time, have developers who are idle work ahead on future deliverables.
49 / 68
Issues that drive design of a life cycle I

What characteristics does the project have? Big or small? Routine or innovative? How costly will defects found after delivery be? Schedule pressure? (Is it most important to deliver on time, to deliver the right functionality, or to delivery low defect code?) Need to show steady progress to stakeholders? Is there a user interaction component? Are the requirements easily dened/well known? Can they be dened early in the cycle? How much are the requirements expected to change over the course of the project? How do the qualications of the team match the needs of the project?
50 / 68
Issues that drive design of a life cycle II
Is formal verication needed? Is there an existing user community that can be used for beta testing, feedback-gathering? Or is this a brand new product that will create its own market?
51 / 68
Customizing a Life Cycle model I
There are many life cycle models to choose from. Generic models such as Waterfall, V, Spiral, Evo, etc. oer a starting point: a rough t based on coarse characteristics of the project. You should tailor the life cycle to t the particular needs of the project. You can pick and choose the best aspects of the generic models; you can omit or add activities, etc.
52 / 68
Customizing a Life Cycle model II

Steps in selecting and customizing a life cycle [3]:
1. Familiarize yourself with the various life cycle models; 2. Analyze the style of project: is it new development work? enhancement of an existing system? 3. Use the characteristics of the project to guide selection of the life cycle model: what are the major risks? Is there a user interface component? Are requirements volatile? Is there schedule pressure? 4. Identify phases (e.g. requirements analysis) and activities that are to take place in each phase (stakeholder interviews, analyzing requirements, developing use cases, etc.) 5. Establish deliverables (internal and external). 6. Determine the QA strategy and how it maps onto the life cycle model (reviews, inspections, verication, validation, etc.)
53 / 68
Part VIII Agile methods
54 / 68
Scrum
Scrum is not an acronym. Its an event in the game of rugby where like-minded people get together and politely discuss ownership of a ball. Video: Ken Schwaber, Google Tech Talks http://video.google.ca/videoplay?docid= -7230144396191025011&q=agile+development
Intro (2m00s to 9m27s). Scrum works for any team (14m20s to 15m54s). Game companies (33m00s to 35m13s)
55 / 68
Origins of Scrum I
Rugby metaphor introduced by Takeuchi and Nonaka in their 1986 paper The New New Product Development Game [10] that reported on innovative processes being used by big companies for new product development (e.g., cars, cameras, copiers.) Under the rugby approach, the product development process emerges from the constant interaction of a hand-picked, multidisciplinary team whose members work together from start to nish. Rather than moving in dened, highly structured stages, the process is born out of the team members interplay. [10] They referred to the process as moving the scrum downeld.
56 / 68
Origins of Scrum II
Key ideas of the Takeuchi-Nonaka model:
Built-in instability: team is given great freedom, but also very challenging goals. An executive in charge of development at Honda remarked, Its like putting the team members on the second oor, removing the ladder, and telling them to jump or else. I believe creativity is born by pushing people against the wall and pressuring them almost to the extreme. [10] Self-organizing teams A project team takes on a self-organizing character as it is driven to a state of zero informationwhere prior knowledge does not apply. Ambiguity and uctuation abound in this state. Left to stew, the process begins to create its own dynamic order. The project team begins to operate like a start-up companyit takes initiatives and risks, and develops an independent agenda. [10] Requirements for self-organizing capability:
57 / 68
Origins of Scrum III

Autonomy: team is not interfered with. Or as one executive said, We open up our purse but keep our mouth closed. Self-transcendence: The project teams appear to be absorbed in a never-ending quest for the limit. Starting with the guidelines set forth by top management, they begin to establish their own goals and keep on elevating them throughout the development process. By pursuing what appear at rst to be contradictory goals, they devise ways to override the status quo and make the big discovery. Cross-fertilization: dierent technical backgrounds, dierent personalities, etc. Such diversity fostered new ideas and concepts.
58 / 68
Origins of Scrum IV
One large room idea: When all the team members are located in one large room, someones information becomes yours, without even trying. You then start thinking of whats best or second best for the group at large and not only about where you stand... Initiatives emerge as a result. Overlapping development phases
59 / 68
Origins of Scrum V
Subtle Control
Teams are controlled very lightly. (Freedom creativity.) Choosing the team carefully: We would add an older and more conservative member to the team should the balance shift too much toward radicalism, said a Honda executive. We carefully pick the project members after long deliberation. Team is encouraged to interact with customers in the eld. Tolerating mistakes. Engineers at Honda are fond of saying that a 1% success rate is supported by mistakes made 99% of the time. Find mistakes early, and correct them immediately. short prototyping cycle.
60 / 68
Software Development Scrum I
A collection of practices, reacting against high-formality processes. Key ideas:

Timeboxes with deliverables Small, self-managed, cross-functional teams of 3-9 people Daily meetings Achieve quality through transparency and monitoring, rather than processes
61 / 68
Software Development Scrum II
Scrum meetings
Daily, less than 15 minutes Each team member asked
What have you done since last meeting? What has impeded your work? What will you do next?
Try to resolve impediments quickly, or schedule smaller meetings immediately following
62 / 68
Software Development Scrum III

Sprint
A short development interval, e.g. 3 weeks Well-dened goal: whats going to be implemented, whats going to be demoed at the end of the spring
Backlog
Prioritized list of work to be done (features, stories, requirements) Rough estimate of ideal number of days required to implement each item Before each sprint, a planning session is held to decide what items from the backlog will be addressed by the sprint
63 / 68
Software Development Scrum IV
End of sprint:
Demo Collect feedback Discuss performance, process Plan next sprint
64 / 68
Part IX Bibliography
65 / 68
Bibliography I
[1] B Boehm. A spiral model of software development and enhancement. SIGSOFT Softw. Eng. Notes, 11(4):1424, 1986. bib
pdf
[2] Frederick P. Brooks, Jr. No silver bullet: Essence and accidents of software engineering. IEEE Computer, 20(4):1019, April 1987. bib pdf [3] Robert T. Futrell, Donald F. Shafer, and Linda I. Shafer. Quality Software Project Management. Prentice-Hall, 2002. bib
66 / 68
Bibliography II
[4] Tom Gilb. Principles of software engineering management. Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA, 1988. bib [5] Watts S. Humphrey. Managing the Software Process. Addison-Wesley, Reading, Massachusetts, 1990. bib [6] Sarah Lichtenstein and Paul Slovic, editors. The Construction of Preference. Cambridge University Press, 2006. bib [7] Elaine L. May and Barbara A. Zimmer. The evolutionary development model for software. Hewlett-Packard Journal, 47(4):3945, August 1996.
bib pdf
67 / 68
Bibliography III
[8] Walker Royce. Software project management: a unied framework. Addison-Wesley, 1998. bib [9] William Royce. Managing the development of large software systems. In Proc. IEEE Wescon, pages 19, August 1970. bib
pdf
[10] Hirotaka Takeuchi and Ikujiro Nonaka. The new new product development game. Harvard Business Review, Jan-Feb 1986. bib pdf
68 / 68
Chapter 3
Process designDo orchestras need conductors?Lightweight vs Heavyweight processesAgile methodsScrumExtreme programming
128
SE362 Lecture 3: Agile methods Todd Veldhuizen tveldhui@acm.org
SE362 Lecture 3: Agile methods

May 13, 2008
1 / 41
Part I Review
2 / 41
Waterfall I
From [6].
3 / 41
Evolutionary I
From [5]
4 / 41
Spiral I
5 / 41
Spiral II
From [2].
6 / 41
Responding to the needs of the project context I
The choice of process is a design problem: how to design a process that best addresses the needs of the situation? E.g.
Requirements uncertainty prototyping Strict deadline implement critical features rst, triage as deadline nears Need to maintain stakeholders support shorter cycles with intermediate demos/releases to build condence etc.
7 / 41
Exercises I
1. A corporation is rewriting its Accounts Payable system to move it from an old batch-type mainframe to a Web-enabled system. No new functionality will be added. The statement of work calls for a conversion as is. Only the input and output subsystems will be altered for the new environment. Because it is a nancial application, testing and verication will be emphasized within the development activities. The schedule allows ve months for the project, with two people working on it. What are the crucial characteristics of this project wrt lifecycle selection? What life cycle would you recommend, and why? (Source: [3].)
8 / 41
Exercises II
2. An electronics corporation has recently decided to venture into a business area developing personal digital assistants (PDAs, like Palm Pilots). The PDA would incorporate a cellular modem. The company has considerable previous experience on product lines similar to this and believes that a cheaper price could present a value-added challenge to the PDA market. It would like to have a working model to present at a national electronics fair coming up 4 months from now. What are the crucial characteristics of this project wrt lifecycle selection? What life cycle would you recommend, and why? (Source: [3].)
9 / 41
Exercises III
3. A corporation has recently completed a three-year process to develop a web content management system. It is now ready to move into the next phase, where new releases will be issued approximately every three months. An average of 12 new features will be included in each release, with development spread across teams composed of one to three engineers, located in Toronto, St. Petersburg, and Bangalore. Development times for the new features can range from one to ve months. Some features can require multiple releases for full implementation. What are the crucial characteristics of this project wrt lifecycle selection? What life cycle would you recommend, and why? (Source: [3].)
10 / 41
Story time
Why (some) large computer projects fail, by Robert N. Britcher. In Software Runaways: Monumental Software Disasters, Robert L. Glass, 1998. [4]. pp. 6582
11 / 41
Part II Agile methods
12 / 41
From Fundamentals of Technology Project Management
13 / 41
Orpheus Chamber Orchestra
14 / 41
Orpheus: Grammy Award
15 / 41
Freiburg Baroque Orchestra
16 / 41
Nota Bene (Waterloo)
17 / 41
Agile methods on the process landscape I
Source: Krzysztof Czarnecki
18 / 41
Basic characteristics of agile methods
Incremental: frequent releases, small deltas Cooperative: close interaction between developers and customers, deemphasize hierarchy Straightforward: methods are easy to learn, low overhead Adaptive: quick reaction to change requests (After [1].)
19 / 41
Agile methods I
Agile methods inherit the benets of incremental processes:

Faster delivery of functionality to customer; More frequent user involvement in the process; Frequent builds of running systems can help detect and resolve risks earlier
Possible challenges with agile methods:

Less formalism may make agile methods hard to adapt to contract situations: often contracts link deliverables derived from the waterfall model to payments. Maybe the customer doesnt want to be continuously involved.
20 / 41
Video
From Scrum Tuning, 1:325:14.
21 / 41
History I
Development of Agile methods [1].
22 / 41
Agile Manifesto I
23 / 41
Agile Manifesto II
Source: agilemanifesto.org
24 / 41
Agile Manifesto: Principles I
1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. 2. Welcome changing requirements, even late in development. Agile processes harness change for the customers competitive advantage. 3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
25 / 41
Agile Manifesto: Principles II
4. Business people and developers must work together daily throughout the project. 5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. 6. The most ecient and eective method of conveying information to and within a development team is face-to-face conversation.
26 / 41
Agile Manifesto: Principles III
7. Working software is the primary measure of progress. 8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indenitely. 9. Continuous attention to technical excellence and good design enhances agility. 10. Simplicitythe art of maximizing the amount of work not doneis essential.
27 / 41
Agile Manifesto: Principles IV
11. The best architectures, requirements, and designs emerge from self-organizing teams. 12. At regular intervals, the team reects on how to become more eective, then tunes and adjusts its behavior accordingly.
28 / 41
Software Development Scrum I
A collection of practices, reacting against high-formality processes. Key ideas:

Timeboxes with deliverables Small, self-managed, cross-functional teams of 3-9 people Daily meetings Achieve quality through transparency and monitoring, rather than processes
29 / 41
Software Development Scrum II
Scrum meetings
Daily, less than 15 minutes Each team member asked
What have you done since last meeting? What has impeded your work? What will you do next?
Try to resolve impediments quickly, or schedule smaller meetings immediately following
30 / 41
Software Development Scrum III

Sprint
A short development interval, e.g. 3 weeks Well-dened goal: whats going to be implemented, whats going to be demoed at the end of the spring
Backlog
Prioritized list of work to be done (features, stories, requirements) Rough estimate of ideal number of days required to implement each item Before each sprint, a planning session is held to decide what items from the backlog will be addressed by the sprint
31 / 41
Software Development Scrum IV
End of sprint:
Demo Collect feedback Discuss performance, process Plan next sprint
32 / 41
Extreme Programming
Very frequent builds (e.g. several a day) Increments delivered every 2 weeks Complete run of test suite for every build.
33 / 41
Key ideas I
Source: extremeprogramming.org and [7] Daily Stand Up Meeting: every morning, everyone on the team stands in a circle and describes problems, solutions. (Standing short meeting.) Customer availability for face to face consultations, on site. Customer writes User Stories (about 3 sentences, plain english.) Developers estimate how many weeks to implement the story; if longer than 3 weeks, needs to be broken into multiple stories. Stories are focused on user needs, not implementation details. Stories are turned into implementation tasks and acceptance tests.
34 / 41
Key ideas II
No overtime: people go home after a 40 hour week. Optimize Last (!)

Todds opinion: performance is determined primarily by language, architecture, data structures + algorithms. Early design decisions eectively set a performance ceiling.
Collective code ownership: anyone can contribute to any facet of the project.
35 / 41
Key ideas III
Coding standards: everyone adheres to the same coding conventions, ideally code does not reveal (in its style) who wrote it Frequent integration: code never checked out for longer than a day Pair programming: two people, one computer. Goal: common ownership, spread knowledge, informal review
36 / 41
Key ideas IV
Unit tests written before code. Automated test suite. When a bug is found, a test is created for it. Continuous refactoring: simplifying code whenever possible Avoid design for change, gamble that it will be faster to incorporate changes as they appear rather than planning for them.
37 / 41
Part III Bibliography
38 / 41
Bibliography I
[1] Pekka Abrahamsson, Juhani Warsta, Mikko T. Siponen, and Jussi Ronkainen. New directions on agile methods: a comparative analysis. In ICSE 03: Proceedings of the 25th International Conference on Software Engineering, pages 244254, Washington, DC, USA, 2003. IEEE Computer Society.
bib pdf
[2] B Boehm. A spiral model of software development and enhancement. SIGSOFT Softw. Eng. Notes, 11(4):1424, 1986. bib
pdf
39 / 41
Bibliography II
[3] Robert T. Futrell, Donald F. Shafer, and Linda I. Shafer. Quality Software Project Management. Prentice-Hall, 2002. bib [4] Robert L. Glass. Software Runaways: Monumental Software Disasters. Prentice Hall. bib [5] Elaine L. May and Barbara A. Zimmer. The evolutionary development model for software. Hewlett-Packard Journal, 47(4):3945, August 1996.
bib pdf
[6] William Royce. Managing the development of large software systems. In Proc. IEEE Wescon, pages 19, August 1970. bib
pdf
40 / 41
Bibliography III
[7] Ian Sommerville. Software Engineering. Addison-Wesley, 8th edition, 2006. bib
41 / 41
Chapter 4
PlanningNormal vs Radical DesignSoftware Project Management PlansNominal vs Secondary effects of planningGoal and ObjectivesScopePlanning fallacyPacked vs unpacked estimationWork Breakdown StructuresEstimationAnchoring
170
SE362 Lecture 4: Planning Todd Veldhuizen tveldhui@acm.org
SE362 Lecture 4: Planning

May 15, 2008
1 / 64
Part I Planning
2 / 64
Why, What, How, Do it, Done it I
Source: [3] The broad phases of a project are sometimes summarized as Why (justication: ROI, strategic value) What (goal and scope) How (the plan) Do it Done it Today: Why, What, an intro to the How
3 / 64
The Schlieen Plan
Source: USA Military Academy/Department of History

4 / 64
Random Military Quotes About Planning I

Dwight Eisenhower on the eve of the D-Day invasion, 1944: Plans are nothing. But planning is everything. Winston Churchill: Plans are of little importance, but planning is essential. Helmuth von Moltke: No campaign plan survives rst contact with the enemy. Detailed plans are fragile and likely to be derailed But, planning leads to a better understanding of the problem space, and equips you with the knowledge you need to respond quickly to the unexpected
5 / 64
Classical AI planning I
Source: [2] e.g. STRIPS Assumptions:
The goal is a precisely specied state of the world; Actions taken by the planner are the only sources of change in the world; Each action can be applied only if its preconditions are met. Each action has a well-dened eect on the world state.
Given a feasible goal, a STRIPS-style planner can produce a very detailed, step-by-step plan that will reach that goal.
6 / 64
Planning under uncertainty I
Source: [2] Goals are fuzzy (e.g. modelled by utility functions) Actions have a probability distribution on possible outcomes Might have imperfect information about the state of the world Dont need plans per se (step-by-step sequences), but policies: If you nd yourself in state X, do Y.
7 / 64
Normal design or radical design? I

Vincenti, in What Engineers Know and How They Know It, describes the concept of normal design: the routine application of known designs and techniques, with modest, evolutionary changes. Traditional software project planning borrowed heavily from project planning in other disciplines (e.g. civil engineering, architecture). This is where Gantt and PERT charts came from. In these disciplines, normal design is the norm: the majority of projects are fairly predictable, and require only modest deviation from standard designs. In software, normal design is less the norm. There are some areas where normal design prevails, e.g., MIS. In these areas traditional software planning is thought to work well.
8 / 64
Normal design or radical design? II
9 / 64
Normal design or radical design? III
But often in software projects we are striking out into the unknown. Instead of normal design, we are undertaking radical design: we are working in an area that is new enough that there are few, if any, established designs to emulate. Traditional project planning does not work for radical design.
10 / 64
Normal design or radical design? IV
From a review by M. B. Solomon, Jr. [?] of the 1972 book Managing the EDP function1 by Ditri, Shaw, and Atkins:
11 / 64
Normal design or radical design? V
Therefore: the rst question we should ask ourselves when planning a project is: To what extent is this project normal design vs. radical design? The answer to this question indicates whether we should be thinking about traditional planning (estimates, schedules, detailed budgets) or a provisional plan that is more concerned with contingencies
12 / 64
Normal design or radical design? VI
Traditional planning:
up-front denite scope, design, etc. detailed estimates detailed schedules detailed budgets
13 / 64
Normal design or radical design? VII

Provisional2 planning:
contingencies risks initial direction tentative schedule continuous, incremental, adaptive, online (based on current thinking and observations) at an appropriate level of detail plans for keeping the project on track despite unpredictable obstacles
1 2
EDP=Enterprise Data Processing arranged or existing for the present, possibly to be changed later
14 / 64
Part II Traditional planning
15 / 64
The SPMP I
The PM is responsible for the Software Project Management Plan (SPMP) that lays out the goal and how to get there. The SPMP should aim for an appropriate level of detail: too much detail
can quickly become irrelevant if there is uncertainty can imply mistrust of developers can require a prolonged planning phase that may not be cost-eective
16 / 64
Secondary eects of planning

An open planning process, with contributions from upper management, stakeholders, and the development team, can:
help the project converge to universal buy-in: establishing a shared agreement of what is to be done and a network of commitments amongst the developers, clients, and managers establish trust, rapport with team
Involving the development team in the planning process can increase their sense of ownership The planning process deepens your (and the teams) understanding of the problem and problem domain These secondary eects may be more important than the plan itself. (This relates to an ongoing theme in this course: that the nominal purpose of some activity (e.g., writing, planning) is often less important than its real eects, which may be subtle and easily overlooked.)
17 / 64
Questions answered by planning I
1. What are we doing and why are we doing it? 2. How much will it cost? 3. How long will it take? 4. How many people will we need? 5. What could go wrong? 6. How will we monitor the project?
18 / 64
What level of formality is appropriate? I
The SPMP summarizes how the project is going to unfold. If everyone has worked together before, is comfortable in their roles, etc. then a formal plan may be unnecessary: why restate what everyone knows? If the team has never worked together, are fresh out of university, etc. then a more detailed project plan will guide them through an unfamiliar process
19 / 64
Early project activities I
Figure out what youre doing and why Summarize the project in a brief Goal Statement Write a 1-3 page Project Charter that summarizes the project Plan the project and write the Software Project Management Plan (SPMP) Approval, stang, ...
20 / 64
Planning activities I
Choosing & customizing the life cycle Work Breakdown Structure Estimating Scheduling Designing the project organizational structure
21 / 64
Goal Statement
A concise statement of the project objectives Specic enough to avoid misinterpretation How the project will be described to outsiders (similar to an elevator speech) Gives everyone a focused goal Ensures everyone agrees about the basic project goals and scope A fuzzy goal will most likely lead to fuzzy results. [3]
22 / 64
Example goal statements

Too vague: Build a timesheet data entry system. Focused: Build and successfully deploy a Web-based timesheet data entry system for the engineering departments internal use before the beginning of next quarter. This version avoids conicting interpretations of the projects quality platform intended users schedule (Adapted from [3].)
23 / 64
Setting clear objectives I
Source: [3] Focus on deliverables, not just processes Measurable and testable criteria (e.g., dollars, dates, % market share) Action-oriented Conversational: elevator speech
24 / 64
What is the scope?
The scope denes what the project is and is not about. Want crisp boundaries; a clear statement you can point to and say Thats out of scope. In dening the scope, try to uncover hidden assumptions that stakeholders may have but are not articulating Often stated as
inclusions; exclusions.
25 / 64
Example: Scope I
From [3] The project is: for internal use; a timesheet data-entry system; web-based; for the engineering departments use; The project is not: intended for use by other departments or customers; a labour accounting system; intended to be accessed by PDAs, cell phones; required to interface to other systems.
26 / 64
The Project Charter I

The project charter briey summarizes the goals, scope, constraints, and rationale for the project. 13 pages Serves as an executive summary of the SPMP; will be passed around at higher-levels in the company for signing o. Brief statements of:
Objectives Major features Performance requirements Constraints Scope Costs and benets (business case)
Possibly in lay language, depending on audience
27 / 64
What is the SPMP? I
aka Software Development Plan (SDP) Exact contents vary; usually lled out from a SPMP template document Typical contents:
Overview of the project Deliverables Project organization Managerial processes Technical processes Budget Schedule
28 / 64
IEEE 1058 I
IEEE 1058: IEEE Standard for Software Project Management Plans Top-level contents: 1. Overview (purpose, scope, objectives, assumptions, constraints, deliverables, schedule and budget summary) 2. References 3. Denitions 4. Project organization (roles and responsibilities; subcontractors; customers; lines of authority and communication)
29 / 64
IEEE 1058 II
5. Managerial process plans (start-up plan; work plan; control plan; risk management plan) 6. Technical process plans (process model; development methods, languages, tools, techniques, development infrastructure, product acceptance plan) 7. Supporting process plans (conguration management, QA, documentation, etc.)
30 / 64
Where to nd document templates
IEEE 1058: table of contents for a SPMP [?] Steve McConnells web site: document templates http://www.construx.com/Page.aspx?hid=1037 Software Productivity Centre (SPC) Numerous links to document templates: http://www.iturls.com/English/ SoftwareEngineering/SE c.asp
31 / 64
Example SPMP I
SCIAMACHY: a European Space Agency satellite SCIAMACHY is an imaging spectrometer whose primary mission objective is to perform global measurements of trace gases in the troposphere and in the stratosphere. SCIAMACHY Data Centre http://neonet.knmi.nl/neoaf/reports/ nl-scia-spmp-6.pdf
32 / 64
Hors doeuvres I
33 / 64
Planning fallacy I
Source: [5] People often underestimate how long a task will take. Two perspectives people use for estimation:
Inside: Thinking about the task, the particular scenario, how the task will be accomplished Outside: Thinking about how long such things usually take, what can go wrong, etc.
There is strong support for the explanation that people tend to favour an inside perspective, and ignore e.g. that something almost always goes wrong. Interestingly, this eect is more pronounced when people make predictions about themselves: when making predictions about others, they tend to take more of an outside perspective.
34 / 64
Planning fallacy II
However, recent results [5] demonstrate that forcing people to take a very detailed inside perspective increases the accuracy of their estimates.
35 / 64
Kruger/Evans experiments I
Subjects were asked to estimate how long a task would take them (getting ready for a date, christmas shopping, preparing a tray of hors doeuvres, ...) Two conditions:
Unpacked: Subjects were asked to plan out the activity in detail, e.g., listing the steps to get ready for a date, making a christmas list, etc. Then they were asked to estimate. Packed: Subjects were just asked to estimate.
36 / 64
Kruger/Evans Experiments
Example results: in one experiment, subjects were asked to estimate how long it would take them to format 9 dictionary denitions in a very detailed style:
From [5]
37 / 64
Source: [5]
38 / 64
Conclusion: evidence that unpacking a task into subtasks reduces the planning fallacy.
39 / 64
Part III Work Breakdown Structure (WBS)
40 / 64
Work packages
Source: Musser/Pidduck, [3] Work packages are the smallest items in the WBS (leaves of the tree) One-to-two rule: 1-2 people for 1-2 weeks Not too small (avoid microplanning) Might contain
Description of work product Eort estimate Stang requirements: who or how many people Acceptance criteria
In estimating/scheduling, work packages are annotated with time/dollar costs and rough start/end dates
41 / 64
What is the right level of granularity? I
WBS might be very detailed or not very detailed, depending on the use to which it will be put. Royce [6]: Large projects tend to be overplanned, small projects underplanned WBS is the basis for setting responsibilities, budget estimation and tracking, time estimation, scheduling, and tracking progress.
42 / 64
What is the right level of granularity? II

Usually 2-3 levels of detail Too little detail schedule, budget, personnel requirements might be badly misestimated Too much detail WBS will require frequent maintenance as the project unfolds Some projects may elaborate WBS as the project unfolds: start with a coarse decomposition, and do detailed WBS only for the next phase (e.g., Scrum) Some authors recommend work packages of 1-2 weeks in duration
43 / 64
Rate chart
WBS is a useful means for progress tracking: if low-level work packages are of similar granularity, can plot number of items completed vs. time Called a progress rate chart, or just rate chart. Known since the late 1970s at least
Source: [7]
44 / 64
Burndown chart
Agile methods adapted rate charts by turning them upside down and calling them Burn-down charts Plot estimated time of remaining work packages vs. date
Source: Laughing Panda

45 / 64
Possible structures for WBS

Royce the younger [6]:
Level 1: workows (management, environment, requirements, design, implementation, deployment, ...) Level 2: lifecycle phases Level 3: major artifacts to be produced Levels 4: activities that lead to major artifacts
Large scale (Musser/Pidduck): 1 Total program 2 Project Managerial levels 3 Task 4 Subtask Technical levels 5 Work package Use levels 1-2 for reporting to upper management/client organization.
46 / 64
WBS as a tree
Source: John Musser
47 / 64
WBS as sections of a document
48 / 64
WBS in Microsoft Project
Source: John Musser
49 / 64
WBS in WBS Chart Pro
Source: Critical Tools

50 / 64
Part IV Estimation
51 / 64
Wheel of fortune
52 / 64
Anchoring I
Experiment:
1. Ask someone what the last two digits of their student ID number are. 2. Ask them to estimate some quantity that is likely to be in the range 0-99, e.g., what percentage of households in Iqaluit have snowmobiles?
Tend to nd a strong correlation between (1) and (2).
53 / 64
Anchoring II
Anchoring eect: when asked to estimate some quantity, people tend to take whatever number was last in their head and bump it up or down. Reliably reproducible in a wide variety of scenarios, including software estimation e.g., [4, 1]
54 / 64
Aranda/Easterbrook experiments [1] I
Subjects presented with a 10-page requirements document and 3-page project setting document (describing the team, company, and its culture.) Subjects were asked to produce an estimate (in months) of how long the project would take, using a method of their choice. Also asked to estimate how accurate they felt their estimate was.
55 / 64
Aranda/Easterbrook experiments [1] II

Three conditions. A paragraph in the middle of the project setting document quoted a manager as saying:
1. (Control) Id like to give an estimate for this project myself, but I admit I have no experience estimating. Well wait for your calculations for an estimate. 2. (2 month) I admit I have no experience with software projects, but I guess this will take about 2 months to nish. I may be wrong of course, well wait for your calculations for a better estimate. 3. (20 months) ...I guess this will take about 20 months to nish...
Assignment of subjects to conditions controlled for their level of experience in project estimation.
56 / 64
Aranda/Easterbrook experiments
From [1]
57 / 64
Aranda/Easterbrook experiments
Average estimates Everyone 2 month Control 20 month 6.8 8.3 17.4
Experienced estimators 7.8 9.0 17.8
58 / 64
Anchoring eects
Anchoring eects take place even when the anchor is known to be unreliable. Experts are inuenced by anchoring eects. Other experiments show that even if you forewarn people about the anchoring eect, they will still be inuenced by it. Anchoring appears to operate unintentionally and nonconsciously...
59 / 64
Impact of anchoring eects
A sloppy pre-planning estimate anchors a more detailed estimate, even if the pre-planning estimate is known to be a wild guess. In contract situations, the cost estimated by a bidder can be strongly inuenced by the estimate given by the customer, even if the customer has just made a wild guess.
60 / 64
Part V Bibliography
61 / 64
Bibliography I
[1] Jorge Aranda and Steve M. Easterbrook. Anchoring and adjustment in software estimation. In Michel Wermelinger and Harald Gall, editors, Proceedings of the 10th European Software Engineering Conference held jointly with 13th ACM SIGSOFT International Symposium on Foundations of Software Engineering, 2005, Lisbon, Portugal, September 5-9, 2005, pages 346355. ACM, 2005. bib pdf [2] Jim Blythe. An overview of planning under uncertainty. Lecture Notes in Computer Science, 1600, 1999. bib
pdf
62 / 64
Bibliography II
[3] Robert T. Futrell, Donald F. Shafer, and Linda I. Shafer. Quality Software Project Management. Prentice-Hall, 2002. bib [4] Magne Jrgensen and Dag I. K. Sjberg. Impact of eort estimates on software project work. Information & Software Technology, 43(15):939948, 2001. bib [5] Justin Kruger and Matt Evans. If you dont want to be late, enumerate: Unpacking reduces the planning fallacy. Journal of Experimental Social Psychology, 40:586598, 2004. bib pdf
63 / 64
Bibliography III
[6] Walker Royce. Software project management: a unied framework. Addison-Wesley, 1998. bib [7] Robert C. Tausworthe. Work breakdown structure in software project management. The Journal of Systems and Software, 1(3):181186, 1980. bib pdf
64 / 64
Chapter 5
EstimationPsychology of estimationCommon knowledge effectIllusion of explanatory depthParkinsons LawStudent syndromeUnder vs OverestimationCone of uncertaintyAccuracy vs PrecisionEffect of project size and typeEstimation techniquesWideband DelphiBiddingCountingPlanning PokerEstimation by analogyCalibrated modelsSchedule estimation
235
SE362 Lecture 5: Estimation Todd Veldhuizen tveldhui@acm.org
SE362 Lecture 5: Estimation

May 20, 2008
1 / 90
Estimates, Targets, Commitments I
Estimate: a preliminary, tentative calculation of project cost/time that is unbiased and analytical Target: a business objective (Need to have Version 2.1 ready to demonstrate at a trade show in May) Commitment: a promise to deliver something by a certain date
2 / 90
Estimates, Targets, Commitments II
Be wary of confusing estimates, targets, and commitments. Need to distinguish between

Providing an estimate (an unbiased, analytical assessment); or Figuring out how to hit a target (e.g., by scoping appropriately.)
3 / 90
Estimates, Targets, Commitments III
Once we make a commitment to a schedule, we control the project to keep it on track. (Might involve ditching unstable functionality, removing requirements, etc. to maintain the schedule.) It is generally thought that if the target and the estimated schedule are within 20% of each other, there is enough maneuvering room (team size, feature set, etc.) to meet the target.
4 / 90
Estimates are probability statements

The many uncertainties in software development make it impossible to say We will nish in 253 days. Instead, an estimate is best thought of as characterizing a probability distribution. The convention is that an estimate species the median of this distribution, i.e., there is a 50% chance of nishing the project in the estimated time. Sometimes called a p50 estimate. (Note that while this denition of estimate is commonplace in software estimation and project management, higher management may not appreciate the dierence between a p50 estimate and a target!) This median value is called the nominal estimate
nominal: a quantity expressed not necessarily corresponding to the exact value.
In the preliminary stages of a project, the error bars of an estimate are often enormous e.g. from 0.25x to 4x.
5 / 90
Part I Psychology issues in estimation
6 / 90
Cognitive Biases
Anchoring eect: the default mechanism people use to estimate is to take whatever background number is available, and adjust up or down. Planning fallacy/optimism bias: people are fundamentally optimistic when it comes to scheduling estimation. Estimates are routinely 30% too small.
7 / 90
Common Knowledge Eect

Study by Gigone and Hastie (1993) [3]. Subjects were presented with proles of college students, and asked to predict their grade in a course. Each prole contained six cues: SAT score, attendance percentage, high school GPA, enjoyment of the course, workload in other courses, and self-rated anxiety. Subjects worked in groups of 3 and were asked to estimate what grade the student received. Each subject knew dierent bits of information (e.g., one person knew the GPA, everyone knew the SAT score, two people knew attendance, etc.) Who-knows-what was randomly varied. A regression model used to determine how cues were weighted
8 / 90
From [3].
9 / 90
Common knowledge eect: Groups tend to ignore knowledge that is not widely shared among the members. They weight knowledge according to how widely it is held [3]. Even if knowledge held by only one person is shared and discussed by the group, it is discounted. Groups tend to discount key knowledge held by lower-status individuals [4].
10 / 90
Illusion of explanatory depth I
11 / 90
Illusion of explanatory depth II

Study by Rozenblit and Keil [12] demonstrating that people are overcondent in their knowledge: they think they understand things far better than they actually do. People feel they understand complex phenomena with far greater precision, coherence, and depth than they really do; they are subject to an illusionan illusion of explanatory depth. Subjects shown a variety of devices (zipper, piano key, helicopter, ush toilet, etc.) and asked how well they understood how it worked (1=not at all, 7=very deeply). Subjects were then asked to write a detailed explanation of how the device worked. They were then asked detailed questions about the devices (e.g., How does a helicopter change from hovering to forward ight?).
12 / 90
Illusion of explanatory depth III
They then read an experts description of the device. In between each of the above, they were asked to rerate their knowledge of the device.
13 / 90
Illusion of explanatory depth IV
14 / 90
Illusion of explanatory depth V
15 / 90
Illusion of explanatory depth VI
People think they know far more than they actually do. Their estimate of their expertise is more realistic if they are asked to provide detailed explanations or answer probing questions. Implication for estimation: if the time required for some task depends on how much of a particular expertise someone has, you will probably get a more realistic estimate if you rst ask the person to describe how they would implement it, and then ask them to estimate.
16 / 90
Parkinsons Law I
Parkinsons Law: () work expands so as to ll the time available for its completion.
Thus, an elderly lady of leisure can spend an entire day in writing and dispatching a postcard to her niece at Bognor Regis. An hour will be spent in nding the postcard, another in hunting for spectacles, half-an-hour in a search for the address, an hour and a quarter in composition, and twenty minutes in deciding whether or not to take an umbrella when going to the pillar-box in the next street.... [11]
17 / 90
Parkinsons Law II
The original paper proposed that bureaucracies grow at a rate of 5-7%, regardless of the actual amount of work to be done (supported by data from the British Navy and Colonial Oce showing steady increases in the number of ocials, even as the size of the navy and the colonies were in rapid decline.) Some of Parkinsons other laws:
Law of Extravagance: Expenditure rises to meet income and tends to surpass it. Law of Triviality: The time spent on any item of a committees agenda will be in inverse proportion to the sum of money involved.
18 / 90
Parkinsons Law III
For software engineers, there is a recursive version of Parkinsons Law: Hofstadters Law: It always takes longer than you expect, even when you take into account Hofstadters Law.
19 / 90
Student Syndrome
Full eort occurs only after a deadline has passed. As usually applied to SPM, means a tendency to work at a low intensity of eort in the early stages of a project, then ramp up to full intensity only as the deadline is being missed. Not to be confused with Medical Student Syndrome1
that medical students frequently experience the symptoms of whichever disease they most recently studied.
20 / 90
Part II Estimation techniques
21 / 90
Overestimation vs. Underestimation
Given that estimates may have large margins of error, should we try for an overestimate (more time than nominally needed) or an underestimate?
22 / 90
Arguments Against Overestimation
Parkinsons Law: if you give a project team 6 months to do a project that could be completed in 4 months, the project team will nd a way to use up the extra 2 months (with the best of intentions.) Student Syndrome: Eort wont reach full intensity until close to the deadline, which may result in the project being late despite the schedule padding.
23 / 90
Arguments Against Underestimation

Developers typically underestimate by 20-30%. Reducing these estimates further reduces the likelihood of meeting the estimate. Cramped schedule can short-change upstream activities (requirements + design), resulting in costly changes late in the schedule. If a project is late, it can become much less ecient: lots of time spent in status meetings, reestimation, apologies, requirements triage, xing hastily implemented code, etc. Underestimated projects have a tendency to turn into demoralizing death march projects
24 / 90
Underestimation vs. Overestimation
The penalties for underestimating are more severe. It is usually recommended not to intentionally underestimate.
25 / 90
Industry Track Record
Capers Jones: project success depends greatly on project size: Approximate On Time Late Failed Size (LOC) (Cancelled) 1000 81% 6% 2% 100000 61% 18% 20% 10000000 14% 21% 65%
26 / 90
Benets of Accurate Estimates
Tracking progress: if the estimate is accurate, can meaningfully compare planned progress to actual progress. Some studies estimate that 40% of all software errors are caused by stress. Extreme schedule pressure can cause the defect density to multiply 4x. Accurate budgeting Increased credibility Many businesses value predictability more than development time, cost, or exibility.
27 / 90
Sources of Estimation Error
Inaccurate information about the project Inaccurate information about the organization Requirements instability: trying to estimate a moving target The estimation process itself.
28 / 90
Poorly dened requirements
Poorly dened requirements can introduce enormous variability in project length. E.g. Suppose that in a data entry form, there is a telephone number eld. If the requirements say Check the telephone number is valid, what does this mean?
nnn-nnn-nnnn? (the quick version say, two hours of work) support international dialing, verify country codes and syntax against a database, cross-check the country code against the address elds...? (say, two months see wtng.info)
29 / 90
Cone of Uncertainty
30 / 90
Cone of Uncertainty: real data
Source: [9]
31 / 90
Cone of Uncertainty
The cone doesnt narrow itself it narrows as decisions are made that reduce variability: detailed requirements, prototyping, etc. If you need the cone to narrow quickly, you need to front-load the schedule with activities that will reduce variability. Because of the large margin of error associated with early estimates, it is dangerous to commit to a target completion date in the very early phases of a project. Meaningful commitments are only possible once the cone has narrowed to within, say, 0.2x. Avoid commitments in the very early phases of a project!
32 / 90
Omitted Activities I
A common source of estimation error is forgetting to include necessary tasks. E.g. developers can accurately estimate the work they remember to estimate, but tend to overlook 20-30% of the necessary tasks. Frequently missed functional requirements:
Setup/installation program Data conversions Glue code to use third-party software Help system, etc.
33 / 90
Omitted Activities II
Frequently omitted nonfunctional requirements:

Interoperability Performance Portability Reusability Usability, etc.
34 / 90
Omitted Activities III
Frequently omitted activities:

Getting new team members up to speed Installation Managing the beta program Supporting and maintaining existing systems Participating in technical reviews Coordinating with subcontractors Performance tuning Demos (customers, trade shows, management) Learning new development tools, etc.
35 / 90
Omitted Activities IV
Frequently omitted non-software activities:

Vacations + Holidays Sick days Company + department meetings Setting up new hardware, etc.
36 / 90
The rule about o-the-cu estimates

O-the-cu estimates (given at short notice with little or no analysis) have a tendency to be interpreted as commitments by upper-level managers. There is a simple rule about o-the-cu estimates: dont make them. Several studies have found that giving o-the-cu estimates is one of the most common errors that project teams make. If you are pressured to give a quick estimate, then at least think about the estimate even if for just 15 minutes and discuss it with some colleagues this will improve accuracy. And, stress that the estimate is still a wild guess and should not be used as the basis for any commitment.
37 / 90
Accuracy vs. Precision
Accuracy = proximity to the true value Precision = number of digits E.g., scheduled departure times for airline ights are precise (9:25) but not accurate. 3 is a more accurate estimate of than 3.4392812. Unwarranted precision can give stakeholders a wrong impression about the error bars.
An estimate of 395 days suggests accuracy to within < 1%. Better to say 400 days, or 13-14 months.
Aim for an estimate that is accurate, but not too precise.
38 / 90
Estimation by experts I
The actual length of time a project takes is a random variable with some distribution: there are numerous things that could go wrong, people might get sick, leave the organization, etc. Estimates are generally understood to refer to the length of time by which a project has a 50% chance of being completed (i.e., the median length.) A simple way to obtain an estimate is to ask an experienced developer or project manager how long they think a project will take.
39 / 90
What factors should inuence estimates?

Most of what we know about software estimation is derived from large data sets of post hoc project statistics. From these statistics, we can ask questions like What inuence does the project size have on productivity?, and develop predictive models Unfortunately, many of the factors that inuence projects are dicult to assess objectively: competence of the requirements analysts, competence of the programmers, team cohesion, etc. Ultimately you have to combine
Uncertain information about requirements (e.g., leading to an estimate of project size); and Subjective information about the team
to arrive at an estimate.
40 / 90
Inuence of project size

Not surprisingly, size of the software being built is the single largest factor aecting the estimate. Development cost and time do not scale linearly with the size of the project. Instead there are Diseconomies of scale at work: the larger a project, the less productive (in terms of LOC/month) developers can be. As project size increases, so does team size, and more coordination and communication activities are required. E.g.: Project Size (LOC) 10000 10000000 LOC/person-year 2000 25000 3005000 COCOMO II (nominal) 3200 1600
41 / 90
Inuence of project type

The second most important factor is project type: is it a safety-critical system (e.g., nuclear power station control) or shrink wrap? For a 250K LOC project: nominal productivity in LOC per person-month Microcode 40 Avionics, real-time 50 Telecom, device drivers 100 Scientic 300 Business systems 600 Combination of project size and kind: enormous variations in productivity
Avionics, 250KLOC : 20200 LOC/person-month Business systems, 10KLOC : 80018,000 LOC/person-month
42 / 90
Personnel factors I
COCOMO II adjustment factor ranges for personnel: Low High Requirements Analyst Capability -29% +42% Programmer Capability -24% +34% Personnel Continuity -19% +29% Domain Experience -19% +22% Language and Tools Exp. -16% +20% Platform Exp. -15% +19% Team Cohesion -14% +11% Note that a team that scored at the max of all of these categories would be (according to the model) 21.8 times more productive than a team who scored at the bottom of each category.
43 / 90
Personnel factors II
Unfortunately, this means you can cause huge swings in the estimate by turning a lot of knobs a little bit, e.g., if you increase each of the above by 10%, this gives you an overall productivity increase of 177% Estimation systems with lots of knobs to turn you can game the estimation process to come out with whatever you want/expect to see.
44 / 90
Styles of estimation techniques

The following techniques are suggested in the literature. Percentages give the fraction of academic journal papers on software estimation that investigate that technique [7]. (This indicates how much interest the technique has generated, not necessarily related to how worthwhile the technique is.) Regression models (49%) Function Points (22%) Expert judgement (15%) Theoretical models (13%) Analogy (10%) Neural networks (7%) Classication and regression trees (5%) Simulation (3%) Other (12%) Currently popular methods: regression, analogy, expert judgement.
45 / 90
Styles of estimation techniques
Formal estimating tools (e.g., regression models) are not widely used in industry. The most dominant method for cost estimation in industry is expert judgement, according to numerous studies [5].
46 / 90
What kind of estimation technique works best? I
Short answer: nobody knows. M. Jrgensen [5] analyzed 15 empirical studies that compared the accuracy of expert estimates to formal model-based estimates:
5 were in favour of expert estimation 5 found no dierence 5 were in favour of formal model-based estimation.
There is strong evidence for the following ndings [5]:

1. When experts correctly apply important domain knowledge not included in estimation models, experts are more accurate. When experts do not have domain knowledge (or apply it incorrectly), model estimates are more accurate.
47 / 90
What kind of estimation technique works best? II
2. Experts use simple heuristics to estimate (e.g., analogy with previous similar projects.) When these heuristics are valid, experts are as good as, or better than, models. When the heuristics are invalid, experts may give biased estimates.
There is some evidence that experts do better than models in low-uncertainty scenarios, and that models do better in high-uncertainty scenarios [5].
48 / 90
What kind of estimation technique works best? III
There is consensus that if models are carefully calibrated to an organizations track record, then they can be very accurate. (In eect, such calibration imbues the models with the kind of inside knowledge experts have.) It is also understood that uncalibrated models (based, e.g., on industry-wide track records) can be inaccurate.
49 / 90
Best practices for estimation I
Best results for estimation are obtained when either:

1. You use formal estimation models that have been calibrated to your organization and problem domain using track-record data. (This requires maintaining a detailed database of previous projects and their outcomes.) 2. You use expert-based estimation, with experts who have deep knowledge of the problem domain and organizational track-record, and use heuristics that have been shown to increase accuracy.
50 / 90
Best practices for estimation II

Combinations of sound estimation methods are more accurate than single methods. (E.g., using both sound expert judgement and sound model-based estimates will improve accuracy.) You should always try to characterize how precise your estimate is, for example, by estimating upper and lower bounds (e.g. p10 and p90 estimates) in addition to a median estimate. (Remember the cone of uncertainty!) If possible, use a checklist of commonly forgotten activities, and/or compare activities to those in experience reports from similar previous projects.
51 / 90
Guidelines for expert estimation I

Jrgensen [6] suggests seven guidelines for expert estimation, based on empirical evidence and industrial experience. Ask for justication; never rely on gut feelings. Valid justications include
Referring to the track record on similar projects A breakdown of the project into activities, estimating the activities, and estimating how much eort will be spent on unplanned activities Applying estimation models that were developed in-house from the track record.
Use experts with experience on similar projects. Accuracy depends on how well experts can recall very similar projects. Amount of general experience is not very relevant. E.g., in one study
Experts with experience on very similar projects had an average 12% estimation error;
52 / 90
Guidelines for expert estimation II

Experts with experience on other projects had an average 39% estimation error.
Accept and assess uncertainty. Some projects are inherently risky; it is important to acknowledge that the estimate may have very wide error bars. Try to estimate the error bars, using track records, or the cone of uncertainty.
One method is to take the initial estimate and multiply by 1.5 to get an 90% interval, and by 0.9 to get a 10% interval. (These numbers can be calibrated from track record information about estimated vs. actual project lengths.) Humans tend to be overcondent: one study found that when project leaders claim 90% certainty that the eort will not exceed some amount, the actual probability is 60-70%.
53 / 90
Guidelines for expert estimation contd [6] I

Actively train people to give more accurate estimates; experience alone is not enough. Typically, a project team estimates a projects most likely eort, then executes the project and measures the actual eort. The actual eort often exceeds the estimated most likely eort. What can we learn from such feedback, other than we have been overoptimistic, again? Jrgensen recommends the following training regimen:
1. Accumulate specications and experience reports from projects. 2. Have developers estimate a project (without looking at the report)
54 / 90
Guidelines for expert estimation contd [6] II

3. Then work through the experience report, looking at the dierence between the estimate and the actual outcome. Provide feedback about forgotten activities, incorrect assumptions, etc., and gure out how to improve the accuracy of the estimate.
Postpone or avoid estimation if possible(!)

Some empirical studies suggest that just having an estimate lowers eciency. Overoptimistic estimates are bad for morale, and lead to a cramped schedule that short-changes analysis, design, and QA. Estimates are almost always overoptimistic. a good reason not to estimate at all, or to postpone estimation, if feasible. (However, planning is still important.)
55 / 90
Estimation in Groups I
A major source of estimation error is unanticipated activities. With a group of estimators, it is more likely that at least someone will think of a given activity and mention it. A basic process for group estimation [10]:
1. Each group member estimates individually, then meet to compare notes. Try to understand the sources of the dierences. 2. Dont just average estimates. Try to come to a consensus. If the most pessimistic estimate comes from an expert, there is probably a reason for it.
56 / 90
Molkken-stvold and Jrgensen (2004) I

Study of individual vs. group estimation 20 individual experts (6.3 yrs of IT experience on average) asked to estimate a project (actual eort 2365 hours.) Initial estimates ranged from 220 to 2286 hours, average was 1088 hrs. Then met in ve groups of four, given an hour to produce an estimate. The group estimate range was 11002251 hours. The group estimate average was 1548 hours, 460 hours more than the individual estimate average (p=0.024) The individual estimate average increased from 1088 hrs to 1424 hrs after the group process (p=0.003). Initial individual estimates had an error of 900% to 3% Group estimates had an error of 53% to 5%.
57 / 90
Wideband Delphi I
Wideband Delphi is a highly structured group estimation technique. McConnell [10] reports that Wideband Delphi cuts estimation error by an average of 40% compared to the initial group average.
58 / 90
Wideband Delphi Protocol I

1. The Delphi coordinator presents each estimator with the specication and an estimation form. 2. Estimators prepare initial estimates individually. (Optionally, this can be done after step 3.) 3. The coordinator calls a group meeting in which the estimators discuss estimation issues related to the project at hand. If the group agrees on a single estimate without much discussion, the coordinator assigns someone to play devils advocate. 4. Estimators give their individual estimates to the coordinator anonymously. 5. The coordinator prepares a summary of the estimates on an iteration form and presents the form to the estimators so they can see how their estimates compare with other estimates.
59 / 90
Wideband Delphi Protocol II
6. The coordinator has estimators meet to discuss variations in their estimates. 7. Estimators vote anonymously on whether they want to accept the average estimate. If any of the estimators votes no, they return to step 3. 8. The nal estimate is the single-point estimate stemming from the Delphi exercise. (Or, a range is derived from the exercise.)
60 / 90
Estimating vs. Bidding I

Sources: [6, 8] Bidding dilemmas:
Early estimates tend to be wildly inaccurate (0.25x 4x) Contract bidding requires an early estimate The utility of winning a contract depends on the dierence between the bid price and actual cost. Its a waste of time to prepare a bid that has no chance of winning. Very dangerous to bid on an infeasible project.
Jrgensen [6] recommends completely separating the bidding process from the eort estimation process, for example, by not giving the estimation team any information about the expected price-to-win.
61 / 90
Part III Counting-based estimates
62 / 90
Counting-based estimates I
Derive an estimate from some feature(s) that can be counted Initial estimates:
features use cases story points (for agile methods)
Mid-project, ner-grained:
detailed requirements function points change requests web pages reports dialog boxes screens database tables
63 / 90
Counting-based estimates II
very important that what you count is correlated with eort! the more items you can count, the better a sample you will have. If you can only count 5 items, it will be hard to obtain a meaningful estimate! Use historical data to convert counts to estimates. E.g.,
1. Count # of use cases 2. Multiply by historical average of # hours of eort per use case, to get estimated total hours; or Divide by historical average # of use cases implemented per month, go get estimated schedule length
64 / 90
Story points
Team reviews the list of stories and assigns a size to the story. Often use a point-scale, e.g.
1, 2, 4, 8, 16 1, 2, 3, 5, 8, 13 Very Small, Small, Medium, Large, and Very Large
Using of powers-of-two gives a logarithmic scale, e.g., like the Richter scale Use historical data on sta-days per story-point to obtain estimates
65 / 90
Planning Poker I
66 / 90
Planning Poker II
Each person has a deck of cards with numbers that represent story points (estimate of how much work is involved). After discussing the story/use case as a group, each person selects a card from their deck and lays it face-down. The cards are not revealed until everyone has selected a card. Avoids people letting themselves be inuenced by other estimates.
67 / 90
Estimation by analogy I
1. Get detailed size, eort, and cost results for a similar previous project. 2. Compare the new project to the old, piece-by-piece. For each piece estimate how much bigger or smaller the project is, and adjust. 3. Check that the assumptions of similarity youre making about the project are valid (e.g., are you using the same programming language? same level of developer skill? etc.)
68 / 90
Estimation by analogy II
Subsystem Database User interface Graphs and reports Foundation classes Business rules Total
Old project 5000 14000 9000 4500 11000 43500
Mult. Factor 1.4 1.4 1.7 1.0 1.5 -
New project Estimate 7000 19600 15300 4500 16500 62900
69 / 90
The importance of calibrated models
Microsoft Excel 3.0: 649 000 LOC; 50 sta-years; $12/LOC; 13000 LOC/sta-year Space Shuttle: 25 600 000 LOC; 22096 sta-years; $77/LOC; 1200 LOC/sta-year
70 / 90
Exercise I
Programmer Capability Domain Experience Language and Tools Exp. Platform Exp. Team Cohesion
-24% -19% -16% -15% -14%
+34% +22% +20% +19% +11%
71 / 90
Calibration I
Calibration = rene your estimation process using historical data. Three sources of historical data for calibration:
The project currently under way (most accurate; but not available until partway through the project) Projects the team has done in the past; Projects the organization has done; Industry data (least accurate)
If you are going to calibrate with data from the current project, you should read up on priors (prior distribution, from Bayesian inference), or at least use a tool that uses Bayesian inference e.g., COCOMO II.
72 / 90
Political advantages of calibrated models I

Using historical data has important political advantages If you use, e.g., COCOMO II, and realistically assess your team as below industry average on several counts, you may nd yourself on the defensive: executives might think you have a low opinion of the company, and the team might think you dont have condence in them. Not good for morale. McConnell: Clearly, half the programmers in the industry are below average, but I rarely meet project managers or executives who believe their programmers are the people who are below average. (To be picky we should note the dierence between means and medians: if 90% of programmers write 100 LOC/day, and 10% write 10 LOC/day, the average is 91 LOC/day; only 10% are below average.)
73 / 90
Political advantages of calibrated models II

Lake Wobegon eect: people consistently rate themselves as above average. ...the poorest performers are also the poorest at self-evaluation. For example, the bottom 25 percent of students tend to think theyre doing better that 65 percent of the class. People who are doing really badly, theyre performing really poorly, tend to think that theyre doing quite well, he says. Which is really interesting because if you ask them to predict how other people will behave in general theyre largely accurate. They actually get other people in general right more or less but they really get themselves wrong dramatically.
74 / 90
Political advantages of calibrated models III
If you use historical data from the team, then it avoids comparisons, and is easily defended.
75 / 90
Diculties with self-assessments
From [1]. First-year psychology students (n=141) asked to estimate how well they did on an exam, relative to the rest of their class.
76 / 90
How accurate does calibration make models? I
US DOD maintains large databases of historical project data, that can be used to assess how much calibration improves accuracy. After calibration, models are usually accurate to within 25% about half the time. (i.e., you have a fty-fty chance of getting an estimate that is within 25% of the projects actual cost.) Accurate to within 25% about half the time is considered a good benchmark for an accurate model. COCOMO II: after calibration,
industry-wide data: within 30%, 52% of the time organizational data: within 30%, 64% of the time
77 / 90
How accurate does calibration make models? II

Ferens 2000: Several authors assert that a models predictive accuracy can be improved by calibrating (adjusting) its default parameters to a specic environment. This article reports the results of a three-year, 10-study project that tests this assertion. Results show that calibration did not improve the predictive accuracy of most of the models we tested. In general, the accuracy was no better than within 25 percent of actual development cost or schedule, about one half of the time. [2] Other authors claim that calibration does signicantly improve accuracy
78 / 90
How accurate does calibration make models? III
With use of Bayesian estimation, calibration generally will not decrease accuracy (if your historical data is accurate and relevant). So, calibrating with historical data is something you should probably do, if possible
79 / 90
Example of a historical project database
Keep track of:

Lines of code, or other measures of size; Eort (sta months) Time (calendar months) Defects (by severity)
This will let you estimate LOC/sta-month. Avoid starting with an enormous database schema of information to track: start small, understand what youre collecting.
80 / 90
Standardized procedure for an iterative project I
It is a good idea to have a standardized estimating procedure for projects, that indicates when and how estimates are done and when they need to be adjusted. Heres an example standard procedure for iterative projects.
81 / 90
Standardized procedure for an iterative project II

1. Exploratory Estimate
Estimate planned feature set using Story Points. Plan rst iteration using historical data: use story-point estimates to obtain a 1-month iteration, but dont estimate the entire project, and dont commit to a schedule.
2. Planning Estimate (for 2nd + 3rd iterations)

Calculate avg. story points per sta-week from previous iterations (to calibrate eort) Calculate average story points per calendar-week (to calibrate schedule) Use these calibrated numbers to plan next iteration of 1 month duration Nominal estimate for entire project using story points.
Estimate can be described internally as between 0.75N and 1.0N , but not to be published externally. No commitments at this stage.
82 / 90
Standardized procedure for an iterative project III

3. Commitment Estimate (after 3rd iteration)
Calibrate story points per sta-week and calendar-week using previous iterations. Calculate nominal estimate for entire project
Describe internally as 0.9N to 1.1N Describe externaly as 0.9N to 1.0 N Commit based on 0.9N to 1.0N
4. Reestimate project whenever major changes in assumptions occur 5. At completion of the project, collect and archive data, and review accuracy of estimates.
83 / 90
Schedule Estimating I
Given an estimate of a project in sta-months, how to estimate time? E.g. with 100 sta-months, is this:
A 10-month project with 10 sta? A 50-month project with 2 sta?
Basic Schedule Equation: ScheduleInMonths = 3.0 StaMonths1/3 E.g., for 100 sta months, get ScheduleInMonths = 3.0 (4.6)1/3 = 13.8 months Therefore, a team of 7 or so. Barry Boehm: this basic equation is one of the most replicated results in software engineering.
84 / 90
Schedule compression I
The following table shows an approximation of the tradeo between compression of the nominal schedule length, and eort that results Schedule compression Eort increase -15% +100% -10% +50% -5% +25% 0% 0% +10% -30% +20% -50%
85 / 90
Part IV Bibliography
86 / 90
Bibliography I
[1] David Dunning, Kerri Johnson, Joyce Ehrlinger, and Justin Kruger. Why people fail to recognize their own incompetence. Current Directions in Psychological Science, 12(3):8387, 2003. bib pdf [2] D.V. Ferens and D.S. Christensen. Does calibration improve predictive accuracy? CrossTalk: The Journal of Defense Software Engineering, pages 1417, April 2000. bib [3] Daniel Gigone and Reid Hastie. The common knowledge eect: Information sharing and group judgment. Journal of Personality and Social Psychology, 65(5):959974, 1993. bib pdf
87 / 90
Bibliography II
[4] Andrea B. Hollingshead. Information suppression and status persistence in group decision making the eects of communication media. Human Communication Research, 23(2):193219, 1996.
bib pdf
[5] Magne Jrgensen. A review of studies on expert estimation of software development eort. Journal of Systems and Software, 70(1-2):3760, 2004.
bib pdf
[6] Magne Jrgensen. Practical guidelines for expert-judgment-based software eort estimation. IEEE Softw., 22(3):5763, 2005. bib pdf
88 / 90
Bibliography III
[7] Magne Jrgensen and Martin J. Shepperd. A systematic review of software development cost estimation studies. IEEE Trans. Software Eng, 33(1):3353, 2007. bib pdf [8] Barbara Kitchenham, Lesley Pickard, Stephen G. Linkman, and Peter Jones. Modeling software bidding risks. IEEE Trans. Software Eng, 29(6):542554, 2003. bib
pdf
[9] Todd Little. Schedule estimation and uncertainty surrounding the cone of uncertainty. IEEE Softw., 23(3):4854, 2006. bib pdf
89 / 90
Bibliography IV
[10] Steve McConnell. Software Estimation: Demystifying the Black Art. Microsoft Press, 2006. bib [11] Cyril Northcote Parkinson. Parkinsons Law, or The Pursuit of Progress. Houghton Miin, 1957. bib pdf [12] Leonid Rozenblit and Frank Keil. The misunderstood limits of folk science: an illusion of explanatory depth. Cognitive Science, 26:521562, 2002. bib pdf
90 / 90
Chapter 6
EstimationCOCOMOSelf-assessment hazardsSchedulingRolling Wave PlanningScheduling tools
326
SE362 Lecture 6: Estimation & Scheduling Todd Veldhuizen tveldhui@acm.org
SE362 Lecture 6: Estimation & Scheduling

May 22, 2008
1 / 43
Part I Estimation (continued)
2 / 43
Estimation by analogy I
1. Get detailed size, eort, and cost results for a similar previous project. 2. Compare the new project to the old, piece-by-piece. For each piece estimate how much bigger or smaller the project is, and adjust. 3. Check that the assumptions of similarity youre making about the project are valid (e.g., are you using the same programming language? same level of developer skill? etc.)
3 / 43
Estimation by analogy II
Subsystem Database User interface Graphs and reports Foundation classes Business rules Total
Old project 5000 14000 9000 4500 11000 43500
Mult. Factor 1.4 1.4 1.7 1.0 1.5 -
New project Estimate 7000 19600 15300 4500 16500 62900
4 / 43
COCOMO I
There are dozens of systems that have been proposed for estimating. Well look at COCOMO as an example. The basic ow in using such systems is: 1. Do enough design/architecture work to have a good idea of what exactly you are going to build. Make a WBS and estimate each part by counting/estimating something (KLOC, classes, functions, function points, object points, use cases, story points, pages of specication, etc.) 2. Adjust some parameters that reect the industry, team size, developer skill, domain expertise, etc. etc. 3. Perform calculations to estimate eort, schedule, and cost
Eort = total # of person-days Schedule = duration of project (usually in months)
5 / 43
COCOMO II
COCOMO = COnstructive COst MOdel

Collected data on lots of projects Fit equations to the data Can use these equations to predict time for new projects
6 / 43
COCOMO III
To apply: estimate KLOC for the project. Calculate Eort, Development time, People required: E = a(KLOC )b EAF D = cE P=
E D d
Eort (person-months) Dev. time (months) # People
EAF is Eort Adjustment Factor. It has a nominal value of 1.0, and is adjusted up or down by various cost drivers. Other coecients: Project type a Organic 2.40 Semi-detached 3.00 Embedded 3.60 b 1.05 1.12 1.20 c 2.50 2.50 2.50 d 0.38 0.35 0.32
7 / 43
COCOMO IV
Example: KLOC=10, EAF=1.0, organic: E = 2.40(10)1.05 = 26.9 person-months D = 2.50(26.9)0.38 = 8.7 months P = 3.09 people So, about 3 people for 9 months. Note that the D (development time/schedule length) equation has the typical form D = 2.5E 3 i.e., project duration scales as the cube root of eort. This is a well-known empirical law of software project estimation.
1
8 / 43
COCOMO V
Kinds of projects:
Organic projects: small projects, experienced developers, exible requirements Semi-detached: medium-size projects, multiple teams, mixed experience levels, some rigid requirements Embedded: tight constraints on hardware, software, and nonfunctional requirements
9 / 43
COCOMO VI
EAF (eort adjustment factor) is selected by multiplying a set of individual cost drivers: Product attributes
Required software reliability (0.751.40) Size of application database (0.941.16) Complexity of the product (0.701.65)
Hardware attributes
Run-time performance constraints (1.001.66) Memory constraints (1.001.56) Required turnabout time (0.871.15)
10 / 43
COCOMO VII
Personnel attributes
Analyst capability (1.460.71) Applications experience (1.290.82) Software engineer capability (1.420.70) Programming language experience (1.140.95)
Project attributes
Use of software tools (1.240.82) Application of SE methods (1.240.83) Schedule pressure (1.231.10)
11 / 43
Exercise
Estimate the time, team size, and budget required to develop a replacement for g++, including:
Parser Semantic analysis, error reporting, etc. Basic optimizations Code generation for x86.
But not including the standard libraries. Use the COCOMO equations: E = 3(KLOC )1.12 EAF D = 2.5E 0.35 P=
E D
Eort (person-months) Dev. time (months) # People
12 / 43
Exercise
One possible answer, from doing wc *.c *.h in the gcc source tree: 120 KLOC = C++ front end (parser + semantic analysis + lowering) 300 KLOC = GCC core (estimate: really around 680k, but a lot of stu we wouldnt need) 80 KLOC = x86 Total = 500 KLOC E = 3162 D = 42 P = 75 Eort (person-months) Months (3.5 yrs) People
Rough cost calculation: at $10k per person-month, about $32 million dollars (or about $64 per line of code).
13 / 43
The importance of calibrated models
Microsoft Excel 3.0: 649 000 LOC; 50 sta-years; $12/LOC; 13000 LOC/sta-year Space Shuttle: 25 600 000 LOC; 22096 sta-years; $77/LOC; 1200 LOC/sta-year
14 / 43
Exercise I
Programmer Capability Domain Experience Language and Tools Exp. Platform Exp. Team Cohesion
-24% -19% -16% -15% -14%
+34% +22% +20% +19% +11%
15 / 43
Calibration I
Calibration = rene your estimation process using historical data. Three sources of historical data for calibration:
The project currently under way (most accurate; but not available until partway through the project) Projects the team has done in the past; Projects the organization has done; Industry data (least accurate)
If you are going to calibrate with data from the current project, you should read up on priors (prior distribution, from Bayesian inference), or at least use a tool that uses Bayesian inference e.g., COCOMO II.
16 / 43
Political advantages of calibrated models I
Using historical data has important political advantages If you use, e.g., COCOMO II, and realistically assess your team as below industry average on several counts, you may nd yourself on the defensive: executives might think you have a low opinion of the company, and the team might think you dont have condence in them. Not good for morale. McConnell: Clearly, half the programmers in the industry are below average, but I rarely meet project managers or executives who believe their programmers are the people who are below average.1
17 / 43
Political advantages of calibrated models II

Lake Wobegon eect: people consistently rate themselves as above average. ...the poorest performers are also the poorest at self-evaluation. For example, the bottom 25 percent of students tend to think theyre doing better that 65 percent of the class. People who are doing really badly, theyre performing really poorly, tend to think that theyre doing quite well, he says. Which is really interesting because if you ask them to predict how other people will behave in general theyre largely accurate. They actually get other people in general right more or less but they really get themselves wrong dramatically.
18 / 43
Political advantages of calibrated models III
If you use historical data from the team, then it avoids comparisons, and is easily defended.
To be picky we should note the dierence between means and medians: if 90% of programmers write 100 LOC/day, and 10% write 10 LOC/day, the average is 91 LOC/day; only 10% are below average.
19 / 43
Diculties with self-assessments
From [2]. First-year psychology students (n=141) asked to estimate how well they did on an exam, relative to the rest of their class.
20 / 43
How accurate does calibration make models? I

US DOD maintains large databases of historical project data, that can be used to assess how much calibration improves accuracy. After calibration, models are usually accurate to within 25% about half the time. (i.e., you have a fty-fty chance of getting an estimate that is within 25% of the projects actual cost.) Accurate to within 25% about half the time is considered a good benchmark for an accurate model. COCOMO II: after calibration,
industry-wide data: within 30%, 52% of the time organizational data: within 30%, 64% of the time These stats underscore how dicult estimation is: even with a complex model like COCOMO II, estimating a 1-yr project will produce a result that is within 4 months only about half the time!
21 / 43
Example of a historical project database
Keep track of:

Lines of code, or other measures of size; Eort (sta months) Time (calendar months) Defects (by severity)
This will let you estimate LOC/sta-month. Avoid starting with an enormous database schema of information to track: start small, understand what youre collecting.
22 / 43
Standardized procedure for an iterative project I
It is a good idea to have a standardized estimating procedure for projects, that indicates when and how estimates are done and when they need to be adjusted. Heres an example standard procedure for iterative projects.
23 / 43
Standardized procedure for an iterative project II

1. Exploratory Estimate
Estimate planned feature set using Story Points. Plan rst iteration using historical data: use story-point estimates to obtain a 1-month iteration, but dont estimate the entire project, and dont commit to a schedule.
2. Planning Estimate (for 2nd + 3rd iterations)

Calculate avg. story points per sta-week from previous iterations (to calibrate eort) Calculate average story points per calendar-week (to calibrate schedule) Use these calibrated numbers to plan next iteration of 1 month duration Nominal estimate for entire project using story points.
Estimate can be described internally as between 0.75N and 1.0N , but not to be published externally. No commitments at this stage.
24 / 43
Standardized procedure for an iterative project III

3. Commitment Estimate (after 3rd iteration)
Calibrate story points per sta-week and calendar-week using previous iterations. Calculate nominal estimate for entire project
Describe internally as 0.9N to 1.1N Describe externaly as 0.9N to 1.0 N Commit based on 0.9N to 1.0N
4. Reestimate project whenever major changes in assumptions occur 5. At completion of the project, collect and archive data, and review accuracy of estimates.
25 / 43
Part II Scheduling
26 / 43
Schedule Estimating I
Given an estimate of a project in sta-months, how to estimate time? E.g. with 100 sta-months, is this:
A 10-month project with 10 sta? A 50-month project with 2 sta?
Basic Schedule Equation: ScheduleInMonths = 3.0 StaMonths1/3 E.g., for 100 sta months, get ScheduleInMonths = 3.0 (4.6)1/3 = 13.8 months Therefore, a team of 7 or so. Barry Boehm: this basic equation is one of the most replicated results in software engineering.
27 / 43
Schedule compression I
The following table shows an approximation of the tradeo between compression of the nominal schedule length, and eort that results Schedule compression Eort increase -15% +100% -10% +50% -5% +25% 0% 0% +10% -30% +20% -50%
28 / 43
Project Scheduling
Inputs: tasks (from WBS) and size/eort estimates Schedule: a preliminary plan of who-does-what-when Primary objectives: shortest time, least cost, least risk Secondary objectives: use resources eectively; have a tool for communicating about where the project is; a tool to monitor and control the project
29 / 43
Scheduling and uncertainty
Scheduling must confront several avours of uncertainty Uncertainty about task durations: its hard to predict how long things will take. In software development, task durations are randoma chance typo creates a subtle bug that takes a week to chase down. Uncertainty about the tasks themselves: if you cannot describe in a high level of detail the outcome of the project, then you cannot describe the ne-grained tasks required to get there. Uncertainty about resources: people fall ill; they change jobs, etc.
30 / 43
Rolling Wave Planning
In projects where there are signicant amounts of uncertainty, planning an entire project to a ne-grained level of detail does not make sense: if youre not sure what youre going to build, how can you schedule it? In such situations, a good practice is rolling wave planning, in which the level of planning detail decreases into the future: next month is planned down to the 1-day level, the month after that to the week level, and the year after that scheduled perhaps at the month level.
31 / 43
Basic components of a schedule
A schedule consists of
Tasks Estimated durations Nominal start and stop times of tasks Dependencies between tasks Milestones
32 / 43
Typical representation of a schedule
Source: Anne Pidduck
33 / 43
Milestones
Milestones have no duration; they identify that the project has reached a particular stage Useful to communicate status to stakeholders
We have successfully integrated the wookumwadger with the fadgomakoo. Weve reached the fourth milestone.
Might be linked to some formal review process: requirements review, sign-o Might be tied to contract terms.
34 / 43
Scheduling tools
There are numerous tools that can be used to (semi-)automate the scheduling process
Lots in the < $100 category Higher end: Microsoft Project, Primavera, MKS. Very high end: project portfolio management (manage many projects simultaneously). Low road: spreadsheet
35 / 43
Joel Spolsky: Painless Software Schedules
A lightweight scheduling technique that is low-overhead, but better than no schedule at all. (In fact, its really a time-accounting/budgeting, rather than scheduling per se.) http://www.joelonsoftware.com/articles/ fog0000000245.html Recommends against using MS Project: high overhead, The bottom line is that Project is designed for building oce buildings, not software. Instead, just use a spreadsheet
36 / 43
Joel Spolsky: Painless Software Schedules
Source: Joel Spolsky
37 / 43
Joel Spolsky: Painless Software Schedules I

Rows are activity/task from WBS Columns:
Priority Original estimate Current estimate Elapsed Remaining (Current est. minus elapsed)
Recommendations:
People should schedule their own tasks Pick ne-grained tasks (2-16 hours apiece): ensures that you have actually thought through the design in enough detail that you can make a reasonable estimate
At the end of each day, sprinkle the 8 hours for the day into the Elapsed column Takes about two minutes a day to update
38 / 43
Joel Spolsky: Painless Software Schedules II
Recommended method of dealing with managers who ask that an estimate be reduced: add another column, let the manager put in whatever estimate they want, and see whose estimates were more realistic at the end of the project.
39 / 43
High-road scheduling I
In larger organizations, project schedules are often pipelined: your project will not have N people for M months, but rather a core team plus people who will join and retire from the project as their expertise is needed. In these scenarios, scheduling is crucial since there are many projects competing for resources, and people with expertise must be booked ahead of time: have to gure out who you need and when.
Technical writers Databases analysts Network engineer Security specialist Web programmer
Schedules must sometimes be constructed around critical resources (e.g., if the only DBA with domain expertise is not available until July, then your schedule will have to be built around her/his availability window.)
40 / 43
Schedule Development
Techniques include: Critical path method Critical chain method PERT What-if analysis Resource leveling
41 / 43
42 / 43
Bibliography I
[1] Barry W. Boehm, Chris Abts, and Sunita Chulani. Software development cost estimation approaches - A survey. Ann. Software Eng, 10:177205, 2000. bib pdf [2] David Dunning, Kerri Johnson, Joyce Ehrlinger, and Justin Kruger. Why people fail to recognize their own incompetence. Current Directions in Psychological Science, 12(3):8387, 2003. bib pdf
43 / 43
Chapter 7
SchedulingTask dependenciesCritical pathsResource levelingPERTProject controlScope controlChange Control BoardsSoftware Conguration ManagementVersion and Revision ControlRelease ManagementEarned Value Management
370
SE362 Lecture 7: Scheduling & Project Control
SE362 Lecture 7: Scheduling & Project Control

May 27, 2008
1 / 66
SE362 Lecture 7: Scheduling & Project Control Todd Veldhuizen tveldhui@acm.org
Part I Scheduling
2 / 66
Task dependencies I
Dependencies are constraints on the order in which tasks may be performed. Precendence: one task must precede another (e.g., you cant test a module until youve coded it.) Concurrence: two tasks that can occur at the same time Leads & Lag time:
Lead time: task B can start when task A is half-nished (a lead time) Lag time: task B cannot start until one week after task A is nished (e.g., in construction: once the concrete foundation is poured, need some lag time to let it dry)
3 / 66
Precedence Diagrams
Precedence diagram. Source: PMBOK
4 / 66
Precedence Diagrams
Tasks are vertices, an edge from A to B indicates that task A must precede task B In its purest form, a precedence diagram represents a partial order (poset)
5 / 66
Kinds of task dependencies
Finish-to-Start (cant start B until A nished. Most common.) Finish-to-Finish (cant nish B until A nished.) Start-to-Start (cant start B until A started.) Start-to-Finish (cant nish B until A started. Rare.)
6 / 66
Kinds of dependencies contd
Mandatory dependencies: inherent in the nature of the work, e.g., cannot test a module until it has been coded. Discretionary dependencies: for best-practice type reasons, want to do X before Y. External dependencies: things that are outside the project that aect its timing. E.g., prototyping cant begin until the special hardware arrives. Resource dependencies: two tasks rely on the same resource e.g. one DBA but multiple DB tasks
7 / 66
Time constraints
Might also have time constraints that arise from e.g. contract conditions Start No Earlier Than Finish No Later Than
8 / 66
Network diagrams
Activity-on-node (AON): tasks are associated with nodes; edges/arrows indicate dependencies. Most common representation. Activity-on-arrow (AOA): nodes represent events, e.g. the start/end of a task; edges represent tasks.
9 / 66
Slack
Also known as oat Slack generally refers to how much time a task can run over its estimate without causing something else to be delayed. Free slack = slack an activity has before it delays the next task (if any) Total slack = slack an activity has before delaying the whole project The concept of slack is very appropriate in e.g. large projects, where there are many people that enter the project to contribute their expertise, then leave It is a bit illusory in small or medium-size projects where you have N people for the duration: if Rs task takes a week longer than planned, this automatically delays everything else R was going to work on.
10 / 66
Critical Path
A critical path is a sequence of activities from start to nish that have no slack. The specic set of sequential tasks upon which the project completion date depends. There might be one or more critical paths.
11 / 66
Critical Path Example
An Activity-On-Arrow (AOA) network. The sequence A, B, C, E, I is a critical path. Source: Anne Pidduck
12 / 66
Critical Path Method
A basic scheduling method dating back to the 1950s. Basic idea: identify the critical path, and optimize the schedule around this. Give priority to tasks on the critical path.
E.g., start them early and put the best people on them. Originally CPM was done with pencil and paper, but nowadays this kind of task is automated by any number of PM software packages
Again, the notion of critical path is more important on large, pipelined projects with a revolving-door cast
13 / 66
CPM Process
Starting from the network of activities, durations, and dependencies, Identify the critical path Calculate the slack times Determine the Early Start (ES) and Early Finish (EF) for each activity: the earliest time the activity could be started/nished, given its dependencies Determine the Late Start (LS) and Late Finish (LF) for each activity: latest time activity could be started/nished without aecting the project nish date
14 / 66
Resource leveling
Initial schedule based only on dependencies between tasks; might require 4 developers in month 1, 8 developers in month 2, and 12 developers in months 3-5, and 4 developers in month 6
But: have at most 7 developers available!
Resource leveling is the process of adjusting the schedule to conform to the available resources. This will require moving tasks around, adjusting dates, etc. to achieve a constant level of resource usage. Some PM software will do these adjustments automatically, but: the software does not know the team, their strengths and weaknesses, so it may reassign tasks in inadvisable ways.
15 / 66
PERT I
PERT = Program Evaluation and Review Technique Acknowledges that duration estimates are uncertain: durations are treated as random variables drawn from a beta-distribution Start with 3 estimates of task durations:
Optimistic (p=0.05) Most likely (modal) Pessimistic (p=0.95)
These are used to calculate condence intervals for milestone and project end dates.
16 / 66
PERT Duration
Source: PMBOK
17 / 66
PERT Formulas I
Completion time along critical path: if there are enough activities, the distribution of T = T1 + T2 + + Tk (where Ti are the task durations on the critical path) converges to a normal distribution (central limit theorem). The variance of the distribution can be calculated from the variances of the individual distributions:
2 2 2 2 = 1 + 2 + + k
18 / 66
PERT Formulas II
The PERT Weighted Average is used to assign a nominal duration to a task: Weighted Average = 1 6 (a + b + 4m) where a, b, m are the optimistic, pessimistic, and most likely.
19 / 66
Distribution calculation/simulation
Given distributions for each tasks duration, it is possible to calculate numerically the distribution of completion dates:
Sums of random variables convolve pdfs Maximum of the completion times of several tasks order statistics
Or, one can estimate the distribution by carrying out a Monte Carlo simulation of the schedule: repeatedly sample the beta distributions, compute the nishing time. Some software packages will do Monte Carlo simulations of schedules. Can be useful when schedule is very constrained/tricky.
20 / 66
Beware the mythical man-month
Fred Brooks, The Mythical Man-Month When schedule slippage is recognized, the natural response is to add people, which is like dousing a re with gasoline. The bearing of a child takes nine months, no matter how many women are assigned.
21 / 66
General scheduling recommendations I

Small projects:
Some degree of planning and scheduling is important: e.g., if you have a prioritized list of what needs to be done and what the dependencies are, you can focus your eorts on the things that are critical to success. Without a plan, there is a tendency to ail around writing code that is unnecessary (e.g. gold-plating) or requires later rework
Medium projects: some degree of scheduling is important for planning, communicating, tracking progress. Large projects: scheduling is much more important. More likely to have a revolving-door cast of experts with time constraints, lots of $ at stake, etc.
22 / 66
General scheduling recommendations II
Almost nobody does scheduling by hand. For small-medium projects, some open-source tool or spreadsheet might be sucient. For large projects, there are many PM software packages available that can be used to create, maintain, and optimize schedules.
23 / 66
Sources
Anne Pidduck QSPM (Futrell, Shafer, Shafer)
24 / 66
Part II Project Control
25 / 66
Project Control
An ongoing eort to keep your project on track To have good control, you need a good plan Controlling a project entails four primary activities:
Planning performance: e.g. schedule Measuring state of the project (e.g., how much work has been completed?) Comparing to baseline If needed, take corrective action
26 / 66
Project Control Principles

Work is controlled, not workers. Control of the project benets developersprojects that spiral out of control can turn into death march projects. Control is based on work completed, not impressions/conjectures about project state Balance: nd an appropriate amount of control, not too much or too little
Too much control: process-heavy, onerous Too little: the project is not visible enough, and can slip away without anyone noticing until its too late
The eort required to correct a project that is o course increases geometrically with time. (Immutable Laws of Project Management, author unknown)
27 / 66
What is being controlled?
time cost eort change versions/conguration quality scope risk
28 / 66
Part III Controlling Scope
29 / 66
Recall: What is the scope of a project?
The scope denes what the project is and is not about. Want crisp boundaries; a clear statement you can point to and say Thats out of scope. In dening the scope, try to uncover hidden assumptions that stakeholders may have but are not articulating Often stated as
inclusions; exclusions.
30 / 66
Example: Scope I
From [1] The project is: for internal use; a timesheet data-entry system; web-based; for the engineering departments use; The project is not: intended for use by other departments or customers; a labour accounting system; intended to be accessed by PDAs, cell phones; required to interface to other systems.
31 / 66
Controlling Scope I
If a project is allowed to change freely, the rate of change will exceed the rate of progress. (Immutable Laws of Project Management, author unknown) Scope creep is a frequent cause of projects spiraling out of control.
32 / 66
Controlling Scope II
Essential ingredients for controlling scope:

1. A clear denition of scope in the Software Project Management Plan (SPMP) that all the stakeholders have signed o on. 2. A willingness to say No. (But diplomatically.) 3. Well-dened change control process outlined in the SPMP. Want a fair process that will make good decisions.
33 / 66
A project without a clear denition of scope
Stakeholder: The demo of the time-tracking system was nice. Next time can we see a demonstration on handheld devices? PM: We werent planning on providing a handheld interface. Stakeholder: What? But how are we supposed to track our time when were away from our desks? Without handhelds, the system is useless!
34 / 66
A project with a clear denition of scope
Stakeholder: The demo of the time-tracking system was nice. Next time can we see a demonstration on handheld devices? PM: No, thats out of scope. You signed o on the scope denition when the project was approved. (Undiplomatic!)
35 / 66
A project with a clear denition of scope

Stakeholder: The demo of the time-tracking system was nice. Next time can we see a demonstration on handheld devices? PM: I can see how a handheld device interface would be useful. Hmm. The scope of this project was to build a web-based timesheet data-entry system for internal use. The projects schedule and budget are based on that scope. To include a handheld interface, we would need to re-plan and re-budget the project and get the changes approved. We can proceed with that if you like, or we could stick to the original plan for now, and start thinking about a handheld device interface as an add-on project. What do you think?
36 / 66
Change Control Board (CCB) I

A committee that decides whether proposed changes should be included Typical membership would include:
Stakeholder representatives Executive sponsors Project manager QA, Marketing, Support...
The CCB analyzes the change request:

Rationale Importance/priority Cost Benet
and decides what action to take, if any.
37 / 66
Valid reasons for changes
Source: Simon Wallace Business needs have changed Organization has changed (restructuring, acquisition, new leaders, etc.) Technology has improved Organizational priorities have changed New legislation/regulations/standards Responding to changes in other, related projects Original requirements/scope were awed.
38 / 66
Change Control Board I

The CCBs primary responsibility is triage: given the scarce development resources, schedule pressures, etc., should the change be accommodated? Possible decisions:
Turn down the change request: too costly, out of scope, not critical. Put change request in a low-priority queue to be addressed if the project nishes early (good chance this is a No.) Put the change request in the requirements for the next release. The change is minor, has a compelling rationale, and can be accommodated without impacting the schedule or budget approve. Accommodate the change by taking something of equivalent complexity out of the project
39 / 66
Change Control Board II
Accommodate the change, and re-plan (budget, schedule). Possibly pass on to an executive level steering committee for decision.
Beware setting up a ponderous bureaucracy that will dither.
40 / 66
Example change control process
Source: Simon Wallace

41 / 66
Example change control process
42 / 66
Example workow for CCB

Source: Stellman & Greene 1. Change request is submitted. 2. A CCB member (e.g., a tester) who is familiar with the project reads and claries the request. 3. The CCB member meets with the PM to explain the request and its signicance. Together they identify project team members whose work will be impacted, and work with them to evaluate the impact. The PM updates the change request to reect that evaluation. 4. At the next CCB meeting, the PM presents the change request and its expected impact. The CCB does a cost-benet analysis. The CCB rejects or approves the change. 5. If approved, the PM updates the project plan to reect the change.
43 / 66
Automated change control processes
Some project-management software packages have built-in support for change control E.g., web form for initial request, gets automatically sent to appropriate people in the change control process for action. In some elds this is known as ECR/ECN (Engineering Change Request/Notice) software.
44 / 66
Conguration Management
Also known as Software Conguration Management (SCM) Encompasses change control + version control Identifying work products, controlled storage of them, change control, and status reporting of intermediate work products Not just code, but also requirements + design changes, releases, documentation, etc.
45 / 66
Terminology
Software Conguration Control Item (SCCI)

Anything suitable for conguration control Source code, documents, diagrams, and so on a.k.a. Source Item (SI)
Conguration metadata
Data about SCCI items and their relationships E.g., version history, reasons for changes, etc.
46 / 66
Version & Revision Control I
Version Control
Controlling software version releases Recording and saving releases Documenting dierences between releases
Revision Control/Source Code Management

Fine-grained control of changes to SCCIs Detecting & resolving conicts, branching/forking, merging branches, cryptographically signed assertions that e.g. a branch passed QA Software tools: CVS, Subversion, monotone, git, BitKeeper, etc.
47 / 66
Version & Revision Control II
gitk
48 / 66
Version & Revision Control
More sophisticated software tools will take action based on revisions:

Notifying other developers whose work could be aected Flagging the revision for testing Automatically starting regression testing
Example: CATIA PLM http://www.3ds.com/flashgallery/ vpm-navigator-improvements/ http://www.3ds.com/flashgallery/ relational-design-boosts-innovation/
49 / 66
Branches
On a large project, revision control is often hierarchical. Large projects usually consist of smaller teams of e.g. 4-6 people. At the same time, the project might have:
A series of release versions that represent previously released versions of the software. A release candidate branch, which is very stable and is being prepared for release. No major changes are accepted. A development version to which major changes are committed by teams Each team might have their own team branch to which team members commit their changes. This allows them to work in parallel with other teams. At intervals, this working branch is merged with the development version. Each individual has one or more sand-boxes where they are modifying and testing the code. These sand-boxes are eventually merged with the team branch.
50 / 66
Conguration Management Needs
Clearly dened management authority Established procedures and guidelines known to the entire team Appropriate tools + infrastructure The Conguration Management Plan (part of the SPMP) outlines how SCM will happen.
51 / 66
Release Management
Projects that are issuing periodic releases of the software will often have a release manager whose job it is to oversee the release process Typically, the release manager maintains a release candidate branch that is being rened toward a stable, usable state. They oversee testing, defect correction, acceptance testing, release numbering, and deployment of the release. They might also oversee beta-testing programmes.
52 / 66
Progress Monitoring I
Goal of progress monitoring is to compare where the project is to where it ought to be, according to the plan Progress monitoring is only useful if you have a plan! Based on progress status, might decide to ignore it, take corrective action, adjust the plan. Widely believed that the longer action is delayed in correcting a project, the more costly (and embarrassing) it will be
Take action immediately, regardless of embarrassment
53 / 66
Progress Monitoring II
Monitoring rates:
Daily, weekly, monthly Might have one or more problem areas under close scrutiny with frequent monitoring
54 / 66
Status Reports
From team(s) to the PM From PM to stakeholder Some software tools will automatically generate status reports, and/or provide an instantaneous project dashboard. Often status reports are updated weekly, more frequently during crises
55 / 66
Stakeholder status report
Executive summary Accomplishments for the period: tasks, milestones, metrics Plans for the next period Risk analysis & review Issues/change requests and actions taken
56 / 66
Programmer Status Reporting
Projects progress rapidly until they are 90 percent complete. Then they remain 90 percent complete forever. (Immutable Laws of Project Management) If a programmer reports completing 4000 LOC of an estimated 5000 LOC, what does this mean? WBS to the rescue:
Use binary reporting: a work package (task) is either complete, or incomplete. Use a ne-grained WBS, so that programmers can nish 1-5 work packages per week. Have a well-dened completion criteria for work packages
57 / 66
Earned Value Management (EVM) I
A popular technique for progress monitoring that combines technical, schedule, and cost performance Planned work is assigned a value, called Planned Value (PV) Metrics are used to measure progress, and are used to calculate Earned Value (EV), which represents the value of the work accomplished so far
EV = sum of PV for all the completed work packages
Actual Cost = cost of the development eort so far (salary, overhead, equipment, etc.)
58 / 66
Earned Value Management (EVM)
Was the project over-budget in the beginning, and under-budget after week 5? Source: Garry Booker/Wikipedia
59 / 66
Project was ahead of schedule in the beginning, but fell behind after week 6. Source: Garry Booker/Wikipedia
60 / 66
Plotting the EV against the AC shows that the project was under-budget relative to the amount of work accomplished. Source: Garry Booker/Wikipedia
61 / 66
Typical EVM chart showing EV, PV, and AC. Source: Garry Booker/Wikipedia
62 / 66
SV: Schedule variance = EV-PV CV: Cost variance = EV-AC Negative values are unfavourable.
63 / 66
Earned Value Management
Benets:
Consistent unit of measure for total progress Forecasting of cost and schedule Expresses project status in terms of value to the business (good for reporting) Can provide early warning of schedule or cost variance
Success factors:
Need a reasonably detailed WBS Need reasonably accurate estimates
64 / 66
65 / 66
Bibliography I
[1] Robert T. Futrell, Donald F. Shafer, and Linda I. Shafer. Quality Software Project Management. Prentice-Hall, 2002.
66 / 66
Chapter 8
Risk ManagementCommon risksRisk analysisPsychology of RiskRisk denialSoftware Risk Management
437
SE362 Lecture 8: Risk Management Todd Veldhuizen tveldhui@acm.org
SE362 Lecture 8: Risk Management

June 3, 2008
1 / 45
Sources
McConnell [3], Chapter 5 Anne Pidduck
2 / 45
Risk Management I
Summary: avoid disaster by anticipating problems Levels of risk management (Pressman):

1. Crisis management: ght res after risks turn into full-blown problems 2. Fix on failure: early detection and quick reaction when risks materialize 3. Risk mitigation: have contingency plans, but do nothing to eliminate them in the rst place 4. Risk prevention: identify risks and prevent them from becoming problems 5. Elimination of root causes: remove factors that make risks possible
3 / 45
Top project risks (Capers Jones, 1994)
MIS projects:
Creeping requirements Excessive schedule pressure Low quality Cost overruns Inadequate conguration control
Commercial:
Inadequate user documentation Low user satisfaction Excessive time to market Harmful competitive actions Litigation expense
4 / 45
Most common schedule risks (McConnell)

Feature creep Requirements or developer gold-plating Shortchanged quality Overly optimistic schedules Inadequate design Silver-bullet syndrome Research-oriented development Weak personnel Contractor failure Friction between developers and customers
5 / 45
Risk assessment + control

The project should adopt a proactive risk management strategy. This is often formalized as a Risk Management Plan, often part of the PMP. Risk Assessment
Risk identication: produce list of risks that could plausibly disrupt the project schedule Risk analysis: assess the likelihood and impact of each risk, and the risk of alternative practices Risk prioritization: produce a list of risks prioritized by impact.
Risk Control
Risk-management planning: a plan for dealing with each signicant risk. Risk resolution: execution of the risk management plans Risk monitoring: monitoring progress toward resolving each risk item.
6 / 45
Story time
McConnell p. 103
7 / 45
Types of risks
Schedule risks: overly optimistic schedule, facilities are not available on time, delays in approval Cost risks: unreasonable budget, volatility in hardware prices Numerous others: requirements, technical, political, legal, regulatory, market, social... many of these in turn cause risks to schedule or cost.
8 / 45
Identifying Risks
A team activity: more people think of more things that can go wrong Easy way: consult a table of common risks, and see which ones pertain McConnell [3] Ch. 5 has an exhaustive table of schedule risksa good starting point. McConnell Classic Mistakes Futrell [1] has a long table of risks, somewhat broader than McConnells.
9 / 45
Risk analysis I
Aim is to characterize each risk by:

Probability of occurring Associated loss (money, time, life, reputation, etc.) Manageability: what actions could control the risk?
Risk Exposure (RE): product of probability and potential loss

E.g. Facilities not ready on time: decide on a probability of 25%, delay of 4 weeks: RE = 1 week E.G. Inadequate design: probability 15%, delay of 10 weeks, RE = 1.5 weeks Sum of REs gives expected total schedule loss due to risks
10 / 45
Risk analysis II
Estimating size of loss: can use WBS-like approach + estimation Estimating probability of loss: tricky
Use a group process A gambling analogy: How much would you bet? Use adjective calibration: highly likely, probably, improbable, unlikely, highly unlikely Humans are notoriously terrible at subjective risk assessment
11 / 45
Activities entailing the same risk exposure
9, 520 km of private plane passenger travel 66, 000 km of automobile driving 110, 600 km of railroad passenger travel 1, 204, 000 km of airline passenger travel 1800 cigarettes smoked (90 packs) 54 days of WWII military service 4.9 births, mother 37 hours of mountain climbing in U.S. (1951-1960)
12 / 45
Risk prioritization
Aim is to identify the risks that are most likely to have impact. Might sort by Risk Exposure (RE), or probability Helps to identify which risks can be ignored (those at the bottom)
13 / 45
Risk Control
Risk management plan: might be part of PMP, or a separate document Possibly just one paragraph per risk.
14 / 45
Psychology of Risk I
Perceived risk depends on culture, personality, gender, organizational aliation, mood, and framing [4, 5].
In the U.S., a signicant subgroup of well-educated, conservative, white men perceive risks as very low (the white male eect.) Toxicologists in industry perceive chemical risks as lower than toxicologists in academia. In a gambling scenario, students in the U.S. and the Netherlands placed greater weight on the probability of losses, and students in Hong Kong and Taiwan place greater emphasis on magnitude of losses.
We tend to overestimate small risks, and underestimate big risks [5].
15 / 45
Psychology of Risk II
People treat risk very dierently if they are asked to rate the risk to themselves vs. the risk to others (risk denial) [5]. This suggests that in risk estimation, it may be helpful to frame the risk question by viewing it as something that could happen to another team of developers. Risk denial is more likely for risks that we have control over (i.e., the more control we feel we have over a risk, the less risky we tend to rate it.) People will accept risks voluntarily that are 1000 times greather than those they would accept if subjected to without choice (e.g. driving a car vs. nuclear accident.) Some relatively minor risks (statistically speaking) cause massive public reactions, resulting in major social and economic impacts (social amplication of risk) [2].
16 / 45
Psychology of Risk III

Asymmetry between gains and losses:
Risk-averse with respect to gains e.g. people prefer to keep their $10 (a sure thing) rather than buy a ticket for a rae, even if the expected gain is higher buying a ticket Risk-seeking with respect to losses (e.g. insurance). People tend to be optimistic and hope for the best, rather than sacricing a little (insurance premium) to avoid possible catastrophic losses.
Software risks involve losses people tend to be risk-seeking (e.g. hope for the best rather than sacrice some planning/prototyping time)
17 / 45
White-male eect
Source: Flynn et al. (1994)

18 / 45
Risk denial: It couldnt happen to me
From [5].
19 / 45
Risk denial
From [5].
20 / 45
Risk denial and perceived control
From [5].
21 / 45
Part I Software Risk Management
22 / 45
SEI Risk Management Activities
23 / 45
SEI Risk Management: Principles

1. Global perspective: consider the project in its larger system context. 2. Forward-looking view: think ahead to identify uncertainties + risks + possible outcomes. 3. Open communication: encourage free ow of information between all levels of the project; value the input of individuals to the risk management process. 4. Integrated management: make risk management an integral part of PM. 5. Continuous: risk management is a continuous, ongoing part of the project. Identify + manage risks throughout the life cycle. 6. Shared product vision 7. Teamwork
24 / 45
Whittaker KPMG Study I

1997 survey of IT project management issues. Questionnaires to 1450 public and private sector organizations in Canada (176 responses) [6]. Three most common reported reasons for project failure:
1. Poor project planning, specically, inadequate risk management and a weak project plan. 2. Weak business case. 3. Lack of top management involvement and support.
Other signicant causes: schedule overruns, using new or unproven technology, poor estimates, weak requirements, vendor failure. Failure modes:
Overran schedule: 90% Overran budget: 55% Did not demonstrate planned benets: 45%
25 / 45
Whittaker KPMG Study II

Risk management is more important in big organizations, and in big projects Four most common risks not addressed as part of the project planning process:
Schedule slippage (73%) Change in scope (51%) Cost overruns (45%) Change of key personnel (38%)
Four most common deciencies in project plans:

Incorrect estimates (63%) Incorrect assumptions about resource availability (52%) Inadequate assignment of activity accountabilities (51%) Missing or incomplete review and approval activities (47%)
26 / 45
Risk management I
Risk Assessment
Identify Analyze Prioritize
Risk Control
Plan Resolve Monitor
27 / 45
Risk management II
Schedule risks Cost risks Others: requirements, technical, political, ... usually indirectly cause risks to schedule or cost
28 / 45
Risk management III
Risk analysis: estimate

Probability of occurring (likelihood) Associated loss (consequence) Manageability
Risk Exposure (RE): product of probability & potential loss Sum of REs gives expected total schedule/budget loss due to risks
29 / 45
Risk Reporting Matrix
Source: SEI
30 / 45
Risk Prole
Risk Prole = graph of Risk Exposure over the lifetime of the project Want this prole to be as at as possible as quickly as possible: resolve risks early Tom Gilb: If you dont actively attack the risks, they will actively attack you.
31 / 45
Risk Planning Meeting
A meeting for risk planning. Maybe occur at regular intervals throughout the lifecycle. Goal: identify, analyze, and prioritize risks; build a risk plan.
32 / 45
Identifying Risks
Brainstorming Checklists
McConnell Ch. 5 has a long list of possible risks SEI Risk taxonomy
33 / 45
Analyzing risks I
Want to identify both the probability of the risk, and the consequences if it materializes Can use Level 1 2 3 4 5 scales to assess probabilities: Likelihood Probability Not Likely 0.1 Low Likelihood 0.3 Likely 0.5 Highly Likely 0.7 Near Certainty 0.9
34 / 45
Analyzing risks II
Betting method suggested by McConnell: if I am willing to wager $ 100 that X happens, and you are willing to bet $ 500 that X doesnt happen, then estimate probability of X at 100/(100 + 500) = 1/6. (Somewhat dubious method, would need careful calibration of odds oered to actual risk.)
35 / 45
Analyzing risks III

Scales to assess consequences: look at possible eect on technical performance, schedule, & cost. Agree to a scale before risk meeting.
Level 1 2 3 4 5 Technical Performance Minimal Minor Moderate Signicant, may jeopardize success Major risk of failure Schedule Minimal Can still meet milestones Uses up all buer Slip < 2 months Slip > 2 months Cost Minimal < 1% budget < 5% budget < 10% budget > 10% budget
Delphi process: after brainstorming, have everyone estimate the probability & consequences individually, then meet to discuss and reach a consensus.
36 / 45
Prioritization
Example of a prioritized risk table [3]: Risk Prob. Weeks RE (Weeks) Features added 0.35 8 2.8 Overly optimistic 0.5 5 2.5 schedule Redesign required 0.15 15 2.25 New tools do 0.3 5 1.5 not deliver ... Summing the Risk Exposure (RE) values gives an estimate of how much time the project can expect to lose due to risks. This should be taken into account when scheduling, e.g., you should have a project-wide buer of comparable size.
37 / 45
Risk Planning/Resolution I
For each signicant risk identied, want to come up with a management plan. General aim is to
Get risk o the critical path if possible Resolve risks early
Possible strategies:
Redesign the project to omit the risky area. Investigate the risk. E.g., if you are unsure if an idea will work, invest some time in prototyping it. If youre not sure a technology will perform acceptably, then start benchmarking it early on and have a backup plan. (But: this only makes sense if the cost of investigating is the RE.) Eliminate the root cause. E.g. if a major risk is contractor failure on a critical component, then reorganize the task assignment so that the contractor works on a less critical component, or nd a contractor you have reason to trust.
38 / 45
Risk Planning/Resolution II
Assume the risk. If the consequences are minor, unpreventable, etc. then perhaps the best course of action is to do nothing at all. Publicize the risk. Communicate to client, upper management what the risky elements of the project are, so they are not blindsided if they materialize.
39 / 45
Discussion
What strategies would you suggest for managing these common risks? Contractor failure Vendor failure (e.g., delivering buggy beta software) Feature creep Overly optimistic schedule Inadequate design Weak business case Lack of top management involvement and support Use of new or unproven technology Change of key personnel
40 / 45
Top-10 Risks List
McConnell suggests maintaining a Top-10 Risks List throughout the project. For each risk, describe the risk, what progress has been made in resolving the risk, its rank and how many weeks it has been on the list.
41 / 45
Story Time
p. 103 McConnell
42 / 45
Part II Bibliography
43 / 45
Bibliography I
[1] Robert T. Futrell, Donald F. Shafer, and Linda I. Shafer. Quality Software Project Management. Prentice-Hall, 2002. bib [2] Roger E. Kasperson, Ortwin Renn, Paul Slovic, Halina S. Brown, Jacque Emel, Robert Goble, Jeanne X. Kasperson, and Samuel Ratick. The social amplication of risk: A conceptual framework. Risk Analysis, 8(2):177187, 1988. bib pdf [3] Steve McConnell. Rapid Development: Taming Wild Software Schedules. Microsoft Press, 1996. bib pdf
44 / 45
Bibliography II
[4] B. A. Mellers, A. Schwartz., and A. D. J. Cooke. Judgment and decision making. Annual Review of Psychology, 49(1):447477, 1998. bib
pdf
[5] Lennart Sj oberg. Factors in risk perception. Risk Analysis, 20(1):112, 2000. bib pdf [6] Brenda Whittaker. What went wrong? Unsuccessful information technology projects. Inf. Manag. Comput. Security, 7(1):2330, 1999. bib
pdf
45 / 45
Chapter 9
MetricsMetrics fallaciesGoal-Question-Metric paradigmGamingPrivacyAutomationModel ttingPareto principlesRoyces Seven
483
SE362 Lecture 9: Metrics Todd Veldhuizen tveldhui@acm.org
SE362 Lecture 9: Metrics

June 5, 2008
1 / 80
Alan Kay
Distinguished lecture: Thursday June 12, 4:30pm, Theatre of the Arts GUIs, Smalltalk, Dynabook, OOP, etc.
2 / 80
Assigned reading I
Eective Use and Misuse of Performance Measurement, Burt Perrin [14] In Poland under communism, the performance of furniture factories was measured in the tonnes of furniture shipped. As a result, Poland now has the heaviest furniture on the planet. [14] (apocryphal?)
3 / 80
Software Metrics I
A metric is a system of measurement. Software metrics aim to measure something about a projects state Metrics can be used for many purposes:
determining if a project is on track identifying error-prone modules assessing productivity ...
4 / 80
Software Metrics II
Some common metrics:

Source Lines of Code (SLOC) Bugs per SLOC SLOC per developer-month Coverage Code churn Estimation accuracy
5 / 80
Software Metrics III
Many important things are dicult to dene/measure:

Productivity Morale Depth of understanding of problem domain Design quality Defect density Code maturity Code decay
Instead we need to be content with measuring quantities that only give indirect information.
6 / 80
Software Metrics IV
Example: three teams set out to implement a document management database for an organization.
1. Team A uses an existing RDMS, Acrobat, etc. supplemented with 50,000 lines of C++ code. (3 people; 2 months) 2. Team B spends a month evaluating the major commercial document management packages. They choose one they feel is mature and suitable, and spend another month installing and conguring it, and writing 5000 lines of scripting code. (3 people; 2 months) 3. Team C looks at the ROI of implementing a document management database, and decides that by making minor business process changes and investing in a better paper ling system, they can deliver the same productivity benets as a document management database and save $500,000.
Which team was most productive?

7 / 80
Robert McNamaras Vietnam I
8 / 80
Robert McNamaras Vietnam II
Scholars analyzing the Vietnam War frequently argue that the United States Armys xation on body countsthe number of enemy deadplayed a major role in contributing to Americas failure to win against a third world nation with considerably fewer military forces... On the basis of the number of enemy killed, ocers and units were rewarded by promotions, medals, and time o from eld duty. [?].
9 / 80
Metrics fallacies
Metrics must be approached with caution: dont mistake the metric for the real thing you want to assess (e.g. mistaking SLOC/developer-month for productivity) Avoid fallacies:
reication fallacy: treating some abstract measure (e.g., SLOC/month) as if it were the central concern quantication fallacy: believing that all progress and decisions can be reduced to number problems
If youre going to use metrics, use them thoughtfully and deliberately.
10 / 80
Goal-Question-Metric (GQM) I
Developed by Victor Basili, part of CMM level 2 Aims to choose metrics that support specic, quantiable goals. Set goals
Customer satisfaction On-time delivery Improved quality Improve reuse Reduce average time to resolve a defect report
11 / 80
Goal-Question-Metric (GQM) II
Develop questions that characterize the goals

What is the distribution of satisfaction/dissatisfaction among the customers? What is our average project overrun? What is the average defect density? MTTF? What percentage of our code is reused? What is our average time to resolve a defect request?
12 / 80
Goal-Question-Metric (GQM) III
Then determine metrics needed to answer the questions:

For each customer, do a follow-up at 1-month, 3-month, and 12-month intervals and ask them if they are very satised/satised/dissatised/deeply dissatised with the product, and solicit feedback. For each project, record the initial scheduled completion date and the nal completion date. Calculate average overrun in months and %, on a quarterly basis.
13 / 80
Metrics for measuring Projects
Project cost Development time Consumption of other resources Rate of requirements changes From these, one can calculate Adherence to schedule (e.g. earned value analysis) Adherence to budget
14 / 80
Metrics for measuring Products

Source lines of code (SLOC) Number of test cases Number of unresolved/resolved defects Number of action items Mean time to failure Code churn (amount of rework) Number of failed builds From these, one can sometimes predict Total LOC for the project Software quality Total number of defects
15 / 80
Metrics for measuring People
Number of sta Experience Eort expended, and distribution of eort among activities LOC/month (danger)
16 / 80
Gaming I
Youll get what you measure, or Be careful what you wish for. Metrics programs run the risk of optimizing just the factors they measure, at the expense of things they dont. E.g., if you base performance reviews in part on programmers SLOC/month, they will have an incentive to produce more SLOC/month, but possibly at the cost of spending less time on design, QA, coordination, etc. If you base performance reviews of project managers in part on average % schedule overrun of their projects, they will gure out a way to avoid schedule overruns.
17 / 80
Gaming II
Need to manage people, not numbers. The kiss of death for a software metrics initiative is to use the data as input into an individuals performance appraisal. Use metrics to understand what is going on, rather than to motivate.
18 / 80
Metrics and privacy
Need to think carefully about what metrics will be disclosed, and to who E.g., number of defects found in testing+review only reported to developer who wrote the module Detailed progress indicators only reported to the team Reported to upper management: actual vs estimated schedule/budget, progress with respect to milestones.
19 / 80
Automated tools for metric collection

The most successful metrics are those that can be collected automatically.
Spend as little time as possible collecting data. Focus on analyzing and understanding data, not collecting it. Best way to understand data is to discuss it with the people involved. Be wary of drawing conclusions from numbers.
Revision control, defect tracking, regression testing, nightly builds, change request trackingall typically automated, and an easy source of data. Numerous sources of metrics tools: search web for software metrics tools
20 / 80
Example: Sourceforge
Source: Sourceforge
21 / 80
Example: Ubuntu
22 / 80
Example: AbiWord
Source: AbiWord project

23 / 80
Example: mining the linux revision history
Source: Mike Godfrey
24 / 80
25 / 80
26 / 80
27 / 80
Example: growth of pine email client
Source: Qiang Tu/Mike Godfrey
28 / 80
Example: growth of X Windows
29 / 80
Example: vim average/median le size
The two largest source les are called misc1.c and misc2.c. Source: Mike Godfrey
30 / 80
Model tting for predictions

With some metrics, there are known models that can be t to predict the future. E.g., number of defects found: one popular model is the Musa-Okumoto model, which has two parameters:
0 Initial failure intensity (=number of failures per cpu/hour, for example) Failure intensity decay parameter
Failure intensity is then treated as (t ) = 0 e (t ) (t ) = 1 ln(0 t + 1) By tting this model to the defects found so far, you can extrapolate into the future to estimate how many defects will be found
31 / 80
Model tting example
Predicting future failures by model tting. Source: S. Y. Kuo
32 / 80
Model tting example
Predicting future failures by model tting. Source: L. Rosenberg & L. Hyatt
33 / 80
Model tting example
Predicting future failures by model tting. Source: R. E. Waterman and L. E. Hyatt.
34 / 80
Example: OpenOce
Source: OpenOce project
35 / 80
80-20 rules
Pareto-style principles: 80% of the eects come from 20% of the causes In software:
80% of the defects come from 20% of the modules 80% of the work is required by 20% of the requirements 80% of the running time is incurred by 20% of the code etc.
A guideline, not a law. Metrics can be useful to identify which modules are error-prone, which requirements are the cause of much work, etc.
36 / 80
Royces seven core metrics [17] I

Management Indicators Work and progress (work performed over time)
Measure plan vs. actual state SLOC, function points, use cases, test cases
Budgeted cost and expenditures (cost incurred over time)

Measure plan vs. actual state Cost per month, full-time sta per month, percentage of budget expended
Stang and team dynamics (personnel changes over time)

Resource plan vs. actuals, hiring rate, attrition rate People per month added, people per month leaving
Quality Indicators Change trac and stability (change trac over time)
Indicates convergence
37 / 80
Royces seven core metrics [17] II

Software Change Orders (SCOs) opened vs closed, by severity and by release/component/subsystem
Breakage and modularity (average breakage per change over time)

Convergence, Software scrap, quality indicator Reworked SLOC per change, by severity, by release/component/subsystem
Rework and adaptability (average rework per change over time)

Convergence, software rework, quality indicator Average hours per change, by severity etc.
Mean time between failures (MTBF) and maturity (defect rate over time)
Test coverage/adequacy, robustnss for use, quality indicator Failure counts, test hours until failure
38 / 80
Bibliography I
[1] Murray R. Barrick, Michael K. Mount, and Timothy A. Judge. Personality and performance at the beginning of the new millennium: What do we know and where do we go next? International Journal of Selection and Assessment, 9(1&2):930, 2001.
[2] Michael Emmett Brady. J. M. Keynes position on the general applicability of mathematical, logical, and statistical methods in economics and social science. Synthese, 76:124, 1988.
74 / 80
Bibliography II
[3]
Avshalom Caspi, Brent W. Roberts, and Rebecca L. Shiner. Personality development: Stability and change. Annual Review of Psychology, 56(1):453484, 2005.
[4] Jan Guynes Clark, Diane B. Walz, and Judy L. Wynekoop. Identifying exceptional application software developers: A comparison of students and professionals. Communications of the Association for Information Systems, 11, February 2003.
75 / 80
Bibliography III
[5] James J. Connolly, Erin J. Kavanagh, and Chockalingam Viswesvaran. The convergent validity between self and observer ratings of personality: A meta-analytic review. International Journal of Selection and Assessment, 15(1):110117, 2007.
[6] K. A. Ericsson and A. C. Lehmann. Expert and exceptional performance: Evidence of maximal adaptation to task constraints. Annual Review of Psychology, 47(1):273305, 1996. [7] Kerry L. Jang, W. John Livesley, and Philip A. Vemon. Heritability of the big ve personality dimensions and their facets: A twin study. Journal of Personality, 64(3):577592, 1996.
76 / 80
Bibliography IV
[8] Oliver P. John, Avshalom Caspi, Richard W. Robins, Terrie E. Mott, and Magda Stouthamer-Loeber. The little ve: Exploring the nomological network of the ve-factor model of personality in adolescent boys. Child Development, 65(1):160178, February 1994.
[9] Oliver P. John and Sanjay Srivastava. The big-ve trait taxonomy: History, measurement, and theoretical perspectives. In L. Pervin and O.P. John, editors, Handbook of Personality: Theory and Research. Guilford : New York, 2nd edition, 2001. [10] Timothy A. Judge, Joseph J. Martocchio, and Carl J. Thoresen. Five-factor model of personality and employee absence. Journal of Applied Psychology, 82(5):745755, 1997.
77 / 80
Bibliography V
[11] Michael K. Mount, Murray R. Barrick, and Greg L. Stewart. Five-factor model of personality and performance in jobs involving interpersonal interactions. Human Performance, 11:145165, 1998. [12] George A. Neuman, Stephen H. Wagner, and Neil D. Christiansen. The Relationship between Work-Team Personality Composition and the Job Performance of Teams. Group & Organization Management, 24(1):2845, 1999. [13] Daniel J. Ozer and Veronica Benet-Martinez. Personality and the prediction of consequential outcomes. Annual Review of Psychology, 57(1):401421, 2006.
78 / 80
Bibliography VI
[14] Burt Perrin. Eective Use and Misuse of Performance Measurement. American Journal of Evaluation, 19(3):367379, 1998. [15] Robert Plomin and Avshalom Caspi. Behavioral genetics and personality. In Lawrence A. Pervin and Oliver P. John, editors, Handbook of Personality: Theory and Research, pages 251276. Guilford Press, 2nd edition, 1999. [16] Rainer Riemann, Alois Angleitner, and Jan Strelau. Genetic and environmental inuences on personality: A study of twins reared together using the self- and peer report neo- scales. Journal of Personality, 65(3):449475, 1997.
79 / 80
Bibliography VII
[17] Walker Royce. Software project management: a unied framework. Addison-Wesley, 1998.
80 / 80
Chapter 10
PersonalityBig Five TraitsPersonality and Job PerformancePersonality and TeamworkGMAExceptional Programmers
529
SE362 Lecture 10: Personality Todd Veldhuizen tveldhui@acm.org
SE362 Lecture 10: Personality

June 10, 2008
1 / 72
Alan Kay
Distinguished lecture: Thursday June 12, 4:30pm, Theatre of the Arts GUIs, Smalltalk, Dynabook, OOP, etc.
2 / 72
Discussion
Suppose you are hiring programmers graduating from university. What criteria would you use to pick people?
3 / 72
What does correlation mean?
Illustration of correlation. Source: Sergey Tarima

4 / 72
Personality I
Personality: prevailing patterns of emotion, behaviour, and thought There are dozens of theories of personality; Myers-Briggs is probably the best known in pop culture Personality type: refers to typologies of personality. Underlying idea that there are distinct types of personalities, in the way that there are types of cultures, buildings, languages.
Jung (Extraversion-Introversion, Sensing-Intuition, Thinking-Feeling) Myers-Briggs (MBTI)
Modern approach is to use empirically-derived traits
5 / 72
Personality II
How to derive personality traits:
Have lots of people ll out questionnaires (self-report inventories) 1=disagree strongly, 5=agree strongly 1. Is talkative 2. Tends to nd fault with others 3. Does a thorough job 4. Is depressed, blue ... If there are, e.g., 44 questions, this gives you a 44-dimensional space; each person is a point in this space. Use principle component analysis (Karhunen-Lo` eve transform) to reduce the number of dimensions while preserving as much information as possible (eigenvectors of covariance matrix).
6 / 72
Personality III
Find that there are about ve major dimensions that

are consistent between self-report vs. reports by others [4] are consistent between self-report vs. observation by trained psychologists [14] are consistent for individuals over time [2] can be replicated more-or-less across languages and cultures (English, Dutch, German, Hungarian, Czech, Chinese, Turkish, Russian, ...)
These are called the Big Five Personality Traits.
7 / 72
The Big Five Trait Taxonomy [14] I

I. Extraversion or Surgency: talkative, assertive, energetic II. Agreeableness: sympathetic, kind, aectionate, good-natured, cooperative, trustful (vs. irritable, suspicious, uncooperative, inexible) III. Conscientiousness: organized, thorough, ecient, responsible, dependable IV. Emotional Stability vs. Neuroticism: stable, calm, contented, unemotional vs. tense, anxious, moody, temperamental, hostile, depressed V. Intellect or Openness: wide interests, intelligent, imaginative, original, insightful, artistic, inventive The last of these does not appear to translate as well across cultures as the rst four. E.g., in a Dutch-language study the Openness factor was more like Unconventionality/Rebelliousness; in a German-language study the factor was more like pure intellect.
8 / 72
The Big Five Trait Taxonomy [14] II
Sometimes these are abbreviated to Openness, Conscientiousness, Extraversion, Agreeableness, Neuroticism (OCEAN). (or, CANOE). These are continuous scales, i.e., think of these as dening a ve-dimensional space. One person might be: Extraversion +0.23 Agreeableness +0.12 Conscientiousness -0.22 Neuroticism -0.12 Openness +0.34
9 / 72
The Big Five Trait Taxonomy [14] III
To avoid conating the extraversion trait (talkative, assertive, ambitious, energetic) with the narrow, literal meaning of the word extraversion, John and Srivastava [14] recommend:
E: Extraversion, Energy, Enthusiasm A: Agreeableness, Altruism, Aection C: Conscientiousness, Control, Constraint N: Neuroticism, Negative Aectivity, Nervousness O: Openness, Originality, Open-Mindedness
10 / 72
Extraversion
From [14]. How personality descriptions from trained psychologists correlated with Big Five traits. High Low -0.83 -0.80 -0.75 -0.71 -0.67 Quiet Reserved Shy Silent Withdrawn 0.85 0.83 0.82 0.82 0.80 0.79 0.64 0.62 0.58 Talkative Assertive Active Energetic Outspoken Dominant ... Adventurous Noisy Bossy
11 / 72
Agreeableness
From [14]. How personality descriptions from trained psychologists correlated with Big Five traits. High Low -0.52 -0.48 -0.45 -0.45 -0.45 ... Fault-nding Cold Unfriendly Quarrelsome Hard-hearted 0.87 0.85 0.85 0.84 0.84 0.82 ... Sympathetic Kind Appreciative Aectionate Soft-hearted Warm
12 / 72
Conscientiousness
From [14]. How personality descriptions from trained psychologists correlated with Big Five traits. High Low -0.58 -0.53 -0.50 -0.49 -0.40 ... Careless Disorderly Frivolous Irresponsible Slipshod 0.80 0.80 0.78 0.78 0.73 0.72 ... Organized Thorough Planful Ecient Responsible Reliable
13 / 72
Neuroticism
From [14]. How personality descriptions from trained psychologists correlated with Big Five traits. High Low -0.39 -0.35 -0.21 0.14 Stable Calm Contented Unemotional 0.73 0.72 0.72 0.71 0.71 0.68 0.64 0.63 ... Tense Anxious Nervous Moody Worrying Touchy Fearful High-strung
14 / 72
Openness/Intellect
From [14]. How personality descriptions from trained psychologists correlated with Big Five traits. High Low -0.74 -0.73 -0.67 -0.55 -0.47 Commonplace Narrow interests Simple Shallow Unintelligent 0.76 0.76 0.72 0.73 0.68 0.64 0.59 0.59 0.59 0.58 ... Wide interests Imaginative Intelligent Original Insightful Curious Sophisticated Artistic Clever Inventive
15 / 72
The Big Five and Heritability

Twin studies [22, 23, 12] have found that there is a substantial genetic inuence on personality Roughly 40-55% of variance is explained by heritability (genetics and/or epigenetics) Correlations found between monozygotic twins (n=123) and dizygotic twins (n=127) raised together [12]:
Trait Monozygotic twins 0.55 0.41 0.37 0.41 0.58 Dizygotic twins 0.23 0.26 0.27 0.18 0.21 Estimated genetic inuence 53% 41% 44% 41% 61%
Extraversion Agreeableness Conscientiousness Neuroticism Openness
16 / 72
The Big Five Inventory
There are various questionnaires you can do online, e.g.

http://test.personality-project.org/ http://www.outofservice.com/bigfive/ http://www.similarminds.com/big5.html
The rst of these is operated by psychology researchers at Northwestern University, and is a bit of work. The second two are fast but I cannot vouch for their quality.
17 / 72
Big Five and Adolescents
In studies of adolescents (12-13 year old boys) [13]: Low Agreeableness and Low Conscientiousness predict juvenile delinquency. Conscientiousness and Openness predict school performance
18 / 72
Big Five and Adolescents
From [13].
19 / 72
Personality and Job Performance [1]

There are two main traits that are thought to correlate positively with job performance in virtually all jobs:
Conscientiousness (organized, thorough, ecient, responsible, dependable) Emotional stability (stable, calm, contented, unemotional)
Conscientiousness appears to be a stronger factor than emotional stability. Indeed, it is hard to conceive of a job where it is benecial to be careless, irresponsible, lazy, impulsive, and low in achievement striving.... Similarly, being anxious, hostile, personally insecure and depressed is unlikely to lead to high performance in any job. [1]
20 / 72
Personality and Absenteeism [15]
Study of nonacademic employees of a large university in the Midwest (n=89) Subjects were 78% women, average age 43.4 years. Absenteeism data collected from university records It appears... that the carefree, excitement-seeking, hedonistic nature of extroverts... led [them] to be absent more... ... the dutiful, rule-bound, and reliable nature of conscientious employees led [them] ... to be absent less.
21 / 72
Personality and Absenteeism
From [15].
22 / 72
Personality and Turnover
Predictors of turnover:
Low scores on emotional stability Low scores on conscientiousness
People with very low emotional stability tend to experience low job satisfaction.
23 / 72
Personality and Training
Predictors of success in training prociency:

Extraversion Openness
24 / 72
Personality and Teamwork
Conscientiousness + emotional stability are thought to inuence success in teamwork [1] Extraversion is related to performance in jobs such as sales and management. Agreeableness is thought to have a positive inuence on teamwork: people who are argumentative, uncooperative, uncaring, disagreeable are likely to have lower ratings of teamwork [16].
25 / 72
Personality and team composition I

Neuman, Wagner, and Christiansen (1999) Team Personality Elevation (TPE) = average personality of team, mean score on Big Five Team Personality Diversity (TPD) = measure of the personality heterogeneity of the team on Big Five
high TPD = heterogeneous on that trait
e.g., a mix of conscientious and non-conscientious: conscientious might view low-conscientious members as freeloaders; low-conscientious might view conscientious as killjoys
low TPD = very homogeneous (e.g., all conscientious extraverts)
26 / 72
Personality and team composition II
Two competing models of teams:

TPD = bad TPD = good: everyone extraverted frequent conicts; personality dierences can be complementary e.g., a few extraverts to run the meetings, some highly conscientious people to keep the project on track.
It appears that diversity of some traits is benecial.
27 / 72
Personality and team composition III
Study method: 82 teams of 4 people (n=328), 76% male. Each team ran a retail department (e.g., electronics, canned goods.) Teams rated on customer service and task completion. Conclusions: performance was positively correlated with
TPE: conscientiousness, agreeableness, openness TPD: extraversion, emotional stability
TPE and TPD predicted 29% of the variance in team performance
28 / 72
Neuman, Wagner, and Christiansen (1999)
From [17].
29 / 72
General Mental Ability I

General Mental Ability (GMA) refers to intelligence, more or less. Measured by standard inventories. GMA and Conscientiousness have been demonstrated to be the two most important predictors of job success:
Translation: People who are smart and hard-working make good employees.
Intelligence predicts performance in school, educational attainment, rate of promotion on the job, income, etc. (Schmidt & Hunter 2000) The correlation between GMA and job performance is:
about 0.70 when performance measured by objective work samples about 0.58 when performance rated by supervisor (skilled jobs)
(a correlation of 1.00 predicts with 100% accuracy.)

30 / 72
General Mental Ability II
GMA is more predictive of job performance than job-specic aptitude tests. Experience is a good predictor of job performance when comparing candidates with 0-5 years of experience; but not a good predictor when comparing candidates with 5+ years of experience (GMA is better.)
31 / 72
Exceptional Programmers
IT managers describe outstanding software developers as:

self-condent highly motivated creative problem solvers good communication skills ability to organize
(Walz and Wynekoop, 1997)
32 / 72
A Study of Exceptional Programmers [3] I
Methodology [3]
Surveyed n=114 IS professionals (oil+gas companies), their managers identied 40 exceptional performers. Surveyed n=119 undergraduate IS and CS majors; identied 18 as exceptional based on GPA Had all subjects complete personality inventories
Personality dierences between exceptional vs. non-exceptional students

High GPA was negatively correlated (-0.53) with extraversion (p=0.015) High GPA was positively correlated (+0.63) with conscientiousness (p=0.018)
33 / 72
A Study of Exceptional Programmers [3] II
Personality dierences between IS vs. CS students

IS students had a mean of +0.255 Extraversion, CS students had a mean of -0.203 (p=0.033)
34 / 72
A Study of Exceptional Programmers [3] III

IS professionals rated as exceptional by their managers
Exceptional IS professionals had mean extraversion score of +0.391, non-exceptional had score of -0.152 (p=0.003) Exceptional had mean conscientiousness score of +0.211, non-exceptional had mean score of -0.082 (p=0.070)
However: NB there was no objective measurement of whether the exceptional professionals performed better
Managers tend to be extraverted themselvesare they equating extraversion with exceptional performance? Extraversion is closely tied to ambition, and correlates strongly with likeability Study did not take into account this confounding factor.
35 / 72
Implications for Hiring I

Select on intelligence
Two stories: p. 11 Blackwell Handbook of Principles of Organizational Behavior
Select on conscientiousness
Conscientious: achievement oriented, hard working, dependable, persistent, responsible, organized, careful, reliable Rely on references.
Select on expertise
Only count experience up to 5 years; anyone with 5+ years of experience is on equal footing. Distinguish between experience (years-on-job) and expertise (expert/exceptional performance) [6]
36 / 72
Implications for Hiring II
Dont use academic performance as a primary criterion; in fact, be wary of screening people based on academic performance. Select on emotional stability
Maybe better phrased as: dont hire people at the very low end of the emotional stability scale (high-strung, moody, insecure, negative, hostile, etc.) Lots of really brilliant people are neurotic Rely on references
For teamwork, hire people with agreeableness
37 / 72
61 / 72
Bibliography I
[1]
Murray R. Barrick, Michael K. Mount, and Timothy A. Judge. Personality and performance at the beginning of the new millennium: What do we know and where do we go next? International Journal of Selection and Assessment, 9(1&2):930, 2001.
[2] Avshalom Caspi, Brent W. Roberts, and Rebecca L. Shiner. Personality development: Stability and change. Annual Review of Psychology, 56(1):453484, 2005.
62 / 72
Bibliography II
[3] Jan Guynes Clark, Diane B. Walz, and Judy L. Wynekoop. Identifying exceptional application software developers: A comparison of students and professionals. Communications of the Association for Information Systems, 11, February 2003.
[4] James J. Connolly, Erin J. Kavanagh, and Chockalingam Viswesvaran. The convergent validity between self and observer ratings of personality: A meta-analytic review. International Journal of Selection and Assessment, 15(1):110117, 2007.
63 / 72
Bibliography III
[5] Aleksander P. J. Ellis, Bradley J. West, Ann Marie Ryan, and Richard P. DeShon. The use of impression management tactics in structured interviews: A function of question type? Journal of Applied Psychology, 87(6):12001208, 2002.
[6] K. A. Ericsson and A. C. Lehmann. Expert and exceptional performance: Evidence of maximal adaptation to task constraints. Annual Review of Psychology, 47(1):273305, 1996. [7] Thomas W. Ferratt, Ritu Agarwal, Carol V. Brown, and Jo Ellen Moore. IT Human Resource Management Congurations and IT Turnover: Theoretical Synthesis and Empirical Analysis. Information Systems Research, 16(3):237255, 2005.
64 / 72
Bibliography IV
[8] Thomas W. Ferratt, Ritu Agarwal, Jo Ellen Moore, and Carol V. Brown. Observations from the front: IT executives on practices to recruit and retain information technology professionals. In SIGCPR 99: Proceedings of the 1999 ACM SIGCPR conference on Computer personnel research, pages 102112, New York, NY, USA, 1999. ACM Press.
[9] Jacqueline N. W. Friedman, Thomas F. Oltmanns, Marci E. J. Gleason, and Eric Turkheimer. Mixed impressions: Reactions of strangers to people with pathological personality traits. Journal of Research in Personality, 40:395410, 2006.
65 / 72
Bibliography V
[10] Brooks C. Holtom, Terence R. Mitchell, Thomas W. Lee, and Edward J. Inderrieden. Shocks as causes of turnover: What they are and how organizations can manage them. Human Resource Management, 44(3):337352, 2005. [11] Leaetta M. Hough and Frederick L. Oswald. Personnel selection: Looking toward the futureremembering the past. Annual Review of Psychology, 51(1):631664, 2000. [12] Kerry L. Jang, W. John Livesley, and Philip A. Vemon. Heritability of the big ve personality dimensions and their facets: A twin study. Journal of Personality, 64(3):577592, 1996.
66 / 72
Bibliography VI
[13] Oliver P. John, Avshalom Caspi, Richard W. Robins, Terrie E. Mott, and Magda Stouthamer-Loeber. The little ve: Exploring the nomological network of the ve-factor model of personality in adolescent boys. Child Development, 65(1):160178, February 1994. [14] Oliver P. John and Sanjay Srivastava. The big-ve trait taxonomy: History, measurement, and theoretical perspectives. In L. Pervin and O.P. John, editors, Handbook of Personality: Theory and Research. Guilford : New York, 2nd edition, 2001. [15] Timothy A. Judge, Joseph J. Martocchio, and Carl J. Thoresen. Five-factor model of personality and employee absence. Journal of Applied Psychology, 82(5):745755, 1997.
67 / 72
Bibliography VII
[16] Michael K. Mount, Murray R. Barrick, and Greg L. Stewart. Five-factor model of personality and performance in jobs involving interpersonal interactions. Human Performance, 11:145165, 1998. [17] George A. Neuman, Stephen H. Wagner, and Neil D. Christiansen. The Relationship between Work-Team Personality Composition and the Job Performance of Teams. Group & Organization Management, 24(1):2845, 1999. [18] Fred Niederman, Jo Ellen Moore, and Susan E. Yager. A view from the SIGCPR conference: what have we learned in this decade? SIGCPR Comput. Pers., 20(4):7589, 1999.
68 / 72
Bibliography VIII
[19] Fred Niederman and Mary Sumner. Decision paths aecting turnover among information technology professionals. In SIGMIS CPR 03: Proceedings of the 2003 SIGMIS conference on Computer personnel research, pages 133142, New York, NY, USA, 2003. ACM Press. [20] Deniz S. Ones, Chockalingam Viswesvaran, and Frank L. Schmidt. Comprehensive meta-analysis of integrity test validities: Findings and implications for personnel selection and theories of job performance. Journal of Applied Psychology, 78(4):679703, 1993.
69 / 72
Bibliography IX
[21] Daniel J. Ozer and Veronica Benet-Martinez. Personality and the prediction of consequential outcomes. Annual Review of Psychology, 57(1):401421, 2006. [22] Robert Plomin and Avshalom Caspi. Behavioral genetics and personality. In Lawrence A. Pervin and Oliver P. John, editors, Handbook of Personality: Theory and Research, pages 251276. Guilford Press, 2nd edition, 1999. [23] Rainer Riemann, Alois Angleitner, and Jan Strelau. Genetic and environmental inuences on personality: A study of twins reared together using the self- and peer report neo- scales. Journal of Personality, 65(3):449475, 1997.
70 / 72
Bibliography X
[24] Jes us F. Salgado and Silvia Moscoso. Comprehensive meta-analysis of the construct validity of the employment interview. European Journal of Work and Organizational Psychology, 11(3):299324, 2002. [25] Frank L. Schmidt and John E. Hunter. The validity and utility of selection methods in personnel psychology: Practical and theoretical implications of 85 years of research ndings. Psychological Bulletin, 124(2):262274, 1998. [26] Cynthia Kay Stevens. Structure interviews to hire the best people. In Edwin A. Locke, editor, The Blackwell Handbook of Principles of Organizational Behavior. Blackwell Publishing, 2004.
71 / 72
Bibliography XI
[27] Jason Bennett Thatcher, Yongmei Liu, Lee P. Stepina, Joseph M. Goodman, and Darren C. Treadway. IT worker turnover: an empirical examination of intrinsic motivation. SIGMIS Database, 37(2-3):133146, 2006.
72 / 72
Chapter 11
Hiring aka Personnel SelectionInterview designImpression ManagementStructured interviewsRetention and TurnoverMotivation and well-being at workHappinessDiurnal mood cycleAffect at workMotivation and Goal SettingSelf-efcacy
579
SE362 Lecture 11: Hiring and retention Todd Veldhuizen tveldhui@acm.org
SE362 Lecture 11: Hiring and retention

June 12, 2008
. .. ..
. . . . . . . . . . . . . . .. .. .. .. .. .. .. .. .. .. .. .. .. ..
. ..
. . . .. .. ..
1 / 56
Alan Kay
Today! Distinguished lecture: Thursday June 12, 4:30pm, Theatre of the Arts GUIs, Smalltalk, Dynabook, OOP, etc.
. .. ..
. . . . . . . . . . . . . . .. .. .. .. .. .. .. .. .. .. .. .. .. ..
. ..
. . . .. .. ..
2 / 56
Review I
Big Five Personality Traits or Five Factor Model: ve principle components of personality that are consistent across languages, cultures, for individuals over time , between self-reports and reports-by-others, have strong genetic component & have predictive power
I. Extraversion: talkative, assertive, energetic II. Agreeableness: sympathetic, kind, aectionate, good-natured, cooperative, trustful III. Conscientiousness: organized, thorough, ecient, responsible, dependable IV. Neuroticism: tense, anxious, moody, temperamental, hostile, depressed V. Openness: wide interests, intelligent, imaginative, original, insightful, artistic, inventive
Dene a continuous, ve-dimensional space: [1, +1]5 in which personality measurements are points.
. .. .. . . . . . . . . . . . . . . .. .. .. .. .. .. .. .. .. .. .. .. .. .. . .. . . . . .. .. ..
3 / 56
Review II
40-60% of these traits are heritable High conscientiousness is correlated positively with how much eort people put into their work (+0.51) and the quality of their work (+0.44) (Mount & Barrick, 1991). General Mental Ability (GMA) or g-factor: basic intelligence. Correlation between GMA and job performance is +0.70 (on objective work samples.) Neuroticism has some negative impacts on work performance, but these eects are relatively weak.
. .. ..
. . . . . . . . . . . . . . .. .. .. .. .. .. .. .. .. .. .. .. .. ..
. ..
. . . .. .. ..
4 / 56
What does correlation mean?
Illustration of correlation. Source: . . Sergey . . . . . Tarima . . . . . .

.. .. ..
. . .. .. .. .. .. .. .. .. .. .. .. .. ..
. ..
. . . .. .. ..
5 / 56
Part I Selecting Personnel
. .. ..
. . . . . . . . . . . . . . .. .. .. .. .. .. .. .. .. .. .. .. .. ..
. ..
. . . .. .. ..
6 / 56
Basic things to look for in hiring
Hiring decisions are probabilistic: when selecting people, you gather evidence that predicts a person will be a good hire. But, no evidence is certain. Prefer people who are intelligent and conscientious. Conscientiousness can be estimated from references. Be cautious about hiring people at the very low end of the emotional stability scale (high-strung, moody, insecure, negative, hostile, etc.) If there is a lot of teamwork, be cautious about hiring people with low agreeableness. Experience: distinguish between no experience and some; but not between some and lots. (Evidence suggests that dierences between 5, 10, 15 years of experience are not good predictors of performance.) Look for expertise (high prociency.)
. .. .. . . . . . . . . . . . . . . .. .. .. .. .. .. .. .. .. .. .. .. .. .. . .. . . . . .. .. ..
7 / 56
What weight should we give to measures? I

Possible ways to select people:

Job experience Reference checks Integrity tests (honesty, predict disruptive behaviors) [14]; tend to measure conscientiousness + agreeableness + adjustment. See discussion in [8]. Age Work sample tests Job knowledge tests GMA tests (intelligence) Peer ratings
. .. ..
. . . . . . . . . . . . . . .. .. .. .. .. .. .. .. .. .. .. .. .. ..
. ..
. . . .. .. ..
8 / 56
85 years of research in personnel selection I
Schmidt & Hunter [18]: survey of meta-analyses combining 85 years of studies into methods for selecting personnel Personnel selection instruments (interviews, references, etc.) are rated in terms of utility increase due to their use:
percentage of increase in output of employees when using the selection method. E.g. if a selection instrument has a utility increase of 25%, this means that people selected using that instrument will be 25% more productive.
General intelligence (GMA/g-factor) is the #1 best predictor of job performance.

Predicts acquisition of job knowledge on the job Predicts performance in job training programs etc. etc.
. .. .. . . . . . . . . . . . . . . .. .. .. .. .. .. .. .. .. .. .. .. .. .. . .. . . . . .. .. ..
9 / 56
85 years of research in personnel selection II
GMA has an average utility increase of 51%. 58% for professional-managerial jobs 56% for high-level complex technical jobs 51% for medium complexity jobs 40% for semi-skilled jobs 23% for completely unskilled jobs.
. .. ..
. . . . . . . . . . . . . . .. .. .. .. .. .. .. .. .. .. .. .. .. ..
. ..
. . . .. .. ..
10 / 56
85 years of research in personnel selection III

Combining a GMA with other selection devices [18]:
Personnel measure Integrity tests Structured employment interviews Work sample tests Conscientiousness tests Job knowledge tests Job try-out procedure Peer ratings Reference checks Unstructured employment interviews Job experience (years) Years of education Graphology (handwriting analysis!) Age % increase in utility 27% 24% 24% 18% 14% 14% 14% 12% 8% 6% 2% 0% 0%
. .. ..
. . . . . . . . . . . . . . .. .. .. .. .. .. .. .. .. .. .. .. .. ..
. ..
. . . .. .. ..
11 / 56
85 years of research in personnel selection IV
These utility measures suggest guidelines of what questions you want to answer through an interview process, and what kind of weight you should give them:

How smart are they? Are they honest, ethical, etc.? How skilled are they? How hard-working? What do their references say?
. .. ..
. . . . . . . . . . . . . . .. .. .. .. .. .. .. .. .. .. .. .. .. ..
. ..
. . . .. .. ..
12 / 56
Why unstructured interviews are poor [19] I
Interviewers are often swayed by stereotypes, consciously or unconsciously (ethnicity, gender, age, weight, etc.) Interviewers dont understand what weight they give to factors: they overestimate the importance of minor cues Interviewers often rely on subjective impressions of interpersonal skills, appearance, cultural t, etc.
Subjective impressions are swayed by impression management tactics used by interviewees
Interviewers form a preliminary impression from resume, then use the interview to gather conrmatory information (conrmation bias)
. .. ..
. . . . . . . . . . . . . . .. .. .. .. .. .. .. .. .. .. .. .. .. ..
. ..
. . . .. .. ..
13 / 56
Why unstructured interviews are poor [19] II
The questions interviewers ask might not be appropriately weighted, e.g. in unstructured interviews, people tend to ask about [17]:

credentials, achievements 15% technical knowledge 0% experience and activities 32% self-evaluative info (strengths and weaknesses, etc.) 48% behaviour descriptions 5%
Results are swayed by interview order (last interviewees rated higher) Tend to have higher standards when there is a large pool of applicants or few positions open Some interviewers do a much better job at personnel selection than others
. .. .. . . . . . . . . . . . . . . .. .. .. .. .. .. .. .. .. .. .. .. .. .. . .. . . . . .. .. ..
14 / 56
Why unstructured interviews are poor [19] III
Conventional, unstructured interviews appear to predominantly assess social skills [17]. First impressions are made unconsciously and are slow to change, even if people are told their rst impression was based on wrong information. People tend to make positive impressions of individuals with narcissistic and histrionic personality disorders [6].
. .. ..
. . . . . . . . . . . . . . .. .. .. .. .. .. .. .. .. .. .. .. .. ..
. ..
. . . .. .. ..
15 / 56
Impression management I
Source: [3]

Impression management = deliberate attempt to create a positive image Self-promotion
Unmerited claims of primary responsibility for successful projects Unmerited claims of value of things for which the candidate was responsible (My software doubled their productivity.) Expressing opinions the interviewee believes will match those of the interviewer Flattering the interviewer
Ingratiation
. .. ..
. . . . . . . . . . . . . . .. .. .. .. .. .. .. .. .. .. .. .. .. ..
. ..
. . . .. .. ..
16 / 56
Impression management II
Defensive tactics
Excuses, justications, apologies for negative outcomes or events
Unstructured interviews swayed by candidates skill at impression management Structured interviews reduce the use of impression management tactics.
. .. ..
. . . . . . . . . . . . . . .. .. .. .. .. .. .. .. .. .. .. .. .. ..
. ..
. . . .. .. ..
17 / 56
Applicants experiences of the interview [19]
Applicants evaluate a job more positively if the interviewer is personable and friendly Applicants rate jobs as more desirable if they have fewer prospects Some evidence that providing realistic information about the job helps applicants self-select out of the applicant pool, avoiding jobs that would make them unhappy increases likelihood of job satisfaction if realistic information given.
. .. ..
. . . . . . . . . . . . . . .. .. .. .. .. .. .. .. .. .. .. .. .. ..
. ..
. . . .. .. ..
18 / 56
Principles for structured interviews I

Structured interviews follow some format that the organization has standardized. Source: [19] Train interviewers: they should

provide helpful information to candidates be warm and and helpful control the ow and sequence of topics: stick to an agenda (applicants view untrained interviewers as less professional & organized)
Develop standard questions & scoring criteria (ask job-relevant questions; avoid conrmation bias) Have interviewers take detailed notes, and score candidates after the interview.
. .. ..
. . . . . . . . . . . . . . .. .. .. .. .. .. .. .. .. .. .. .. .. ..
. ..
. . . .. .. ..
19 / 56
Principles for structured interviews II
Ensure that pre-interview information provided is valid (resumes, test scores, etc.) Ask applicants about their decision processes and criteria, and provide realistic, helpful information. Avoid asking transparent questions that telegraph the answer you want:
How would you say your communication skills are?
Ask follow-up questions. E.g., if the candidate mentions they volunteer with some organization, inquire about

What roles did they hold? What specic things did they do? Ask specic questions about how they worked with other people in the organization.
. .. ..
. . . . . . . . . . . . . . .. .. .. .. .. .. .. .. .. .. .. .. .. ..
. ..
. . . .. .. ..
20 / 56
Survey of IT hiring practices I
Source: survey of 98 senior-level IT managers [4]

Practices used for recruitment: 0=not at all, 3=very important Sourcing (nding people):

Referrals (2.38) Recruiting rms/contractors (2.31) College relationships/Coops and interns (1.79) Networking at professional events (1.56) Internet (1.56) Job fairs (1.32)
. .. ..
. . . . . . . . . . . . . . .. .. .. .. .. .. .. .. .. .. .. .. .. ..
. ..
. . . .. .. ..
21 / 56
Survey of IT hiring practices II
Skill requirements:

Interpersonal + communication (2.61) Technical aptitude (2.61) Business knowledge/skill (2.22) Total work environment, concern for the individual (2.66) Company reputation, visibility, vision (2.45) Availability of new technologies (2.42) Training opportunities (2.36)
Competitive dierentiation in recruiting:
. .. ..
. . . . . . . . . . . . . . .. .. .. .. .. .. .. .. .. .. .. .. .. ..
. ..
. . . .. .. ..
22 / 56
Legal and ethical issues
Do some research rst if you decide to use tests, particularly psychological tests:
APA Joint Committee on Testing Practices http://www.apa.org/science/jctpweb.html Rights and Responsibilities of Test Takers Informed consent, condentiality, ...
Unstructured interviews account for the majority of litigation in the U.S.; followed by GMA, physical ability tests. Sometimes GMA tests are ruled discriminatory R.L. Lowman, The Ethical Practice of Psychology in Organizations (1998): ethics casebook for human resources professionals
. .. .. . . . . . . . . . . . . . . .. .. .. .. .. .. .. .. .. .. .. .. .. .. . .. . . . . .. .. ..
23 / 56
Part II Retention
. .. ..
. . . . . . . . . . . . . . .. .. .. .. .. .. .. .. .. .. .. .. .. ..
. ..
. . . .. .. ..
24 / 56
Retention
Circa 1998, Fortune 500 companies had turnover rates between 25% and 35% for IT workers [12].
. .. ..
. . . . . . . . . . . . . . .. .. .. .. .. .. .. .. .. .. .. .. .. ..
. ..
. . . .. .. ..
25 / 56
The unfolding model of voluntary turnover

Sources: [7, 13] Four paths of voluntary turnover. Paths 1-3 involve a shock (some precipitating event, positive or negative.)
1. Shock follow pre-existing plan leave without considering alternatives or commitment to organization. Job satisfaction is irrelevant. (Spouse moves.) 2. Shock re-evaluation of organizational attachment due to image violations leaves without considering alternatives. (Passed over for promotion and quits.) 3. Shock comparison of job with alternatives leaves. (Unexpected oer from a 100 best places to work for company.) 4. Job dissatisfaction thoughts of leaving job job search departure
Paths 1-3 (shocks) account for 58%-64% of turnover in one study.

. .. .. . . . . . . . . . . . . . . .. .. .. .. .. .. .. .. .. .. .. .. .. .. . .. . . . . .. .. ..
26 / 56
Importance of retention practices

Survey of IT managers [5]
Interesting work Market-anchored compensation Promotion from within Communication by senior management Financial stability Empowerment/Participation Personal dev./training Flexible work/time Monetary rewards/bonuses Financial stability In-house/formal training program Teamwork Bonus/variable compensation Annual traditional performance appraisal 2.69 2.48 2.42 2.28 2.26 2.25 2.24 2.23 2.18 2.26 2.12 2.06 2.03 2.03
. .. ..
. . . . . . . . . . . . . . .. .. .. .. .. .. .. .. .. .. .. .. .. ..
. ..
. . . .. .. ..
27 / 56
Thatchers turnover model
Source: [20]. .
.. ..
. . . . . . . . . . . . . . .. .. .. .. .. .. .. .. .. .. .. .. .. ..
. ..
. . . .. .. ..
28 / 56
Part III Motivation and well-being at work
. .. ..
. . . . . . . . . . . . . . .. .. .. .. .. .. .. .. .. .. .. .. .. ..
. ..
. . . .. .. ..
29 / 56
Happiness
. . . . Source: New York Times .. .. ..
. . . . . . . . . . . .. .. .. .. .. .. .. .. .. .. .. .. ..
. ..
. . . .. .. ..
30 / 56
Happiness I
Source: [15] Two streams of modern research: Hedonic (hee-don-ic) well-being: maximize pleasure, minimize pain.
Subjective Well-Being (SWB)

Life satisfaction Positive mood Absence of negative mood
. .. ..
. . . . . . . . . . . . . . .. .. .. .. .. .. .. .. .. .. .. .. .. ..
. ..
. . . .. .. ..
31 / 56
Happiness II
Eudaimonic/eudaemonic (yoo-duh-mon-ic) well-being: self-actualization; extent to which life activities mesh with deeply held values
Psychological Well-Being (PWB): autonomy, personal growth, self-acceptance, life purpose, mastery, positive relatedness Self-Determination Theory (SDT): 3 basic psychological needs are autonomy, competence & relatedness; fullling these results in well-being, growth, integrity, vitality, etc.
. .. ..
. . . . . . . . . . . . . . .. .. .. .. .. .. .. .. .. .. .. .. .. ..
. ..
. . . .. .. ..
32 / 56
Happiness III
Happiness and personality:
Extraversion + agreeableness are consistently positively correlated with SWB Neuroticism is negatively correlated with SWB Perceive events more favourably Are less responsive to negative feedback More likely to belittle opportunities they dont have
Chronically happy people:

The frequency of positive experiences seems more important than their intensity. Major life events tend to have only temporary eects on SWB.
. .. ..
. . . . . . . . . . . . . . .. .. .. .. .. .. .. .. .. .. .. .. .. ..
. ..
. . . .. .. ..
33 / 56
Happiness IV
Social class + wealth
People in richer nations are happier than people in poorer nations In the developed world, increases in national wealth have not been associated with increases in SWB Within-nation dierences in wealth show only small, positive correlations with happiness Increases in personal wealth do not typically result in increased happiness The more people focus on nancial & materialistic goals, the lower their well-being. Lagom ar b ast. (Enough is best.)
. .. ..
. . . . . . . . . . . . . . .. .. .. .. .. .. .. .. .. .. .. .. .. ..
. ..
. . . .. .. ..
34 / 56
Happiness V
Relatedness: warm, trusting and supportive interpersonal relationships

a basic human need essential for well-being at or near the top of the list of factors that inuence happiness loneliness (absence of relatedness) is reliably correlated with unhappiness people who have more intimate, higher-quality relationships tend to have higher SWB
. .. ..
. . . . . . . . . . . . . . .. .. .. .. .. .. .. .. .. .. .. .. .. ..
. ..
. . . .. .. ..
35 / 56
Happiness VI
Goal pursuit
Feeling competent & condent with respect to valued goals is associated with well-being Progress towards valued goals contributes to well-being Kinds of goals:

Approach goals (attain something) vs. avoidance goals (trying to avoid something) Autonomous/self-endorsed goals vs. heteronomous/extrinsic goals Self-concordant goals: fulll basic needs & aligned with ones true self
Approach goals increase well-being; avoidance goals are negatively linked to well-being. Autonomous goals are linked to well-being. Heteronomous goals have weaker linkage, if any.
. .. ..
. . . . . . . . . . . . . . .. .. .. .. .. .. .. .. .. .. .. .. .. ..
. ..
. . . .. .. ..
36 / 56
Food for thought
Source: The American Freshman surveys, UCLA.
. .. ..
. . . . . . . . . . . . . . .. .. .. .. .. .. .. .. .. .. .. .. .. ..
. ..
. . . .. .. ..
37 / 56
Diurnal mood cycle
Source: David Watson
. .. ..
. . . . . . . . . . . . . . .. .. .. .. .. .. .. .. .. .. .. .. .. ..
. ..
. . . .. .. ..
38 / 56
Aect at work I
Source: [2]
Job satisfaction: a pleasurable or positive emotional state resulting from the appraisal of ones job or job experiences. (Locke) Job satisfaction = work makes you happy
. .. ..
. . . . . . . . . . . . . . .. .. .. .. .. .. .. .. .. .. .. .. .. ..
. ..
. . . .. .. ..
39 / 56
Aect at work II
Work groups tend to develop group aective tone, i.e., consistent emotional states and reactions. Proposed reasons include:

common experiences similarity of work, and interdependence mood regulation norms and rules emotional contagion
. .. ..
. . . . . . . . . . . . . . .. .. .. .. .. .. .. .. .. .. .. .. .. ..
. ..
. . . .. .. ..
40 / 56
Aect at work III
Common inuences on workplace mood include

time of day extent of hassles, task-juggling, etc. organizational justice/injustice spillover from home/personal issues enhances creativity increases helping behaviours, cooperation, reduces aggression condence (self-ecacy) decision quality (?) Some evidence can yield more accurate judgements (dampen optimism?)
. .. .. . . . . . . . . . . . . . . .. .. .. .. .. .. .. .. .. .. .. .. .. .. . .. . . . . .. .. ..
Eects of workplace mood: positive mood

Negative mood
41 / 56
Motivation and goal-setting I
Source: [10] and [9].
Employees reach higher levels of performance when they are given dicult-yet-attainable goals rather than told to do their best. This is one of the most robust ndings in all of industrial/organizational psychology. [16, 11] The higher the goal, the higher the performance. Amount of praise, feedback, participatory decision making, etc. only inuence behavior to the extent that it is involved in goal-setting.
. .. ..
. . . . . . . . . . . . . . .. .. .. .. .. .. .. .. .. .. .. .. .. ..
. ..
. . . .. .. ..
42 / 56
Motivation and goal-setting II
Four principles:
The goal must be challenging and specic.

People adjust their level of eort to goal diculty. Challenging goals facilitate pride in accomplishment. Specicity of goal meaningful feedback Without time limits: high goals improve persistence; with time limits, high goals increase eort. If the goal is set by a manager, it should include a logic and rationale. Otherwise, use participatory goal-setting.
. .. ..
. . . . . . . . . . . . . . .. .. .. .. .. .. .. .. .. .. .. .. .. ..
. ..
. . . .. .. ..
43 / 56
Motivation and goal-setting III
Provide feedback in relation to goals
That which gets measured gets done. Mason Haire In the absence of goals, feedback has little/no eect on performance (empirical evidence.)
. .. ..
. . . . . . . . . . . . . . .. .. .. .. .. .. .. .. .. .. .. .. .. ..
. ..
. . . .. .. ..
44 / 56
Motivation and goal-setting IV
Gain goal commitment

Goal-setting is meaningless without commitment Outcome expectancies are crucial: the outcomes that will result from the goal (raise, promotion, training, ...) Need to maintain/foster sense of self-ecacy (condence/feeling of competence): can be coached. Low self-ecacy: look for reasons to abandon goals High self-ecacy: commit to challenging goals Story: p. 112 Blackwell
Provide resources needed to attain the goal
. .. ..
. . . . . . . . . . . . . . .. .. .. .. .. .. .. .. .. .. .. .. .. ..
. ..
. . . .. .. ..
45 / 56
Cultivate self-ecacy I
Source: [1]

Self-ecacy = feeling of competence Distinct from self-esteem (liking of self) Perceived ecacy of self-managed teams predicts productivity and job satisfaction Self-ecacy predicts entrepreneurship, innovation adoption Low self-ecacy increases job stress: dont feel are up to the job High self-ecacy = unfazed by heavy/challenging workloads
. .. ..
. . . . . . . . . . . . . . .. .. .. .. .. .. .. .. .. .. .. .. .. ..
. ..
. . . .. .. ..
46 / 56
Cultivate self-ecacy II
Sources of beliefs about self-ecacy:
enactive mastery experiences: have succeeded in the past vicarious experiences: looking to models, social comparisons persuasion and social inuence physiological/aective states (mood)
Performance feedback can be an important source of self-ecacy:

highlight capabilities especially in the early stages, feedback can have a huge impact on self-ecacy positive feedback from a credible observer can be powerful
. .. ..
. . . . . . . . . . . . . . .. .. .. .. .. .. .. .. .. .. .. .. .. ..
. ..
. . . .. .. ..
47 / 56
. .. ..
. . . . . . . . . . . . . . .. .. .. .. .. .. .. .. .. .. .. .. .. ..
. ..
. . . .. .. ..
48 / 56
Bibliography I
[1] Albert Bandura. Cultivate self-ecacy for personal and organizational eectiveness. In Edwin A. Locke, editor, The Blackwell Handbook of Principles of Organizational Behavior. Blackwell Publishing, 2004. Arthur P. Brief and Howard M. Weiss. Organizational behavior: Aect in the workplace. Annual Review of Psychology, 53(1):279307, 2002. Aleksander P. J. Ellis, Bradley J. West, Ann Marie Ryan, and Richard P. DeShon. The use of impression management tactics in structured interviews: A function of question type? Journal of Applied Psychology, 87(6):12001208, 2002.
. .. .. . . . . . . . . . . . . . . .. .. .. .. .. .. .. .. .. .. .. .. .. .. . .. . . . . .. .. ..
[2]
[3]
49 / 56
Bibliography II
[4] Thomas W. Ferratt, Ritu Agarwal, Carol V. Brown, and Jo Ellen Moore. IT Human Resource Management Congurations and IT Turnover: Theoretical Synthesis and Empirical Analysis. Information Systems Research, 16(3):237255, 2005. Thomas W. Ferratt, Ritu Agarwal, Jo Ellen Moore, and Carol V. Brown. Observations from the front: IT executives on practices to recruit and retain information technology professionals. In SIGCPR 99: Proceedings of the 1999 ACM SIGCPR conference on Computer personnel research, pages 102112, New York, NY, USA, 1999. ACM Press.
. .. .. . . . . . . . . . . . . . . .. .. .. .. .. .. .. .. .. .. .. .. .. .. . .. . . . . .. .. ..
[5]
50 / 56
Bibliography III
[6] Jacqueline N. W. Friedman, Thomas F. Oltmanns, Marci E. J. Gleason, and Eric Turkheimer. Mixed impressions: Reactions of strangers to people with pathological personality traits. Journal of Research in Personality, 40:395410, 2006. Brooks C. Holtom, Terence R. Mitchell, Thomas W. Lee, and Edward J. Inderrieden. Shocks as causes of turnover: What they are and how organizations can manage them. Human Resource Management, 44(3):337352, 2005. Leaetta M. Hough and Frederick L. Oswald. Personnel selection: Looking toward the futureremembering the past. Annual Review of Psychology, 51(1):631664, 2000.
. .. .. . . . . . . . . . . . . . . .. .. .. .. .. .. .. .. .. .. .. .. .. .. . .. . . . . .. .. ..
[7]
[8]
51 / 56
Bibliography IV
[9] Gary P. Latham. Motivate employee performance through goal-setting. In Edwin A. Locke, editor, The Blackwell Handbook of Principles of Organizational Behavior. Blackwell Publishing, 2004.
[10] Gary P Latham and Craig C. Pinder. Work motivation theory and research at the dawn of the twenty-rst century. Annual Review of Psychology, 56(1):485516, 2005. [11] Edwin A. Locke and Gary P. Latham. Work motivation and satisfaction: Light at the end of the tunnel. Psychological Science, 1(4):240246, 1990.
. .. .. . . . . . . . . . . . . . . .. .. .. .. .. .. .. .. .. .. .. .. .. .. . .. . . . . .. .. ..
52 / 56
Bibliography V
[12] Fred Niederman, Jo Ellen Moore, and Susan E. Yager. A view from the SIGCPR conference: what have we learned in this decade? SIGCPR Comput. Pers., 20(4):7589, 1999. [13] Fred Niederman and Mary Sumner. Decision paths aecting turnover among information technology professionals. In SIGMIS CPR 03: Proceedings of the 2003 SIGMIS conference on Computer personnel research, pages 133142, New York, NY, USA, 2003. ACM Press.
. .. ..
. . . . . . . . . . . . . . .. .. .. .. .. .. .. .. .. .. .. .. .. ..
. ..
. . . .. .. ..
53 / 56
Bibliography VI
[14] Deniz S. Ones, Chockalingam Viswesvaran, and Frank L. Schmidt. Comprehensive meta-analysis of integrity test validities: Findings and implications for personnel selection and theories of job performance. Journal of Applied Psychology, 78(4):679703, 1993. [15] Richard M. Ryan and Edward L. Deci. On happiness and human potentials: A review of research on hedonic and eudaimonic well-being. Annual Review of Psychology, 52(1):141166, 2001.
. .. ..
. . . . . . . . . . . . . . .. .. .. .. .. .. .. .. .. .. .. .. .. ..
. ..
. . . .. .. ..
54 / 56
Bibliography VII
[16] Sara L. Rynes, Amy E. Colbert, and Kenneth G. Brown. HR professionals beliefs about eective human resource practices: correspondence between research and practice. Human Resource Management, 41(2):149174, 2002. [17] Jes us F. Salgado and Silvia Moscoso. Comprehensive meta-analysis of the construct validity of the employment interview. European Journal of Work and Organizational Psychology, 11(3):299324, 2002.
. .. ..
. . . . . . . . . . . . . . .. .. .. .. .. .. .. .. .. .. .. .. .. ..
. ..
. . . .. .. ..
55 / 56
Bibliography VIII
[18] Frank L. Schmidt and John E. Hunter. The validity and utility of selection methods in personnel psychology: Practical and theoretical implications of 85 years of research ndings. Psychological Bulletin, 124(2):262274, 1998. [19] Cynthia Kay Stevens. Structure interviews to hire the best people. In Edwin A. Locke, editor, The Blackwell Handbook of Principles of Organizational Behavior. Blackwell Publishing, 2004. [20] Jason Bennett Thatcher, Yongmei Liu, Lee P. Stepina, Joseph M. Goodman, and Darren C. Treadway. IT worker turnover: an empirical examination of intrinsic motivation. SIGMIS Database, 37(2-3):133146, 2006.
. .. .. . . . . . . . . . . . . . . .. .. .. .. .. .. .. .. .. .. .. .. .. .. . .. . . . . .. .. ..
56 / 56
Chapter 12
Individuals and Small GroupsMotivation and Goal-SettingSelf-efcacyWork groups vs TeamsTrust, Potency, and SafetyTeam DesignBoundary ActivitiesCohesion and BondingGroup DynamicsTransactive MemorySocial LoangIntragroup Conict
636
SE362 Lecture 12: Small groups Todd Veldhuizen tveldhui@acm.org
SE362 Lecture 12: Small groups

June 17, 2008
1 / 44
Part I Motivation
2 / 44
Motivation and goal-setting I
Source: [10] and [9]. Employees reach higher levels of performance when they are given dicult-yet-attainable goals rather than told to do their best. This is one of the most robust ndings in all of industrial/organizational psychology. [12, 11] The higher the goal, the higher the performance. Amount of praise, feedback, participatory decision making, etc. only inuence behavior to the extent that it is involved in goal-setting.
3 / 44
Motivation and goal-setting II
Four principles:
The goal must be challenging and specic.
People adjust their level of eort to goal diculty. Challenging goals facilitate pride in accomplishment. Specicity of goal meaningful feedback Without time limits: high goals improve persistence; with time limits, high goals increase eort. If the goal is set by a manager, it should include a logic and rationale. Otherwise, use participatory goal-setting.
4 / 44
Motivation and goal-setting III
Provide feedback in relation to goals

That which gets measured gets done. Mason Haire In the absence of goals, feedback has little/no eect on performance (empirical evidence.)
5 / 44
Motivation and goal-setting IV
Gain goal commitment

Goal-setting is meaningless without commitment Outcome expectancies are crucial: the outcomes that will result from the goal (raise, promotion, training, ...) Need to maintain/foster sense of self-ecacy (condence/feeling of competence): can be coached. Low self-ecacy: look for reasons to abandon goals High self-ecacy: commit to challenging goals Story: p. 112 Blackwell
Provide resources needed to attain the goal
6 / 44
Cultivate self-ecacy I
Source: [3] Self-ecacy = feeling of competence Distinct from self-esteem (liking of self) Perceived ecacy of self-managed teams predicts productivity and job satisfaction Self-ecacy predicts entrepreneurship, innovation adoption Low self-ecacy increases job stress: dont feel are up to the job High self-ecacy = unfazed by heavy/challenging workloads
7 / 44
Cultivate self-ecacy II
Sources of beliefs about self-ecacy:
enactive mastery experiences: have succeeded in the past vicarious experiences: looking to models, social comparisons persuasion and social inuence physiological/aective states (mood)
Performance feedback can be an important source of self-ecacy:

highlight capabilities especially in the early stages, feedback can have a huge impact on self-ecacy positive feedback from a credible observer can be powerful
8 / 44
Part II Groups
9 / 44
Small Groups I
Sources: [7] Work group:
an interdependent group of people who see themselves (and are seen by others) as a social entity embedded in some organizational context working together to perform some tasks
A team is a work group that develops

A sense of shared commitment A striving for synergy among members
Measure the eectiveness of a team by

the work they do (quality, quantity, speed, etc.) consequences the group has for its members its growth (enhancement of team capability)
10 / 44
Small Groups II
Overarching question: How can we design and manage teams to maximize their eectiveness? Major issues:
Composition Bonding & cohesion Leadership Motivation Group goals Group decision-making Group processes Intra-group conict Inter-group conict
11 / 44
Small Groups III
Major indicators of teams [5]

Morale/spirit Social support Communication & cooperation Workload sharing Participation Goal interdependence Team eectiveness & performance
12 / 44
Small Groups IV
Kinds of tasks: Steiner (1972)

Additive: contributions of team members are added together (e.g., brainstorming, etc.) Conjunctive: performance based on lowest performer (assembly line) Disjunctive: performance based on highest performer, e.g., problem solving Discretionary: team members combine their resources however they wish Can draw similarities to sequential vs. parallel complexity, e.g., embarassingly parallel problems
13 / 44
Trust I
For members to trust the team, need potency and safety [8]. Potency / Collective ecacy
Team members feel the team is competent to accomplish the task Group-equivalent of self-condence or self-ecacy Potency can predict performance over and above group member ability
14 / 44
Trust II
Safety
Feel that the team will not harm the individual and/or their interests. Edmondson: a shared belief that the team is safe for interpersonal risk taking. Evidence that safety is especially important for teams attempting to innovate: lack of safety seems to predict adherence to status quo Open communication is associated with team performance; safety is probably an antecedent Implications for SE activities, e.g., code reviews
15 / 44
Team Design I
Source: Meta-analysis by Stewart of 93 studies [13] Team design factors: those features of the task, group, and organization that can be directly manipulated by managers to create the conditions for eective performance. Three major kinds of features: group composition, task design, and organizational context
16 / 44
Group composition I
Personality
Agreeableness: team members who are helpful, trusting, friendly, cooperative Mean level of agreeableness is positively related to team performance (corr 0.35) Mean level of emotional stability (corr 0.25) These personality traits are more important in teamwork than in jobs that involve two-person interactions (e.g. customer relations)
17 / 44
Group composition II
Heterogeneity vs. homogeneity

Mixed results Heterogeneity is usually advocated for teams engaged in creative tasks, e.g., new product development Heterogeneity of job-related characteristics (cross-functionality) is thought to be more important than heterogeneity of demographics (age, ethnicity, etc.) Functional heterogeneity encourages information exchange, which is positively correlated with team performance [8]
Developers, architects, QA, technical writers, HCI experts, ...
18 / 44
Group composition III
Heterogeneity of extraversion improves team performance [4] Evidence that some team demographics can result in the development of counterproductive subgroups, e.g., half the team is fresh out of college, and the other half is 45 years old.
Want to avoid cliques (factionalism) Want to avoid isolated subgroups or individuals (ostracism)
19 / 44
Group composition IV
Team size
Anecdotal claims in the software engineering literature that teams of 2-5 people are best In the psych research literature, mixed results:
Some studies: large teams = coordination + process losses Other studies: bigger is better Highly dependent on task design, context, etc.
If large team, important to avoid conjunctive bottlenecks where performance depends on weakest team members; and to pick task designs + processes that will scale (e.g., consensus decision-making on architectural decisions with a team of 120 developersprobably fatal.)
20 / 44
Team-level Task design I
What task is the group performing, and how will subtasks be divided amongst its members? Autonomy/empowerment of the team is critical: give the team more information and decision-making authority. This increases motivation and lets teams adapt the team to task demands. Autonomy is thought to be most benecial when work conditions and requirements are uncertain and dynamic (i.e., autonomy on an assembly line might not be productive.)
21 / 44
Team-level Task design II

Task meaningfulness: providing individuals with meaningful tasks increases individual productivity Traditional SE team models (e.g., Brooks Surgical Team) might give all the meaningful work to a few people could be counterproductive Intrateam coordination:
High coordination improves community-building, cohesion and reduces social loang However, high interdependence can lead to degradation of performance as well too much time spent coordinating Goldilocks principle
22 / 44
Boundary activities I
Source: [1] Boundary activities = interaction of the team with external people + organizations Team performance is often closely tied to their ability to carry out boundary activities:
Drawing on organizational expertise Interacting with stakeholders Requirements-gathering Usability testing
Sometimes boundary activity is carried out by specic individuals (either explicitly delegated, or it works out that way): boundary spanners In composing teams, important to think about what boundary activities will be required, and what kind of people would best carry them out
23 / 44
Boundary activities II
E.g., XP advocates having a customer representative on the development team to foster boundary activity Cross-functional teams Good boundary spanners might:
Have domain expertise Have important social ties Be extraverted Have research skills Be skilled in requirements-gathering, etc.
24 / 44
Group strategizing I
Teams that anticipate problem in advance and have contingency plans are more likely to overcome roadblocks and obstacles (Tesluk & Mathieu, 1999).
Risk management
Important that the team have unambiguous, well-prioritized goals, and agree on how those goals will be achieved
25 / 44
Cohesion + Bonding I
Source: [5] Cohesion refers to how tight the group is:
Festinger (1950): the total eld of forces which act on members to remain in the group. These forces may depend on the attractiveness or unattractiveness of either the prestige of the group, members of the group, or the activities in which the group engages.
Social/Interpersonal cohesion measures how attracted people are to the group: ask members
How much they like one another (all n 2 pairings) How long they want to stay in the group Typical questionnaire indicator:
Our team would like to spend time together outside of work hours
26 / 44
Cohesion + Bonding II
Task cohesion measures how committed members are to the task the group is undertaking. Evidence this is more closely related to work performance than interpersonal cohesion
Team members can work eectively together without becoming great friends. Typical questionnaire indicator:
Our team is united in trying to reach its goals for performance Im unhappy with my teams level of commitment to the task (reverse scored)
27 / 44
Cohesion + Bonding III
28 / 44
Bonding I
Source: [8] Development of positive feelings for one another, and for the team Trust implies willingness-to-work-together; bonding reects a sense of rapport and desire to stay together as a group The very high end of social cohesion Occurs over time: eects are not seen during team formation, but as the team works closely together Evidence that bonding is positively associated with team performance when work-ow interdependence is high (Beal et al. 2003).
29 / 44
Bonding II
Virtual teams have diculty bonding. Baltes et al. meta-analysis of 27 studies of virtual teams:
Results suggest that computer-mediated communication leads to decreases in group eectiveness, increases in time required to complete tasks, and decreases in member satisfaction compared to face-to-face groups. [2]
These results suggest that virtual team support technologies may not be mature enough to support high-functioning teams.
However, there is some indication that certain activities work better in virtual teams, e.g., brainstorming
Bonding is associated with developing a team culture: shared attitudes, jokes, etc.
30 / 44
Bonding III
Bonding encouraged when teams high on agreeableness, emotional stability, and extraversion (and variance in extraversion).
31 / 44
Group dynamics I
Intra-group communication:
Higher participation from team members who are high in self-esteem, well-educated, satised with their group More intra-group communication in small, self-managed teams Can be encouraged by rotating leadership
32 / 44
Group dynamics II
Shared mental models: team develops an organized understanding of relevant knowledge, shared by its members (Mohammad & Dumville, 2001) Transactive memory
the knowledge possessed by each individual + knowledge of who knows what transactive memory is strongly related to team performance therefore, during team formation activities, it is important that the team develop an understanding of each others expertise
33 / 44
Group dynamics III

Social loang
Phenomenon that people can reduce their eort level when they are part of a group Can result in a group being less eective than the sum of its members, even on highly disjunctive tasks Can be exacerbated by measuring only group performance instead of team performance, e.g., tug-of-war Can be reduced by peer feedback. Negatively associated with team cohesiveness Certain demographics aect loang: male, north americans loaf more More loang on simple tasks Less loang when individual contributions are unique
34 / 44
Intra-group conict I
Issue-based conict: can be very constructive and improve team performance, if managed properly.
A team that avoids conicts at all costs can perform terribly. Important to have healthy debate about important technical issues.
Personal conict: can be highly destructive and degrade team functioning Leaders who promote procedural justice and apply rules consistently are able to minimize relationship conict (Naumann & Bennett 2000). Face-to-face developmental feedback from peers at the project midpoint can drastically reduce conict [6]
Peer feedback is thought to be especially important in self-managed teams (e.g. your SE-1,2,3 projects)
35 / 44
Intra-group conict II
Peer feedback use for performance appraisals e.g. for raises can be questionable: susceptible to bias, can promote feelings of injustice + popularity contests Peer feedback use for personal development can be very constructive.
Study of 511 students, 80 self-managing project groups [6]:

Each member kept records of behaviors exhibited by each member and their eect on the group on an observation form Appraisal process: each team member managed the appraisal process for one other member. This person collected the observation forms, summarized them, and completed a formal appraisal form for the appraisee. Appraisal meeting: each appraisal manager gave a verbal summary of the teams feedback to their appraisees while members observed.
36 / 44
Intra-group conict III
Substantial increases in team eectiveness after appraisals
37 / 44
Druskat & Wol (1999)
From [6]. Peer reviews conducted just prior to Time 3.

38 / 44
39 / 44
Bibliography I
[1]
Deborah Ancona and David Caldwell. Compose teams to assure successful boundary activity. In Edwin A. Locke, editor, The Blackwell Handbook of Principles of Organizational Behavior. Blackwell Publishing, 2004.
[2] Boris B. Baltes, Marcus W. Dickson, Michael P. Sherman, Cara C. Bauer, and Jacqueline S. LaGanke. Computer-mediated communication and group decision making: A meta-analysis. Organizational Behavior and Human Decision Processes, 87(1):156179, January 2002.
40 / 44
Bibliography II
[3] Albert Bandura. Cultivate self-ecacy for personal and organizational eectiveness. In Edwin A. Locke, editor, The Blackwell Handbook of Principles of Organizational Behavior. Blackwell Publishing, 2004.
[4] Murray R. Barrick, Greg L. Stewart, Mitchell J. Neubert, and Michael K. Mount. Relating member ability and personality to work-team processes and team eectiveness. Journal of Applied Psychology, 83(3):377391, 1998. [5] Sally A. Carless and Caroline De Paola. The Measurement of Cohesion in Work Teams. Small Group Research, 31(1):7188, 2000.
41 / 44
Bibliography III
[6] Vanessa Urch Druskat and Steven B. Wol. Eects and timing of developmental peer appraisal in self-managing work groups. Journal of Applied Psychology, 84(1):5874, 1999.
[7] Richard A. Guzzo and Marcus W. Dickson. Teams in organizations: Recent research on performance and eectiveness. Annual Review of Psychology, 47(1):307338, 1996. [8] Daniel R. Ilgen, John R. Hollenbeck, Michael Johnson, and Dustin Jundt. Teams in organizations: From input-process-output models to imoi models. Annual Review of Psychology, 56(1):517543, 2005.
42 / 44
Bibliography IV
[9] Gary P. Latham. Motivate employee performance through goal-setting. In Edwin A. Locke, editor, The Blackwell Handbook of Principles of Organizational Behavior. Blackwell Publishing, 2004.
[10] Gary P Latham and Craig C. Pinder. Work motivation theory and research at the dawn of the twenty-rst century. Annual Review of Psychology, 56(1):485516, 2005. [11] Edwin A. Locke and Gary P. Latham. Work motivation and satisfaction: Light at the end of the tunnel. Psychological Science, 1(4):240246, 1990.
43 / 44
Bibliography V
[12] Sara L. Rynes, Amy E. Colbert, and Kenneth G. Brown. HR professionals beliefs about eective human resource practices: correspondence between research and practice. Human Resource Management, 41(2):149174, 2002. [13] Greg L. Stewart. A Meta-Analytic Review of Relationships Between Team Design Features and Team Performance. Journal of Management, 32(1):2955, 2006.
44 / 44
Chapter 13
Group Judgement and Sunk CostsGroup Decision MakingCommon Knowledge EffectStructured Decision ProcessesAvoiding Premature ClosureGroupthinkSunk CostsIT Governance Abroad
681
SE362 Lecture 13: Group judgement & Sunk costs
SE362 Lecture 13: Group judgement & Sunk costs

June 24, 2008
1 / 50
SE362 Lecture 13: Group judgement & Sunk costs Todd Veldhuizen tveldhui@acm.org
Part I Group Decision Making
2 / 50
Gigone & Common Knowledge Eect
Format for studies

individuals given pieces of information (cues) relevant to making a decision group asked to make a decision vary who-knows what: if one person has a cue, but others dont, is it seen as relevant? regression model to determine how cues were weighted
3 / 50
From [4].
4 / 50
Common knowledge eect: Groups tend to ignore knowledge that is not widely shared among the members. They weight knowledge according to how widely it is held [4]. Even if knowledge held by only one person is shared and discussed by the group, it is discounted. Groups tend to discount key knowledge held by lower-status individuals [6].
5 / 50
Advisor/advisee scenarios
In situations where one person is making the decision based on information collected from various advisors, they tend to (a) weight their own position most heavily; (b) give more weight to advisors who:
have similar preferences to theirs; are more condent have a track record of giving accurate advice.
6 / 50
Importance of structured decision processes
Tindale (1998) videotaping studies of group-decision making on conjunctive problems Groups rarely discussed strategy for deciding Usually just exchanged information about their individual judgments, then picked one individuals undefended judgement. This can work for simple decision problems; but on complex and error-prone decision problems, it leads to incorrect decisions.
7 / 50
Avoiding Premature Closure [9] I

In group decision making, there can be pressure to come to a consensus An early majority preference can lead to reduced exchange of information and premature closure of debate Group members are reluctant to change their initial preferences, once formed: tend to choose a position and then seek conrmation of it The longer a discussion continues, the more likely unshared information is to be discussed Placing all unshared information in the hands of at least one group member increases its eect Group members can be trained to explore more information Devils advocates can help in information sharing
8 / 50
Avoiding Premature Closure [9] II
Assigning group members to be responsible for certain categories of information helps Quality of decisions are better if groups are told there is a unique right answer. Evidence that it is helpful to split the decision process into two components helps: (a) information gathering; (b) integration and decision making.
9 / 50
Groupthink [3] I
Disastrous outcomes by groups of team experts
Admiral Kimmel + advisors focus on training rather than defending Pearl Harbor despite warnings of possible surprise attack by Japanese (1941) Truman + advisors escalate the Korean war by crossing the 38th parallel into North Korea (1950) Kennedy+advisors authorize the Bay of Pigs invasion (1960) Escalation of Vietnam war by Johnson+advisors (196467) Watergate cover-up by Nixon White House Space shuttle Challenger disaster
Groupthink: a mode of thinking that people engage in when they are deeply involved in a cohesive in-group, when the members strivings for unanimity override their motivation to realistically appraise alternative courses of action.
10 / 50
Groupthink [3] II
Generally thought to have some descriptive validity, but has been dicult to reproduce situations leading to groupthink in laboratory conditions. Avoiding groupthink: devils advocate; avoid conrmation-seeking behaviour; adopt a process that forces detailed consideration of alternatives.
11 / 50
Part II Sunk Cost Eects
12 / 50
Canadas Gun Registry I

82. The Commissioner of the Royal Canadian Mounted Police shall, after consulting with the federal Minister and the Solicitor General of Canada, appoint an individual as the Registrar of Firearms. 83. (1) The Registrar shall establish and maintain a registry, to be known as the Canadian Firearms Registry, in which shall be kept a record of (a) every licence, registration certicate and authorization that is issued or revoked by the Registrar; (b) every application for a licence, registration certicate or authorization that is refused by the Registrar; (c) every transfer of a rearm of which the Registrar is informed under section 26 or 27; (d) every exportation from or importation into Canada of a rearm of which the Registrar is informed under section 42 or 50; (e) every loss, nding, theft or destruction of a rearm of which the Registrar is informed under section 88; and (f) such other matters as may be prescribed.
13 / 50
Canadas Gun Registry II
Sources: CBC news Indepth; 2002 Report of the Auditor General of Canada, Ch. 10; 2006 Report of the Auditor General of Canada, Ch. 3: Large Information Technology Projects.
In 1995, Bill C-68 passed by the senate. Mandates a gun registry. Dept. of Justice states the registry will cost $119 million to develop, but that $117 million in registration fees will be collected; total cost to taxpayers will be $2 million. Proclamation delayed until 1998 to give Dept. of Justice time to implement the computer system.
14 / 50
Canadas Gun Registry III

In 1998, Dept. of Justice estimated program would cost $544 million. In 2000, Dept. of Justice told parliament that it had spent $327 million on the registry. Estimated cost: $764 million. In 2001 the Dept. concluded its 3 yr old computer system was not working well: technology was expensive, inexible, archaic, and could not be modied at reasonable costs to support future operations. In 2002, cost hits $629 million; includes $227 in computer costs and $332 million for other programming costs. Dept. of Justice predicts costs will reach $1 billion by 2005.
15 / 50
Canadas Gun Registry IV

In 2002, Govt decided to outsource the registry. Winning contractor proposed to junk the existing system and replace it with existing private sector approaches. Only 75% of gun owners register their guns by the deadline of Jan 1, 2003 In 2004, documents obtained by CBC indicate the project has cost $2 billion.
Est. 10 million rearms in Canada $200 per rearm
In 2006, government introduces legislation to abolish the gun registry for ries and shotguns. Handgun registry will remain in place, as it has since 1934.
16 / 50
Canadas Gun Registry V

2002 Auditor General report:
Scope of the computer system projects were well beyond the Dept. of Justices previous experience. Major project management problems: lack of a formal nancial reporting framework, by 1999 there were more than 1000 change requests. (such other matters as may be prescribed.) Complexity of the system increased becausue
many design assumptions were invalid; system designed to capture detailed info about rearms for criminal investigations; but this was beyond the administrative needs of the program small changes, such as modications in data entry on a form, required major changes in the whole system because of its size and complexity, and these changes typically took three to six months to implement at a cost of millions of dollars.
17 / 50
Canadas Gun Registry I
Review: In 1995, started as a purportedly $2 million dollar project; in 2002, project outsourced and 3 yrs of internal development work discarded; by 2003 deadline, only 75% of gun owners registered; in 2004, documents obtained by CBC put the cost at $2 billion (est. $200 per rearm); in 2006, registry for ries and shotguns abolished; registry for handguns remains in place (since 1934).
18 / 50
Canadas Gun Registry II

The project was repeatedly escalated: Year Cost (thousands) 1995 2 000 1998 544 000 2000 764 000 2002 1 000 000 2 000 000 2004
CBC estimate.
2002 Auditor General report:

Computer system projects were well beyond the Dept. of Justices previous experience. Scope creep: by 1999 there were more than 1000 change requests (Bill C-68 scope denition perilously included such other matters as may be prescribed.) Many design assumptions were invalid
19 / 50
Canadas Gun Registry III
...small changes, such as modications in data entry on a form, required major changes in the whole system because of its size and complexity, and these changes typically took three to six months to implement at a cost of millions of dollars.
20 / 50
Keil et al. 1995
Controlled experimental study of sunk cost eects.
21 / 50
Keil et al. 1995 [7]
22 / 50
23 / 50
24 / 50
25 / 50
26 / 50
Eect of sunk cost & alternatives
From [7].
27 / 50
Sunk Cost I
Sources: [2, 5] You have made a $100 down payment on an item that costs $200. You nd the identical item from another source for $90. Do you
a. Pay the $100 that remains on the $200 item; or b. Pay $90 to the other source and give the $100 up as lost?
Most people choose (a), despite (b) having lower cost. Sunk Cost Eect or Escalation of Commitment: increasing commitment to losing course of action; tendency to persist in a course of action despite clear signals of problems. Throwing good money after bad
28 / 50
Sunk Cost II
An alarmingly frequent pattern of IT project failure where projects spiral out of control, cost far more than budgeted, and eventually are cancelled (e.g. Canada gun registry: from $2 million to $2 billion99900% over budget!) Also common pattern for failure of entrepreneurial ventures
29 / 50
Sunk Cost III

Arkes and Blumer (1985): a sunk cost increases condence in success
As the president of an airline company, you have invested 10 million dollars of the companys money into a research project. The purpose was to build a plane that would not be detected by conventional radar, in other words, a radar-blank plane. When the project is 90% completed, another rm begins marketing a plane that cannot be detected by radar. Also, it is apparent that their plane is much faster and far more economical than the plane your company is building. Use the following 0 to 100 scale. Write in the box the number between 0 and 100 that reects what you think your planes chance of nancial success really is.
Condition 1: Company already invested $10 million. Prob. of success estimate = 41%. Condition 2: Project not yet started. Prob. of success estimate = 34%.
30 / 50
Sunk Cost IV
A sunk cost increases ones estimate of the probability that the endeavour will succeed.
This project will succeed, because if it doesnt, we will have wasted a lot of money. People with high self-ecacy (condence) are more prone to escalating commitment [10]
31 / 50
Sunk Cost V
Theoretical explanations [8]
Self-justication theory (SJT)/cognitive dissonance: people adjust their condence in the project to justify their previous commitment.
Staw (1976): sunk cost eect is increased if people feel more personal responsibility Dissonance: why would we be spending all this money/eort if the project were unlikely to succeed?
Prospect theory: people exhibit risk averse or risk seeking behaviour depending on how a problem is framed. People are risk seeking when presented with choices between negative options. When presented with a sure loss (abandoning investment), vs. risk of a larger loss but a chance of breaking even, they tend to choose the risk.
32 / 50
Sunk Cost VI
Approach/avoidance theory: driving forces (to continue the project) outweigh restraining forces (to discontinue project). Completion eect: motivation to achieve a goal increases as an individual gets closer to that goal. Desire to achieve closure inuences behaviour.
33 / 50
Sunk Cost VII

Escalation of software projects [8, 7]
Runaway systems: projects that go wildly over budget or schedule through escalation (increasing budgets/schedules) Escalation occurs in 38% of projects (2000) Projects frequently escalate for 15 or more months. Only 23% of escalated projects were rated completed and successful; 84% of non-escalated projects were.
Escalation is an indication of probable project failure.
Compounding factors:
Mum eect: concealing negative information about the project from superiors Deaf eect: superiors are aware of negative information, but ignore or discount it.
34 / 50
Sunk Cost VIII

How to avoid escalation?
Some evidence that people informed about escalation of commitment are less likely to demonstrate it (Nathanson et al 1982). Need to detect troubled projects and abandon or redirect them. Alerted by negative project status: performance problems with respect to cost, schedule, functionality, or quality. Many troubled projects should never have been approved in the rst place: need to ensure there is a persuasive business case, rm scope, clear and feasible plan, organizational capacity to successfully complete the project, plausible estimates, etc. The presence of an alternative substantially decreases the likelihood of escalation [7]: suggests that projects with clearly dened best alternatives will be less likely to escalate. Need transparency of the project status.
35 / 50
Sunk Cost IX
Setting clear criteria for project audit/abandonment in planning stages of the project: e.g. green-yellow-red zones for budget, schedule, change requests, open defect reports
36 / 50
Sunk Cost X
Regular internal audits/demos/etc.

E.g. EA ISACA: Information Systems Audit and Control Association; Certied Information Systems Auditor (CISA) certication
Chaos report guidelines: maximum six people for six months. Need culture in which it is okay for a team to announce that, despite best eorts, their project has gone o the rails and should be abandoned (Avoid mum eect/deaf eect).
37 / 50
How to abandon a project I

A rigorous risk assessment before the project starts makes project abandonment less upsetting: the stakeholders knew the project risks before it started, they were willing to take the gamble, and now they will be informed that the gamble did not pay o. Goal: avoid establishing culture of mum eect by abandoning projects in such a way that impact on individuals is minimized. If you re the team, you may be pleasantly surprised at how well the remaining projects (appear) to do much better! Convey the information privately to key stakeholders rst, before announcement.
38 / 50
How to abandon a project II
Need to be sensitive to the personal investment team members have made in the project. Assure them that there will not be recriminations, demotions, rings, etc.: emphasize the role of process failures over individual failings Appoint some external to the project to (sensitively) gure out what went wrong, and how to avoid future occurrences.
39 / 50
Recommendations of the 2006 Auditor General Report [1] I

Between 20032006, Canada federal government undertook 88 IT projects, total spending of $2.9 billion per year
A good deal of this was spent on troubled and/or cancelled megaprojects Roughly equal to total tuition paid at Canadian universities
Since 1996 the Public Accounts Committee has recommended

smaller, more manageable projects dedicated, qualied project managers better monitoring of IT projects annual reporting on status of projects under development
40 / 50
Recommendations of the 2006 Auditor General Report [1] II

Treasury Board developed Enhanced Management Framework (EMF) (1996?) and EMF-II (1998) to improve IT governance. However, problems persist because many departments are not following the EMF. Projects are also failing to follow the Treasury Boards guidelines on Project Management: many projects
do not dene scope + measures of success in the business case do not perform a rigorous risk assessment do not adequately assess whether the department/agency has the capacity to undertake the project
...although research clearly indicates that small IT projects are more likely to succeed than large ones, departments and agencies are again undertaking large IT projects.
41 / 50
Recommendations of the 2006 Auditor General Report [1] III

Auditor General is routinely denied access to information it needs to assess IT projects: ...we were denied access to most of the evidence of the Secretariats review of project documents such as the business case, options analysis, project plan, and risk management plan... We found that the quality of project management varied widely from project to projectfrom good to seriously awed. Projects that had weak project management practices have experienced long delays and large cost overruns. Some improvements: e.g., some departments & agencies are having third-party reviews of their projects. Some projects are well-managed (My Account, 2006 Census Online, Global Case Management, Secure Channel).
42 / 50
Auditor General: Summary of projects
Source: 2006 Auditor General report.

43 / 50
IT Governance Abroad I
Abroad: UK, US, Australia mandate independent third-party reviews. The UK has an organization (OGC) which combines procurement + programme management: has a system of Gateway Reviews.
http://www.ogc.gov.uk/gateway_process_ documentation.asp Each gateway review is a brief report, written & delivered in 1 week by external reviewers. Assigns a status to the project: red (in danger), amber (proceed, but with changes), or green (project on target.) Gateway 0: Strategic assessment. Direction & planned outcomes. Gateway 1: Business justication. Does the project have a valid business case? Gateway 2: Delivery strategy. Reviews the outline business case and the delivery strategy before tender etc.
44 / 50
IT Governance Abroad II
Gateway 3: Investment decision. Reviews the full business case and governance arrangements. Occurs prior to funding & resources committment. Gateway 4: Readiness for service. Determines if the organization is ready to go live with the necessary business changes, and manage the operating service. Gateway 5: Operations review & benets realization. Determines if the desired benets of the project are being achieved, and whether the business changes are operating smoothly. Repeated regularly during service lifetime.
45 / 50
46 / 50
Bibliography I
[1] Oce of the Auditor General of Canada . Report of the Auditor General of Canada to the House of Commons, 2006. Chapter 3: Large Information Technology Projects.
[2] Hal R. Arkes and Laura Hutzel. The role of probability of success estimates in the sunk cost eect. Journal of Behavioral Decision Making, 13(3):295306, 2000. [3] James K. Esser. Alive and well after 25 years: A review of groupthink research. Organizational Behavior and Human Decision Processes, 73(23):116141, 1998.
47 / 50
Bibliography II
[4] Daniel Gigone and Reid Hastie. The common knowledge eect: Information sharing and group judgment. Journal of Personality and Social Psychology, 65(5):959974, 1993.
[5] Cheng-Suang Heng, Bernard C. Y. Tan, and Kwok-Kee Wei. De-escalation of commitment in software projects: Who matters? what matters? Information & Management, 41(1):99110, 2003. [6] Andrea B. Hollingshead. Information suppression and status persistence in group decision making the eects of communication media. Human Communication Research, 23(2):193219, 1996.
48 / 50
Bibliography III
[7] Mark Keil, Duane P. Truex III, and Richard Mixon. The eects of sunk cost and project completion on information technology project escalation. IEEE Transactions on Engineering Management, 42(4), November 1995.
[8] Mark Keil, Joan Mann, and Arun Rai. Why software projects escalate: An empirical analysis and test of four theoretical models. MIS Quarterly, 24(4):631664, 2000. [9] Norbert L. Kerr and R. Scott Tindale. Group performance and decision making. Annual Review of Psychology, 55(1):623655, 2004.
49 / 50
Bibliography IV
[10] Glen Whyte, Alan M. Saks, and Sterling Hook. When success breeds failure: the role of self-ecacy in escalating commitment to a losing course of action. Journal of Organizational Behavior, 18:415432, 1997.
50 / 50
Chapter 14
LeadershipLegitimacy and LegitimationFull-Range Leadership TheoryTransactional LeadershipTransformational LeadershipShared LeadershipApacheOpen Source LeadershipEmergent LeadershipChemers Recipe
732
SE362 Lecture 14: Leadership Todd Veldhuizen tveldhui@acm.org
SE362 Lecture 14: Leadership

June 26, 2008
1 / 38
Legitimacy and Legitimation I

Source: [18] Often said that project managers have responsibility without authority What is meant by this is that PMs tend to have little coercive power, i.e., the ability to shape the behaviour of people by controlling punishments and rewards However, coercive power is inecient: requires large expenditure of resources to obtain modest inuence Better to have legitimacy: the belief that authorities, institutions, and social arrangements are appropriate, proper and just. People instinctively defer to people and authorities they feel are legitimate. Even if you have no coercive power, studies suggest that having legitimacy facilitates the ability to gain decision acceptance and promote rule-following
2 / 38
Legitimacy and Legitimation II
In organizations, legitimacy is strongly associated with

leadership procedural justice (i.e., fair decision-making and allocation of resources). internalization of norms: people become self-regulating
3 / 38
Leadership styles have changed
Source: [3] Then (mid-20th century):

People had bosses, loyalty to rm, longterm job security Children taught to respect authority People unquestioningly internalized organizational goals
Now (21st century):

Flattened hierarchies, increasingly self-managed teams Teams of educated professionals, trend to collegial rather than superior-subordinate relationships Children taught to be responsible for their own actions, to question authority when necessary
4 / 38
Leadership in the 21st century

Eective leadership is increasingly
emergent: teams and organizations select their own leaders, either informally or formally; task-specic: teams might choose dierent leaders over time, depending on who is best-qualied to lead the current activities shared leadership: simultaneously have multiple leaders; emergent leaders coexist with nominal, organizational leaders transformational new leadership: charismatic, instill pride, communicate personal respect, inspire lofty goals, promote change, etc.
Trudeau, Roosevelt, Kennedy, Martin Luther King, Nelson Mandela, Gro Harlem Brundtland
5 / 38
Leadership
Thousands of books are published; gurus proliferate; fads come and go Leadership can be studied scientically.
1. Factor analysis: what are the principal dimensions in which leadership styles vary? 2. Assess: how do leadership styles predict outcomes?
One of the well-validated theories of leadership is Full-Range Leadership Theory (FRLT). Primary instrument is the Multifactor Leadership Questionnaire (MLQ).
6 / 38
Full-Range Leadership Theory

MLQ is a questionnaire that assesses leader attributes and behaviors, as seen by their followers. Factor analysis (principal component analysis) used to uncover primary axes of variation in leadership styles 5-9 factors indicating three primary leadership types. Leadership theory is validated by determining if leadership style predicts outcomes:
Measure leader with MLQ Measure outcomes: subordinate/team performance, satisfaction, eort, commitment
Determine what leadership factors are correlated with outcomes.
7 / 38
A leadership theory
Full-Range Leadership Theory (FRLT) due to Avolio and Bass (1991). [1] Factor analysis identies three major avours of leadership styles: 1. Laissez-faire: leader avoids making decisions, abdicates responsibility, does not use authority 2. Transactional leadership: cater to the followers immediate self-interests through benecial transactions; people are motivated through rewards for carrying out their duties 3. Transformational leadership: leaders inuence followers to transcend self-interest for the greater good of their organizations. These form a hierarchy of leadership styles: laissez-faire is the lowest level of functioning; the highest is transformational leadership, which augments transactional leadership behaviours.
8 / 38
Laissez-Faire Leadership [3]
the avoidance of leadership is absent when needed takes no action even when problems become chronic associated with subordinate dissatisfaction, conict, and ineectiveness.
9 / 38
Dimensions of Transactional Leadership I

Three factors of transactional leadership [1, 3, 17]: Contingent reward leadership: followers are promised & given material ($$) or psychological rewards contingent on performance (e.g., pay for performance)
I can get what I want if I work as agreed with him/her. The work I do for him/her determines what I get for it. Tells me what to do to be rewarded for my eorts.
Management-by-exception (active): leader actively ensures that standards are met by taking corrective action when problems are anticipated
Draws attention to the mistakes that I make. Keeps careful records of my mistakes. Shows concern to prevent failures.
Management-by-exception (passive): leader intervenes only after mistakes have been made or noncompliance has occurred, i.e., re-ghting
10 / 38
Dimensions of Transactional Leadership II
As long as work is going as planned, he/she does not try to make improvements. Things have to go wrong for him/her to take action. Enforces rules when things dont get done.
Sometimes contingent reward is split into two factors: promises and rewards.
11 / 38
Dimensions of Transformational Leadership [1, 3, 17] I

Idealized Inuence (charismatic leadership): instills pride and faith in followers by overcoming obstacles and condently expressing disenchantment with the status quo [17].
I am ready to trust him/her to overcome any obstacle. Turns threats into opportunities. In my mind, he/she is a symbol of success and accomplishment.
Sometimes split into:

attributed: charismatic leader who is condent, powerful, focuses on higher-order ideals and ethics behavior: charismatic actions of the leader that are centered on values, beliefs, sense of mission
12 / 38
Dimensions of Transformational Leadership [1, 3, 17] II

Inspirational Motivation: leaders energize their followers by viewing the future with optimism, projecting an idealized vision, communicating to followers that the vision is achievable, inspiring them to embrace ambitious goals
If there is risk involved for us, he/she takes the rst step. Gives me reasons to believe in what I can do. Does not allow me to accept defeat.
Intellectual Stimulation: leaders appeal to followers sense of logic and analysis by challenging followers to think creatively and nd solutions to dicult problems; articulates new ideas that prompt followers to rethink conventional practice and thinking
His/her ideas enable me to rethink ideas which I had never questioned before.
13 / 38
Dimensions of Transformational Leadership [1, 3, 17] III
Arouses my curiosity about new ways of doing things. Makes me less critical of creative ideas.
Individualized Consideration: leader advises, supports, and pays attention to the individual needs of followers, allowing them to develop and self-actualize
Takes time to nd out what I need. Works with me on a one-on-one basis. Spends time coaching me.
14 / 38
The Multifactor Leadership Hierarchy
Source: MLQ P/L, Melbourne.

15 / 38
Transformational Leadership predicts outcomes
Transformational leadership qualities are associated with: obtaining performance beyond basic expectations of workers (augmentation hypothesis) [14] ratings of leader eectiveness satisfaction with the leader increased satisfaction with performance appraisals
16 / 38
Directive vs. Participative Leadership
Transformational leaders can be either authoritarian/autocratic or democratic/participatory. Some evidence that more participatory styles of management can be associated with better outcomes
Meta-analytic ndings that participation in work decisions has a positive correlation with performance (r=0.26) and satisfaction (r=0.23) [11] Autonomy & participatory decision making is positively correlated with satisfaction, commitment, involvement, performance, motivation, stress, turnover [15]
17 / 38
Can leadership be taught?

Are leaders born or made? Early studies of leadership as an innate trait were unsatisfactory [5] Correlations between personality and leadership tend to be fairly weak [4]. Big Five personality traits explain
28% of the variability in leadership emergence 15% of the variability in leadership eectiveness 12% of the variability in charisma 5% of the variability in intellectual stimulation 6% of the variability in individualized consideration
There is a correlation of 0.24 between transformational leadership and extraversion. There is evidence that leadership training can increase the amount of transformational leadership behaviour exhibited [2].
18 / 38
Case study in shared leadership: Apache
Source: Netcraft Web Server Survey
19 / 38
Case study in shared leadership: Apache I
Source: [9] Market share 50-70% over the last decade Multinational: U.S., Britain, Canada, Germany, Italy Volunteers with other full-time jobs Voting system:
20 / 38
Case study in shared leadership: Apache II

There was no Apache CEO, president, or manager to turn to for making decisions. Instead, we needed to determine group consensus, without using synchronous communication... What we devised was a system of voting via email that was based on minimal quorum consensus. Each independent developer could vote on any issue facing the project by sending mail to the mailing list with a +1 (yes) or -1 (no) vote. For code changes, three positive votes and no negative votes (vetoes) were required before the change would be allowed in the nal source. For other decisions, a minimum of three +1 and an overall positive majority was required... By setting the minimum at three positive votes, only a subset of the group had to be involved in any decision... the minimum vote enforced a high degree of peer review over all code changes.
21 / 38
Case study in shared leadership: Apache III
Innovation: Competitors mistakenly assume Apache will be unable to take on new or unusual tasks because of the perception that we act as a group rather than follow a single leader. What they fail to see is that, by remaining open to new contributors, the group phas an u nlimited supply of innovative ideas, and it is the individuals who chose to pursue their own ideas who are the real driving force for innovation.
22 / 38
Transformational leadership in OSS projects

Survey study of 118 OSS developers from sourceforge.net [13] Questionnaire assessed:
Transactional vs. transformational leadership styles exhibited by OSS leaders Intrinsic Motivations of OSS developers:
enjoyment-based motivation (because its fun) obligation-based (because its noble)
Extrinsic Motivations of OSS developers:

identied regulation: motivated by career incentives or self-development (e.g., become a better programmer) introjected regulation: performing an action to improve self-esteem (seek approval from self or others; ego-boosting) external regulation: individuals motivated by monetary rewards or punishment; OSS leaders do not inuence this.
Contribution: estimated time spent on the project per week

23 / 38
Transformational leadership in OSS projects [13]

Major ndings: 29% of variance in contributions of OSS developers is explained by motivation variables introjected regulation (approval-seeking; ego-boosting) did not have a statistically signicant eect on contribution (but: these were self-reports; interpret this to mean that few OSS developers say I am doing this because I am insecure and I need the approval of others.) Transformational leadership intrinsic motivation
Intellectual stimulation & individualized consideration enjoyment-based motivation (its fun) Idealized behaviour & inspirational motivation obligation-based motivation (noble purpose)
Active management by exception extrinsic motivation

24 / 38
Transformational leadership in OSS projects
Source: [13]
25 / 38
Emergent leadership I
How do teams choose and decide to follow a leader? [5] Leader emergence: the process by which people obtain leadership status Leadership status can be implicit: people defer to that person, without them being ocially appointed a leader Individuals gain leadership status through
demonstration of task-related competence (heavily weighted) loyalty to group values conforming to perceived leader stereotypes (acting like a leader)
Once someone is seen as a leader, selective attention (preferentially noticing when they exhibit leadership qualities) and memory reinforce that judgement
Groups have built-in stability when it comes to leader selection
26 / 38
Problems of attribution
Romance of leadership: remarkable outcomes (either positive or negative) are likely to be attributed to leadership eects
Other reasonable causes are ignored
Conversely, leaders tend to explain poor performance of followers by internal, personal causes such as motivation and ability (fundamental attribution error)
Plausible external causes (lacking of training or support) are ignored
Successes and failures tend to be attributed to properties of people (quality of leadership; competence of followers) rather than valid situational/circumstancial factors
27 / 38
Gender and leadership
Circa 1965: prevailing bias against women as leaders Modern studies [5]:
Women tend to emerge as leaders as often as men Tend to be evaluated similarly as men Few real dierences in leadership behavior or style exist between men and women Women are still susceptible to the impediments created by negative stereotypes about female leadership
28 / 38
Chemers recipe I
Image management: Leaders must build credibility in the legitimacy of their authority by projecting an image that arouses feelings of trust in followers
Act like a leader viewed as a legitimate leader selective attention & memory reinforce the leaders legitimacy, so it becomes self-sustaining Leader must be seen as competent in task-relevant abilities Leader must be seen as honest, trustworthy, loyal to group norms and values
Relationship development: Leaders must develop relationships with subordinates that enable them to attain individual and collective goals
Coaching and providing appropriate guidance to subordinates
29 / 38
Chemers recipe II
Avoid making misattributions about causes of failure (e.g., viewing subordinates as incompetent when they lack proper training or support) Career planning for subordinates Providing intellectual stimulation, individualized consideration
Resource deployment: Leaders must eectively use the knowledge, skills, and material resources present in the group to accomplish goals
Project condence, optimism Motivate people Adapt nature of leadership & group process to the task at hand, e.g., rely more on participatory decision-making in ambiguous, less predictable situations
30 / 38
Part I Bibliography
31 / 38
Bibliography I
[1] John Antonakis, Bruce J. Avolio, and Nagaraj Sivasubramaniam. Context and leadership: an examination of the nine-factor full-range leadership theory using the multifactor leadership questionnaire. The Leadership Quarterly, 14:261295, 2003.
[2] Bruce J. Avolio and Bernard M. Bass. You can drag a horse to water but you cant make it drink unless it is thirsty. The Journal of Leadership Studies, 4(1), 1998. [3] Bernard M. Bass. Two decades of research and development in transformational leadership. European Journal of Work and Organizational Psychology, 8:932, 1999.
32 / 38
Bibliography II
[4] Joyce E. Bono and Timothy A. Judge. Personality and transformational and transactional leadership: A meta-analysis. Journal of Applied Psychology, 89(5):901910, 2004.
[5] Martin M. Chemers. Leadership research and theory: a functional integration. Group Dynamics, 4(1), 2000. [6] Robert B. Cialdini and Noah J. Goldstein. Social inuence: Compliance and conformity. Annual Review of Psychology, 55(1):591621, 2004.
33 / 38
Bibliography III
[7] David De Cremer and Daan van Knippenberg. How do leaders promote cooperation? The eects of charisma and procedural fairness. Journal of Applied Psychology, 87(5):858866, 2002.
[8] Kurt T. Dirks and Donald L. Ferrin. Trust in leadership: Meta-analytic ndings and implications for research and practice. Journal of Applied Psychology, 87(4):611628, 2002. [9] Roy T. Fielding. Shared leadership in the apache project. Commun. ACM, 42(4):4243, 1999.
34 / 38
Bibliography IV
[10] Chad A. Higgins, Timothy A. Judge, and Gerald R. Ferris. Inuence tactics and work outcomes: a meta-analysis. Journal of Organizational Behavior, 24:89106, 2003. [11] John A. Wagner III. Participations eects on performance and satisfaction: A reconsideration of research evidence. The Academy of Management Review, 19(2):312330, 1994. [12] Ronit Kark, Boas Shamir, and Gilad Chen. The two faces of transformational leadership: Empowerment and dependency. Journal of Applied Psychology, 88(2):246255, 2003.
35 / 38
Bibliography V
[13] Yan Li, Chuan-Hoo Tan, Hock-Hai Teo, and A. Talib Mattar. Motivating open source software developers: inuence of transformational and transactional leaderships. In SIGMIS CPR 06: Proceedings of the 2006 ACM SIGMIS CPR conference on computer personnel research, pages 3443, New York, NY, USA, 2006. ACM Press. [14] Kevin B. Lowe, K. Galen Kroeck, and Nagaraj Sivasubramaniam. Eectiveness correlates of transformational and transactional leadership: A meta-analytic review of the MLQ literature. The Leadership Quarterly, 7:385425, 1996.
36 / 38
Bibliography VI
[15] Paul E. Spector. Perceived Control by Employees: A Meta-Analysis of Studies Concerning Autonomy and Participation at Work. Human Relations, 39(11):10051016, 1986. [16] Thomas Sy, Richard Saavedra, and St ephane C ot e. The contagious leader: Impact of the leaders mood on the mood of group members, group aective tone, and group processes. Journal of Applied Psychology, 90(2):295305, 2005. [17] Bennett J. Tepper and Paul M. Percy. Structural Validity of the Multifactor Leadership Questionnaire. Educational and Psychological Measurement, 54(3):734744, 1994.
37 / 38
Bibliography VII
[18] Tom R. Tyler. Psychological perspectives on legitimacy and legitimation. Annual Review of Psychology, 57(1):375400, 2006.
38 / 38
Chapter 15
NegotiationSoft vs Hard StylesWin-winFacilitatedCase StudyNegotiating PrinciplesPsychology of NegotiationInuence TacticsThats Not All TechniqueLikingDoor-in-the-FaceFoot-in-the-doorTheory W
771
SE362 Lecture 15: Negotiation Todd Veldhuizen tveldhui@acm.org
SE362 Lecture 15: Negotiation

July 3, 2008
1 / 36
Assigned reading
Theory-W Software Project Management: Principles and Examples [3] An Experience of Principled Negotiation in Requirements Engineering [4]
2 / 36
Question
When is SE-2 deadline?
3 / 36
Things to negotiate
In software projects, we might negotiate: Requirements Initial schedules Overruns Changes in functionality Resources Work division Out-of-court settlements after projects go horribly wrong
4 / 36
What is negotiation
Negotiation = discussions to reach agreement. Negotiation is a social situation: we follow a script, consciously or not. This script gives us a process, a mindset (framing), and a sense of appropriate behaviour and ethics Choosing the script for the negotiation aects the style and outcome of the negotiation.
5 / 36
Styles of negotiation I
Soft: make concessions to cultivate relationships; trust others; goal is to come to an agreement. Hard or win-lose: assumption that it is a zero-sum game, that is, any thing that is good for one party is bad for the other party. (Problem framed as combat/war; the pie to be divided up has a xed size.)
6 / 36
Styles of negotiation II
Win-win: enter the negotiations with the philosophy that all parties should benet from the negotiation process. (Problem framed as problem solving to nd mutual benet.)
Famous popular book: Getting to Yes: Negotiating Agreement Without Giving In on principled negotiation; > 2 million copies sold
7 / 36
Styles of negotiation III
Facilitated: a facilitator helps the parties come to an agreement.
8 / 36
Story time
From [4].
9 / 36
Soft negotiation I
Source: [4] Participants are friends Goal is agreement Make concessions to cultivate relationships Be soft on the people and problem Trust others Disclose your bottom line Accept one-sided losses to reach agreement Search for the answer they will accept Try to avoid a contest of wills Yield to pressure
10 / 36
Hard (win-lose/xed pie) Negotiation I

Source: [4] Participants are adversaries Goal is victory Demand concessions as a basis of relationships Be hard on the people and problem Distrust others Dig into your position Make threats Mislead on your bottom line Demand one-sided gains as the price of agreement Search for the answer you will accept Insist on your position Try to win a contest of wills Apply pressure
11 / 36
Win-win/Principled Negotiation I
Source: [4] Participants are problem solvers Goal is a wise outcome reached eciently and amicably Separate the people from the problem (dont tie relationships to the success or failure of the negotiation.) Be soft on the people, hard on the problem Proceed independent of trust Focus on interests, not positions Explore interests Avoid a bottom line Invent options for mutual gain Develop multiple options; decide later
12 / 36
Win-win/Principled Negotiation II
Insist on objective criteria (for a successful outcome of the negotiations) Try to reach a result based on standards independent of wills Reason and be open to reason; yield to principle not pressure.
13 / 36
Win-win/Principled Negotiation III
Emphasizes: Recognize higher-level interests of the parties (e.g., get a good computing system installed, not just spend as little as possible and do as little work as possible) Recognize common ground Create a wide range of mutually benecial options Avoid entrenchment of positions; this impedes progress Try to appreciate each others point of view Follow a fair process
14 / 36
Case study: Bustard (2002) I
Source: [4] IT project for Environmental Health (EH) departments in Northern Ireland Separate the People from the Problem
Multiple clients: 29 sites in four groups Clients had signicantly dierent computing experience Some clients suspicious of the consultants independence
15 / 36
Case study: Bustard (2002) II
Focus on interests not positions. Shared interests between the four client groups:
The basic need for a computer system The additional benets of computerization The benets of working together on the system specication The need to act quickly.
16 / 36
Case study: Bustard (2002) III
Interests shared between client group and potential suppliers:

The benets of the EH client group going to tender together (one combined project simpler to manage) The benets of adopting the same system The benets of having a good working relationship with the eventual supplier.
17 / 36
Case study: Bustard (2002) IV
Invent options for mutual gain

Phased development of system: easier for suppliers to tender, reduced risk to EH client group Develop comprehensive criteria for system selection Oering exible requirements Build on existing equipment
Insist on objective criteria

Negotiate the process rst Agreeing on the selection criteria in advance
18 / 36
Basic negotiating principles I
Source: Weiss-Wik [6] Adopt a win-win outlook Prepare for the negotiation. Study the facts of the situation, set objectives, set priorities, plot a course of action. Model the other partys objectives etc. Develop bottom line/Best Alternative To a Negotiated Agreement (BATNA): if the proposed agreement is worse than your BATNA, then no point in proceeding. Be aware of tactics the other party might use; need to recognize psychological warfare
19 / 36
Basic negotiating principles II
Communicate skillfully: speak forthrightly, clearly, specically. Check assumptions and understandings to avoid misinterpretations. Come to a shared understanding of each others situations and objectives. Demonstrate willingness to cooperate and adapt: problem-solving behaviour. Find ways to build trust. Finalize agreements clearly and by your own hand whenever possible.
20 / 36
Psychology of negotiation I
Source: [1] Negotiators have an egocentrism bias
In judging fairness, parties overweight the views that favor themselves The more egocentric the negotiators are, the more diculty they have reaching agreement. Thought that egocentrism bias results from the ambiguities of the situation, e.g., how to judge what is fair ? Reducing ambiguity reduces the inuence of egocentrism; as does communication that allows negotiators to form a shared understanding of the situation.
21 / 36
Psychology of negotiation II
Mental models
Negotiators build mental models of the other negotiators objectives, the situation, etc. These inuence actions. These models can initially conict. As negotiation proceeds, people develop shared mental models. One partys belief (mistaken or not) can change the perception of reality for both parties. E.g., in an identical negotiation task, people who are told they are negotiating with a business person will behave dierently than those told they are negotiating with a friend The more accurate and detailed these mental models, the better the outcome.
22 / 36
Psychology of negotiation III
Mood:
Positive moods increase the likelihood that negotiators will adopt a cooperative strategy. Angry negotiators misjudge the interests of the other negotiators, are more self-centered, have worse outcomes.
23 / 36
Psychology of negotiation IV
Framing:
People tend to assume that win-lose rules are at play, even when the negotiation experiment has been set up to allow win-win outcomes. People tend to form a win-lose or win-win framing at the onset of negotiations, and stick to that mindset.
24 / 36
Psychology of negotiation V
Deception
1990s: inconclusive debate about whether deception in negotiations was a good thing, or reprehensible Deception is more likely to occur when people have individualistic motivations than when they have cooperative motivations Negotiators expectations that their partner will deceive them are inuenced by their own tendency to deceive
E.g., when partners in a negotiation are given the possibility of winning $100 or $1, people who can win $100 think their opponent is more likely to deceive, even when they know their opponent is only playing for $1.
25 / 36
Psychology of negotiation VI
Advantages of face-to-face
Face-to-face has the highest level of social presence, people develop higher level of rapport, trust, & cooperation than with audio only or computer-mediated communication. People are less likely to deceive when negotiating in person. In a situation where win-win outcomes were possible, face-to-face negotiators had better outcomes
26 / 36
Psychology of negotiation VII
Disadvantages of face-to-face
When individualistic negotiators could not see the other negotiator, they used fewer pressure tactics, less likely to impasse, and obtained higher joint prot. Cooperative negotiators did not benet from not being able to see one another Face-to-face can enhance tension when one of the negotiators has Machiavellian tendencies
27 / 36
Psychology of negotiation VIII

E-mail
Lacks social context cues People are more forthright Weakens inhibitions to socially undesirable behaviour People feel more anonymous in email; reduces evaluation anxiety and attention to social norms E.g., study of 48 groups, 24 negotiating by computer and 24 face-to-face
Via computer: 102 instances of rude or impulsive behaviour Face-to-face: 12 instances of rude or impulsive behaviour
Email negotiations suer from higher rates of breakdown.
28 / 36
Psychology of negotiation IX
Multiparty negotiations
Many pairwise relationships to consider Procedures designed to minimize conict by reducing communication backre: reduce opportunities for parties to learn about each others interests and nd win-win outcomes Agendas that require resolving issues one at a time dramatically reduces the ability to nd win-win outcomes: negotiation on many points simultaneously is necessary to nd tradeos across issues Unanimous decision rules (requiring agreement from all parties) are cumbersome but do increase the quality of agreements Constraining communication to pairs of parties at a time results in less co-operation, worse outcomes.
29 / 36
Inuence I
Famous book: Inuence: Science and Practice, Robert B. Cialdini (2000). Academic survey paper by Cialdini: [5]. In many decision-making situations, people use heuristics (fast, approximate techniques) to decide, rather than thinking things through carefully. Salespeople (and unprincipled negotiators!) can obtain compliance to requests by exploiting psychological tricks. Need to be prepared for these so you can recognize them being applied and reject them.
30 / 36
Inuence II
Thats Not All (TNA) technique:
A target is presented with an initial request, then the deal is immediately sweetened before the target can respond. First request sets an anchor; second request looks like a great deal relative to the rst request. E.g., a psychology club bake sale(!)
Condition 1: Prospective customers told cupcakes were $0.75 by salesperson A. Then salesperson B whispered into As ear, and A announced the price also included a packet of cookies. Condition 2: Prospective customers told the price was $0.75 for a cupcake and a packet of cookies. 73% of subjects in condition 1 bought; only 40% of condition 2 bought.
31 / 36
Inuence III
Liking: the more fond we are of someone, the more likely we are to comply with their request.
Friendship Physical attractiveness Even brief exposures to someone makes us more likely to comply. Perceived similarity (e.g., shared names, birthdays...)
Door-in-the-face technique
Precede request with a more extreme request that is likely to get rejected In negotiation, called extreme oers: lower expectations/anchor
Foot-in-the-door technique
Precede request with a minimal, small request so that target is likely to comply Follow with a larger request People appear to want to be consistent, so are more likely to comply with the large request.
32 / 36
Other negotiation tactics I
Good cop/bad cop Claiming to have limited authority Take it or leave it Cherry picking: assemble a fake competitors oer by combining the best parts of all the other oers Many others: if negotiating will be a party of your job, you should get training and read up on these.
33 / 36
Barry Boehms Theory W I

Source: [2, 3] A project management model introduced by Barry Boehm Theory W: Make everyone a winner Establish a set of win-win preconditions
Understand how people want to win (e.g. professional growth for developers; easy-to-use systems with readable documentation for users, ...) Establish reasonable expectations: users usually dont understand what is hard vs. easy to achieve. Need to educate them. (e.g. p. 905 [3]). Match peoples tasks to their win conditions Provide a supportive environment
[Theory W] holds that software project managers will be fully successful if and only if they make winners of all the other participants in the software process: superiors, subordinates, customers, users, maintainers, etc.
34 / 36
Barry Boehms Theory W II
Structure a win-win software process

Establish a realistic process plan Use the plan to control the project Identify and manage your win-lose or lose-lose risks Keep people involved
Structure a win-win software product

Match product to users and maintainers win conditions
e.g. [3, p. 906]
35 / 36
Bibliography I
[1] Max H. Bazerman, Jared R. Curhan, Don A. Moore, and Kathleen L. Valley. Negotiation. Annual Review of Psychology, 51(1):279314, 2000. [2] B. Boehm and R. Ross. Theory-W software project management: a case study. In ICSE 88: Proceedings of the 10th international conference on Software engineering, pages 3040, Los Alamitos, CA, USA, 1988. IEEE Computer Society Press. [3] B. W. Boehm and R. Ross. Theory-w software project management principles and examples. IEEE Trans. Softw. Eng., 15(7):902916, 1989.
36 / 36
Bibliography II
[4] David W. Bustard. An experience of principled negotiation in requirements. In Australian Workshop on Requirements Engineering, November 27 2002. [5] Robert B. Cialdini and Noah J. Goldstein. Social inuence: Compliance and conformity. Annual Review of Psychology, 55(1):591621, 2004. [6] Stephen Weiss-Wik. Enhancing negotiators successfulness: Self-help books and related empirical research. Journal of Conict Resolution, 27(4):706739, December 1983.
37 / 36
Chapter 16
Systems ThinkingHard vs Soft SystemsWicked ProblemsEmergent PropertiesDesign in a Systems ContextIronies of AutomationSocial costs of ComputerizationExplicit vs Tacit Views of WorkSystems Thinking in Software DesignProblem FramingSoft System MethodsEthnographySoft Systems Methodlogy (SSM)CATWOESystem Diagrams and Rich Pictures
809
SE362 Lecture 17: Systems Thinking, Soft Systems Methodology
SE362 Lecture 17: Systems Thinking, Soft Systems Methodology

July 10, 2008
1 / 54
SE362 Lecture 17: Systems Thinking, Soft Systems Methodology Todd Veldhuizen tveldhui@acm.org
Part I Review
2 / 54
Review I
Normative theories: how design ought to be done Descriptive theories: how design is actually done In practice, design work is opportunistic: not top-down but proceeding in ts and false starts, with repeated iterations, and any goal or subgoal may be attacked at any moment... [3] Design media need to accomodate how people design, but often fail to do so; media of choice remain
paper and pencil / whiteboard ASCII text
Design communities Metaphor Expertise
3 / 54
Part II Systems Thinking
4 / 54
Hard and soft systems I
Hard systems are technological, have clear boundaries, interactions, etc.

E.g., towers of hanoi
Soft systems contain a large human component: social, political, cultural, socially constructed reality
E.g., computerization of medical records
5 / 54
Example: computerization of hospital medical records I

Consider a project to computerize patient medical records at a hospital. Many stakeholders with conicting goals (patients, nurses, doctors, labs, govt, management, researchers, accounting, transcriptionists, ...) High reliability requirement High security/condentiality requirement High level of government regulation High degree of autonomy (self-governance instead of top-down chain-of-command)
6 / 54
Example: computerization of hospital medical records II
Intense politics: longstanding resentments, power struggles The hospital is an intersection of several highly rened cultures (the nursing profession; doctors; business; information systems; laboratories; etc.) all of which have their own viewpoint, terminology, values, needs, etc.
7 / 54
Example: computerization of hospital medical records III

The medical record has numerous uses: recording patient info, care planning, research studies, nancial accounting, reporting to government, disease control reporting, coroner, justice system. The medical record is a boundary object that serves as a social glue between stakeholders. Each stakeholder has a fundamentally dierent view of what a medical record is. Computerizing the medical record will radically change or eliminate numerous jobs, and alter the political/power structure of the hospital. A very soft system!
8 / 54
Wicked Problems I
Idea due to Rittel [8] that has been adopted/appropriated by the software community Social system problems that
lack a denitive formulation have no stopping rule have no true or false answers, just better or worse ones have no immediate or ultimate way to test a solution every implemented solution leaves traces that cannot be undone (e.g. cannot build a freeway to see how it works.). Makes it hard to prototype. no way to exhaustively describe all possible solutions every wicked problem is essentially unique every wicked problem can be considered a symptom of another problem (e.g., crime poverty political system ...)
9 / 54
Wicked Problems II
choice of solution depends on how you choose to explain the source of the problem: framing is an essential and instigating activity
10 / 54
Systems thinking I
System = elements + relationships Emphasize holism (behaviour determined by system as a whole) over reductionism (behaviour explained by behaviour of subsystems)
holism: the view that an organic or integrated whole has a reality independent of and greater than the sum of its parts
Every system is part of a larger system, and every system can be partitioned into smaller systems. Interactions between components of a system can be subtle and lead to unpredictable behaviour
11 / 54
Emergent properties I
A property is said to be systemic if none of the component parts of a system have it, but the system as a whole possesses it. Emergent properties: Emergence is generally understood to be a process that leads to the appearance of structure not directly described by the dening constraints and instantaneous forces that control a system. [2] Weak emergentism: takes the position that emergent properties are systemic properties determined by the way the system components are arranged [10].
12 / 54
Emergence: layered reality I
13 / 54
Emergence: layered reality II
14 / 54
Emergence: layered reality III
15 / 54
Emergence: layered reality IV
16 / 54
Emergence: layered reality V
17 / 54
Emergence: layered reality VI
18 / 54
Emergence: layered reality VII
19 / 54
Emergence: layered reality VIII
20 / 54
Emergence: layered reality IX
21 / 54
Emergence: layered reality X
22 / 54
Emergence: layered reality XI
23 / 54
Implications of emergence I
Reductionism (i.e., understanding a system by understanding its components) is of limited use Changes to components can have unpredictable implications on the next layer up To successfully intervene in a system, we may need to understand and model it at various levels:
A software component The library of which it is a part The process The distributed system The socio-technical system (comprising the computer systems, the people using it, and the organization) The organization and its niche in the business ecology
24 / 54
Design in a systems context I

We shape our tools and they in turn shape us. Marshal McLuhan
1 design
system ] emergent eects

t
implement
When technology is injected into a setting, the roles and responsibilities of those in that setting change. K. Cass (1996)
25 / 54
Story time: Unintended consequences I
1. Trouble Ticketing System [5] 2. Big Bank [5] 3. HELP System [5]
26 / 54
Ironies of automation [1] I

Attempts to automate processes often create new problems. ... the designer who tries to eliminate the operator still leaves the operator to do the tasks which the designer cannot think how to automate... it means that the operator can be left with an arbitrary collection of tasks, and little thought may have been given to providing support for them. [1] Automation can take away all the straightforward tasks, leaving the operator in the role of dealing primarily with exceptional workows Automation can turn expert operators into inexpert ones, because they are no longer able to keep their skills fresh (1.1.1)
27 / 54
Social costs of computerization I
From [5] Displacement: computerization can lead to job loss and job insecurity Intensication: working harder and longer. Increased workplace stress due to electronic monitoring. Reduction or redenition of skill Loss of work autonomy and control
28 / 54
Explicit vs. tacit views of workplace I

Applying hard systems thinking to soft problems often results in computer systems designed around some nominal, idealized picture of workows, and may not account for:
How people actually work Exceptional workows ...misunderstandings of the true context of work become embodied in computer-based systems, with negative consequences not only for the people who do the work, but also for the productivity and eciency that the system is intended to enhance. [5]
Nominal/explicit view of workplace: jobs are made up of tasks that are dened in company handbook of procedures
29 / 54
Explicit vs. tacit views of workplace II
Activity-oriented/tacit: the range of activities, communication practices, relationships, and coordination that it takes to accomplish business functions is complex, and is continually mediated by workers and managers alike. An activity-oriented analysis of work centers on everyday work practiceson how employees actually make the business function eectively. ([5], summarizing Sachs (1995))
30 / 54
Systems thinking in software design I
When people are involved, projects quickly become complicated. Need to be concerned with:
social behaviour of people in groups cognitive psychology physical interaction of people with objects culture politics and power structures ethics
Layers of emergence cannot be ignored
31 / 54
Problem framing / denition I
The problem framing is how the problem is stated. It determines (1) the view of the problem context; (2) subjective emphasis/biasing/assumptions/attitudes towards certain viewpoints or solutions. Humans are very susceptible to framing eects, e.g.,
1. Positive: This ground beef is 80% lean. 2. Negative: This ground beef is 20% fat.
People rate (1) as signicantly leaner, higher quality, better tasting, and would pay more for it [6].
32 / 54
Problem framing / denition II
Sch ons idea of generative metaphor: framing the problem can introduce an implicit metaphor that casts a spell, limiting solutions to things that make sense in terms of that metaphor. E.g., referring to a problem as a blight encourages a disease metaphor, and makes solutions that are similar to disease treatment more plausible [9]. Reframing the problem in terms of a dierent metaphor can lead to new solution ideas.
33 / 54
Problem framing / denition III
Systems thinking emphasizes taking a big picture view: e.g., understanding the problem in its full social/political/cultural context. A basic tenet of systems thinking: reject the initial problem framing, and seek a framing that is broad and does not bias toward a particular solution. Example:
A large architecture rm needs very-high resolution scanners and plotters to convey sketches and drawings among a geographically distributed team.
Problem framing / denition IV
Designers at a large architecture rm are not able to work eectively in distributed teams because they cannot show their sketches to each other quickly enough. (Better.) Possible solutions:
consolidate the rm in one location dont use distributed teams use courier services use high-denition teleconferencing use high-res scanners + plotters; etc.
Design techniques for wicked problems I
There are numerous methodologies for dealing with wicked problems that are heavy with human/organizational issues: Participatory design Soft Systems Methodology Sociotechnical design Structured Planning Human-Centered Design Activity-Centered Design Social informatics
36 / 54
Common themes for soft system methods

Big picture view of system Reject initial problem framing; view problem structuring as an activity of fundamental importance Approach the problem with a degree of humility: view the system, workows, roles as a complex response to needs you (as a designer) only imperfectly understand Need to model systems, understand layering, emergence, etc. User/stakeholder involvement, possibly to the point of co-determination (joint decision making between designers and users) Design as if people mattered Understanding how design will reshape the system
37 / 54
Greenbaum and Kyng I
Four issues for design ([5], describing work of Greenbaum and Kyng): 1. The need for designers to take work practice seriouslyto see the current ways that work is done as an evolved solution to a complex work situation that the designer only partially understands 2. The fact that we are dealing with human actors, rather than cut-and-dried human factorssystems need to deal with users concerns, treating them as people, rather than as performers of functions in a dened work role.
38 / 54
Greenbaum and Kyng II
3. The idea that work tasks must be seen within their context and are therefore situated actions, whose meaning and eectiveness cannot be evaluated in isolation from the context 4. The recognition that work is fundamentally social, involving extensive cooperation and communication
39 / 54
Ethnography I
Ethnography is a qualitative research method for observing people in their typical settings, and has been adapted to software design from cultural anthropology. Asking people what they do is risky: often people dont do what they say they do. Instead, observe people at work, & possibly do that work yourself, and try to understand the system from the inside. Seek an emic perspective:
emic = native point of view, without imposing your own viewpoint etic = outsiders perspective
Within one system, there can be several distinct emic perspectives; each stakeholder has a dierent subjective experience of the system (cf. umwelt) Methods: eldnotes, interviews with open-ended questions, gather samples of work/documents, etc.
40 / 54
Ethnography II
Example: study of CAD use in a mechanical design setting [4]:

Researcher studied the rm for over a year: volunteered as a technical writer in exchange for access to the site, was known as the resident sociologist. Was able to write a detailed, qualitative explanation of how design objects (sketches, CAD les, etc.) were used, how designers interacted with machinists and managers, etc., and describe some of the failings of CAD systems.
41 / 54
Soft Systems Methodology (SSM)
A methodology for tackling messy, real-world situations: human activity systems Take seriously the idea of holism, emergent properties: reject reductionism, interesting properties may have no meaning in terms of the components Build models of the whole system, to understand interactions and emergent properties
42 / 54
Peter Checkland interview
Peter Checkland developed Soft Systems Methodology (SSM). http: //www.open2.net/systems/practice/pet.html
43 / 54
SSM: basic ow
Problem situation considered problematic Problem situation expressed Root denitions of relevant purposeful activity systems (i.e. tackle ontology: decide what exists, name concepts) Conceptual models of the systems: social systems, political systems, etc. Comparison of models and real world Changes: systemically desirable, culturally feasible Action to improve the problem situation
44 / 54
SSM: transformation process
A transformation process has inputs and outputs A system may comprise numerous transformation processes, and which of these are interesting depends on point-of-view E.g., a public library:
a local population that population better informed books dog-eared books local need for information and entertainment that need met local provision of education that provision enhanced books on the shelves books in the community etc.
45 / 54
Root denitions: CATWOE
Root denitions (ontology) found by considering, for a transformation process T: Customers: beneciaries/victims of T Actors: those who would do T Transformation process: conversion of input to output Weltanschauung: the worldview which makes T meaningful in context Owner(s): those who could stop T Environmental constraints: elements outside the system which it takes as given
46 / 54
System diagram / Rich picture
A system diagram portrays the components of a system and their interactions In software, rich pictures are one popular approach developed by Peter Checkland. These are cartoonish drawings that illustrate the system structure, processes, and concerns of actors (as thought bubbles).
47 / 54
Rich picture example
Source: [7]
48 / 54
Example system: railway maintenance defect reporting
Source: Jeremy Rose

49 / 54
50 / 54
Bibliography I
[1]
Lisanne Bainbridge. Ironies of automation. In J. Rasmussen, K. Duncan, and J. Leplat, editors, New Technology And Human Error, pages 271283. J. Wiley and Sons, New York, 1987. bib pdf
[2] James P. Crutcheld. Is anything ever new? considering emergence. In G. Cowan, D. Pines, and D. Melzner, editors, Santa Fe Institute Studies in the Sciences of Complexity, volume XIX. Addison-Wesley, Reading, MA, 1984. bib
ps
51 / 54
Bibliography II
[3]
T. R. G. Green. Cognitive dimensions of notations. In Proceedings of the HCI89 Conference on People and Computers V, Cognitive Ergonomics, pages 443460, 1989. bib pdf
[4] Kathryn Henderson. Flexible Sketches and Inexible Data Bases: Visual Communication, Conscription Devices, and Boundary Objects in Design Engineering. Science Technology Human Values, 16(4):448473, 1991. bib pdf
52 / 54
Bibliography III
[5] Sarah Kuhn. Design for people at work. In Terry Winograd, editor, Bringing design to software, pages 273294. ACM Press, New York, NY, USA, 1996.
bib pdf
[6] I.P. Levin, G. J. Gaeth, J. Schreiber, and M. Lauriola. A new look at framing eects: Distribution of eect sizes, individual dierences, and independence of types of eects. Organizational Behavior and Human Decision Processes, 88:411429(19), 2002. bib pdf [7] Andrew F. Monk and Steve Howard. Methods & tools: the rich picture: a tool for reasoning about work context. Interactions, 5(2):2130, 1998. bib pdf
53 / 54
Bibliography IV
[8] H. Rittel and M. Webber. Dilemmas in a general theory of planning. Policy Sciences, 4:155169, 1973. bib pdf
[9] D. Sch on. Generative metaphor: A perspective on problem setting in social policy. In A. Ortony, editor, Metaphor and Thought. Cambridge University Press, 1978. bib [10] Achim Stephan. Varieties of emergentism. Evolution and Cognition, 5(1):4959, 1999. bib pdf
54 / 54
Chapter 17
Intellectual Property ManagementPatentsSubmarinesMonetizationAbuses and TrollsPrior ArtDefensive PublishingInfringementTrade SecretsCopyright
864
SE362 Lecture 18: Intellectual Property Protection
SE362 Lecture 18: Intellectual Property Protection

July 15, 2008
1 / 21
Sources
SE362 Lecture 18: Intellectual Property Protection Todd Veldhuizen tveldhui@acm.org
A practical guide to software licensing for licensees and licensors, 2nd edition, H. Ward Classen (2007). A Review of Software Patent Issues, Russell McOrmond (2003). Disclaimer: The information in these lectures should be viewed as my reasonable eort to understand the material. You should not rely on this information as legal advice. Seek qualied counsel.
2 / 21
Kinds of Intellectual Property
Patents Trade secrets Copyrights Trademarks
3 / 21
Patents
4 / 21
Patents I
An exclusive right to practice an invention granted by the government: a government-sanctioned and protected monopoly. Invention must be
useful (has industrial applications) novel (not already invented, as evinced by prior art) unobvious (not obvious to someone skilled in art)
Patent holder is required to disclose the invention in full, clear, and exact terms. Software was not considered patentable until fairly recently in the US. In 1981 the US Supreme Court in Diamond v. Diehr ruled that the execution of a process, controlled by running a computer program, was patentable. (Not software itself, per se). Europe: as of 1985, software patentable
5 / 21
Patents II
Canada: patent act says, No patent shall be granted for any mere scientic principle or abstract theorem. but does not mention software. Terms of patents are about 20 yrs from ling date in the US. Many challenges caused by patents:
Patent oce examiners are often not skilled enough to judge whether a specialized patent is useful, novel, or unobvious. E.g. take any activity X that people do, and patent Method and apparatus for X on a computer network (shopping, transactions, order fulllment, testing software, marketing, ...) The legal test of unobvious is applied subjectively; the USPTO routinely issues patents on things that are believed to be obvious and/or well-known
6 / 21
Patents III
Widely believed that many/most patents are invalid due to prior art, called junk patents. But, onus is on the challenger to prove this; expensive litigation is required to have a patent ruled invalid. Courts must presume a patent is valid until the USPTO re-examines the patent and rules it invalid. So many basic ideas have been patented that it is very dicult to write software without infringing on patents Only certain forms of published work are considered prior art, e.g., if you distribute your software on the internet, this is not generally considered prior art. IP suits are extremely costly; generally in the US, a patent contest costs $250,000 for just the initial steps
7 / 21
Patents IV
Patents comprise multiple claims, which can be invalidated separately. Generally people write their patents as broadly as possible, with many overlapping claims, so that even if some claims are ruled invalid, the remaining will stand. E.g., one patent might cover 40 minor variations on a single idea. There is no requirement that the patent holder be actively trying to exploit the invention Patents can be bought and sold in special markets (e.g., Ocean Tomo)
8 / 21
Patent Cooperation Treaty

International treaty, 1970 Unied procedure for ling patent applications in the participating states (an international application or PCT application) Patents are issued by individual countries (no such thing as an international patent) Applicant les an international application in one country; one of the applicants must be a citizen/resident of that country Application is published 18 months after ling After 30 months, patent application enters national phase during which patent applications are led with individual countries Advantages: can defer ling patents in other countries up to 30 months (rather than within 1 year of disclosure). Costs about $4000
9 / 21
Submarine patents
Submarine patent: patent is issued many years after it is led In the interim, many companies may have based their business model on ideas that turn out to infringe the patent. Most countries publish applications 18 months after ling, regardless of whether the patent has been issued; this reduces the potential for submarine patents In 2000, USPTO started publishing patent applications 18 months after ling.
However, patent holders can now obtain royalties for infringement that occurred after the patent was published (but before it was issued). Applicants can be exempted from publishing if they promise not to patent the invention in another country that requires publication, or le for rights to the patent under e.g. the Patent Cooperation Treaty
10 / 21
Exploiting patents I
Patents can be monotized in several ways:

1. By using the patent to protect a monopoly position, i.e., actively marketing a product that exploits the invention 2. By licensing the patent to other parties 3. By litigating other parties for infringement.
11 / 21
Patent abuses I
Deliberately ling submarine patents and keeping them pending for many years, in the hope of snaring large numbers of potential infringers when the patent is issued Large rms can bludgeon small competitors with the threat of patent litigation, even if no real infringement exists Some rms (patent enforcement entities a.k.a. patent trolls) entire business model consists of maintaining a large portfolio of junk patents acquired on the open market, and litigating to force businesses into paying steep license fees.
12 / 21
Prior art I
Trade secrets are not considered prior art (e.g., Company X takes out a patent on an algorithm Company Y has been using for years. Not considered prior art. But, in some jurisidictions Company Y can claim prior user rights.) Prior art must be published publicly, provide enough detail that a person skilled in the art could implement it. Many countries require the information to be recorded in a xed form (e.g., published in paper form). In EU, oral disclosures are considered prior art. Prior art does not have to be published in the country in which the patent has been led
13 / 21
Patent exclusions I
US patent exclusions: A person shall be entitled to a patent unless...

invention was known or used by others in the US, or was patented or described in a printed publication in any country before the date of invention invention was patented or described in a printed publication in any country more than one year prior to the date of application for patent inventors must le for patent with in one year of the publication, public use, or marketing of an invention.
14 / 21
Defensive publishing
Purposefully publishing an invention to prevent competitors and/or patent trolls from
15 / 21
Patent infringement
Infringement: practicing the invention without license from the patent holder. Legal tests vary, but generally it must be shown that the infringers product falls within one of the claims of the patent. In international cases, liability is only for infringement that occurs within the country for which the patent is valid (i.e., a Canadian company cannot be eectively sued for marketing software solely in Canada that infringes a US patent). To defend against infringement, generally ght both in civil court (arguing that no infringement occurred) and with the patent oce (arguing that the relevant claims of the patent are invalid).
16 / 21
Trade secrets I
Economically valuable information (e.g., software, techniques, methods) that is hard for outsiders to discover independently, and is the subject of reasonable eorts to maintain its secrecy Overlaps with what can be patented; but, some things can be protected as trade secrets that could not be patented. Misappropriation: the trade secret equivalent of infringement.
acquisition of the trade secret by shady means disclosure or use of the trade secret without express or implied consent by someone who knew or had reason to know that the trade secret had been improperly acquired, or there was an obligation to maintain its condentiality
17 / 21
Trade secrets II
Trade secrets must be actively kept secret; the purpose of patents is to publicly publish inventions but maintain the kind of protection that trade secrets provide Trade secrets are protected indenitely by law (unlike patents, which expire and pass into the public domain) A competitor that is able to independently reproduce a trade secret is free to do so Provides broader protection than copyright: e.g., source code can be copyrighted, but the concept cannot. However, the concept can be protected as a trade secret. Skills and experience obtained during the course of an employees employment are not considered trade secrets.
18 / 21
Trade secrets III
If misappropriation occurs, the owner of the trade secret can seek relief and damages for both the loss that occurred to the company, and unjust enrichment that occurred as a result of the misappropriation
19 / 21
Copyrights I
Copyright protects works of authorship xed in any tangible medium of expression, now known or later developed, from which they can be perceived, reproduced, or otherwise communicated, either directly or with the aid of a machine or device. Excludes ideas, procedures, processes, systems, methods of operation, concepts, principles, discoveries e.g. it protects source code, but not the ideas, concepts, algorithms in it, or the operations it performs Copyright prevents others from copying code without the owners permission Does not prevent others from reverse-engineering
20 / 21
Copyrights II
It is not necessary to put (C) 2008 Me in your code. However, doing so eliminates any possible claim that someone innocently copied the code without knowing it was copyrighted. (The equivalent of putting up a fence and a no trespassing sign.) A registered copyright can be obtained by ling some paperwork and fees. Benets (in the US):
Can obtain up to $150,000 in damages for intentional infringement without needing to prove loss, and the right to obtain attorneys fees Is proof of the validity of the copyright, so that the onus is on the infringer to prove in court that the owner was not entitled to the copyright. Can be used to prevent the importation of infringing copies of the work.
21 / 21
Chapter 18
Software LicensingTransferring Intellectual Property RightsPerpetual vs Fixed-TermPermitted UseExclusivityDerivative WorksReverse EngineeringRerpesentations and Tort LawWarrantiesDisclaimersIndemnities
886
SE362 Lecture 19: Software Licensing Todd Veldhuizen tveldhui@acm.org
SE362 Lecture 19: Software Licensing

July 17, 2008
1 / 21
Sources & References
A practical guide to software licensing for licensees and licensors, 2nd edition, H. Ward Classen (2007). Canadian Intellectual Property Oce (CIPO) http://www.ic.gc.ca Open Source Licensing: Software Freedom and Intellectual Property Law, Lawrence Rosen. (Available in print and as a free e-book). Disclaimer: The information in these lectures should be viewed as my reasonable eort to understand the material. You should not rely on this information as legal advice. Seek qualied counsel.
2 / 21
Transferring Intellectual Property Rights
IP rights can be given to another party in two ways:

assignment: the current owner transfers all the rights (i.e. ownership) to another party. Such transfers must be made in written agreements. license: the owner grants certain rights to another party, but retains ownership
3 / 21
Basic license terminology
Licensor: holds the IP and/or has the right to grant a license Licensee: the entity/entities that are receiving the license. Depending on wording of the license, may include or exclude subsidiaries, etc. Exclusive license: the licensor promises not to license the software to anybody else. Eectively, such a license is a transfer of copyright ownership for the period of the license.
4 / 21
Who is the licensee?

If you are acquiring a license to use some software, you should think carefully about who is the licensee: If your company is sold, merges, or your unit is spun o or acquired, will you still have the right to use the software? (Usually you would want to reserve the right to transfer the license to a subsidiary/spin-o/etc.) If you retain consultants, will they be licensed users? (ditto outsourcing) Will subsidiaries of your company be covered by the license? Do the terms of the license require the software be used only in a particular country?
5 / 21
Perpetual vs. xed-term licenses I

In principle, a perpetual license does not expire; the licensee has rights to the software more-or-less indenitely, provided they do not violate the terms of the license. (There are some exceptions, e.g., in the US, the licensor can terminate the license after 35 years if they provide advance written notice of at least two years and at most 10 years, and to so before 40 years after the license is granted. Generally such exceptions occur far longer after the software would become obsolete.) A perpetual license provides protection for the licensee in the event that the licensor decides to discontinue the software or goes bankrupt. It also protects the licensee from abrupt and arbitrary increases in license fees.
6 / 21
Perpetual vs. xed-term licenses II

To protect a licensee who licenses software in compiled form, some license agreements require that the source code be placed in escrow (i.e., in the custody of a third party), to be disclosed to the licensee in the event that the licensor fails to support the software, goes bankrupt, etc. Often licenses are perpetual and irrevocable (or perpetual and nonterminable): the licensor cannot revoke the license (a perpetual license that is not irrevocable is essentially saying You can use the software until we decide otherwise.) To protect the licensor, generally say Subject to the provisions of this agreement, the licensee is granted a perpetual and irrevocable ...., so that it is clear that violation of the license terms is grounds for terminating the license.
7 / 21
Perpetual vs. xed-term licenses III
To grant a license that is in eect perpetual but still collect annual license fees, a license can be for one year, but renewable at the sole discretion of the licensee, with license fees expressed in real dollars (i.e., pegged to an ination index.) Annual or monthly licenses are increasingly common: provides a steady revenue stream for the licensor, and a smaller up-front cost for the licensee.
8 / 21
Uses a license permits I
A license grants the right to use some software, subject to certain restrictions. E.g. Visual C++ infamously came with a license that prohibited users from publishing benchmark results It is very important to spell out in the license exactly what uses the license permits and prohibits, e.g.: Use shall mean the ability to run, execute, duplicate, and distribute internally the Licensed Software in its Object Code form. NB Contra Proferentem: ambiguities in an agreement are interpreted against the party that imposed it.
9 / 21
Uses a license permits II
Restrictions should be spelled out in a way that their violation results in specied consequences:
revocation of the license injunctive relief for copyright/IP infringement (i.e., the licensor can try to recover damages through the courts)
Basic copyright-related uses:

reproduction (i.e. copying) preparing derivative works distributing copies of derivative works
10 / 21
Uses a license permits III
Licenses often limit use to the licensees internal business purposes only. This prevents e.g., someone purchasing a compiler and making it available online as a service. Any specic uses the licensee wants to prevent should be spelled out, as internal business purposes is ambiguous (hence contra preferentem could apply.)
11 / 21
Exclusive vs. Non-exclusive
A non-exclusive license means the licensor is free to license the software to other parties. An exclusive license could be considered if the software would provide a unique competitive advantage. However, note that a perpetual, exclusive license is almost the same as a permanent transfer of copyright The licensor will generally want to ensure that exclusive licenses are limited in time, geographical region (in which case think carefully about internet distribution and SaaS), or vertical
12 / 21
Per-user, per-cpu, etc. licenses
Licenses can restrict the use of the software to a specic computer, a specic operating system, specic site, a number of seats (users) or number of concurrent users. Licensee should consider wording that will protect them in the event of a failure of a computer system or site, e.g., having the right to temporarily transfer the license to a backup site if a catastrophic failure occurs. Licenses that allow the use of software in multiple countries need to be considered carefully; such licenses would be governed by the laws of the foreign country, possibly with unpredictable consequences
13 / 21
Derivative works
Derivative works is a term that exists in US copyright law (but not Canada) If a license permits the creation and distribution of derivative works, the licensor should be careful to protect their interests:
E.g. if distributing a software library, is the licensee prohibited from wrapping that library in a value-added API and selling it? Generally, the licensor should try to prevent redistribution that would deprive it of revenues (i.e. redistributing a derivative work that competes with the software) In some countries (e.g. US) if the derivative work is suciently dierent from the original work, the licensee would attain copyright ownership of it. To avoid this possibility, licensors can require licensees to assign copyright ownership of any derivative works to the licensor.
14 / 21
Reverse engineering
If software is distributed in object/compiled form, licenses often prohibit reverse engineering. This prevents a competitor from licensing the software, and then examining it carefully to produce a competing product. In the US, DMCA prohibits reverse engineering In the US and EU, reverse engineering is permitted for interoperability (e.g., reverse engineering a le format so it can be read by another application) In Canada, C-61 is interpreted by some as prohibiting reverse engineering; denitely it makes it easy to package your software in such a way that reverse engineering is prohibited (e.g., encrypting it; C-61 specically prohibits circumventing protection measures by decrypting 41).
15 / 21
Representations I
Licensing software immediately puts the licensor at risk of lawsuits under tort law. Tort law refers generally to laws that let people litigate to recover damages. This is separate from contractual provisions, copyright infringement, etc. To seek remedy under tort law, the plainti must demonstrate that damages were caused to them A licensee could seek to recover damages if the licensor made representations (statements of facts) that turned out to be false in a way that caused harm, or if the licensor made warranties (promises that certain facts would be true) that turned out to be false and caused harm.
16 / 21
Representations II
E.g. if a salesperson claims the software will solve a problem, and it doesnt, the licensor could be accused of fraudulent misrepresentation Need to be concerned with several types of damage:
direct: e.g., the amount of money the licensee paid for some software that didnt function consequential, e.g., the amount of business the licensee lost because the software didnt work
Licenses usually have wording that limits liability, e.g., limiting liability to the amount of the license fee.
17 / 21
Representations III
E.g.: No party.. will be liable for any consequential (including, without limitation, lost revenues and prots), incidental, indirect, special, or punitive damages whatsoever arising out of or relating to this agreement even if such party has been advised in advance of the possibility of such damages... The maximum, total, aggregate liability [of the parties] under this agreement shall not in any event exceed the amount payable under this agreement.. Limitations of liability may not protect the licensor if they made misrepresentations about the software (e.g. the licensee can rescind the contract)
18 / 21
Warranties
A warranty is a promise that certain facts will be true Shrink-wrap software (where the license is written solely by the licensor) generally avoids making few or any warranties. When the license is drafted by both sides, the licensee will generally demand certain warranties be made by the licensor, e.g., performance standards, compatibility, data integrity, free from viruses & trapdoors, does not infringe on 3rd party IP, does not contain any GPL software Licensor needs to be cautious with making warranties. And, ensure there are no implied warranties by saying, e.g., Except as set forth in section..., the licensor makes no other representations, warranties, or conditions to the licensee whatsoever...
19 / 21
Disclaimers
disclaimer = a statement that denies responsibility for something Unless specied otherwise, licenses generally imply certain warranties, especially merchantability: that the software is reasonably t for the purpose for which it is sold Licensors generally try to disclaim any implied warranties, e.g., merchantability It is generally a good idea to disclaim certain specic things: uninterrupted service, free of defects, etc.
20 / 21
Indemnication
An indemnity is a promise to protect a party from third-party lawsuits E.g., if I license software X from WatSoft, and then GuelphSoft decides that WatSoft infringed its IP, then GuelphSoft might seek damages from me also. If I oer consulting services using software X, and make claims about it, then someone might seek damages from me for misrepresentation, and also seek damages from WatSoft Indemnications promise to absolve the other party in the event of certain lawsuits. Generally indemnify the entity as well as its ocers, directors, employees and agents.
21 / 21
Part I Bibliography
22 / 21
Bibliography I
23 / 21
Chapter 19
Project RetrospectivesPricing of Software LicensesDevelopment ContractsTermination and Breaches
910
SE362 Lecture 20: Software Licensing

July 22, 2008
1 / 28
Reminder
No class on thursday due to SE-2 deadline.
2 / 28
Project retrospectives I
Project retrospectives are reviews of a project after it nishes. (Previously called postmortem project reviews.) Aim: think about how things went, what to do dierently in the future. Two styles:
User-focused review: done from the users viewpoint. Developed-focused review: done from the developers viewpoint.
Norman Kerths Four Key Questions:

1. What did we do well, that if we dont discuss we might forget? 2. What did we learn? 3. What should we do dierently next time? 4. What still puzzles us?
3 / 28
Project retrospectives II
Typical issues to consider:
To what extent did the processes used (e.g., lifecycle, change control) help or hinder? Did we spend too much time planning? Too little? How did the SPMP compare with how things unfolded? How accurate did our estimates turn out to be? If they were o, what was the reason? How could we prevent misestimating like this in the future? How did the team perform? What assumptions did we make that turned out to be wrong? What risks developed into actual problems? What problems occurred that were not anticipated by the risk analysis? Did the project achieve its goals, not in the narrow sense of on-time and quality, but in delivering a project that will meet the business needs and/or solve the problem it was supposed to solve?
4 / 28
Project retrospectives III
Possible format:
1-3 days (depending on size of project) People prepare beforehand Experienced facilitator leads the discussion
There is a handbook by Norman L. Kerth:

Project retrospectives: a handbook for team reviews, Norman L. Kerth (2001).
5 / 28
Assignment 3
Write a 2-3 pages retrospective of your SE-2 project I will provide a structured template and list of issues to consider.
6 / 28
Part I Licensing contd
7 / 28
Pricing of software licenses
Source: H. Ward Classen, A Practical Guide to Software Licensing for Licensees and Licensors, 2nd edition Service bureau licenses Lump sum Development contracts
Time and materials Fixed price
8 / 28
Service bureau licenses
price per transaction, billed monthly (e.g. Amazon Web Services)

licensor: provides more steady revenue stream licensee: can cost longer in the long run; less risk; gives licensor an incentive to provide responsive service+maintenance
9 / 28
Lump sum
One-time payment from licensee to licensor, e.g., shrink-wrap Creates a disadvantageous situation for the licensee: once the payment is made, licensor does not have a strong incentive to provide support + maintenance
10 / 28
Development contracts I
suitable for projects where some degree of customization/integration is required, and/or ongoing maintenance is needed Time and materials:
licensor is compensated for employees time at a negotiated rate, as well as for travel, equipment, etc. disadvantage to licensee: licensor does not have strong incentive to keep costs down. suitable for situations where the scope of work is uncertain, and it would be hard to negotiate a xed price usually payable monthly dicult to budget generally advantageous to licensor in the event of a dispute, the licensee does not have much leverage: there are no payments being withheld
11 / 28
Development contracts II
Fixed price
generally advantageous to licensee higher prot opportunity for licensor, but also higher risk: can be hugely costly to licensor if a large project is underestimated. usually divide payments among milestones each milestone has carefully specied trigger for payment (e.g., acceptance, delivery, etc.)
12 / 28
Development contracts III
if payment on acceptance, licensee has higher leverage; if payment on delivery, licensor has higher leverage one way to compromise: advance payment on delivery, repayable to licensee if deliverable not accepted. An advance payment bond (issued by a bank or insurer) can be used to limit licensees risks. In this case, a third party (the surety) ensures that the obligations will be performed. In the event of a dispute, the surety would reimburse the licensee and then go after the licensor; contracts for such bonds are usually designed so this would be a nancial death sentence for the licensor, to motivate the licensor to perform their obligations.
13 / 28
Ongoing payments
Usually advantageous to split the license into two separate agreements:
a software license a maintenance contract
Typically the software license is given a short warranty period, e.g., 60 days. This limits the possible losses of the licensor in the event of a dispute; once the 60 days are up, they could usually only be required to refund the maintenance amounts. Maintenance contracts are usually 15-20% of the license fee, per year Can peg ongoing payments to an ination index. (However, be wary that licensors costs may inate faster than general consumer goods; may want to peg to specic commodity indices e.g. energy prices.)
14 / 28
Termination and breaches I

Licenses can be terminated in two ways: (1) for convenience, if the agreement includes provisions for this. Generally, the licensee will want the freedom to terminate the license. (2) if the licensor or licensee breaches the license, this may result in termination of the contract (and/or remedies and damages). Kinds of breaches:
Minor/partial/immaterial: a party breaches the literal terms of the contract, but has generally acted in good faith and the dierence between what was promised and performed is not major. The non-breaching party cannot obtain a court order requiring the breaching party to fulll their obligations, but can seek compensation for damages they have incurred.
15 / 28
Termination and breaches II

Material breach: a party fails to perform its obligations under the contract in a major way. A court can order the breaching party to fulll their obligations, or award damages. Fundamental breach: A fundamental breach occurs where the event resulting from the failure of one party to perform a primary obligation has the eect of depriving the other party of substantially the whole benet that the parties intended should obtain from the contract. An important Canadian precendent is Syncrude Canada Ltd. v. Hunter Engineering Co.: Hunter agreed to provide Syncrude with gear boxes, but they were not usable for the intended purpose, and Syncrude spent $1 M to repair them. Hunter sought to have a liability limitation clause upheld that limited their liability to 24 months after shipment. Supreme court dismissed their case: Hunter U.S. was liable for the repair of the gearboxes, even though their failure
16 / 28
Termination and breaches III

was discovered after the contractual warranty period had expired, because of a breach of the implied warranty of tness contained in s. 15(1) of the Ontario Sale of Goods Act. The Hunter U.S. contract neither explicitly excluded the implied warranty nor was inconsistent with it so as to render it inapplicable. The circumstances surrounding this contract met the conditions necessary to bring the implied statutory warranty into play. Lesson: to avoid liability, need to explicitly contract out of all statutory protections. (However, note that this particular precendent was for a sale, rather than a license.) It is up to the court to decide if a breach is immaterial, material, or fundamental.
17 / 28
Termination and breaches IV

License agreements should spell out what happens in the event of a breach by the licensee, and in the event of a breach by the licensor. Need to distinguish between types of breaches. E.g., usually a licensee can terminate the agreement only if there is a material breach of the license by the licensor. This prevents a licensee who wants to terminate the agreement from exploiting some minor, literal infraction of the license conditions. However, when specifying what happens in the event of breaches, need to understand contract law precedents. Courts have often refused to uphold contract provisions that seem unfair. Often have a cure period during which the oending party can attempt to x the breach.
18 / 28
Termination and breaches V

However, certain breaches cannot be cured, e.g., disclosing intellectual property/trade secrets. Usually the licensor can terminate the agreement immediately if these kinds of breaches occur. Licensees will usually try to include a provision that will let them continue using the software until a dispute is resolved, and to continue using the software for a reasonable time after the license is terminated, to give them time to nd a replacement. Licensee should get language requiring licensor to correct serious problems Licensee should try to get language stating that the licensor cannot walk away from the contract if it becomes unprotable (specic performance). However, this creates the potential of unbounded losses for the licensor.
19 / 28
Termination and breaches VI

Some licenses may require parties to submit to binding arbitration, as a way of reducing potential litigation costs and headaches. To guard against late deliveries, a licensee can seek to have liquidated damages included in the agreement. These are damage amounts specied in the license agreement that will be automatically awarded to the licensee in the event of specic breaches. (E.g., $50,000 for each month late delivery or part thereof). Courts will only uphold liquidated damages if they approximate the actual damage suered. Also, courts can decide that the licensee was part of the problem that caused a delay, and refuse to uphold the damage amounts.
20 / 28
Part II Bibliography
21 / 28
Bibliography I
22 / 28
Chapter 20
Open SourceFree Beer LicensesGNU Public LicenseLGPLOther OSS LicensesDual LicensingSoftware Process AssessmentCapability Maturity ModelCMMICMMI vs AgileSPICE
933
SE362 Lecture 21: Software Licensing, CMMI
SE362 Lecture 21: Software Licensing, CMMI

July 29, 2008
1 / 34
Reminders + Announcements
SE362 Lecture 21: Software Licensing, CMMI Todd Veldhuizen tveldhui@acm.org
Last years nal posted on website Final is, I believe, Saturday August 9 from 7:30-9:30pm. Im travelling next week (returning late on friday) but will try to respond promptly to emails.
2 / 34
Part I Open Source
3 / 34
Free beer licenses I
Suppose you post software you wrote on the web and say I wrote this software; you can do whatever you want with it. Good idea?
4 / 34
Free beer licenses II
Probably nothing bad will happen. However, have you have potentially exposed yourself to liability? Possibility that someone could use your software, it fails and causes damage, and they come after you under tort law. Generally, if you are going to release software, always try to put in disclaimers. Better yet, use a standard license (GPL, BSD, MIT, Apache, etc.)
5 / 34
Open source licenses I
Two main varieties:

GPL-style licenses: require derived works to be available under the same license Permissive open source licenses (e.g. BSD, MIT)
Confusion arises from two concepts of free software: libre (freedom/liberty) and gratis (no cost)
6 / 34
GPL I
http://www.gnu.org/licenses/gpl.html Free software is a matter of liberty, not price. To understand the concept, you should think of free as in free speech, not as in free beer. (Richard Stallman) Basic freedoms:
1. The freedom to run the program for any purpose. 2. The freedom to study and modify the program. 3. The freedom to copy the program so you can help your neighbour. 4. The freedom to improve the program, and release your improvements to the public, so that the whole community benets.
GNU Public License (Version 3, June 2007) GPL permits distributing verbatim copies of the source code. Need to keep license, copyright, etc. notices intact, and distribute the license.
7 / 34
GPL II
Can charge money for conveying copies. If you modify the source and want to distribute this modied version, you must place notices of this in the code, and release the entire work under GPL. Need to display notices in GUI, if applicable. Derived works also have to be GPLed (copyleft). What constitutes a derived work? tricky. If distribute in object form, must also distribute source or provide free access to it. System library exception: dont need to distribute source for system libraries e.g. libc, libstdc++ Cannot distribute programs that link to libraries with GPL-incompatible licenses
8 / 34
GPL III
Using GPLed software for commercial applications is tricky. The Free Software Foundation (FSF) maintains that if you dynamically link to a GPLed library, this constitutes a derivative work if the executable and GPL code make function calls to each other and share data structures. There is no clear legal precedent here. Hence, commercial software companies should be cautious in using GPLed code.
9 / 34
LGPL
Lesser GNU Public License Also known as Library GPL Does not place restrictions on software that links with a GPLed library, as long as the GPLed library is not modied: A program that contains no derivative of any portion of the Library, but is designed to work with the Library by being compiled or linked with it, is called a work that uses the Library. Such a work, in isolation, is not a derivative work of the Library, and therefore falls outside the scope of this License.
10 / 34
BSD/MIT/etc. licenses
Permissive free software licenses Permits distribution in either source or binary form In binary form, must include copyright notice, conditions, and disclaimers Includes disclaimers of warranty + liability More friendly for commercial use
11 / 34
Dual licensing
A business model: release software under a free license for noncommercial use to support open source projects + encourage community involvement. Simultaneously sell the software under a more restrictive license for commercial use. Success stories: Trolltech, MySQL, etc. (Trolltech bought by Nokia for 104 million EUR in Jan 2008).
12 / 34
[1] CMMI Product Team. CMMI for Development, Version 1.2. Technical Report CMU/SEI-2006-TR-008, Carnegie Mellon Software Engineering Institute, August 2006. [2] Robert T. Futrell, Donald F. Shafer, and Linda I. Shafer. Quality Software Project Management. Prentice-Hall, 2002. [3] Donald J. Reifer. The CMMI: its formidable. Journal of Systems and Software, 50(2):9798, 2000. [4] Terence P. Rout. ISO/IEC 15504Evolution to an international standard. Software Process Improvement and Practice, 8:2740, 2003. [5] Walker Royce. CMM vs. CMMI: From conventional to modern software management.
13 / 34
Technical report, Rational Software Corporation, February 2002. [6] Richard Turner and Apurva Jain. Agile meets CMMI: Culture clash or common cause? In Don Wells and Laurie A. Williams, editors, Extreme Programming and Agile Methods - XP/Agile Universe 2002, Second XP Universe and First Agile Universe Conference Chicago, IL, USA, August 4-7, 2002, Proceedings, volume 2418 of Lecture Notes in Computer Science, pages 153165. Springer, 2002.
14 / 34
Part II Software process assessment: CMMI and SPICE
15 / 34
Software Process Assessment (SPA) I
Sources: [1, 2] SPAs are audits that assess an organizations software processes. CMMI (Capability Maturity Model Integration)
CMM now obsolete; CMMI introduced in 2000 (?), CMM appraisals expire December 31, 2007. Updates the CMM to be consistent with modern thinking on SE
ISO/IEC 15504 SPICE (Software Process Improvement and Capability dEtermination)
16 / 34
CMM I
Source: [5] Introduced in 1990. Denes 5 levels of software maturity
Level 1 (initial): immature or undened process Level 2 (repeatable): requirements management, project planning, tracking, quality assurance, conguration management Level 3 (dened): organizational process focus, process denition, training program, peer reviews Level 4 (managed): process measurement and analysis, quality management, defect prevention Level 5 (optimizing): technology innovation, process change management
Most organizations aimed for Level 3.
17 / 34
CMM II
Criticisms of CMM (by Royce the younger):
Activities + artifacts encourage waterfall mentality: requirements spec frozen before design, big design up front, etc. No emphasis on architecture, design, assessment of the software, deployment Overemphasizes quality by policing: peer reviews, inspections, traditional QA; neglects nding big aws in architecture CMM requires more documents, more checkpoints, more artifacts, more reviews, more plans.
The thicker the documents, the better
Activity based: if you do these activities, you are mature. (Nothing to characterize if you are doing these activities competently.) Emphasized process over outcomes
18 / 34
CMMI History
Source: [3] CMMI resulted from a team of 100 people from defense contractors (Boeing, Lockheed, Raytheon, etc.) and SEI There were 34 models based on CMM that were integrated to form the CMMI The CMMI is a meta-model that tries to be general enough to subsume all the CMM variants Needless to say, any set of documents created by a hundred people by denition must be a compromise solution.
19 / 34
CMMI History
Source: [1]
20 / 34
CMMI I
Sources: [5, 1] Process areas (22):

Causal Analysis and Resolution (CAR) (identify causes of selected defects, take action to prevent them in the future) Conguration Management (CM) Requirements Development (RD) Requirements Management (RM) ... Validation (VAL) Verication (VER)
21 / 34
CMMI II
Generic Practices: apply across the process areas
Establish an Organizational Policy (dene organizational expectations for a process) Plan the Process (process description, roles, etc.) Provide Resources (provide adequate resources for the work) Assign Responsibility (for performing the process etc.) Train People (to perform or support the process) Manage Congurations Identify and Involve Relevant Stakeholders Monitor and Control the Process Objectively Evaluate Adherence Review Status with Higher Level Management ... Ensure Continuous Process Improvement Correct Root Causes of Problems
22 / 34
CMMI III
CMMI addresses six project management areas:

Project Planning Project Monitoring and Control Supplier Agreement Management Integrated Project Management (integration with the organization, e.g., managing stakeholder involvement) Risk Management Quantitative Project Management (metrics)
23 / 34
CMMI IV
Also has ve maturity levels (in the staged avour of CMMI; also available in a continuous avour)
Level 1 (initial): ad hoc methods and unpredictable results Level 2 (managed): repeatable project performance. Requirements management, project planning, conguration management, etc. Level 3 (dened): processes consistent across projects, multi-stakeholder requirements, evolutionary design, verication + validation, risk management, training Level 4 (quantitatively managed): collecting metrics + exploiting historical results of projects to achieve tradeos between cost, quality, and timeliness; statistical quality-control methods Level 5 (optimized): rapidly recongurable + quantitative, continuous process improvement.
24 / 34
CMMI V
CMMI also focuses on activities, but incorporates many modern best practices, and discourages waterfall mentality (e.g. explicit feedback loop between requirements development and delivery/demo of products to customer) Things CMMI encourages that are consistent with iterative methods:
Attack risks early with an iterative lifecycle Establish a change management environment Enhance change freedom with round-trip engineering Instrument the process for objective quality control Establish a scalable, congurable process
25 / 34
CMMI VI
CMMI is somewhat vague: it often tells you what to do, but not how to do it. E.g., estimation
part of Project Planning (PP) Develop a Work Breakdown Structure (WBS), identify work packages in enough detail to allow estimation Use appropriate methods to determine the attributes of the work products and tasks that will be used to estimate the resource requirements... Examples of current methods include... Lines of code or function points for software... Estimate the attributes of the work products and tasks.
CMMI cannot be used as a guide for process development on its own; instead you need to ll in the blanks
26 / 34
CMMI vs. Agile Methods I

Source: [6] Comparison of CMMI to agile methods, by experts in agile methods and CMMI at USC workshop Classied the 40 components of CMMI as conicting/supporting/neutral of agile methods. Found 17/40 components conicted Found 22/40 components supportive or neutral Philosophical dierences identied by survey:
What provides customer trust?
CMMI: Process infrastructure Agile: Working software, participation
Scope of approach:
CMMI: Broad, inclusive, organizational Agile: Small, focused
27 / 34
CMMI vs. Agile Methods II

Where knowledge created during projects resides:
CMMI: Process assets Agile: People
Perceived mindset of practitioners:

CMMI: Disciplined, follow rules, risk averse Agile: Informal, creative, risk taking
Scaling challenges:
CMMI: Scaling down: doable, but dicult Agile: Scaling up: undened
Goals of the approach:

CMMI: Predictability, stability Agile: Performance, speed
28 / 34
SPICE I
Source: [4] Software Process Improvement and Capability dEtermination (SPICE) aka ISO/IEC 15504 ISO/IEC standard for software process assessment Inspired by CMM and ISO 9001, but tries to harmonize numerous models Conducted trials of the draft standard:
Companies implemented the draft standard and providing feedback
http://www.sqi.gu.edu.au/spice/ Five categories of processes:

Customer-Supplier (CUS) Engineering (ENG) Project process category (PRO) Support process category (SUP) Organizational process category (ORG)
29 / 34
SPICE II
Also has ve capability levels:
Level Level Level Level Level 1: 2: 3: 4: 5: Performed Managed Established (process denition & deployment) Predictable (process measurement & control) Optimising (innovation & optimization)
Very high-level, e.g., ENG.3.1 Develop software architectural design. Transform the software requirements into a software architecture that describes the top-level structure and identies its major components. Hence, numerous approaches can be made compatible with 15504. Appears to be big design up front, with some allowances for staged release
30 / 34
SPICE III
Emphasis on documentation and traceability. SEI is working to improve the compatability of CMMI with ISO/IEC 15504.
31 / 34
32 / 34
Bibliography I
[1] CMMI Product Team. CMMI for Development, Version 1.2. Technical Report CMU/SEI-2006-TR-008, Carnegie Mellon Software Engineering Institute, August 2006. [2] Robert T. Futrell, Donald F. Shafer, and Linda I. Shafer. Quality Software Project Management. Prentice-Hall, 2002. [3] Donald J. Reifer. The CMMI: its formidable. Journal of Systems and Software, 50(2):9798, 2000. [4] Terence P. Rout. ISO/IEC 15504Evolution to an international standard. Software Process Improvement and Practice, 8:2740, 2003.
33 / 34
Bibliography II
[5] Walker Royce. CMM vs. CMMI: From conventional to modern software management. Technical report, Rational Software Corporation, February 2002. [6] Richard Turner and Apurva Jain. Agile meets CMMI: Culture clash or common cause? In Don Wells and Laurie A. Williams, editors, Extreme Programming and Agile Methods - XP/Agile Universe 2002, Second XP Universe and First Agile Universe Conference Chicago, IL, USA, August 4-7, 2002, Proceedings, volume 2418 of Lecture Notes in Computer Science, pages 153165. Springer, 2002.
34 / 34

SE362 SoftwareProjectManagement

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

SE362 SoftwareProjectManagement

Uploaded by

Copyright:

Available Formats

SE362 Software Project Management

5 EstimationPsychology of estimationCommon knowledge effectIllusion of explanatory depthParkinsons

6 EstimationCOCOMOSelf-assessment hazardsSchedulingRolling Wave PlanningScheduling tools

7 SchedulingTask dependenciesCritical pathsResource levelingPERTProject controlScope controlChange 1

SE362 Lecture 1: Introduction Todd Veldhuizen tveldhui@acm.org

SE362 Lecture 1: Introduction

SE362 Lecture 1: Introduction Todd Veldhuizen tveldhui@acm.org

Part I Administrative Stu

SE362 Lecture 1: Introduction Todd Veldhuizen tveldhui@acm.org

Workload and Evaluation

SE362 Lecture 1: Introduction Todd Veldhuizen tveldhui@acm.org

20%: assignments (3) 30%: midterm (..) 50%: nal (TBA)

SE362 Lecture 1: Introduction Todd Veldhuizen tveldhui@acm.org

Rapid Development, Steve McConnell (1996)

SE362 Lecture 1: Introduction Todd Veldhuizen tveldhui@acm.org

SE362 Lecture 1: Introduction Todd Veldhuizen tveldhui@acm.org

SE362 Lecture 1: Introduction Todd Veldhuizen tveldhui@acm.org

SE362 Lecture 1: Introduction Todd Veldhuizen tveldhui@acm.org

SE362 Lecture 1: Introduction Todd Veldhuizen tveldhui@acm.org

What will you get out of this course? I

SE362 Lecture 1: Introduction Todd Veldhuizen tveldhui@acm.org

This is primarily a course about project leadership.

Learn critical thinking skills

What will you get out of this course? II

SE362 Lecture 1: Introduction Todd Veldhuizen tveldhui@acm.org

Do you want to be a PMP? I

SE362 Lecture 1: Introduction Todd Veldhuizen tveldhui@acm.org

SE362 Lecture 1: Introduction Todd Veldhuizen tveldhui@acm.org

Part II How does SE362 t in the SE curriculum?

What knowledge is important to a software professional? [1, 2] I

SE362 Lecture 1: Introduction Todd Veldhuizen tveldhui@acm.org

What knowledge is important to a software professional? [1, 2] II

SE362 Lecture 1: Introduction Todd Veldhuizen tveldhui@acm.org

What knowledge is important to a software professional? [1, 2] III

SE362 Lecture 1: Introduction Todd Veldhuizen tveldhui@acm.org

What knowledge is important to a software professional? [1, 2] IV

SE362 Lecture 1: Introduction Todd Veldhuizen tveldhui@acm.org

What knowledge is important to a software professional? [1, 2] V

SE362 Lecture 1: Introduction Todd Veldhuizen tveldhui@acm.org

What knowledge is important to a software professional? [1, 2] VI

SE362 Lecture 1: Introduction Todd Veldhuizen tveldhui@acm.org

What knowledge is important to a software professional? [1, 2] VII

SE362 Lecture 1: Introduction Todd Veldhuizen tveldhui@acm.org

What knowledge is important to a software professional? [1, 2] VIII

SE362 Lecture 1: Introduction Todd Veldhuizen tveldhui@acm.org

SE362 Lecture 1: Introduction Todd Veldhuizen tveldhui@acm.org

Part III Overview of SE362

SE362 Lecture 1: Introduction Todd Veldhuizen tveldhui@acm.org

SE362 Lecture 1: Introduction Todd Veldhuizen tveldhui@acm.org

SE362 Lecture 1: Introduction Todd Veldhuizen tveldhui@acm.org

A theme: vagueness III

SE362 Lecture 1: Introduction Todd Veldhuizen tveldhui@acm.org

SE362 Lecture 1: Introduction Todd Veldhuizen tveldhui@acm.org

SE362 Lecture 1: Introduction Todd Veldhuizen tveldhui@acm.org

Of course, the problem of distinguishing problems from pseudoproblems is itself a pseudoproblem.

What is project management?

SE362 Lecture 1: Introduction Todd Veldhuizen tveldhui@acm.org

Project Management Skills

SE362 Lecture 1: Introduction Todd Veldhuizen tveldhui@acm.org

Some basic PM concepts

SE362 Lecture 1: Introduction Todd Veldhuizen tveldhui@acm.org

SE362 Lecture 1: Introduction Todd Veldhuizen tveldhui@acm.org

Source: PMBOK Guide