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
• 251 ratio programming
• 281 ratio debugging
• Development methods help reduce ratio
• Add more organized and systematic processes
  (documentation, standards, meetings, reviews)
• 51 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 (lt5) a very basic structure

5
Medium Project Structure

• Staff from 5-20

6
Large Projects

• Staff gt 40 Require further decomposition

7
Project Issues Affecting Structure

• Project Size - Issues with Communication/coordinat
  ion
• Simultaneous Hardware and Software development
• If software requires more high reliability -gt
  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 gt 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 Managers 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 shouldnt
  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 shouldnt 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, youll 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 dont 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 doesnt
  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
• Dont rely exclusively on or hide behind the
  projects 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 projects
  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