<<   , Apple wwdc 2012  >>
Theory W Software Management
Theory W Software Management
Outline
Outline
The Software Project Managers Problem
The Software Project Managers Problem
The Software Management Theory Problem
The Software Management Theory Problem
Approaches to Date
Approaches to Date
Sorting out software advice
Sorting out software advice
Koontz-ODonnell Management Framework
Koontz-ODonnell Management Framework
Theory X and Theory Y*
Theory X and Theory Y*
Theory Z: Japanese-Style Management
Theory Z: Japanese-Style Management
Theory W Software Management Steps
Theory W Software Management Steps
Theories X, Y, Z, and W: An Example
Theories X, Y, Z, and W: An Example
Theories X, Y, Z, and W: An Example (cont
Theories X, Y, Z, and W: An Example (cont
Theory W Solution to Problem
Theory W Solution to Problem
Strategic Guidelines Derived from Win-Win Preconditions
Strategic Guidelines Derived from Win-Win Preconditions
Strategic Guidelines Derived from Product, Process Guidelines
Strategic Guidelines Derived from Product, Process Guidelines
Outline
Outline
Theory W Principles and Practices
Theory W Principles and Practices
Win-Win, Win-Lose, and Lose-Lose Situations
Win-Win, Win-Lose, and Lose-Lose Situations
The Software Project Managers Problem
The Software Project Managers Problem
Making Everyone a Winner: Potential Conflicts
Making Everyone a Winner: Potential Conflicts
Negotiation Principles*
Negotiation Principles*
Theory W Principles and Practices
Theory W Principles and Practices
Understanding Peoples Win Conditions
Understanding Peoples Win Conditions
Win Conditions: People in General
Win Conditions: People in General
Maslow Human Need Hierarchy
Maslow Human Need Hierarchy
Maslow Need Hierarchy
Maslow Need Hierarchy
People Self-Actualize in Different Ways
People Self-Actualize in Different Ways
Win Conditions: Software People
Win Conditions: Software People
Ranking of Motivating Factors
Ranking of Motivating Factors
Ranking of Motivating Factors
Ranking of Motivating Factors
Comparative Growth Needs and Social Needs
Comparative Growth Needs and Social Needs
Experiments Show that Programming Team Performance is Highly Sensitive
Experiments Show that Programming Team Performance is Highly Sensitive
Effect of Objectives on Productivity
Effect of Objectives on Productivity
Incorporating Peoples Goals in Management Decisions: DP People
Incorporating Peoples Goals in Management Decisions: DP People
Understanding Peoples Win Conditions
Understanding Peoples Win Conditions
Reaching Out
Reaching Out
Studying the Culture
Studying the Culture
Projecting Yourself Into Others Win Situations
Projecting Yourself Into Others Win Situations
The Modified Golden Rule
The Modified Golden Rule
Mutual Exploration
Mutual Exploration
Reconciling Peoples Win Conditions
Reconciling Peoples Win Conditions
Win-Win, Win-Lose, and Lose-Lose Situations
Win-Win, Win-Lose, and Lose-Lose Situations
Win-Win, Win-Lose, & Lose-Lose Examples: Uniword
Win-Win, Win-Lose, & Lose-Lose Examples: Uniword
Getting to Win-Win
Getting to Win-Win
Negotiation Principles
Negotiation Principles
Separate the People From the Problem
Separate the People From the Problem
Focus on Interests, Not Positions
Focus on Interests, Not Positions
Inventing Options for Mutual Gain
Inventing Options for Mutual Gain
Getting to Win-Win: COCOMO F-16 Example
Getting to Win-Win: COCOMO F-16 Example
Getting to Win-Win: COCOMO F-16 Example
Getting to Win-Win: COCOMO F-16 Example
Insist on Using Objective Criteria
Insist on Using Objective Criteria
Searching out Win-Win Situations
Searching out Win-Win Situations
Expanding the Option Space
Expanding the Option Space
Incorporating Peoples Goals in Management Decisions: Users
Incorporating Peoples Goals in Management Decisions: Users
Teambuilding
Teambuilding
Setting Up Reasonable Expectations
Setting Up Reasonable Expectations
Theory W: A Large-Project Example
Theory W: A Large-Project Example
Review Team Procedures
Review Team Procedures
Review Findings
Review Findings
Review Recommendations
Review Recommendations
Structuring a Win-Win Software Process - FAA/AAS Risk Management Plan
Structuring a Win-Win Software Process - FAA/AAS Risk Management Plan
Applying Win Conditions: Tactical Example
Applying Win Conditions: Tactical Example
Tactical Example - II
Tactical Example - II
Structuring A Win-Win Software Product - Student COCOMO Programs
Structuring A Win-Win Software Product - Student COCOMO Programs
Conclusions
Conclusions
Theory W Management and Trust
Theory W Management and Trust

: Theory W Software Management. : csews. : Theory W Software Management.ppt. zip-: 69 .

Theory W Software Management

Theory W Software Management.ppt
1 Theory W Software Management

Theory W Software Management

Barry Boehm, USC

2 Outline

Outline

The Problem For the software project manager For software management theories Approaches to date Theory W Principles and Practices Theory W Research Issues Conclusions

3 The Software Project Managers Problem

The Software Project Managers Problem

Ambitious goals No Overruns No Surprises

Quick Schedule Low budget

Software Project Manager

Lots of Functions User-Friendly Fast, robust

4 The Software Management Theory Problem

The Software Management Theory Problem

Easy to understand Easy to learn, apply

Covers all classes of projects Covers procedural, technical, economic, people concerns

Provides useful, situation-specific advice

5 Approaches to Date

Approaches to Date

Objectives: Simple, General, Specific Alternatives Eclectic combinations of advice DoD-STDS, Procedural Guidebooks Koontz-ODonnell Elaborations One-minute manager, et al. Theories X, Y, Z Theory W: Make everyone a winner

6 Sorting out software advice

Sorting out software advice

Build It twice

Thorough test planning

Do it top-down

Prove everything correct

Use disciplined reviews

Do it outside-in

Programming standards

Independent test teams

Use walk-throughs

Chief Programmer teams

Measurable milestones

Early requirements baseline

Program Library

Involve the user

Structured Programming

Design verification

Configuration management

Project work authorizations

End-item acceptance plan

Automated aids

Unit development folders

7 Koontz-ODonnell Management Framework

Koontz-ODonnell Management Framework

Purpose Unity of goals Cost- effectiveness Span of Management

Purpose Contribution to goals Commitment Verifiability Cost-Effectiveness Precedence

Purpose Contribution to goals

Purpose Harmony of goals

Purpose Assurance of goals Cost-effectiveness Control responsibility

Motivation Understanding of goals Reflection of goals

Selection Top talent Job matching Career progression Skills balance Teamwork

Structure Reflection of plans Organizational suitability individuality

Delegation of Authority Unity of command Parity of authority Responsibility Authority level Absoluteness of responsibility

Communication Parity of information Responsibility Receptiveness Integrity

Structure Premises WWWWWHHW Synchronization

Recruiting Reward Openness Commitment

Process Standards Critical-point Exception Flexibility Timeliness Action

Leadership Identification Empathy Sustained initiative Integrity Team building Management of time

Process Limiting Factor Flexibility Navigational change Performer Participation

Division of Work Form follows function Peoples strengths Functional definition Separation

Retention Reinforcement Team building Phase out Backup

8 Theory X and Theory Y*

Theory X and Theory Y*

Theory X People inherently dislike work They have to be coerced into working The prefer being told what to do Theory Y People dont inherently dislike work People can exercise self-direction Commitment to objectives depends on resulting rewards People can learn to seek responsibility Work creativity is widely distributed Peoples potential is only partially utilized

* D. McGregor, The Human Side of Enterprise, 1960.

9 Theory Z: Japanese-Style Management

Theory Z: Japanese-Style Management

People work best toward goals which they have helped establish Once people have bought into goals, you can trust them to perform If people share a common set of values, they can develop workable project goals

10 Theory W Software Management Steps

Theory W Software Management Steps

Establish a set of win-win preconditions Understand how people want to win Establish a set of win-win objectives Establish reasonable expectations Match peoples objectives to their win conditions Provide a supportive environment Structure a win-win software process Establish a realistic process plan Highlight potential win-lose, lose-lose risk items Keep people involved Provide feedback Confront, resolve new win-lose, lose-lose situations Structure a win-win software product Match product to users, maintainers win conditions

11 Theories X, Y, Z, and W: An Example

Theories X, Y, Z, and W: An Example

Problem George and Harry want same system analysis job Both well-qualified deserving

12 Theories X, Y, Z, and W: An Example (cont

Theories X, Y, Z, and W: An Example (cont

Problem George and Harry want same system analysis job Both well-qualified deserving Solutions Theory X: Boss makes arbitrary choice Theory Y: Boss asks for proposals, picks most ambitious one Theory Z: Boss pre-builds consensus on team objectives, bhooses based on Qualifications rating

13 Theory W Solution to Problem

Theory W Solution to Problem

Understand how people want to win George: career path to marketing Harry: Extensive travel to Boston; Daughter in college there Establish a set of win-win objectives by realigning expectations or expanding option space Find comparable marketing-oriented job for George Find comparable job with Boston travel for Harry

14 Strategic Guidelines Derived from Win-Win Preconditions

Strategic Guidelines Derived from Win-Win Preconditions

Win-Win Precondition

Developer Team

Users

Maintainers

Customers

Operations concept Operations procedures

Cost-benefit analysis

Career path development

Mission Analysis Operations concept Prototyping Requirements spec Early users manual

Understand win conditions

Requirements scrub

Team building, negotiating, communicating

Reasonable expectations

Resource allocation

Change control participation

Match tasks to win conditions

User-spec reviews Prototype exercise

Quality assurance

Status tracking

Staffing, organizing

Early error detection

Maintenance training Conversion Deliverable support environment Configuration management

Developer training Support environment Configuration management

Customer training

Supportive environment preparation

User training Cutover preparation

Modern programming practices

15 Strategic Guidelines Derived from Product, Process Guidelines

Strategic Guidelines Derived from Product, Process Guidelines

Guideline

Users

Maintainers

Customers

Development Team

Process Planning

Process Involvement

Process Feedback

Product Structuring

Operational plan Installation and training plans

Life-cycle support plan

Development plans

Risk management plans

System engineering plan participation Review participation Prototype exercise

System engineering plan participation Review participation Quality assurance

Cost-benefit reviews, approvals

Delegation Planning participation

Team building, negotiating, communicating

Reviews

Reviews

Status tracking, controlling

Performance feedback

Service-oriented Efficient Easy to learn Easy to use Tailorable

Easy to modify Programming standards

Efficient Correct Feasible

Easy to modify Balanced Correct

16 Outline

Outline

The Problem For the software project manager For software management theories Approaches to date Theory W Principles and Practices Theory W Research Issues Conclusions

17 Theory W Principles and Practices

Theory W Principles and Practices

Principles Win-win, win-lose, and lose-lose situations Getting to win-win Getting to yes: Principles of negotiations Practices: Examples Understanding win conditions Establishing win-win objectives Structuring win-win software process Structuring win-win software products

18 Win-Win, Win-Lose, and Lose-Lose Situations

Win-Win, Win-Lose, and Lose-Lose Situations

Developers Win Space Win-Lose

Users Win Space Win-Lose

Win-Win

Lose-Lose

19 The Software Project Managers Problem

The Software Project Managers Problem

Ambitious goals No Overruns No Surprises

Quick Schedule Low budget

No bugs Well-documented Easy to change

Software Project Manager

Lots of Functions User-Friendly Fast, robust

Fast career path Preference for design Defer documentation

20 Making Everyone a Winner: Potential Conflicts

Making Everyone a Winner: Potential Conflicts

Proposed Solution

Loser

Winner

Quick, Cheap, Sloppy Product

Developer & Customer

User

Lots of bells and whistles

Developer & User

Customer

Driving too hard a bargain

Customer & User

Developer

Actually, nobody wins in these situations

21 Negotiation Principles*

Negotiation Principles*

Dont bargain over positions Use 4-step solution approach Separate the people from the problem Focus on interests, not positions Invent options for mutual gain Insist on using objective criteria

* Fisher & Ury, Getting to Yes, 1981.

22 Theory W Principles and Practices

Theory W Principles and Practices

Principles Win-win, win-lose, and lose-lose situations Getting to win-win Getting to yes: Principles of negotiations Practices: Examples Understanding win conditions Establishing win-win objectives Structuring win-win software process Structuring win-win software products

23 Understanding Peoples Win Conditions

Understanding Peoples Win Conditions

Principles People in general Software people Practices Reaching out Studying the culture Projection Mutual Exploration

24 Win Conditions: People in General

Win Conditions: People in General

Maslow Need Hierarchy Motivating Factors Theories X, Y, Z, and W

25 Maslow Human Need Hierarchy

Maslow Human Need Hierarchy

A. Maslow, Motivation and Personality, 1954.

Self-Actualization

Esteem and Autonomy

Belongingness and love

Safety and Security

Physiological (Food and Drink)

26 Maslow Need Hierarchy

Maslow Need Hierarchy

Satisfied needs arent motivators Unsatisfied lower-level needs dominate higher-level needs Management implications Create environment and subculture which satisfies lower-level needs Stability Shared values, community Match to special needs Tailor project objectives, structure to participants self-actualization priorities

27 People Self-Actualize in Different Ways

People Self-Actualize in Different Ways

Becoming a Better Manager Becoming a Better Technologist Helping Other Developers Helping Users Making People Happy Making People Unhappy Doing New Things Increasing Professional Stature

Project Managers Must be Very Sensitive to these Differences-Remember the Modified Golden Rule

28 Win Conditions: Software People

Win Conditions: Software People

Overall motivating factors Growth needs vs. social needs Responsiveness to objectives Some management implications

29 Ranking of Motivating Factors

Ranking of Motivating Factors

General (Herzberg)

1. Achievement 2. Recognition 3. Work Itself 4. Responsibility 5. Advancement 6. Salary 7. Possibility for growth 8. Relations, subordinate 9. Status 10. Relations, superior

30 Ranking of Motivating Factors

Ranking of Motivating Factors

General (Herzberg)

DP Professionals (Fitz-Enz)

1. Achievement 2. Recognition 3. Work Itself 4. Responsibility 5. Advancement 6. Salary 7. Possibility for growth 8. Relations, subordinate 9. Status 10. Relations, superior

1. Achievement 2. Possibility for growth 3. Work Itself 4. Recognition 5. Advancement 6. Tech. Supervision 7. Responsibility 8. Relations, peers 9. Relations, subordinate 10. Salary

12

11

14

31 Comparative Growth Needs and Social Needs

Comparative Growth Needs and Social Needs

32 Experiments Show that Programming Team Performance is Highly Sensitive

Experiments Show that Programming Team Performance is Highly Sensitive

to Given Objectives*

1

4

4

5

3

2-3

1

2

3

5

5

2

1

4

4

4

3

3

1-2

2

2-3

5

5

1-2

1

Resulting Rank on Performance**

Team Objective: Optimize

Time To Complete

No. of Statements

Memory Required

Program Clarity

Output Clarity

Time To Complete

No. of Statements

Memory Required

Program Clarity

Output Clarity

*Weinberg, 1972

** 1=Best

33 Effect of Objectives on Productivity

Effect of Objectives on Productivity

(Weinberg-Schulman, 1974)

Team Objective: Optimize

Number of Statements

Man-hours

Productivity (State M-H)

Core Memory 52 74 0.7 Number of Statements 33 30 1.1 Execution Time 100 50 2.0 Program Clarity 90 40 2.2 Programming, Man-hours 126 28 4.5 Output Clarity 166 30 5.5

34 Incorporating Peoples Goals in Management Decisions: DP People

Incorporating Peoples Goals in Management Decisions: DP People

Concentrate on Meaningful Work, Growth Opportunities Carefully Define Objectives, Priorities Downplay Status as a Primary Motivator Watch Out for Peter Priniciple Try to Develop Responsibility Participation in Planning, Goal-Setting Increase Feedback Remember the Modified Golden Rule

35 Understanding Peoples Win Conditions

Understanding Peoples Win Conditions

Principles People in general Software people Practices Reaching out Studying the culture Projection Mutual Exploration

36 Reaching Out

Reaching Out

Interviews, conversations Surveys, questionnaires Tours of duty Hypothesis testing Prototypes, scenarios OPS-concept document Draft users manuals

37 Studying the Culture

Studying the Culture

Background reading User shared values, taboos Operations analysis Example: Accounting for funds, man-hours Previous experiences with automation Scars and bruises Previous winners

38 Projecting Yourself Into Others Win Situations

Projecting Yourself Into Others Win Situations

Do unto others .. As you would have others do unto you Computer sciences world (compilers, OS, etc.) Users are programmers Applications world Users are pilots, doctors, tellers

Build computer systems to serve users and operators .. Assuming users and operators like to write programs, and know computer science

Counterexample: The Golden Rule

39 The Modified Golden Rule

The Modified Golden Rule

Do unto others as you would have others do unto you if you were like them

40 Mutual Exploration

Mutual Exploration

Users: How can software technology help them become more effective? Prototypes, demonstrations Owners: How can the software product enhance their value to the ongoing mission? Ease of change; diagnostics Subordinates: How can the project help them achieve career goals? Training, breadth of experience General: Helping people find out and demonstrate they are winners

41 Reconciling Peoples Win Conditions

Reconciling Peoples Win Conditions

Principles Win-Win, Win-Lose, and Lose-Lose situations Negotiation principles Practices Searching out Win-Win situations Expanding the option space Teambuilding and shared values Setting expectations

42 Win-Win, Win-Lose, and Lose-Lose Situations

Win-Win, Win-Lose, and Lose-Lose Situations

Lose-Lose

Soft Wizards Win Space Win-Lose

Universal Micros Win Space Win-Lose

Win-Win

43 Win-Win, Win-Lose, & Lose-Lose Examples: Uniword

Win-Win, Win-Lose, & Lose-Lose Examples: Uniword

Win-Win License fee for soft wizards Structured programming Win-Lose Best and final offer Independent user-interface designs Gold-plated DBMS Lose-Lose Establishing unrealistic schedule Staffing with incompatible people Poor planning Adding people to catch up No concurrence on product features

44 Getting to Win-Win

Getting to Win-Win

Feasible initial increment of uniword

Product universal micros wants in 9 months

Products softwizards can build in 9 months

45 Negotiation Principles

Negotiation Principles

Fisher & Ury, Getting to Yes, 1981 Dont bargain over positions Use 4-step solution approach Separate the people from the problem Focus on interests, not positions Invent options for mutual gain insist on using objective criteria

46 Separate the People From the Problem

Separate the People From the Problem

Put yourself in their shoes Recognize and understand emotions Present proposals in terms of their values Make sure they participate in the process Face the problem, not the people

47 Focus on Interests, Not Positions

Focus on Interests, Not Positions

Ask Why? Ask Why not? Look forward, not back Be concrete but flexible Be hard on the problem, soft on the people

48 Inventing Options for Mutual Gain

Inventing Options for Mutual Gain

The four basic steps: Fisher and Ury

What is wrong

What might be done

In Theory

In the Real World

Step III. Approaches What are possible strategies or prescriptions? What are some theoretical cures? Generate broad ideas about what might be done.

Step II. Analysis Diagnose the problem: Sort symptoms into categories. Suggest causes. Observe what is lacking. Note barriers to resolving problem.

Step IV. Action ideas What might be done? What specific steps might be taken to deal with the problem?

Step I. Problem Whats wrong? What are current symptoms? What are disliked facts contrasted with a preferred situation?

49 Getting to Win-Win: COCOMO F-16 Example

Getting to Win-Win: COCOMO F-16 Example

Products developer can build in 12 months

Products user wants in 12 months

50 Getting to Win-Win: COCOMO F-16 Example

Getting to Win-Win: COCOMO F-16 Example

Products developer can build in 12 months

Products user wants in 12 months

Prioritize development increments

Add technology, key people

51 Insist on Using Objective Criteria

Insist on Using Objective Criteria

Fair standards Fair procedures Establish joint search for criteria Dont yield to pressure Develop best alternative to negotiated agreement

52 Searching out Win-Win Situations

Searching out Win-Win Situations

Breaking options into parts Functionality A take lead on user I/F; B on comm. Proc. Increments Phases Realigning options OS, DBMS, applications Input, process, output Inventory, production, distribution

53 Expanding the Option Space

Expanding the Option Space

Linking to future options, career paths Linking to extra rewards Providing extra support Surfacing new technical options Creating ownership Can be easily overdone, though

54 Incorporating Peoples Goals in Management Decisions: Users

Incorporating Peoples Goals in Management Decisions: Users

Give Users Opportunities for Achievement, Responsibility Swedish Bank Minimize User Difficulties With Product Help Messages Avoid Lock-Step Controls Dont Assume Users Have Urge to be Computer Scientists Data Entry Language Remember the Modified Golden Rule

55 Teambuilding

Teambuilding

Build appreciation for others win conditions Establish shared values Group planning, issue resolution Offsites

56 Setting Up Reasonable Expectations

Setting Up Reasonable Expectations

User: functionality Customer: budget, schedule Performer: Lead design role Research content

Better to establish low expectations and come up than to establish high expectations and come down.

57 Theory W: A Large-Project Example

Theory W: A Large-Project Example

Scope of Phase I contract Develop Ada object-oriented design approach Use on representative system CSCI Demonstrate requirements satisfaction Functions, portability, performance, reliability Learn lessons; incorporate into Phase II development Customer expectations No problems with Phase I Phase I CSCI fully usable in Phase II External PDR, CDR reviewer comments Design not object-oriented Should consider PDR, CDR not passed Would cause major slip in Phase I completion Review team called in to assess situation, make recommendations

58 Review Team Procedures

Review Team Procedures

Review team composition Key PDR, CDR external reviewers Contractor non-project Ada experts External Ada Experts Review charter Determine if design is/isnt object-oriented? Determine if PDR, CDR are/arent passed? Determine how to get best system design & plan Output ground rules Full consensus; no minority reports Initial activities Find out how people want to win Customer, contractor, external reviewers Establish reasonable expectations Determine how well design satisfies rqts. Identify risks Reconcile with expectations

59 Review Findings

Review Findings

Software rqts. not traceable to OPS-concept Design faithfully followed project OOD guidelines Design would have major problems in meeting full-scale performance & reliability rqts. Design would make significant classes of changes difficult

60 Review Recommendations

Review Recommendations

Consider Phase I CSCI a throwaway prototype A win for external reviewers Revised expectations for customers Congratulate customer for foresight in establishing a 2-phase, lessons-learned approach A win for customer Consider PDR, CDR passed A win for customer and contractor Establish risk management plan to address risk items identified A downstream win for customer, contractor, external reviewers, and users

61 Structuring a Win-Win Software Process - FAA/AAS Risk Management Plan

Structuring a Win-Win Software Process - FAA/AAS Risk Management Plan

Users winners Reliability: Use Ada; risk-manage exceptions, elaboration, RTS Performance: Risk-manage tasking, RTS, non-Ada use Customers winners Cost, schedule: Risk-manage compiler limits; host, target support; developer readiness (exercise); key personnel Maintainers winners Train maintenance personnel in Ada Have maintenance personnel develop maintenance plans Get maintenance personnel involved in development Developers winners Re-evaluate fixed-price strategy Require developer risk management plan (RMP) Base selection on RMP, exercise as well as proposal

62 Applying Win Conditions: Tactical Example

Applying Win Conditions: Tactical Example

Situation : Susan, a new 1st-level manager, proposes that project use a new test tool she worked on Understanding win conditions: Susan : Help project avoid errors Justify time spent on tool Others : New tool immature, adds risk Project considered, rejected similar tool Establishing reasonable expectations: Meeting to explore tool use options, concerns Others more sympathetic to tools value Susan more sympathetic to project risks

63 Tactical Example - II

Tactical Example - II

Matching tasks to win conditions Use tool experimentally on Susans work package Others review experience If successful, use on entire project Provide supportive environment Training on tool usage Budget for tool improvement Keeping people involved Periodic reviews positive: integration errors down 45% Agreement to use on entire project Providing feedback Bonus award for Susan, key subordinates Division recognition of project contribution Preparation for division-wide use of tool

64 Structuring A Win-Win Software Product - Student COCOMO Programs

Structuring A Win-Win Software Product - Student COCOMO Programs

Requirement: Enter N input attributes Solution Precondition: 0 acceptable inputs Post-condition: N acceptable inputs Invariant: i acceptable inputs, add an acceptable input i+1 acceptable inputs Program: Loop through input attributes User problem: Cant backtrack to fix previous inputs

65 Conclusions

Conclusions

Theory W addresses success criteria reasonably well Simple Expressible in 4 words, 8 steps Detailed guidelines derivable from steps General Applies to all classes of projects Strongest on people issues, but also addresses procedural, technical, economic issues Specific Provides specific solutions for both strategic and tactical management issues Provides criterion for testing management solutions

66 Theory W Management and Trust

Theory W Management and Trust

Effective management is built on a bedrock of trust Practicing Theory W generates trust People see that youre looking out for their win conditions Theory W is self-reinforcing If people know that as a manager youre going to consider other peoples win conditions - theyll start thinking about them too

Theory W Software Management
http://900igr.net/prezentacija/anglijskij-jazyk/theory-w-software-management-220438.html
c

29
900igr.net > > > Theory W Software Management