IS 556 Project Management

1. IS 556 Project Management On Time On Budget: Chapter 5 - MANAGING SOFTWARE DEVELOPERS Case Study: Ford Motor David Lash

2. Objectives • Project Organization • Team Organization • Types of reporting and why • Status Reports • Status Meetings • Some notes on managing developers

3. Managing Software Developers • “Average” developer tends to be … • highly creative, highly logical. • Possessive? Temperamental? Introverted? • Sackman Productivity study • 25:1 ratio – programming • 28:1 ratio – debugging • Development methods help reduce ratio • Add more organized and systematic processes (documentation, standards, meetings, reviews) • 5:1 ratio • Organization & social structure can add variance of 25% or more

4. Organizational Structure • Supervise developers VS lead • direct vs facilitate • The larger the project the more important the structure • For small team (<=5) a very basic structure

5. Medium Project Structure • Staff from 5-~20

6. Large Projects • Staff > ~ 40 Require further decomposition

7. Project Issues Affecting Structure • Project Size - Issues with Communication/coordination • Simultaneous Hardware and Software development • If software requires more high reliability -> more QA • Corporate structures may be centralized • Support structure like IT, • Secretarial, legal, • H/R

8. Matrix Organization • Project manager manages technical project development issues • Function manager handles other issues such as salary, reviews, training. • Functional managers within project management organization • Common in larger organizations

9. Matrix Organization

10. Matrix Organization Advantages • Expertise in special fields • Rapid development of specialists • Assigned to projects as needed • Flexibility in assigning people to projects as needed • People have functional home as project ends • Manager concentrates on technical issues • Shared responsibility (and stress) w/ functional areas • Can relieve top-management from day-to-day

11. Matrix Organization Disadvantages • Weak project management authority • No control over salary, promotion • Potential for conflicting priorities (function vs project) • Susceptible to role ambiguity. • Weak loyalty to project manager or team • Developers more likely to be loyal to who pays them. • More difficult for developers to change area • Project decisions can be more difficult

12. Projects are organized by teams • Will look at some types of teams • Democratic teams • Chief Engineer Teams • Expert Teams

13. Project teams • Projects are best organized into teams • At least those ~ >= about 5 developers • Advantages • Delegation of authority • Knowledge of team members tasks • Sharing of knowledge • Ease of communication within team • Identification of contribution

14. Projects are organized by teams • Democratic Teams • No specific leader – but may be one for admin tasks (e.g., coordinating mtgs, communications). • Leader might • Represents project to team • Represents team to project manager • Represents team to other functions • Ideally decisions made by everyone

15. Chief Engineer Teams • Chief Engineer Team leader - coordinator and technical mentor • Supervise work of others • Technical mentor to others • Administrative and coordination • Represent Project Manager to team and team to PM

16. Expert Teams • Formed as needed – (AKA SWAT Teams) • Used to assure quality or solve problems • Expert at specific task • Expert at communication • Often are managed as a democratic team.

17. Most Common Team Structures When do we use each? How? What is vital to success of each?

18. Objectives • Project Organization • Team Organization • Types of reporting and why • Status Reports • Status Meetings • Some notes on managing developers

19. Reporting • Types of management reports • written reports, verbal reports, status meetings, product demonstrations and even Intranet • Support QA and test reports • 90/10 rule - takes 50% of the time for last 10% • Why? • Tacit assumption that “work = new functionality” and work is not fixing small details. • Last 10% can be the most complex • Better to ask - how much longer until finished

20. Team Status Report • Suggests status reports from each team member • Could include: • Red flags • Concerns for Manager’s attention • Frequently involve resources (personnel) and things needed from client (sign off) • Update on activities during period • Description of activities on WBS during period • Planned activities • What plan to do for next period (Includes tasks and administration). • Problems • Reconcile activities with those planned in previous report • Problems are frequently mundane, but shouldn’t sound whiny • PM often collect status reports and roll into a master report.

21. Project Status Meeting • Periodic and regular • Address issues in team status reports • Attended by all key project members • Held to report and to resolve issues

22. Basic Reporting Techniques • Project status deliverables are separate and apart from other project deliverables • Periodic, written status reports • Verbal updates • E-Mail updates • Status meetings • Project status meetings • Steering Committee updates • Timesheets

23. Basic Reporting Techniques • Along with timesheets, the status report is the basic historical document. • Status reports should be issued . . . • From team members to team leaders • From project managers to project sponsors and stakeholders. • Status reports are summaries, not detailed diaries. • Usually 1-2 pages. • Provide early warnings of potential issues or problems between the team and team/project leadership. • Real problems shouldn’t be buried in status reports. • Any red flagged item should have been previously disclosed. • Significant changes in project status require: • advance notice, as soon as the information is known. • a personal visit to verbally update the key sponsor(s). • Reading about a major delay in a status report or finding out about a significant issue for the first time at a steering committee meeting is not acceptable.

24. Basic Reporting Techniques • Periodic, written status reports should contain: • Accomplishments • Planned Activities • Problems and general issues, including resource constraints • Red flags • The periodic, written status report should contain: • Date prepared • Date covered • Name of submitter • Project name (team name) • If the status report is written by the project manager to management . . . • budget and schedule variances must be discussed.

25. Basic Reporting Techniques • Another form of status report is the stoplight report. • A summary style report for reporting to top management. • Uses traffic lights to indicate current status. Stop Light Report For Release 1.23

26. Basic Reporting Techniques • The stoplight report approach can also be used in conjunction with key performance indicators (KPIs) to present a balanced scorecard for to management for the project. • Might include • List of tasks completed • Defect statistics • Top 10 Risk List • Percent of schedule used • Percent of resources used

27. Basic Reporting Techniques • Periodic written status reports • Adopt and use a consistent format for all team members • Publish weekly or bi-weekly. • Page 108 (OTWB) has sample report. (next slide)

28. Weekly Status Report

29. Basic Reporting Techniques • Timesheets • Organize the project in such a way that significant development events are tracked and reported. • There are differing schools of thought about the method and the extent of the details in capturing time worked against a project. • If you want to improve your estimating accuracy for future projects, you’ll be wise to keep good records of time spent.

30. Basic Reporting Techniques • Capture all time. • Develop activity codes and report what was done. • Capture time to the work breakdown structure (WBS). • Capture time to the work product or deliverable. • Page 108/109 (SPSG) has sample time codes.

31. Example Time Codes Page 108/109 (SPSG) has sample time codes.

32. Status Meetings • Meetings . . . • The event we love to hate in the business world. • Biggest complaint - they are too long. • Usually wander off the subject. • Usually don’t start on time. • What to do: • Hold fewer formal meetings. • Make these meetings shorter. • Have a prepared, formal agenda or format and stick to it for every meeting. • The project manager is the meeting leader/facilitator. • Appoint another team member as the scribe to record the notes of the meeting. • Rotate the scribe function if possible. • However, if someone takes good notes and doesn’t mind, stay with that person.

33. Status Meetings • A typical status meeting: • Coverage of outstanding issues or questions from last meeting. • Project progress since last meeting. • Review the project schedule. • Review the project budget. • New issues or developments. • Review the issues list. • Resolve issues or approve resources for further investigation. • Review the changes list. • Approve, reject or defer action on changes.

34. Status Meetings • A typical status meeting (continued): • Potential problems,focused on • Deliverables (Scope Reductions and Delays) • Estimates (Plan versus Actual Comparisons) • Resources and Constraints • (Plan versus Actual) • Personnel Changes and Issues • (Turnover, Absences) • Overtime Worked • Schedules • Affect on Deliverables • Affect on External Events, such as production and training schedules

35. Status Meetings • How to keep meetings shorter: • Encourage frequent, informal or working meetings between team members. • There is a difference between idle conversations and informal meetings. • The project manager or team leader should: • Insist on both an agenda for and notes from informal or working meetings. • These can be e-mail updates to the participating parties with copies to the team and project leaders.

36. Status Meetings • Meeting books: • The meeting agenda and supporting documents that will be discussed should be in the hands of attendees at least 24 hours prior to a scheduled meeting. • Attendees need to review these and should be prepared to ask questions or discuss them. • Reading at a meeting is counterproductive. • Meeting minutes: • Publish as soon as practical after the meeting concludes.

37. How to Report • Project Intranets • (department to department) • Project Extranets • (consultant to client) • What are they: • Web sites containing all documentation and deliverables related to the project.

38. Using Web Sites • Web Sites or “Project Portals” are a great way to manage the project management related deliverables and other project work products. • Many of the latest versions of Project Management tools include collaboration and web scheduling pieces. • Most importantly: • Don’t rely exclusively on or hide behind the project’s web site. • Project management remains largely a person to person activity.

39. Example software project intranet There are no secrets on a successful software project. Both good and bad news must be able to move up and down the project hierarchy without restriction. – SPSG – Pg 93.

40. Motivating Developers • Software development is an analytic but creative task • Analytic/creative types are sensitive and often cynical • If a project manager is too controlling can often be problematic • If not detailed enough can be problematic • If not egoless (humility) enough can be problematic. • Management by edict seldom works. • Your personal style, sense of humility, attention to detail and own emotional stability may • Be more important to you and your project’s success (then getting an A++++ in IS556).

41. Objectives • Project Organization • Team Organization • Types of reporting and why • Status Reports • Status Meetings • Some notes on managing developers