FIRST LEVEL CHECKS

   

Project plan: contents analysis

The first quick and very simple check you can do on a project plan is to check its table of contents. (If it doesn't have one send it back!) This is likely to take no more than 5 “10 minutes and can tell you whether it is worthwhile you spending any more time than this assessing the plan.

They may have different names but the table of contents should contain the following elements:

  1. Management summary. Some sort of overview or summary.

  2. Statement of what is to be done. The goal of the project.

  3. Deliverables. Also part of the goal. These may come under a number of headings:

    1. Software

    2. Hardware

    3. Documentation

    4. Services

  4. Completion criteria. How do we know when the project is over? (A key part of the goal.)

  5. Acceptance criteria. How does our customer decide the project is over? (Also a key part of the goal.)

The next eight are all part of the plan and the backup plan.

  1. Work breakdown structure (WBS). A list of all the jobs that have to be done to complete the project together with estimates of their associated effort and any assumptions made.

  2. A Gantt chart. Showing the WBS phased over time, and stating any assumptions made.

  3. Milestones. A list of key dates extracted from the Gantt chart.

  4. Resources required. Human and otherwise .

  5. Resource loading. How the resources are phased over time.

  6. Project budget (optional). Derived from the effort in the WBS (6) and Resources (9 and 10).

  7. Project organization chart (optional). Among other things, this serves to identify the project leader.

  8. Backup plan/margin for error. Sometimes called risk analysis.

The project plan represents a prediction of how things will go in the future with regard to this project. The intention of this section is to show that the author of the plan has given some thought to what he will do when what happens in reality differs from the project plan.

Match these 13 elements against the table of contents of the plan you are assessing. Without delving too deeply, this will give you your first indication of how well put together the plan is.

Project plan: work breakdown structure analysis

The next thing you need to see is whether or not the plan is complete, in the sense that it contains all of the various work elements that make up the project. The checklist displayed in Example 1 allows you to do this. Use it as a guide to highlight missing Project Plan elements. The checklist is presented in the form of a WBS, a structure that breaks down all of the project elements from a high to a detailed level.

The WBS tries to make the most general possible assumption about the life cycle that the project follows. The life cycle can be described as follows .

1 The requirements for the system are developed.

2 Following on from this, an overall architecture for the system is developed. This architecture gives the major blocks of the system.

3 The system is programmed (3.1) and a working (integrated) version (3.2) of it is produced.

4 Testing is planned (4.1) and carried out (4.2). 4b is often referred to as alpha test.

5,6 Both while the system is under development and after it is released, accepted, and has gone into maintenance, elements 5 and 6 (project management and configuration management) operate on the system.

7 Manuals are developed.

8 The system is released and implemented and accepted.

9 Training, initially of project team personnel and eventually of system users, takes place.

10 The system, having been accepted, goes into maintenance.

11-13 Some other elements that are likely to occur on almost any project.

The WBS is presented in such a way that you can add in your own WBS checklist elements, gathered from your own experiences over time.

EXAMPLE 1: WORK BREAKDOWN STRUCTURE

  1. Requirements analysis

    1.0 Reviews

    1.1 Requirements document(s)

    1.2 Request for proposal

  2. Product design

    2.0 Reviews

    2.1 High-level design (basic architecture)

    2.2 Low-level design (detailed design/program specs )

    2.3 Possible development of prototypes

  3. Programming

    3.0 Code walkthroughs

    3.1 Code and unit test

    3.1.1 Write code element

    3.1.2 Clean compile code element

    3.1.3 Unit test code element (including element test plan)

    3.1.4 Code element documentation

    3.2 Integration

    3.3 Test environment development

    3.4 Development support

    3.4.1 Database administration

    3.4.2 Development environment

    3.4.3 System build

  4. Testing

    4.0 Reviews

    4.1 Write test plans

    4.2 Alpha test (system test)

    4.3 Beta test (acceptance test)

  5. Project management

    5.0 Reviews

    5.1 Production of initial project plan and ongoing project monitoring and control

    5.2 Management of subcontractors

  6. Configuration management

    6.0 Reviews

    6.1 Ongoing configuration management

    6.2 Release

  7. Documentation

    7.0 Reviews

    7.1 User (different types)

    7.2 Administrator

    7.3 Release notes

    7.4 Technical manuals, i.e. manuals describing how the software works

    7.5 Help texts

  8. Implementation

    8.0 Reviews

    8.1 Installation

    8.1.1 Plans

    8.1.2 Activities

    8.1.3 Test

    8.2 Conversion

    8.2.1 Plans

    8.2.2 Activities

    8.2.3 Test

  9. Training

    9.0 Reviews

    9.1 Familiarization by project personnel

    9.2 Training of project personnel

    9.3 User training

  10. Maintenance

  11. Staffing

    11.1 Recruitment

    11.2 Staff training

  12. Quality

    12.1 Quality management

    12.2 Quality plans

  13. Administration

    13.1 Public holidays

    13.2 Annual holidays

    13.3 Sick

    13.4 Meetings

Match these WBS elements against those in the plan you are assessing. This will show you what, if anything, has been forgotten in your plan.

Project plan: Gantt chart analysis, high-level overview

The Gantt chart is the heart of your project plan. If there isn't one in the plan you are assessing, then send it back now, because there's not much point in going any further.

The Gantt chart can be assessed at a number of different levels, each one becoming progressively more detailed than the previous one. The more detailed the assessment the more likely you are to catch potential flaws in the plan. However, more work is required on your part to do this detailed analysis.

The three levels we will look at, working from the highest to the lowest , are:

  1. High-level overview

  2. Critical path

  3. All jobs

At this stage, however, we will only concern ourselves with a high-level overview.

The plan should present an overall high-level overview of the project. In other words, the plan should show:

  • What the main phases of the project are

  • How long these phases last

  • How they relate to each other

  • The amount of work in each phase

It doesn't take long to check this, and there are a number of advantages to doing so.

First, this overview gives you milestones “ points in time at which the project has to be in a particular state. If, when a particular milestone comes, a project isn't at the expected stage, then this is early warning that something is wrong.

The presence of a high-level overview also implies clarity of vision on the part of the project manager. It indicates that the project manager has clearly thought through “ at least at a high level “ what he is being asked to do.

An example of a plan which has exactly the kind of overview we are looking for is shown in Figure 14.1. Figure 14.2 shows one which is almost the direct opposite of what we mean. Both plans are based on real life.

Figure 14.1. Plan with high-level overview

graphics/14fig01.gif

Figure 14.2. Plan with no proper overview

graphics/14fig02a.gif

graphics/14fig02b.gif

One other thing to watch for at this level is the amount of activities being paralleled. Sometimes if a project has a very tight deadline or a deadline which has been set in advance of the plan being drawn up, the way people try to allow for this is to run several activities in parallel. There is nothing intrinsically wrong with this unless the activities that are being run in parallel are actually ones which in fact cannot be. For example, a number of potential system suppliers can't really be assessed until a Request For Proposal (RFP) has been drawn up. (An RFP is a document sent out by a company inviting other companies to tender for certain products or services.) It may be possible for some of the assessment jobs to be done, for example gathering information about particular products or systems or suppliers, while the RFP is still being drawn up, but it is certainly not possible for the RFP and the supplier assessment to complete at the same time!

Project plan: resource analyses

Two quick checks that should be done on a project are to examine its resourcing. At its simplest what this means is that the scheduling of people on the project takes account of some basic realities.

The first of these realities (Check 1) is that the allocation of people to jobs takes into account the fact that people can only work five days a week, and that there are certain holiday periods when they don't work. Thus you should check that the effects of:

  • annual leave ( especially for projects running over the summer)

  • public holidays

  • long weekends

  • seasonal holidays (Christmas, Easter)

have been accounted for.

Also, projects or phases of projects which end on Saturdays and Sundays should be looked at with some suspicion. They can imply that some basic thinking things through has not been done.

Check 2 is to check that every job in the project plan has a human being's name against it (see Chapter 4). If this is not the case, then that is not necessarily a problem provided there are jobs elsewhere in the plan “ e.g. hiring, recruitment, internal transfers, agreeing of subcontracts, and so on “ to supply these human beings' names.

Project plan: PSI analysis

If you've read Chapters 1 “ 10, you'll know what the PSI (probability of success indicator) is. If not, have a quick scan through Appendix 3 which will give you an overview.

The PSI is quickly calculated (you can use Figure 14.3 to help you) and will not only show you what kind of shape a project is in, but the low scores will enable you to say, in your review of the project plan, where the project manager should focus his energies.


Figure 14.3.

graphics/14fig03.gif


   


How To Run Successful Projects III. The Silver Bullet
How to Run Successful Projects III: The Silver Bullet (3rd Edition)
ISBN: 0201748061
EAN: 2147483647
Year: 2001
Pages: 176

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net