lecture 7
Skip this Video
Download Presentation
Lecture 7

Loading in 2 Seconds...

play fullscreen
1 / 32

Lecture 7 - PowerPoint PPT Presentation

  • Uploaded on

Lecture 7. COM822J1: Project Management & Software Quality Control. Lecture 7. Motivation (Chapter 11) Teamwork (Chapter 12) Team structure (Chapter 13) Steve McConnell, Rapid Development: Taming Wilde Software Projects, Microsoft Press, ISBN 1-55615-900-5, 1996. Chapter 11. Motivation.

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about ' Lecture 7' - miranda-ballard

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
lecture 7

Lecture 7

COM822J1: Project Management & Software Quality Control

Lecture 6

lecture 71
Lecture 7
  • Motivation (Chapter 11)
  • Teamwork (Chapter 12)
  • Team structure (Chapter 13)
      • Steve McConnell, Rapid Development: Taming Wilde Software Projects, Microsoft Press, ISBN 1-55615-900-5, 1996

Lecture 6

chapter 11

Chapter 11


Chapter 11

  • Of the four dimensions of rapid development (people, process, product, technology) – people has the greatest potential to shorten software schedules across a variety of projects
  • “Motivation is undoubtedly the single greatest influence on how well people perform. Most productivity studies have found that motivation has a stronger influence on productivity than any other factor” (Boehm, 1981)


  • Motivation
    • Is a soft factor
    • Is difficult to quantify and measure
    • Is known to be an important factor
      • But companies often don’t do anything about it
    • Knowledge about it is available


typical developer motivation
Typical Developer Motivation

Typical Developer Motivation

Programmers – public

More motivated by

Possibility for growth

Personal life

Opportunity for technical supervision

Interpersonal relations with their peers

Much less motivated by


Interpersonal relationship to subordinates



Programmers – managers

More motivated by

Possibility for growth

Personal life

Opportunity for technical supervision

Much less motivated by responsibility


Interpersonal relationship with subordinates

Typical Developer Motivation

top five motivation factors for developers
Top Five Motivation Factors For Developers
  • Achievement
  • Possibility for growth
  • Work itself
  • Personal life
  • Technical-supervision opportunity

Top Five Motivation Factors For Developers

Ownership (buy-in)

People will work harder to achieve their own goals

Let developers set their own schedules

Goal setting

Avoid setting too many goals/objectives/priorities

… (Achievement)

Team performance ranked against objectives that teams were told to optimise (Source: Rapid Development - Taming Wilde Software Projects, McConnell, 1996).

Top Five Motivation Factors For Developers

possibility for growth
… (Possibility For Growth)
  • Software development
    • Is an exciting, constantly changing field
    • You have to (can) learn every day
  • It is in an organisations best interest to help people determine how they wish to grow professionally
    • Short-term and long-term impacts and benefits
  • Possibilities for an organisation
    • Providing tuition reimbursements for professional development classes
    • Giving time off to attend classes or to study
    • Providing reimbursements for purchase of professional books
    • Assigning developers to projects that enhance their skills
    • Assigning a mentor to each new developer
    • Avoid excessive schedule pressure

Top Five Motivation Factors For Developers

work itself
… (Work Itself)
  • Internal motivation comes from three sources
    • People need to experience meaning in their work
    • Experience responsibility for the outcome of their work
    • They must know the actual results of their work activities
  • Five dimensions of the work itself that can contribute to these three sources of motivation
    • Meaningfulness to people
      • Skill variety (avoid boredom and fatigue)
      • Task identity (requires you to complete a whole, identifiable piece of work)
      • Task significance (how does your work affect others, social welfare)
    • Responsibility for outcome
      • Autonomy (degree of control over means and methods you use to do your job)
    • Know about the result of work activities
      • Job feedback (direct feedback how effective you are)
  • Opportunity to focus on the work itself (distractions such as administration)

Top Five Motivation Factors For Developers

personal life
… (Personal Life)
  • Personal life is 4th most important factor for developers - but only 15th for managers
    • Likely to be the hardest motivational factor for the manager to understand
    • Managers sometimes reward their best workers by assigning them to the highest-profile, highest-pressure projects
      • To a manager the extra responsibility would be a treat (reward) - personal life doesn’t matter that much for him
      • To the developer the diminished personal life is a loss (punishment)
    • Manager doesn’t have to understand the details why personal life is so important for the developer
    • All a company can do is
      • Schedule projects realistically
      • Respect vacation and holidays
      • Be sensitive to requests for time off during the workday

Top Five Motivation Factors For Developers

technical supervision opportunity
… (Technical-Supervision Opportunity)
  • For a developer a technical-supervision opportunity represents an achievement
    • There exists a level of expertise sufficient to direct others
    • For a manager this might represent a step backwards
      • A manager is already supervising others and is probably happy to not getting involved into technical supervision
  • Tips
    • Assign each person on a project to be the technical lead for a particular product area (user-interface design, database connectivity, etc.)
    • Assign each person to be the technical lead for a particular process area (technical reviews, data conversion, installation, etc.)
    • Assign all but the most junior developers to be mentors

Top Five Motivation Factors For Developers

other motivation factors
Rewards and incentives

Developers grow tired of working for unappreciative companies

Rewards are therefore important for long-term motivation

It is important to present any reward as a gesture of appreciation rather than an incentive

A reward should be unexpected

The work should be the motivator and not the (expected) reward

Possible awards

Recognition diners

Conference sponsorship

Cash bonuses

Vacation-time bonuses

Pilot projects

The Hawthorne Effect

Run every project as an experiment (pilot project)

Try out some new methodology in each project

Inform the team that the project is a pilot project

Performance reviews

Is the single most important form of task-relevant feedback supervisors can provide

Other Motivation Factors

Other Motivation Factors

motivation killers
Hygiene factors

Management manipulation

Excessive schedule pressure

Lack of appreciation for development’s efforts

Inappropriate involvement of technically inept management

Not involving developers in decisions that affect them

Productivity barriers

Low quality

Heavy-handed motivation campaigns

Motivation Killers

Motivation Killers

chapter 12

Chapter 12


Chapter 12

software uses of teamwork
Software Uses Of Teamwork
  • Team - a small group of people with complementary skills who are committed to a common purpose, performance goals, and approach for which they hold themselves mutually responsible
  • Teaming up in software
    • Developing and reviewing project’s requirements
    • Designing difficult parts of the project
    • Reviewing individuals developers designs and code
    • Developing coding standards
    • Coordinating work on related pieces of a project
    • Testing of requirements and design
    • Auditing of projects progress

Software Uses Of Teamwork

teamwork s importance in rapid development
Teamwork’s Importance In Rapid Development
  • Small projects versus large projects
    • Large projects are group efforts
  • Variations in team productivity
    • 10/1 differences on individual productivity levels
    • Team productivity
      • 5/1 differences, different backgrounds and experience
      • 2.5/1 differences, similar backgrounds and experience
  • Cohesiveness and performance
    • Work hard, are focused on project goals, enjoy work
    • Cohesiveness contributes more to productivity than individual capabilities and experience do
      • Contribution of a person’s to the cohesiveness of the team before their individual capabilities

Teamwork’s Importance In Rapid Development

creating a high performance team
A shared, elevating vision or goal

A sense of team identity

A result driven structure

Competent team members

A commitment to the team

Mutual respect

Interdependence among team members

Effective communications

A sense of autonomy

A sense of empowerment

Small team size

A high level of enjoyment

Creating A High-Performance Team

Creating A High-Performance Team

why teams fail
Why Teams Fail
  • Lack of common vision
  • Lack of identity
  • Lack of recognition
  • Productivity roadblocks
  • Problem personnel
  • Ineffective communication
  • Lack of trust

Why Teams Fail

long term team building
Long-term Team Building
  • Higher productivity
  • Lower start-up costs
  • Lower risk of personnel problems
  • Less turnover
  • The idleness question

Long-term Team Building

teamwork guidelines
Teamwork Guidelines

Source: Rapid Development -Taming Wilde Software Projects, McConnell, 1996.

Teamwork Guidelines

chapter 13

Chapter 13

Team Structure

Chapter 12

  • Even when you have skilled, motivated, hard-working people, the wrong team structure can undercut their efforts instead of catapulting them to successA poor team structure can increase development time, reduce quality, damage moral, increase turnover, and ultimately lead to project cancellationCurrently about on-third of all team projects are organised in ineffective ways (Johns 1994)


team objectives and team structures
Team Objectives And Team Structures
  • The first consideration is to determine the team’s broad objectives
    • Problem resolution
      • Focuses on solving a complex poorly defined problem
    • Creativity
      • Aim of the team is to explore possibilities and alternatives
    • Tactical execution
      • Team focuses on carrying out a well-defined plan

Team Objectives And Team Structures


Source: Rapid Development - Taming Wilde Software Projects, McConnell, 1996.

Team Objectives And Team Structures

additional team design features
Additional Team Design Features
  • There are four more team-structure features that seem to characterise all kinds of efficiently functioning teams
    • Clear roles and accountabilities
      • Every person in the team counts, knows what to do, and is accountable for his/her work
    • Monitoring of individual performance and providing feedback
      • Need for mechanisms for letting the team know whether their performance is acceptable and in what way it needs improvement
    • Effective communication
      • Information must be easily accessible, originate from reliable resources, room for informal discussions/communication
    • Fact-based decision making
      • E.g., avoid arbitrary, subjective, decision making

Additional Team Design Features

team models
Team Models
  • Business team (all kinds of projects: problem resolution, creative, tactical execution)
    • Peer group headed by a technical lead
    • Aside from technical lead all team members have equal status
    • Technical lead is an active contributor, and is chosen on the basis of technical experience rather than management skills
  • Chief programmer team (projects: creative, tactical execution)
    • Some developers are (much) better than others
    • The chief programmer drafts the entire specification, completes all the design, writes the vast majority of the production code, and is virtually responsible for all of the decisions on a project
    • Backup programmers, research assistants
  • Skunkworks team (projects: creative)
    • Group of talented, creative product developers
    • Work in a facility free from bureaucratic restrictions
    • Develop and innovate (creative, but poor visibility)

Team Models

  • Feature team (projects: problem-resolution, creative)
    • Team organised according to features (printing, graphing, documentation)
    • Responsibility for parts of the product’s functionality
    • Hierarchical, reporting structure
  • Search and rescue team (projects: problem resolution)
    • Focuses on solving a specific problem
    • Requires specialised knowledge, skills
  • SWAT team (projects: tactical execution)
    • Special weapons and tactics - skilled with advanced tools
  • Professional athletic team (projects: tactical execution)
    • The manager operates more in the background
    • The developers are the stars of the team
    • Team members have highly specialised roles and so are critical for the success of a project
    • Highly specialised projects relevant to the individual strength of the team members

Team Models

  • Theatre team (projects: modern multimedia projects)
    • Central role is occupied by the director
    • Individual team members are restricted in their creativity (interpret their roles)
    • You sign up for a (one) particular role
    • Strong direction and a lot of negotiation about project roles
    • Integrates strong individual contributions within a central vision on creative projects
  • Large teams
    • Special problems of communication and coordination
    • Create small groups (teams)
    • Appoint representatives to interact with each other
  • In reality we find a mixture, or the use of different team structures at different times or in parallel

Team Models

effectiveness profile of team lifecycle
Effectiveness Profile Of Team Lifecycle

Source: Project Management, H. Maylor, 1996

Effectiveness Profile Of Team Lifecycle

lecture summary
Lecture Summary
  • This lecture was about
    • Motivation
    • Teamwork
    • Team structure

Lecture 6 Summary