Reporting Progress

1
Chapter 13

• Reporting Progress

2
Introduction

• When we talk about reporting progress, we are
  thinking about reporting upwards, boss,board,
  customer etc. But for the project manager there
  is also another group to report the project team.

3
Introduction

• Reporting to the team can be very motivating
  experience, as team members can see the
  importance of their own contribution and the
  appreciation that others feel for their efforts.

4
Recipients of progress reports

• Recipients of the progress will differ from
  project to project but recipients are likely to
  include
• The project manager superior In an in-house IT
  department this may be a systems development
  manager or IT manager/director. Or in a systems
  company this would be business manager maybe for
  very large projects a board member.

5
Recipients of progress reports

• The customer The person who pays for the
  project.
• The users Who will use the new system.
• The quality assurance department, if there is one.

6
Recipients of progress reports

• Each of these groups have different reporting
  requirements. The users want to know when the new
  system be ready and when they need to start
  training and system implementation. The customer
  will also want to know the project is being done
  on a time and materials basis and costs.

7
Recipients of progress reports

• IT manager wants to know when resources will be
  required and when they will become free for other
  projects. Business manager wants to know the
  profitability of the project and quality
  assurance want to arrange quality audits at
  appropriate points in the project.

8
Frequency of reporting

• If reporting be made too frequent their
  production will take full time occupation
• If reporting be made infrequent causes losing the
  opportunity of raising the important issues and
  getting decisions made and clarified

9
Frequency of reporting

• Report should at least be prepared at the end of
  each project phases or perhaps keyed to project
  milestones.
• If the project has a very long stage some
  mid-stage report may be used.

10
Report content and format

• The reporting requirements should be established
  and agreed at the start of the project.
• In addition the format and structure of the
  reports needs to be agreed and documented.

11
Report content and format

• Exception reporting, assuming the project is
  running smoothly, this form of reporting should
  lessen the work involved for the project manager
  and enable everyone to concentrate on those areas
  that are not going quite well and need more
  management attention.

12
Report content and format

• There are disadvantages on exception reporting
  form that the users and the customer feels that
  everything is going wrong because they only see
  the failures. Many projects canceled for this
  reason.So that project managers needs to find a
  formula to not only showing problems but also
  emphasize the projects achievements.

13
Reports to the customer

• A project identifier (project name, report
  sequence number,date of report)
• A short narrative review of progress since the
  last report
• Milestones achieved, with dates and comparison
  with planned dates.
• Problems encountered (with solutions and
  proposals)
• Current predicted project end-date and other
  important dates.
• Change requests (details of new ones, status of
  existing ones)
• Cost details

14
Reports to the users

• A project identifier (project name, report
  sequence number,date of report)
• A short narrative review of progress since the
  last report
• Milestones achieved, with dates and comparison
  with planned dates.
• A revised schedule of user interface activities
  (such as review meetings, prototyping demo,
  training and implementation dates)

15
Reports to IT and business management

• All details on the customer report and also
  include
• Significant customer interface issues encountered
  for example any disaggreements over the scope
  or specification of the work.
• Opportunities for additional work or follow-on
  business.

16
Reports to QA personnel

• A project identifier (project name, report
  sequence number,date of report)
• A short narrative review of progress since the
  last report
• Milestones achieved, with dates and comparison
  with planned dates.
• Quality problems encountered and solutions
  applied.
• Current predicted end-date and dates for
  significant quality events such as major reviews
  or stage-ends.

17
Reports to the project team

• It is less formal than others
• It is probably better to hold a team meeting and
  deliver a verbal report
• For larger projects, written communication may be
  needed.

18
Report Presentations

• The objectives of the projects and its expected
  benefits.
• The achievements to the date.
• The problems
• The vision of the future

19
Reporting in PRINCE2

• Project initiation
• End-stage assessment
• Mid-stage assessment
• Highlight report
• Checkpoint
• Project closure

20
Summary

• Many people will wish to receive reports on the
  progress of the project. These includes the
  customer, the users, senior IT management and
  members of the project team.

21
Summary

• The reporting frequency needs to be set properly
  to higher the effiency of the project and the
  content and format of reports have to be designed
  for the needs of the recipients and written
  reports may be supplemented by presentations.

22
Thank youFor your Participation