Page 1 Sponsored by the U.S. Department of Defense © 2007 by Carnegie Mellon University Watts S. Humphrey The Software Engineering Institute Carnegie Mellon.

Slides:



Advertisements
Similar presentations
This material is approved for public release. Distribution is limited by the Software Engineering Institute to attendees. Sponsored by the U.S. Department.
Advertisements

Presentation to HRPA Algoma January 29, My favourite saying… Fail to plan, Plan to Fail. 2.
S3-1 © 2001 Carnegie Mellon University OCTAVE SM Process 3 Identify Staff Knowledge Software Engineering Institute Carnegie Mellon University Pittsburgh,
SEP1 - 1 Introduction to Software Engineering Processes SWENET SEP1 Module Developed with support from the National Science Foundation.
1 Disciplined Software Engineering Watts S. Humphrey Software Engineering Institute Carnegie Mellon University Pittsburgh, PA Sponsored by the.
Copyright © 1994 Carnegie Mellon University Disciplined Software Engineering - Lecture 1 1 Disciplined Software Engineering Lecture #7 Software Engineering.
PRO2 - 1 Introduction to the Personal Software Process SWENET PRO2 Module Developed with support from the National Science Foundation.
Page 1 Sponsored by the U.S. Department of Defense © 2005 by Carnegie Mellon University Watts S. Humphrey Software Engineering Institute Carnegie Mellon.
Copyright © 1997 Carnegie Mellon University Introduction to the Personal Software Process - Lecture 1 1 Introduction to the Personal Software Process Lecture.
W5HH Principle As applied to Software Projects
1 - Sudhir P, Balasubrahmanyam P Leveraging TSP SM /PSP SM Metrics to drive Predictability and Quality of product releases An Intuit Perspective.
Leadership in the Baldrige Criteria
The Manager as Leader 3.1 The Importance of Leadership
Software Management Plan (part I) Software management’s 7 deadly sins The “3 P’s” of software management Why big software projects fail: the key 12 questions.
Stoimen Stoimenov QA Engineer QA Engineer SitefinityLeads,SitefinityTeam6 Telerik QA Academy Telerik QA Academy.
Fundamental of Software Project Management Team Assignment 1 – K15T2 – Team 07.
Diploma of Project Management Course Outline NSW Course Number Qualification Code BSB51407.
Productive Engineering Teams
INFO 637Lecture #31 Software Engineering Process II Launching & Strategy INFO 637 Glenn Booker.
Team Launch Introduction. Real projects are large and complex, and most software is created by teams Merely throwing people together does not result in.
Diploma of Project Management Course Outline NSW Course Number Qualification Code BSB51407.
Object-Oriented Software Engineering Practical Software Development using UML and Java Chapter 10: Testing and Inspecting to Ensure High Quality Part 4:
Demystifying the Business Analysis Body of Knowledge Central Iowa IIBA Chapter December 7, 2005.
1. 2 IMPORTANCE OF MANAGEMENT Some organizations have begun to ask their contractors to provide only project managers who have been certified as professionals.
Project Tracking. Questions... Why should we track a project that is underway? What aspects of a project need tracking?
Introduction to Software Engineering LECTURE 2 By Umm-e-Laila 1Compiled by: Umm-e-Laila.
SE-280 Dr. Mark L. Hornick 1 In software engineering, we sometimes distinguish between "practice" and "process". By "practice", we mean "what" software.
Recap from last week Understand organizations, including the four frames, organizational structures. Explain why stakeholder management and top management.
Disciplined Software Engineering Lecture #6 Software Engineering Institute Carnegie Mellon University Pittsburgh, PA Sponsored by the U.S. Department.
PBL in Team Applied to Software Engineering Education Liubo Ouyang Software School, Hunan University CEIS-SIOE, January 2006, Harbin.
SE 501 Software Development Processes Dr. Basit Qureshi College of Computer Science and Information Systems Prince Sultan University Lecture for Week 6.
This material is approved for public release. Distribution is limited by the Software Engineering Institute to attendees. Sponsored by the U.S. Department.
This material is approved for public release. Distribution is limited by the Software Engineering Institute to attendees. Sponsored by the U.S. Department.
Basic of Project and Project Management Presentation.
1 Project Management Introduction. 2 Chap 1 What is the impact? 1994: 16% of IT projects completed “On-Time” 2004 : 29% of IT projects “On- Time” 53%
ORGANIZATIONAL BEHAVIOR
Lecture: The Personal Software Process. 2 Overview  Personal Software Process assumptions process stages measures and quality strategy results.
Disciplined Software Engineering Lecture #7 Software Engineering Institute Carnegie Mellon University Pittsburgh, PA Sponsored by the U.S. Department.
Personal Software Process SM for Engineers: Part II TSP.
© 1998 Carnegie Mellon UniversityTutorial The Personal Software Process (PSP) The overview of the PSP that follows has been built from material made.
This material is approved for public release. Distribution is limited by the Software Engineering Institute to attendees. Sponsored by the U.S. Department.
This material is approved for public release. Distribution is limited by the Software Engineering Institute to attendees. Sponsored by the U.S. Department.
© Mujtaba, 2007 Workforce Diversity Management Dr. Bahaudin G. Mujtaba.
From Quality Control to Quality Assurance…and Beyond Alan Page Microsoft.
An Introduction to Software Engineering. Communication Systems.
“Look, who is the most successful in attracting and holding good people? The nonprofits. The satisfaction has to be greater than in business because there.
This material is approved for public release. Distribution is limited by the Software Engineering Institute to attendees. Sponsored by the U.S. Department.
Disciplined Software Engineering Lecture #3 Software Engineering Institute Carnegie Mellon University Pittsburgh, PA Sponsored by the U.S. Department.
This material is approved for public release. Distribution is limited by the Software Engineering Institute to attendees. Sponsored by the U.S. Department.
Disciplined Software Engineering Lecture #15 Software Engineering Institute Carnegie Mellon University Pittsburgh, PA Sponsored by the U.S. Department.
Copyright © 1994 Carnegie Mellon University Disciplined Software Engineering - Lecture 1 1 Disciplined Software Engineering Lecture #15 Software Engineering.
This material is approved for public release. Distribution is limited by the Software Engineering Institute to attendees. Sponsored by the U.S. Department.
Watts Humphrey IBM director of programming and vice-president of technical development Joined CMU Software Engineering Institute in 1986 Initiator and.
This material is approved for public release. Distribution is limited by the Software Engineering Institute to attendees. Sponsored by the U.S. Department.
Project Management Workshop James Small. Goals Understand the nature of projects Understand why Project Management is important Get an idea of the key.
This material is approved for public release. Distribution is limited by the Software Engineering Institute to attendees. Sponsored by the U.S. Department.
Copyright © 1994 Carnegie Mellon University CSCI511Personal Software Process - Personal Implications of PxP 1 Disciplined Software Engineering Lecture.
Carnegie Mellon Software Engineering Institute © 2006 by Carnegie Mellon University Software Process Performance Measures James Over Software Engineering.
New Supervisors’ Guide To Effective Supervision
MGT 461 Lecture #27 Project Execution and Control Ghazala Amin.
Introduction to the Personal Software Process. Overview Process Fundamentals PSP Concepts and Structure PSP Planning and Measurement PSP Quality Management.
Capacity-Building Coaching …..working with a group Joan M. Oakes, MSW.
1. WHAT IS A PROJECT? “A project is a problem scheduled for solution.” This definition forces us to recognize that projects are aimed at solving problems.
Chapter-5 PROJECT MANAGEMENT 1. Project Management Project Management – > a carefully planned and organized effort to accomplish a specific (and usually)
School of Business Administration
Identify the Risk of Not Doing BA
IT Project Management Version IT Industry Apprenticeship System
Team Software Process (TSP)
Presentation transcript:

page 1 Sponsored by the U.S. Department of Defense © 2007 by Carnegie Mellon University Watts S. Humphrey The Software Engineering Institute Carnegie Mellon University The Ideal Software Job

© 2007 by Carnegie Mellon University 2 Great Projects We hear a lot about death-march projects. What about those truly great projects? These are the projects that we remember and talk about. They were interesting, exciting, and fun. Why couldn’t every job be like that? This talk is about turning ordinary jobs into memorable ones.

© 2007 by Carnegie Mellon University 3 Agenda Typical projects Critical success factors People management Knowledge work A knowledge-working process Industry experience

© 2007 by Carnegie Mellon University 4 Typical Software Projects Typically, software projects are not successful. In engineers’ opinions, these projects were not achievable from the outset had excessive management pressure required unreasonable overtime were technically frustrating had lots of team conflict operated in a chaotic environment

© 2007 by Carnegie Mellon University 5 Successful Projects The general view is that a successful project meets the users’ expectations is delivered on or near the committed schedule cost what it was supposed to cost These are management’s typical views of success. The developers’ views are quite different.

© 2007 by Carnegie Mellon University 6 The Developers’ Views Developers view projects as successful if they were a technical challenge the product worked as it was supposed to work the team was high performing and cohesive In general, developers feel that, on such projects the product was well designed, implemented, and tested the team members enjoyed working together the team did not feel pressured by management

© 2007 by Carnegie Mellon University 7 Comparing Views of Success Developers typically feel that the key to success is technical challenge and team chemistry cost, schedule, or user reaction alone do not make projects memorable Management feels that the key is cost and schedule performance and user reaction projects can be successful almost regardless of the technical challenge or team chemistry

© 2007 by Carnegie Mellon University 8 Critical Success Criteria The key to truly great projects is to align the engineers’ and managers’ views of success. This, however, involves changes in management style engineering behavior Success Team Management Project Alignment

© 2007 by Carnegie Mellon University 9 People Management For developers to consistently meet management’s expectations, they must be trained in personal and project planning personal quality-management methods project tracking and reporting For teams to consistently work in this way, they must be competently led coached recognized and rewarded

© 2007 by Carnegie Mellon University 10 Historical Management Styles Management systems have evolved to meet ever more demanding needs. The principal phases of this development have been Body management – people as oxen Task management – people as machines Knowledge management – people as individuals

© 2007 by Carnegie Mellon University 11 Body Management In body management, people are valued for their muscles. They must be driven and directed. Historically, body management has treated people as slaves. In body management, motivation is through fear.

© 2007 by Carnegie Mellon University 12 Task Management - 1 As defined by Frederick Winslow Taylor, there are three principles to task management. Work incentives are required. Management knows the best way to do each job. Management requires that the workers follow this best way.

© 2007 by Carnegie Mellon University 13 Task Management - 2 These principles rest on several assumptions. The workers cannot be trusted to manage themselves. -Managers and workers have different motivations. -Unless the workers are managed, they will be unproductive. The managers closely monitor and control the work. The managers understand current job status and can take prompt corrective action.

© 2007 by Carnegie Mellon University 14 Knowledge Management -1 All development is knowledge work. Knowledge work requires assimilating and integrating concepts produces intangible intellectual products involves working with people Managing knowledge workers fundamentally differs from managing other workers.

© 2007 by Carnegie Mellon University 15 Knowledge Management - 2 The key rule in managing knowledge work is: the workers must manage themselves. To manage themselves, these professionals must be properly trained guided supported

© 2007 by Carnegie Mellon University 16 Managing Knowledge Work -1 The four principles of knowledge management are Only the workers understand the work. Knowledge workers must manage themselves. The workers must be trusted to manage their work. Knowledge workers need motivation, leadership, and coaching.

© 2007 by Carnegie Mellon University 17 Managing Knowledge Work -2 To manage themselves, knowledge workers must behave like responsible managers. They must make accurate plans negotiate commitments track their work consistently do what they say they will do Software is the first knowledge industry. It won’t be the last!

© 2007 by Carnegie Mellon University 18 Knowledge Work Challenges There are four management challenges in large-scale knowledge work. Development management Commitment management Project management People management

© 2007 by Carnegie Mellon University 19 Development Management Large-scale knowledge products are extraordinarily complex. Many critical decisions involve design details. Only the knowledge workers understand those details. That means that decision-making must be decentralized. That also means that management responsibility must be decentralized.

© 2007 by Carnegie Mellon University 20 Commitment Management Commitment management has two objectives. To make commitments that can be met To strive to meet all commitments This requires detailed development plans. For knowledge work, detailed plans can only be made by the people who will do the work.

© 2007 by Carnegie Mellon University 21 Project Management - 1 The objectives of project management are to produce quality products meet program commitments This requires that project management consistently understand project status maintain process discipline rebalance program resources protect the development teams

© 2007 by Carnegie Mellon University 22 Project Management - 2 For knowledge work, this further requires that the developers and their teams regularly and accurately report project status do quality work This further requires that the knowledge workers and their teams precisely know their project status know how to do quality work consistently work the way that they know they should

© 2007 by Carnegie Mellon University 23 A Knowledge-Work Process The Software Engineering Institute (SEI) has developed the Team Software Process (TSP) for knowledge work. The TSP shows knowledge workers how to manage themselves. Define their own processes Make their own plans Negotiate their commitments with management Track, manage, and report on their own work SM Team Software Process and TSP are service marks of Carnegie Mellon University.

© 2007 by Carnegie Mellon University 24 TSP Launch Meetings In starting a TSP project, management asks the team to produce its own plan. In TSP launch meeting 1, management describes what they want done explains why the job is important answers the team member’s questions The team then produces a plan to address management’s goals.

© 2007 by Carnegie Mellon University 25 An Example TSP Project The project was to develop communications test equipment. Management described the product they wanted. a new communication-line tester required new hardware and software The finished product had to be available in nine months.

© 2007 by Carnegie Mellon University 26 TSP Launch Meetings During the four-day TSP launch, the team members define a process and strategy for doing the job produce detailed team and personal plans assess the risks of their plans prepare a plan presentation to management The team and team leader are guided through the launch process by a qualified TSP coach.

© 2007 by Carnegie Mellon University 27 TSP Launch Meeting 9 At the end of the TSP launch, the team presents its plan. best plan alternative plans Management then probes the team’s plan assesses the plan approves the plan if it is suitable

© 2007 by Carnegie Mellon University 28 The Example TSP Project The project was to develop communications test equipment. Plan Size - KLOC 110 Effort - hours 16,000 Schedule - weeks 77 Defects per KLOC Integration and system test 1.1 Field trial 0.0 Customer use 0.0

© 2007 by Carnegie Mellon University 29 The Example TSP Project The project was to develop communications test equipment. Plan Actual Size - KLOC Effort - hours 16,000 14,711 Schedule - weeks Defects per KLOC Integration and system test Field trial Customer use

© 2007 by Carnegie Mellon University 30 Why the TSP Works The TSP addresses the fundamental issues of knowledge management. Provides the developers the skills to manage themselves. Enables management to trust the developers to manage themselves. Guides teams in making responsible commitments. Builds teams that own their processes and plans.

© 2007 by Carnegie Mellon University 31 TSP Industrial Experience Hundreds of organizations are using the TSP. Microsoft uses the TSP in its world-wide IT organization. Intuit has widely adopted TSP for their software work. Oracle is introducing TSP in its product-development groups. IBM has started a product-development effort.

© 2007 by Carnegie Mellon University 32 NAVAIR Experience Product size (KSLOC) Defect density (defects/KSL OC) Number of defects Cost of addressing defect Cost of addressing all defects WARP (before TSP) $8,330$4,169,831 AVJMPS (after TSP) $8,330$2,177,169 Cost saving from reduced defects $1,992,663 Cost of TSP training & support $225,300 Total cost savings from reduced defects $1,767,363 KSLOC: One thousand source lines of code

© 2007 by Carnegie Mellon University 33 Microsoft Results Non-TSP Projects TSP Projects Released On Time 42%66% Average Days Late 256 Mean Schedule Error 10%1% Production Defects/KLOC Sample Size 8015

© 2007 by Carnegie Mellon University 34 A Microsoft TSP Study Team performance improved with experience. In 4 releases, one team delivered on time increased productivity by 81%

© 2007 by Carnegie Mellon University 35 Intuit Results From data on over 40 TSP teams, Intuit has found that post code-complete effort is 8% instead of 33% of the project for TSP projects, standard test times are cut from 4 months to 1 month Twice the function in less time with higher quality. Development Test Non-TSP TSP

© 2007 by Carnegie Mellon University 36 Intuit TSP Survey Results % Favorable Engineers love it… Once they adopt it they can’t imagine going back

© 2007 by Carnegie Mellon University 37 Conclusions Because they require knowledge work, software projects have not typically been successful. Knowledge work requires a new management paradigm. In the future, all development work will be knowledge work. Such work requires developers who can manage themselves a knowledge-working management style

© 2007 by Carnegie Mellon University 38 For More Information Visit the PSP/TSP web sites General: Symposium: Contact SEI customer relations Phone, voice mail, and on-demand FAX: 412/ See the Watts Humphrey books Winning with Software: an Executive Strategy, Addison- Wesley, 2002 PSP: A Self-Improvement Process for Software Engineers, Addison-Wesley, 2005 TSP: Leading a Development Team, Addison-Wesley, 2006 TSP: Coaching Development Teams, Addison-Wesley, 2006