Once the project has started, the project plan is the baseline for monitoring and controlling:

1. Keeping track of (monitoring) the project progress, basically, by a reporting system
2. Identifying deviations from the project plan (considered as part of the monitoring)
3. Taking controlling actions as a response to deviations from the project plan.

Before you proceed, please read chapter 6 of the textbook (Wysocki 2009).

Reporting and identifying deviations from the project plan

The first thing to decide is the intensity of reporting. Many reports provide a deeper insight into what is going on and lowers the risks of failure. However, many reports are time-consuming – to provide them as well as to evaluate them; low risks cost money. Having a low-level reporting scheme, reporting costs are low, but the risk of failure increases.

A project manager sets up a reporting system, which includes the following characteristics:

• Schedule for the provision of reports
• Different types of reports
• Reports that provide a basis for decision
• Identifying existing or potential problems
• Appropriateness to the targeted audience (e.g., a report for a senior manager will look different to that one for the leader of a work package).

The reporting system has to provide the following essentials to the project manager:

• Work (in terms of results) done vs. work ahead
• Time spent vs. time remaining
• Budget/personnel resources spent vs. budget/personnel resources remaining
• Measuring positive and negative deviations from the project plan (mostly in %) for work, time, and budget/personnel resources.

Reporting has to be manageable, meaning that the project manager has to evaluate the reports. “Wordy” reports are required in some cases. However, graphics provide a good overview and are appropriate tools to start with – even if “wordy” documentation has to be added in several cases.

We will provide the following examples for graphical tools:

• Milestone trend charts
• Gannt charts

Again we will use the simplified “project” of module 3 with its textual WBS and its even more simplified Gantt chart (which skips the work package “project management” and the hierarchies of the work packages/activities):

Work Breakdown Structure: Textual outline

1. Project management

1. Meetings
2. Reporting
3. Controlling

2. Updating and detailing requirements and system specifications

1. User interviews
2. System architecture

3. Prototyping

1. Development of components
2. System integration

4. Testing

1. End user tests
2. Administrators tests

5. Implementation

1. Technical implementation
2. Workflow implementation

6. Closing out

1. Documentation
2. Maintenance concept

Gantt chart example:

Diagram - Click here

Milestone trend charts

Milestone trend charts provide a rough overview on rather large projects. Milestones reflect the key intermediate results during a project. Deviations from milestones provide an idea about the project’s progress in general.

In the simplified project example, the following milestones might have been defined:

M1: Documented system specification (Apr 4, 2000)

M2: Completed prototype (Aug 4, 2000)

M3: Test report (Sep 15, 2000)

M4: Implemented system (Nov 10, 2000)

M5: Final project report and maintenance contract (Dec 22, 2000).

In this case, you want to analyze a completed project in order to learn lessons for the next one. There two examples for the development of milestone delays:

Example 1:

Diagram - Click here

Example 2:

Diagram - Click here

The two examples show different “extremes” of what can happen during a project. In example 1, you can observe a slow, successive delay in the completion of milestones. Example 2 shows a sudden and significant delay for milestone 3.

In example 1, you can assume that something is going wrong with general workflows and project management. You have to analyze these general aspects in order to improve your next project. In example 2, project management and general workflows obviously worked quite well: In the beginning, milestones were completed early, and after the delay of milestone 3, progress was speeding up. However, some sort of catastrophe happened during the completion of milestone 3. For your next project you know: Your concepts for and performance of testing need significant improvements.

Gantt charts

Using the same example, we now assume that the project manager has to report about the project’s progress on May 5, 2000.

Diagram - Click here

The black bars show the percentage work completed:

• Design: 100 %
• Prototype Component A: 20 %
• Prototype Component B: 90 %.

This tool provides you with a more detailed insight into what is happening in your project than the milestone trend chart. In this case, you are a bit late with the prototype of component B. But this is a small activity, not on the critical path; and, therefore, you need not to worry a lot about its completion.

The development of the prototype of component A requires more attention.

Everything might be OK: You have read in the textbook (Wysocki 2003, see figure 10.7) that, in the beginning of an activity, progress is slow – people have to start working, collect information, and prepare further work, which does not affect immediate results. So you still might be on schedule, but a more detailed analysis might let you sleep better (see below).

Performance of personnel

The prototype development of component A is supposed to take 60 working days, which are 12 calendar weeks (Apr 17 – Jul 7, 2000). After 4 calendar weeks (May 12, 2000), the project manager checks the progress and finds a work completion of 20 %.

We assume that three persons are engaged in this activity of developing the component A prototype, performing the following sub-activities:

• John Doe, adapting/developing functionalities 1-3
• Erika Mustermann, adapting/developing functionalities 4-30
• Mr. No, adapting/developing functionalities 31-40.

After 4 calendar weeks, 8 of 40 functionalities have been completed, which are 20 % of the overall work. The project manager was expecting the completion of 9 of 40 functionalities, which are 22,5 % - which on the first view might not be a severe problem. However, the following table presenting the performance of each staff member reveals that the project manager has a real problem:

(W = calendar week, F = functionality)

This table reveals that 8 of 40 functionalities are developed but not those as planned.

Mr. No is completely on schedule – in terms of working hours as well as results.

Erika Mustermann was working as many hours as planned; however, she developed 3 functionalities more than expected in the first 4 weeks.

John Doe was only borrowed from another project in order to develop three important functionalities within the first 4 weeks. However, he completed only 1 functionality. To make things worse, already, he has invested 17 extra hours, and no further hours are planned for this project.

Something that looked rather like a small nuisance in the beginning turned out to be very serious.

Taking controlling actions

A first type of change is an additional request by the customer. “We have seen a nice functionality that should be added to the system” is a typical sentence. From the point of view of the project manager, such a change is not too bad. Of course, he/she will have lots of work in fulfilling the additional request, but nobody can blame the project manager for a delay or increasing costs.

Wysocki (2009) suggests a very formal process, including official project change requests and project impact statements. This is a good advice, because, somehow, this customer’s request will end up with contracting issues and money.

Much worse are other changes that simply happen: your key staff member breaks his leg, a provider does not deliver a required data set in time, or the development of a piece of software is simply more complicated than expected. You might tell your customer all these stories – but he will not have the slightest interest in listening to you.

As a project manager you have several general options:

1. If you listened to the advice in module 3, you have already created a buffer for those cases in the preliminary project plan.
2. If the problem occurs in an activity which is not on the critical path, this activity can probably be shifted without major problems.
3. If the problem occurs in an activity on the critical path, compressing the schedule (see module 3) might help.
4. Getting more and more desperate, you might have to shift resources. You might look for other resources of non-critical activities and “borrow them” for the activity that is in trouble.
5. The last chance is to import additional resources: internal resources, mostly meaning extra hours for your staff, and external resources, mostly meaning money to spend for your company.
6. If nothing works, you will have to go to Canossa: negotiate with your customer. A good approach is to ask for postponing intermediate results, still guaranteeing the scheduled project end. The last approach is to postpone the project end. The very last approach is to ask for more money.