Step Analyse project characteristics

The general purpose of this part of the planning operation is to ensure that the Chapter 4 elaborates on appropriate methods are used for the project. the process of analysing project characteristics.

Step 3.1: Distinguish the project as either objective- or product-driven

This has already been discussed in the first chapter. A general point to note is that as system development advances, it tends to become more product-driven, although the underlying objectives always remain and must be respected.

Step 3.2: Analyse other project characteristics (including quality-based ones)

For example, is this an information system that is being developed or a process control system, or does it have elements of both? Is it a safety-critical system, that is, where human life could be threatened by a malfunction?

Step 3.3: Identify high level project risks

Consideration must be given to the risks that threaten the successful outcome of the project. Generally speaking most risks can be attributed to the operational or development environment, the technical nature of the project or the type of product being created.

At IOE, Amanda identifies the danger of there being resistance to the new system Case Study Example: by maintenance engineers, especially as a new centralized group accounts office High level risks is to be set up. Amanda decides therefore that additional efforts are needed to consult all sections involved and that the new procedures should be introduced in small increments to accustom staff to them gradually.

Brigette at Brightmouth College considers the application area to be very well-defined. There is a risk, however, that there might be no application on the market that caters for the way that things are done at the moment. Brigette, therefore, decides that an early task in the project is to obtain information about the features of the main payroll applications that are available.

Step 3.4: Take into account user requirements concerning implementation

The clients will usually have their own procedural requirements. For example, work for government departments usually requires the use of SSADM.

Step 3.5: Select general lifecycle approach in the light of the above

The project life cycle to be used for the project will be influenced by the issues Chapter 4 discusses life raised above. For example, a prototyping approach might be used where the user cycles in more detail, requirements are not clear.

Chapter 5 goes into more detail on this topic. Function points are an attempt to measure system size without using the number of lines of code.

Chapter 7 goes into this in more detail.

PRINCE 2 suggests that the PBS be presented as a hierarchy diagram. In practice it may be more convenient to produce a structured list.

Step 3.6: Review overall resource estimates

Once the major risks have been identified and the broad project approach has been decided upon, this would be a good point at which to re-estimate the effort and other resources required to implement the project. Where enough information is available, an estimate based on function points might be appropriate.

Project Management Made Easy

Project Management Made Easy

What you need to know about… Project Management Made Easy! Project management consists of more than just a large building project and can encompass small projects as well. No matter what the size of your project, you need to have some sort of project management. How you manage your project has everything to do with its outcome.

Get My Free Ebook

Post a comment