The project control cycle
Management, in general, can be seen as the process of setting objectives for a system and then monitoring the system to see what its true performance is. In Figure 1.2 the 'real world' is shown as being rather formless. Especially in the case of large undertakings, there will be a lot going on about which management should be aware. As an example, take an IT project that is to replace locally held paper-based records with a centrally-organized database. It might be that staff in a large number of offices that are geographically dispersed need training and then need to use the new IT system to set up the back-log of manual records on the new database. It might be that the system cannot be properly operational until the last record has been transferred. It might also be the case that the new system will be successful only if new transactions can be processed within certain time cycles. The managers of the project ought to be asking questions about such things as how effective training has been, how many records have still to be transferred to the new database and transfer rates. This will involve the local managers in data collection. Bare details, such as 'location X has processed 2000 documents' will not be very useful to higher management: data processing will be needed to transform this raw data into useful information. This might be in such forms as 'percentage of records processed', 'average documents processed per day per person' and 'estimated completion date'.
In the example above, the project leader might examine the 'estimated completion date' for completing data transfer for each branch and compare this with the overall target date for completion of this phase of the project. In effect they are comparing actual performance with one aspect of the overall project objectives. They might find that one or two branches are not going to complete the transfer of details in time, and would then need to consider what to do (this is represented in Figure 1.2 by the box making decisions/plans). One possibility would be to move staff temporarily from one branch to another. If this is done, there is always the danger that while the completion date for the one branch is pulled back to before the overall target date, the date for the branch from which staff are being moved is pushed forward beyond that date. The project manager would need to calculate carefully what the impact would be in moving staff from particular branches. This is modelling the consequences of a potential solution.
Several different proposals could be modelled in this way before one was chosen for implementation.
Having implemented the decision, the situation needs to be kept under review by collecting and processing further progress details. For instance, the next time that progress is reported, a branch to which staff have been transferred might still be behind in transferring details. This might be because the reason why the branch has got behind in transferring details is because the manual records are incomplete and another department, for whom the project has a low priority, has to be involved in providing the missing information. In this case, transferring extra staff to do data input will not have accelerated data transfer.
Project objectives should To have a successful software project, the manager and the project team members be clearly defined. must know what will constitute success. This will make them concentrate on what is essential to project success.
There might be more than one set of users of a system and there might be different groups of staff who are involved its development. There is a need for well defined objectives that are accepted by all these people. Where there is more than one user group, then a project authority needs to be identified. Such a project authority has overall authority over what the project is to achieve.
This authority is often held by a project steering committee, which has overall responsibility for setting, monitoring and modifying objectives. The project manager still has responsibility for running the project on a day to day basis, but has to report to the steering committee at regular intervals. Only the steering committee can authorize changes to the project objectives and resources.
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 the project has been. For example, 'to reduce customer complaints by 50%' would be more satisfactory as an objective than 'to improve customer relations'.
In order to keep things manageable, objectives might need to be broken down into sub-objectives. Here we say that in order to achieve A we must achieve B, C and D first. These sub-objectives are also known as goals, steps on the way to achieving an objective, just as goals scored in a football match are steps towards the objective of winning the match.
This committee is likely to contain user, development and management representatives.
The measure can, in some cases, be an answer to simple yes/no question, 'Did we install the new software by 1 st June?' for example.
Identify the objectives and sub-objectives of the Brightmouth College payroll Exercise 1.7 project. What measures of effectiveness could be used to check the success in achieving the objectives of the project?
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.