The Nature and Purpose of Project Management.
.0 The Nature and Purpose of Project Management
Project Management has evolved in order to plan, co-ordinate and control the complex and diverse activities of modern industrial and commercial projects.
All projects share one common characteristic - the projection of ideas and activities into new endeavours. The ever-present element of risk and uncertainty means that the events and tasks leading to completion can never be foretold with absolute accuracy. For some very complex or advanced projects even the possibility of successful completion might be of serious doubt.
The purpose of Project Management is to foresee or predict as many of the dangers and problems as possible and to plan, organise and control activities so that the project is completed as successfully as possible in spite of all the risks.
2.0 Project Management
The open university Software Project Management module (1987) suggests that management involves the following activities:
* Planning - deciding what is to be done
* Organizing - making arrangements
* Staffing - selecting the right people for the job
* Directing - giving instructions
* Monitoring - checking on progress
* Controlling - taking action to remedy hold ups
* Innovating - coming up with new solutions
* Representing - liasing with users
Traditionally management has been seen as a preserve of a distinct class within the organisation. As technology has made the tasks undertaken by an organisation more sophisticated, many management tasks have become dispersed throughout the organisation: there are management systems rather than managers. Nevertheless most projects will have a one person who is in charge. Such people are focused on the overcoming of obstacles to success, they are primarily trouble-shooters and their job is likely to be shaped by the problems that confront the project. A survey of managers that was published by Thayer, Pyster and Wood identified the following commonly experienced problems
* Poor estimates and plans
* Lack of quality and measures
* Lack of guidance about making organisational decisions
* Lack of techniques to make progress visible
* Poor role definition - who does what?
* Incorrect success criteria
3.0 Project Approaches
3.1 The Waterfall Model
This is the classical model of system development. Alternative names for this model are one-shot or once-through.
This approach is where each phase of the project is carried out in a strict sequence, every phase needs to be checked and signed off before moving to the next.
The phases are:
As you can see some of the arrows on the diagram are pointing upwards and backwards. This indicates that a later stage may reveal the need for some extra work at an earlier stage, but this should be the exception rather than a rule, after all the flow of a waterfall should be downwards with the possibility of just a little water splashing back. The limited scope for iteration is in fact once of the strengths of this approach. With a large project you want to avoid reworking tasks previously completed. Having to re-open completed activities can play havoc with promised completion dates. When this approach is worked well it allows project completion times to be forecast with more confidence than with some more iterative approaches allowing projects to be controlled effectively. However where there is uncertainty about how a system is to be implemented, and there very often is, a more flexible, iterative approach might be required.
Some of the problems with this approach is that it is difficult to change anything in a phase once it has been completed, and the results cannot be seen until the end of the project. Projects using this approach can often run out of time and budget, it is very rigid for today's rapidly changing business world.
3.2 The V Process model
This approach is an elaboration of the waterfall model and stresses the necessity for validation activities that match the activities that create the products of the project.
The V-Process Model can be ...
This is a preview of the whole essay
Some of the problems with this approach is that it is difficult to change anything in a phase once it has been completed, and the results cannot be seen until the end of the project. Projects using this approach can often run out of time and budget, it is very rigid for today's rapidly changing business world.
3.2 The V Process model
This approach is an elaboration of the waterfall model and stresses the necessity for validation activities that match the activities that create the products of the project.
The V-Process Model can be seen as expanding the activity testing in the waterfall model. Each step has a matching validation process which can, where defects are found, cause a loop back to the corresponding development stage and a reworking of the following steps. Ideally this feedback should only occur where a discrepancy has been found between what was specified by a particular activity and what was actually implemented in the lower activity on the descent of the V-loop.
For example: the system designer might have written that a calculation be carried out in a certain way. A second developer building code to meet this design might have misunderstood what was required. At system testing stage, the original designer would be responsible for checking that the software is doing what was specified and this would discover the coders misreading of that document. Only corrections should be feed back, not the system designers second thoughts, otherwise the project would slip into 'evolutionary prototyping'.
3.3 Incremental Delivery
This approach involves breaking the application down into small components which are then implemented and delivered in sequence. Each component delivered must give some benefit to the user.
Time boxing is often associated with the incremental approach. Here the scope of deliverables for an increment is rigidly constrained by an agreed deadline. This deadline has to be met, even at the expense of dropping some of the planned functionality. Omitted features can be transferred to later increments.
Advantages of this approach:
* The feedback from early increments improve later stages.
* The possibility of changes in requirements is reduced because of the shorter time span between the design of a component and its delivery.
* Users get benefits earlier than with a conventional approach.
* Early delivery of some useful components improve cash flow, because you get some return on investment early on.
* Smaller sub-projects are easier to control and manage
* 'Gold-plating' that is the requesting of features that are unnecessary and not in fact used, is less as users will know that they get more than one bite of the cherry - if a feature is not in the current increment then it can be included in the next.
* The project can be temporarily abandoned if more urgent work crops up.
* Job satisfaction is increased for developers who see their labours bearing fruit at regular, short, intervals.
Disadvantages of this approach
* Software breakage, that is, later increments may require modifications to earlier increments.
* Programmers may be more productive working on one large system than on a series of smaller ones.
* Grady Booch, an authority on OO, suggests that with what he calls requirements driven projects (which equate to incremental delivery) 'Conceptual integrity sometimes suffers because there is little motivation to deal with scalability, extensibility, portability or reusability beyond what any vague requirements might imply'. Booch also suggests that there may be a tendency towards a large number of discrete functions with little common infrastructure.
The delivery plan
The nature and order of each increment to be delivered to the users have to be planned at the outset.
The process is similar to strategic planning, but at a more detailed level. Attention is given to the increments of a user application rather than the whole application. The elements of the incremental plan are that the system objectives, open technology and the incremental plan.
4.0 SETTING OBJECTIVES
Effective objectives are concrete and well defined. Vague aspirations such as 'to improve customer relations' are unsatisfactory. Objectives should be such that it is obvious to all whether the project has been successful or not. Ideally there should be measures of effectiveness, which tell us how successful a project has been. For example 'to reduce customer complaints by 50%' would be a satisfactory objective rather than 'tom improve customer relations'. The measure can be, in some cases, simply a yes or no question (i.e. did we reduce the number of customer complaints by 50%?
At the end of each project is the realisation of some specific goal or objective. It is not enough to assign a project to someone and say "see what you can do with this". A specific objective increases the chances of leading to a specific outcome. While there may be one major, clear project objective, in pursuing it there may be interim project objectives. In lots of instances, project teams are tasked with achieving a series of objectives in pursuit of the final objective. In many cases, teams can only proceed in a stair step fashion to achieve the desired outcome. If they were to proceed in any other manner, they may not be able to develop the skills or insights along the way that will enable them to progress in a productive manner.
Objectives can often be set under three headings:
Performance and Quality
The end result of a project must fit the purpose for which it was intended. The specification must be satisfied.
At one time quality was seen as the responsibility of the quality control department, relying on inspection and testing to discover faults and then arranging for their rectification. In more recent years the concept of total quality management has come to the fore, with responsibility for quality shared by all the staff and the workforce from the top management downwards.
Achieving the quality, performance and reliability objectives obviously requires competence in engineering and design, but this must be complemented by adequate quality procedures (which could be ISO 9000).
Budget
The project must be completed without exceeding the authorized expenditure. There are however many projects where there is no direct profit motive, however it is still important to pay proper attention to the cost budgets and financial management still remains essential.
Financial sources are not always inexhaustible and a project might be abandoned altogether if funds run out before completion, in which case the money and effort already invested becomes forfeit and must be written off. In extreme cases the project contractor could face ruin.
Time to Completion
Actual progress has to match or beat planned progress. All significant stages of the project must take place no later than their specified dates, to result in total completion on or before the planned finish date.
The timescale objective is extremely important, late completion or delivery of a project is not very likely to please the project purchaser or sponsor.
One common risk for projects is failure to start on time.
5.0 PROJECT PLANNING
The STEPWISE Method
The framework with whichever project approach you use, should always apply to the planning process used. It is called the STEPWISE method.
Step 0 - Select Project
This is called step 0 as it is way outside the main project planning process. Projects are not initiated out of thin air - some process must decide to start this project rather than an other. While feasibility study might suggest that the project is worthwhile, it would still need to be established that it should be done before other projects also found to be worthwhile. This evaluation may be done on an individual basis or as part of the strategic planning.
Step 1 - Identify project scope and objectives
The activities in this step ensure that all the parties to the project agree on the objectives and are committed to the success of the project. A danger to be avoided is overlooking people who are affected by the project.
Step 2 - Identify project infrastructure
Projects are rarely initiated in a vacuum. There is usually some kind of existing infrastructure into which the project can fit. If they do not know already, project leaders must find out the precise nature of this infrastructure
Step 3 - Analyse project characteristics
The general purpose of this part of the planning operation is to ensure that the appropriate methods are used.
Step 4 - Identify project products and activities
The more detailed planning of the individual activities now takes place. The longer term planning is broad and in outline, while more immediate tasks are planned in some detail.
Step 5 - Estimate effort for each activity
At this point estimates of staff effort required, the probable elapsed time and the non-staff resources needed for each activity will need to be produced.
Step 6 - Identify activity risks
We now need to look at each activity in turn and assess the risks to its successful outcome. A project plan will be based on a huge number of assumptions, and so some way of picking out the risks that are most important is needed.
Step 7 - Allocate resources
The type of staff needed for each activity is recorded. The staff available for the project are identified and are provisionally allocated tasks.
Step 8 - Review/publicise the plan
A danger when controlling any project is that an activity can reveal that an earlier activity was not properly completed and needs to be reworked. This can transform a project that appears to be progressing well into one that is badly out of control. It is important to know that when a task is reported as completed that it really is - hence the importance of reviews.
Step 9 and 10 - Execute plan and lower levels of planning.
Once the project is underway, plans will need to be drawn up in greater detail for each stage as it becomes due. Detailed planning of the later stages will need to be delayed because more information will be available nearer the start of the stage. However it is necessary to make provisional plans for the more distant tasks, because thinking about what needs to be done can help unearth potential problems, but sight should not be lost of the fact that these plans are provisional.
6.0 References:
Software Project Management, third edition - Bob Hughes and Mike Cotterell
Project Management, sixth edition - Dennis Lock
Class Notes
