Critically assess the personal attributes you would expect to find in a successful project manager. Go on then to evaluate the effectiveness of the systems approach in building up a full picture of a project.

Leading on from this point, a project manager should be able to see different parts of a project in terms of their whole. It is of huge benefit to the project manager if they can do this; to be able to see the relationships and interdependencies between the many parts of the project. If the project manager can do this he will be able to understand, and hopefully foresee, how changes in one aspect of the project will affect other components of the project. This leads on to one final, major point. According to Lackman (1987, p 15) the 'most important, fundamental ability for a successful project manager' is the 'ability to maintain broad awareness while focusing on details'. If a project manager has broad awareness they are able to recognize potential risks before they become serious problems and deal with them swiftly. This is an integral aspect of the successful project manager's make-up; the ability to deal with situations before they become full-scale critical problems. The ability to focus on details is also of great importance as this is elementary to the completion of the project.

These, therefore, are the main aspects the successful project manager should be looking to have. Some can be taught others are more elusive, and will depend on the personality of the individual involved. However, with experience these are attributes all project managers should be looking to attain.

Part 2: Evaluate the effectiveness of the systems approach in building up a full picture of a project.

Project management has historically relied on techniques such as critical path analysis, earned value concept, configuration management, risk analysis and other such methods. These techniques are derived from a whole range of 'management disciplines' ranging from 'personnel' to 'operational research' (Saunders 1992, p 153). Recently there has been a feeling that these procedures have failed to deliver the necessary results and that perhaps to take a holistic approach, or systems perspective, would be of more value. The ensuing analysis describes, briefly, what the systems approach is, and looks at how effective it can be.

Fundamentally, when using the systems approach, the entire project is considered as a means of better understanding the role of each individual activity, function or component. When applied to the project management process, it can be used to provide a framework for identifying, defining and organizing project requirements in the order they occur. Basically, the result is a model of the process.

The systems approach can be very effective when it comes to building up a full picture of a project. There are many reasons for this. Firstly, as is frequently the case in project management, problems are only partially solved during the individual stages that make up the project. Frequently the problem will rear its head in another stage, later on in the life of the project (unless the cause of the problem truly lies within the individual stage). However, taking a systems approach means the entire process is considered and individual stages are thought of as being interrelated. This means that changes in any part of the process will produce changes in another part. This implies that using the systems approach makes the project manager aware of these relationships (possibly via feedback loops) and gives him (or her) a better understanding of the impact of change (Milosevic 1989, p 173). They are then better able to plan and organise activities, and have a better comprehension of how separate functions relate to each other. This can be thought of as taking a total approach as opposed to a partial approach.

Another reason why the systems approach is so good at building up a full picture of a project, is that it not only takes into account those factors within the boundaries of the project, but also those traditionally thought of as being outside the scope of the project structure. Therefore, when taking a systems approach all elements which affect project results are included, for example these could involve functions of the organisation itself or external contractors. This is vitally important as these external factors can have a major bearing on the outcome of a project. In some ways a systems view almost defines project management as a subsystem of a larger system (Milosevic 1989, p 174). In doing this a complete framework is established showing not only aspects of the project, but of how the project fits into the environment overall. This type of framework provides an excellent reference for analysing, discussing and communicating project requirements, functions such as planning and scheduling are also greatly aided (Medley 1989, p E.1.8).

Using the systems approach requires extensive documentation to be made available; this again aids understanding of the project, facilitating the entire process and making it more transparent, it can also smooth the transition of various contractors if and when required (Medley 1989, p E.1.9).

There are, however, some problems when using the systems approach. The systems approach takes into account all (external) factors that could affect the project outcome. However, in many cases not enough information is known about the (sometimes complex) relationships between external factors and the project itself. This knowledge or understanding can be troublesome to express or quantify. Another difficulty when using the systems approach is the relative inability to capture useful experience from past projects. It can be done to a certain extent, but not well enough. Perhaps some sort of formal mathematical modelling would be required to do this sufficiently well (Milosevic 1989, p 178).

Thus overall, the systems approach can be very useful in building up a holistic picture of the project management process, particularly aiding general understanding of it, and creating knowledge of the relationships that exist between individual activities. Furthermore it also gives an insight into a bigger picture - how the project fits into its environment as a whole. It is not a perfect solution or methodology however, but can be used to fit certain ventures and is ever evolving.

Part 3: Prepare a briefing note identifying the method you would use to sub-divide the scope of work within a project.

The method I would use to sub-divide the scope of work within a project would be to use a work breakdown structure (WBS). The vast majority of projects are way too complex to be managed and controlled effectively and efficiently without breaking them down into manageable segments (Slack et al 1995, p 647). Using a WBS does this very competently.

A WBS generally takes the form of a tree structure. It is an all-inclusive, hierarchical (from general to specific) formation of tasks, or deliverables, that are required to be carried out in order for the project to be completed. Essentially it identifies the major tasks, or sub-projects of the project itself, and breaks these down into sub-tasks until a defined, manageable series of assignments called a work package is arrived at. From this point each work package can be allocated its own objectives in terms of time, cost and quality. The WBS should be arranged logically and in such a way that each level relates to the one above, and also the one below.

Work breakdown structures are effective and helpful for a variety of reasons. First of all they are very adaptable; the breakdown of work can be specified in a plethora of ways to meet the requirements of the particular situation. For example the breakdown could be expressed in terms of the activities of the project (e.g. 'define needs' and 'select suppliers'); or it could be stated in terms of functions (e.g. 'finance', 'IT' and 'operations'); alternatively it may be expressed in terms of a physical grouping (e.g. 'hardware' and 'software'), all in their own way assisting with the reduction in complexity of visualizing the project as merely one single entity (Maylor 2003, p 89).

Another benefit, and reason why I would advocate the use of a work breakdown structure, is that (following on from the previous point) it encourages simplicity. The WBS brings clarity and demarcation to the project planning process. Without the use of it, the project would certainly never be completed satisfactorily, and doubtless chaos would reign. What the WBS does very well is that it summarises visually the status of work to be done; thus offering an attractive alternative to mere narrative. What it also does in this sense is give a clear job, or responsibility, to each team member for a manageable part of the project. The WBS shows 'how the jigsaw fits together' (Slack et al 1995, p 647), thus aiding a comprehension of where the project is 'going', and what part team members play in taking it there. Further, it provides a framework for building up information for reporting purposes.

A WBS therefore is an ideal technique to aid the planning process of a project, providing an exhaustive, graphical representation of the work required to fulfil the objectives of the project, in an easy to follow, and understandable format.

REFERENCES

* Cash, C. & Fox, R. (1992), 'Elements of Successful Project Management', Journal of Systems Management, vol. 43 no. 9, p 10-12.

* Flannagan, R. (1993), Risk Management in Construction, Blackwell.

* Lackman, M. (1987), 'Controlling the Project Development Cycle Part2 - Profile of a Successful Project Manager', Journal of Systems Management, vol. 38 no. 2, p 13-15.

* Male, S. & Kelly, J. (1993), Value Management in Design and Construction, Spon.

* Maylor, H. (2003), Project Management, 3rd edn, Pearson Education Limited, Essex.

* Medley, L. G. (1989), 'Systems Approach To Project Management', AACE International Transactions, p E.1.1-E.1.10.

* Milosevic, D. Z. (1989), 'Systems approach to strategic project management', Project Management, vol. 7 no. 3, p 173-179.

* Saunders, R. G. (1992), 'Project management: a systems perspective', International Journal of Project Management, vol. 10 no. 3, p 153-159.

* Slack, N., Chambers, S., Harland, C., Harrison, A. & Johnston, R. (1995), Operations Management, Pitman.