Project Management Instructor: Dr. Jerry Gao

Project Management Jerry Gao, Ph.D. Jan The Management Spectrum - People - The Players - Team Leaders - The Software Team - Coordination and Communication Issues - The Problem - Software Scope - Problem Decomposition - The Process - Melding the Problem and the Process - Process Decomposition - The Project (the rule)

The Management Spectrum - People - Three P’s: Effective software project management focuses on the three P’s: (1) people, (2) problem, and (3) process - People: Software engineering work is an intensely human endeavor. A people management capability maturity model (PM-CMM) --> key practice areas for software people: - recruiting, selection, performance, management, training, compensation, career development, organization and work design, and team/culture development The most important contributor to a successful software project --> having smart people with good skills Organizations with high levels of maturity in the people management ---> implementing effective software engineering practice

The Management Spectrum - The Problem - Three P’s: Effective software project management focuses on the three P’s: (1) people, (2) problem, and (3) process - Problem (related to a project): Before starting a project, we need to define and identify its - Objectives and scope - Alternative solutions - Technical and management constraints Considering other factors: delivery deadlines, budgetary restrictions, personnel availability technical interfaces, and so on. Without these information, it is impossible - To define reasonable estimates of the cost - To conduct an effective assessment of risk - To do realistic breakdown of project tasks - To come out a manageable project schedule

The Management Spectrum - The Process - Three P’s: Effective software project management focuses on the three P’s: (1) people, (2) problem, and (3) process - Process: A software process provides the framework --> a comprehensive plan for software development A number of different tasks sets applicable to all software projects: - tasks, milestones, deliverables, and quality assurance points Umbrella activities -> occurs throughout the process: - software quality assurance - software configuration management - measurement

People - The Players - In a software process, there are five types of players: - Senior managers, who defines the business issues. (strong influence on the project) - Practitioners, who deliver the technical skills for engineering software - Project (technical) managers, who must plan. Motivate, organize and control the practitioners. - Customers, who specify the requirements for the software. - End users, who interact with the software once it is released for use.

People - Team Leaders - Project management is a people-intensive activity. How to select a good team manager? MOI model of leadership suggested by Jerry Weinberg [WEi86]: - Motivation - the ability to encourage technical people. - Organization- the ability to mold existing processes that will enable initial concept to be translated into a final product. - Ideas or innovation - the ability to encourage people to create and feel creative. Software managers should concentrate on - understanding the problem to be solved, - managing the flow of ideas, - letting everyone on the team know that quality counts. Four important key traits to be an effective project manager: - Problem solving - Managerial identity - Achievement - Influence and team building

People - The Software Team Mantei [MAN81] suggests three generic team organizations: - Democratic decentralized (DD): - the software engineering team has no permanent leader. - decision is made by group consensus. - communication among team members is horizontal. - Controlled decentralized (CD): - has a leader -> coordinates specific tasks and secondary leaders. - secondary leaders have responsibility for subtasks. - horizontal communications among subgroups and individuals. - vertical communication in the control structure - decision is made by leaders. - Controlled centralized (CC): - team leader manages top-level problem solving and internal team coordination. - communication between the leader and team members is vertical.

People - The Software Team group Team leader secondary team leader communication group DD: CC:DC:

People - The Software Team FT1 P1 Pn FTm X X X X X X P1 Pn FT1FTm P1 T1Tm Pn X X X Project manager+ informal teams with coordinator Functional tasks team X X X XX engineer Project manager + team leaders Project manager + n engineers + m tasks

People - The Software Team Mantie’s seven project factors related to project team structure: - the difficulty of the problem to be solved. - the size of the resultant programs - the modularity of problem - the reliability of the software - the team life time - the rigidity of the delivery date - the degree of sociability (communication overhead) Team TypeDDCDCC DifficultyHighLowLow SizeSmallLargeLarge Team Life TimeLongShortShort ModularityLowHighHigh ReliabilityHighHighLow Delivery dateLaxLaxStrict SociabilityHighLowLow

People - The Software Team Constantine [CON’93] suggests four “organization paradigms” for software engineering teams: - A closed paradigm: a team with a traditional hierarchy of authority (like CC) - The random paradigm: a team loosely and depends on individual initiative of the team members - The open paradigm: heavy communication + control structure like CC - The synchronous paradigm: relies on the nature compartmentalization of a problem + little active communications Chief programmer team (by Harlan Mills described in Baker’s [BAK72]) : a senior engineer (1), technical staff (2-5), a backup engineer, support staff (e.g. technical writers), software librarian (1). Book “Peopleware” by DeMarco and Lister discussed “jelled team”: A jelled team is a group of people so strongly knit that the whole is greater than the sum of the parts… They don’t need managed in a traditional way, they don’t need to be motivated. They got momentum.

People - Coordination and Communication Issues Many failure causes of a software project. Here are some of them related to communications and coordination of a project: - The large scale of development efforts --> complexity, confusion, and significant difficulties in coordination of teams. - Uncertainty is common due to the changes of requirements and team status - Interoperability --> interoperations among systems Good and effective formal and informal communication mechanisms: - Formal impersonal approaches documents, deliverables, memos, project milestones, schedules, project control tools, change requests, and related documents, error tracking reports and data. - Formal, interpersonal procedures quality assurance activities (code & design inspection, review meeting) - Informal, interpersonal procedures informal group meeting (such as meeting with customers and users) - Electronic communication ( , web sites, video-based conference) - Interpersonal network

Problem - Software Scope A software project manager is confronted with a dilemma at the beginning of a software engineering project. - Software scope: (a) Context: - How does the software to be built fit into a large system, product, or business? - What constraints are imposed as a result of the context? (b) Information objectives: - What customer-visible data objects are produced as output from the software? - What data objects are required for input? ( c) Function and performance: - What function does the software perform to transform input data into output? - Are any special performance characteristics to be addressed?

Problem Decomposition Problem decomposition --> problem partitioning. Problem decomposition --> two areas: - the functionality of the delivery software system - the process that will be used to deliver the system - Functional decomposition: - Identify and define the functional scope of the system in terms of functional features and/or sub-functional systems. - Apply decomposition method on each feature. An example of the function features for a word processing system: - spell checking - sentence grammar checking - reference checking for large documents - section and chapter reference validation for large documents.

Process - Melding the Problem and the Process Each function to be engineered by the software team must pass through the set of framework activities: - customer communication - tasks to establish effective communications with customers. - planning - tasks to define resources, timelines, an so on. - risk analysis - tasks to assess both technical and management risks. - engineering - tasks to build the application system - construction and release - installation, release control, and customer support. - customer evaluation - task to obtain customer feedback and evaluation result. Process decomposition: - Select a software process model for the project. - Define a preliminary project plan based on the set of common process framework activities. - Partition the software process based on the tasks and activities common process framework (CPF)

Process - Process Decomposition Each function to be engineered by the software team must pass through the set of framework activities: - customer communication - tasks to establish effective communications with customers. - planning - tasks to define resources, timelines, an so on. - risk analysis - tasks to assess both technical and management risks. - engineering - tasks to build the application system - construction and release - installation, release control, and customer support. - customer evaluation - task to obtain customer feedback and evaluation result. Process decomposition: - Select a software process model for the project. - Define a preliminary project plan based on the set of common process framework activities. - Partition the software process based on the tasks and activities common process framework (CPF)

Process - Process Decomposition A small project may require the following work tasks: - Develop list of clarification issues. - Meet with customer to address clarification issues. - Jointly develop a statement of scope. - Review the state of scope with all concerned. - Modify the statement of scope as required. A complex project may require the following work tasks: - Review the customer request. - Plan and schedule a formal, facilitated meeting with the customer. - Conduct research to define proposed solutions and existing approaches. - Prepare a “working document” and an agenda for the formal meeting. - Conduct the meeting. - Jointly develop mini-spec for correctness, consistency, and lack of ambiguity. - Assemble the min-specs into a scoping document. - Review the scoping document with all concerned. - Modify the scoping document as required.