Software Management Plan (part II)

1. Software Management Plan (part II) Fear of trying: The plight of rookie project managers Coaching the rookie manager 10 lessons learned from implementing integrated product teams

2. Fear of trying: The plight of rookie project managers • What do we teach the rookies who have just been appointed to lead their first software project? • Four attributes: • Communication • Understand how to tune your communication (presentation, written report, a phone call, etc) to the audience • The overall thrust of the communication may be the same, but the tone and structure differ for each audience • Some people has natural instinct, but most don’t • Must be trained by mentors By R. Pressman, Software Management, 7th Ed., pp. 281-283, 2006

3. Fear of trying: The plight of rookie project managers • Four attributes: • Negotiation • Rob Thomsett refers to “first, second, and third wave” project management. • First wave (1960s, 1970s): software people dictated the delivery dates and costs to the end users • Second wave (1980s): more balanced relationship • Third wave (1990s): balance of power shifted to the customers • Establish a dialogue • Plot negotiating strategy • Identify, then overcome, obstacles to success • Come to terms • Make it happen By R. Pressman, Software Management, 7th Ed., pp. 281-283, 2006

4. Fear of trying: The plight of rookie project managers • Four attributes: • Organization • Managers need organizational skills to administer the technical work, coordinate the people who are assigned the tasks, and track/control the progress • Organization is a partitioning process, know how to partition well • Partition the interactions with team members, know which roles are most important in any given situation • Facilitation • Make things easy for the technical people doing the work • Shield the team from burdens of everyday corporate bureaucracy By R. Pressman, Software Management, 7th Ed., pp. 281-283, 2006

5. Coaching the rookie manager • How do we grow good project managers? • Coaching vs. mentoring • Be willing to be coached • Learning through experience • An example of interaction between a rookie team manager (Frank) and a developer (Henry) • Match on “what must be done” • Frank had section “what Henry does not need to do to succeed.” By L. Hohmann, Software Management, 7th Ed., pp. 285-287, 2006

6. 10 lessons learned from implementing integrated product teams (IPTs) • Leadership • Lesson 1: strong upper management commitment to drive the implementation of concurrent engineering and IPTs in the face of opposition is required • Lesson 2: three to six months after adopting concurrent engineering (CE) and integrated product teams (IPTs), there is a high level of frustration and a desire to revert to the familiar approaches. Strong leadership is required to continue to employ CE and IPT approaches By P.R. Popick and S.A. Sheard, Software Management, 7th Ed., pp. 295-298, 2006

7. 10 lessons learned from implementing integrated product teams (IPTs) • IPT set up • Lesson 3: take the time to clearly define the IPT purpose, end products, customers, process, and product measures, resources, and team incentives. Encourage the IPTs to act within their empowerment domains • Decision making • Lesson 4: Carefully define the consensus decision-making procedure and when it is to be used, and use it to make some important decisions at all levels of the organization By P.R. Popick and S.A. Sheard, Software Management, 7th Ed., pp. 295-298, 2006

8. 10 lessons learned from implementing integrated product teams (IPTs) • Roles and responsibilities • Lesson 5: Make sure the leadership (including all levels of management) and the IPTs define, record, and commit to the new roles and responsibilities. Periodically, the leadership and the IPTs should review and revise the roles and responsibilities • Communication • Lesson 6: Effective and efficient team communication depends upon the IPT membership recognizing which work is best done as a team, as a subteam, and as individuals By P.R. Popick and S.A. Sheard, Software Management, 7th Ed., pp. 295-298, 2006

9. 10 lessons learned from implementing integrated product teams (IPTs) • Communication • Lesson 7: Establish a formal mechanism for communication between IPTs, and identify IPT dependencies early • Team skills and training • Lesson 8: Make sure the IPTs are supported with training that defines a core set of engineering discipline skills, interpersonal skills, IPT methods skills, and project management skills By P.R. Popick and S.A. Sheard, Software Management, 7th Ed., pp. 295-298, 2006

10. 10 lessons learned from implementing integrated product teams (IPTs) • A changing work sequence to develop engineering products • Lesson 9: Engineers and managers need to recognize and adopt a different approach to engineering work product development to realize the benefits of concurrent engineering • A balanced system approach to CE and IPTs • Lesson 10: CE and IPT approaches require integration into the overall system of management, with a focus on establishing the IPT empowerment and determining how performance appraisals and rewards will be administered in the team environment By P.R. Popick and S.A. Sheard, Software Management, 7th Ed., pp. 295-298, 2006