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. /: 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 lite 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.
Stop 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.
2.6 Step 4: Identify project products and activities
The more detailed planning of the individual activities that will be needed now takes place. The longer term planning is broad and in outline, while the more immediate tasks are planned in some detail.
Step 4.1: Identify and describe project products (or deliverables) In general there can be no project products that do not have activities that create them. Wherever possible, we ought also to ensure the reverse: that there are no activities that do not produce a tangible product. Making sure we have identified all the things the project is to create helps us to ensure that all the activities we need to carry out are accounted for.
These products will include a large number of technical products including training material and operating instructions, but also products to do with the management and the quality of the project. Planning documents would, for example, be management products.
The products will form a hierarchy. The main products will have sets of component products, which in turn might have sub-component products and soon. These relationships can be documented in a Product Breakdown Structure (PBS).
This part of the planning process draws heavily on the standards laid dow n in PRINCE 2. These specify that products at the bottom of the PBS should be documented by Product Descriptions. which contain:
• the name/identity of the product;
• the purpose of the product;
• the derivation of the product (that is, the other products from which it is derived);
• the composition of the product;
• the relevant standards;
• the quality criteria that should apply to it.
Case Study Example: PBS
At IOE. Amanda finds that there is a standard PBS that she can use as a check-list for her own project.
Brigette at Brightmouth College has no installation standard PBS. although she can, of course, refer to various books for standard check-lists. She decides that one part of the PBS should contain the products needed to help select the appropriate hardware and software for the payroll application (Figure 2.2).
Stop 4.2: Document generic product flows
Some of the products will need some other product to exist first before they can be created. For example, a program design must be created before the program can be written and the program specification must exist before the design can be commenced. These relationships can be portrayed in a Product Mow Diagram (PFD). Figure 2.3 gives an example.
Figure 23 A fragment of a PFD.
Case Study Example: At IOE, Amanda has a standard installation PFD. Many of the products that will IOE has standard PFD make up Amanda's application will be of the same type: hence the same generic
PFD will apply to each instance. It is pointless in these circumstances to draw up a separate PIT) for each instance of the product.
Exercise 2.2 Draw up a possible Product Flow Diagram (PFD) based on the Product
Breakdown Structure (PBS) shown in Figure 2.2. This represents the products that will be produced when gathering information to be presented to potential suppliers of the hardware. The volume figures are for such things as the number of employees for whom records will have to be maintained.
This may be delayed to later in the project when more information is known.
Step 4.3: Recognize product instances
Where the same generic PFD fragment relates to more than one instance of a particular type of product, an attempt should be made to identify each of those instances.
Case Study Example: identifying product instances
Amanda decides that there are likely to be four major software modules needed in her application for which the PFD fragment in Figure 2.3 would be appropriate The products that Brigette can identify at the present all have a single instance.
Step 4.4: Produce ideal activity network
In order to generate one product from another there must be one or more activ ities that carry out the transformation. By identifying these activities we can create an activity network, which shows the tasks that have to be carried out and the order in which they have to be executed.
Case Study Example: Part of the initial activity network for the IOE Maintenance (¡roup Accounts Activity network for IOE project might look like Figure 2.4. Maintenance Accounts
Exercise 2.3 Draw up an Activity Network for the Product Flow Diagram that you created in
Exercise 2.2 (or the PFD given in the solution if you prefer!).
The activity networks are * ideal* in the sense that no account has been taken of resource constraints. For example in Figure 2.4, it is assumed that resources are available for all four software modules to be developed in parallel.
Step 4.5: Modify the ideal to take into account need for stages and check-points
The approach to sequencing activities described above encourages the formulation of a plan that will minimize the overall duration, or 'elapsed time', for the project. It assumes that an activity will start as soon as the preceding ones upon which it depends have been completed.
There might, however, be a need to modify this by dividing the project into stages and introducing checkpoint activities. These are activities that draw-together the products of preceding activities to check that they are compatible. These checkpoints are sometimes referred to as milestone events. A checkpoint could potentially delay work on some elements of the project - there has to be a trade-off between efficiency and quality.
Amanda decides that after the four modules have been specified, the four Exercise 2.4 specifications need to be carefully checked to see that they are consistent and compatible. Redraw the activity network in Figure 2.4 to reflect this.
Was this article helpful?
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.