Project MGT 1

This free downloadable QSheet (Quick-learn Sheet) introduces and explains an array of key issues that are fundamental
to successful project management. From understanding the basic concept of a project to addressing the organisational requirements of each project initiative, from selecting the most appropriate life-cycle model to mastering project planning and control; this QSheet should prove an invaluable aid. This information is taken from GetAhead in Organizing Projects, GetAhead in Planning Projects and GetAhead in Controlling Projects. GetAhead in Organizing Projects This 5 hour interactive multimedia training course is equivalent in scope to a two-day instructor led course. It will teach you all of the practical techniques needed to put the appropriate management and supervisory structure in place for projects of any size. This course is accredited by the Association for Project Management. GetAhead in Planning Projects This 5 hour interactive multimedia training course is equivalent in scope to a two-day instructor led course. It will teach you all of the practical techniques needed to carry out the appropriate degree of planning for projects of any size. It also covers project planning diagrams and a comprehensive hierarchy of project plans. This course is accredited by the Association for Project Management. GetAhead in Controlling Projects This 5 hour interactive multimedia training course is equivalent in scope to a two-day instructor led course. It will teach you all of the practical techniques needed to design and implement the optimum control mechanisms for projects of any size. This course is accredited by the Association for Project Management. At $29.95 or 19.95 each these GetAhead project management training courses represent outstanding value for money with over 70,000 GetAhead courses sold worldwide. You can order online for same day despatch and if you are not delighted with you can return the courses within 10 days for a full refund. Buy all 3 project management training courses for $79 or 49. NB. This QSheet represents only a fraction of the multimedia training course.
Full details of this course are available at:
www.getahead-direct.com or
www.getahead.uk.com
QSheet Contents Introduction ........................................................................................................................................... 3 Project Management Characteristics .......................................................................................................... 3 Keeping Sight of the Goal......................................................................................................................... 4 Is it a Single Project? .............................................................................................................................. 4 The 3 Main Roles? ................................................................................................................................... 4 The Matrix Management Approach ............................................................................................................ 5 Matrix Management Needs Effective Communication ................................................................................... 5 Sources of Conflict .................................................................................................................................. 6 Staff Concerns ........................................................................................................................................ 7 Management Structure ............................................................................................................................ 8 Management Structure - Style .................................................................................................................. 8 Management Structure - Representation .................................................................................................... 8 Project Team Fundamentals ..................................................................................................................... 9 Concerns of New Team Members .............................................................................................................. 9 Motivating Team Members ..................................................................................................................... 10 Is Theory Y Management ....................................................................................................................... 10 Project Life Cycles ................................................................................................................................. 11 The Gantt Chart .................................................................................................................................... 12 The Gantt Charts Limitations ................................................................................................................. 12 Resource Planning................................................................................................................................. 13 Resource Definitions & Allocation ............................................................................................................ 13 Resource Aggregation, Leveling & Smoothing ........................................................................................... 14 Monitoring the Critical Path .................................................................................................................... 14 Converting Resources into Costs ............................................................................................................. 14 Configuration Management - Introduction ................................................................................................ 15 Configuration Control ............................................................................................................................ 15 Configuration Management Plan.............................................................................................................. 16 The Configuration Administrator.............................................................................................................. 17 Issue & Submission Procedures............................................................................................................... 17 Configuration Audits .............................................................................................................................. 17 Project Change Control .......................................................................................................................... 18 Identifying Project Change ..................................................................................................................... 18 Change Control Mechanism .................................................................................................................... 19 Change Control Forms ........................................................................................................................... 20 Document Update Request ..................................................................................................................... 21 Change Request.................................................................................................................................... 22 Project Planning Introduction.................................................................................................................. 23 Standard Planning Diagrams .................................................................................................................. 24 Project Plans ........................................................................................................................................ 25 Product Based Planning ......................................................................................................................... 26 Product Based Planning - Illustrated ........................................................................................................ 26 Planning Diagrams Overview .................................................................................................................. 27 Work Breakdown Structure..................................................................................................................... 28 Work Breakdown Structure Work Packages............................................................................................ 29 Work Breakdown Structure Illustration.................................................................................................. 29 Work Breakdown Structure Guidelines .................................................................................................. 30 Product Descriptions.............................................................................................................................. 31 Product Descriptions - Illustrated ............................................................................................................ 31 Product Flow Diagrams .......................................................................................................................... 32 PERT Charts ......................................................................................................................................... 33 PERT Charts Illustrated ....................................................................................................................... 33 PERT Charts Relationship Identification ................................................................................................. 34 GetAhead in Organizing Projects ............................................................................................................. 35 GetAhead in Planning Projects ................................................................................................................ 36 GetAhead in Controlling Projects ............................................................................................................. 37 Project Management - Customer Reviews................................................................................................. 38
Copyright Interactive Training Technologies Ltd All Rights Reserved
www.getahead.uk.com
Introduction
Effective project management facilitates the smooth running of horizontally oriented work in organizations that are traditionally vertically oriented. Projects require the co-operation of line managers both across the departments involved and throughout the various levels of seniority. In large scale projects, an almost entirely self-contained project team can be created, either by assigning line staff to the project on a full-time basis or by hiring in external resources. Often a combination of both is used but in either case, because the project staff are essentially full-time, the conflicts between line and project management are minimized. In these situations the project team member has only one boss, the project manager. Even in these large selfcontained projects, it is likely that there will be a requirement for some resources that are outside of the their control. The very fact that the project is used to operating in isolation, may accentuate any communication problems that then arise. However, it is more typical for projects to use staff and other resources that remain under the control of a departmental or line manager. This type of project environment raises both the opportunities and potential hazards of integrating line and project management. The challenge is to create an environment that fosters cooperation and not one that breeds counter-productive competition.
Project Management Characteristics

Projects normally require key resources, which are not under the direct control of the project manager. The project manager will therefore need to negotiate with the relevant line manager to borrow and control these resources as and when they are required. The cooperation of line managers is essential for the success of the project and project management staff should work hard at developing a good working relationship with them. The staff assigned to the project will often be reporting to two bosses - their line manager and the project manager; it is important that their position is clear at all times. Effective project management is characterized by the following: Clear leadership and direction Seamless integration of new members into the team Ability to communicate clearly Arbitration skills when problem solving Ability to handle interpersonal conflicts Capability to plan and secure commitments
Project management staff should have the proven ability to assimilate and prioritize individual demands to make effective decisions. Conflict is a common occurrence in a project environment and project management staff should be skilled in conflict resolution. They will be judged heavily on their personal experience and the credibility that they already possess within the organization.
www.getahead.uk.com
Keeping Sight of the Goal

Project based working involves the efforts of a group of people dedicated to achieving a specific goal. A series of factors will contribute to the success of the project: The appointment of project leaders at all levels who are committed to the project and respected by the team. A shared belief in what the team is trying to achieve and a constant focus on the goals. A willingness to negotiate with those outside of the team for the benefit of the project.
The single most important factor in determining the success of the team is constant referral to the question "What are we trying to achieve?" It is all too easy for project teams to lose sight of the overall aim of the project.
Is it a Single Project?
Every project should be placed under the overall control of a single project manager. Large or complex projects may well be divided into a number of sub-projects and sub-project managers can then be used to control them. The division of a project into sub-projects is the responsibility of the project owner, who should work closely with the overall project manager when determining this. Sub-projects are often defined in terms of discrete areas of work, which can be allocated to sub-project managers with relevant expertise. The use of sub-project managers enables a wide variety of management structures to be imposed on any given project. This series of courses share a common theme of being based on project scenarios that justify division into subprojects. However, projects are often smaller and more straightforward, making this sub-division unnecessary. Where this is the case, all responsibilities assigned to the sub-project manager should be undertaken by the project manager themselves, who may then decide to delegate some of these to task leaders. It is important not to make the organization of your project more complicated than necessary. You should apply the organizational framework detailed in this course in as streamlined a way as your project allows.
The 3 Main Roles?

There are three major project management roles: the project manager, sub-project manager and task leader. The appointment of any or all of these positions should be made entirely with reference to the needs of the project. In the smallest of projects both the roles and responsibilities of all three of these roles could be undertaken by a single project manager. Even though all three roles could be combined within one individual the demands placed on this individual may still not justify a full-time position. At the other extreme some projects can be enormous in scope, complexity and duration. The building of the Channel Tunnel, as one of the largest civil engineering projects in history, involved scores of project management staff, covering all three of the roles outlined. The Channel Tunnel results were by no means atypical of such large scale and complex projects. Despite the bringing together of the best engineers, designers and project management experts available the project did suffer from significant delays and a significant overspend. The inescapable conclusion is that to maximize the opportunities for success, projects and their corresponding management structures, should be run by staff who have gained experience in projects of a similar size and nature.
www.getahead.uk.com
The Matrix Management Approach

When calling on a variety of resources, often from various departments, projects are operating in a matrix management environment. This is a descriptive term for the management environment where projects cut across organizational boundaries and involve staff who are required to report to their own line manager as well as to the project manager. This is not a radical departure from traditional hierarchical management; indeed the traditional vertical management structure is still in place but is enhanced by temporary horizontal structures representing each project. To see an illustration of the type of reporting structures that arise, click on the graphic.
The diagram illustrates the reporting structures that may result in an organization that is running multiple projects. An individual who is working in department B and who is assigned part-time to projects X and Y will find themselves reporting to three different managers all of whom will have some degree of authority over this member of staff.
Matrix Management Needs Effective Communication

Matrix management relies on cooperation and communication between everyone involved. Whilst in a pure project environment, the decision-making authority rests with the project manager; in a matrix environment all major decisions will be reached by consensus. A satisfactory working arrangement needs to be reached that bridges the inevitable differences in priority that will exist between project managers and line managers. Project managers will tend to view their own project as the focal point whereas departmental managers will tend to view things from a departmental perspective. To function effectively matrix management environments should have the following characteristics: There should be effective channels of communication between the managers involved. All of the relevant line managers should contribute to project planning and resourcing decisions should be reached by consensus. There should be formal procedures in place for resolving any management conflicts that do arise. Project staff should feel committed to the project as well as to their own department. In an ideal world the project manager would have little more to do than plan the project, secure the agreement of the line managers to deliver their pieces of the jigsaw on time and within budget, and then sit back and let it all happen. The real world is usually very different.
Matrix management relies on cooperation and communication between project and line managers, as all major decisions are necessarily reached by consensus.
To function effectively, matrix management environments should incorporate effective channels of communication as well as formal procedures for resolving any management conflicts that arise.
www.getahead.uk.com
Sources of Conflict Conflict is an inevitable consequence of project-based working. Therefore, it is important to understand the effects on staff morale, when project-based working is introduced.
Regardless of how well planned a project may be, it will be subject to unforeseen demands and the direction of the project may need to change as it progresses. Conflict often arises from decisions that inconvenience people, but are nevertheless essential to the success of the project. Unforeseen changes in priority may result in conflict both within the project environment and between the project and the external departments that will be most effected by a change in project emphasis. If a project falls behind the plan then there is likely to be conflict between the project and external departments who will then be expected to extend their commitment of personnel to it. Technical conflicts are common where a department is supporting the project in a technical capacity. The project manager may reject the solution preferred by the department on technical, cost or scheduling grounds. The administrative procedures in use on the project may be unfamiliar to some of the external departments effected. Personality conflicts often manifest themselves as one of the earlier types of conflict already highlighted. This often makes them difficult to identify and therefore they can be very difficult to resolve. The project manager will often try to minimize each external departments billing to the project. Conversely, the departmental managers will often try to secure as much of the projects budget as possible. Conflict is an inevitable consequence of project work, where there is constant pressure to achieve targets within strict time and resource constraints.
www.getahead.uk.com
Staff Concerns
When introducing project working into an organization a variety of issues may cause concern to members of staff, especially those who are requested to work on the first projects that are implemented. It is common for staff involved in project work to be concerned about the extent to which the efforts they expend on project related work will be recognized. This problem may be compounded if they feel their project related work will not be acknowledged and recognized within their own department. Staff may feel that their personal rewards may be jeopardized by undertaking project related work. They may feel that however hard they work on the project it will not effect their chances of advancement or promotion within their department. Staff may be concerned that the project itself may not be an outstanding success and that any perceived failure on its part will reflect badly on the individual staff involved with it. Staff involved with projects may have long term worries about what happens to them at the end of the project. Perhaps their department will learn to cope without them; or even worse it may have developed new procedures whilst they were otherwise occupied. Projects are all about utilizing existing resources and expertise in an efficient and effective way to get things done. The downside of this, from a staff perspective, may be that projects are not seen as training oriented environments in which to develop personal skills. This concern is primarily an issue with staff seconded to projects on a full time basis. They may feel increasingly isolated and left behind in relation to their long time colleagues and the departmental practices with which they are familiar. Many of these issues may be complicated further if staff are working on more than one project at a time. Personnel assigned to a project should be totally clear about the management structures, which affect them on a day-to-day basis.
www.getahead.uk.com
Management Structure
Every project requires authorization and funding and the body responsible for this is usually called the project sponsor. In the context of critical projects in large organizations, this body is often the board of directors. It is essential that a project is effectively 'owned' either by an individual or a body, that is the project manager. This entity is appointed by the project sponsor to authorize the necessary work and to have responsibility and accountability for the success of the project. In small projects the project owner and the project manager may be one and the same individual. The project managers should be appointed, by the project owner, to assume day-to-day management of the project. There can be two levels of project manager depending on the size of the project - the overall project manager and one or more sub-project managers. The project teams are made up of a mixture of representatives from the marketing or user departments and technical experts who are involved in the production of the overall deliverable or end product. In organizations that are heavily project oriented, a project office may be set up, to serve as a central body of excellence - providing resources to the various projects that are initiated. Its main functions are to maintain the continuity of project development activities. The types of management organization that are appropriate to projects of different sizes, and how the theoretical organizational structure of each individual project should be tempered by real world requirements.
Management Structure - Style

The management organization required will vary depending on the size and complexity of each particular project. On large projects a comprehensive framework may be required, whilst on smaller projects it may be desirable to combine roles within one individual. The questions raised by the problem of establishing a sound project management structure revolve around the creation of effective reporting lines. There are two organizational extremes that can be adopted: In the first scenario, all of the personnel working on the project remain in their normal situation, reporting to their line managers. In this case, the project management will need to coordinate the required project work through the line managers. Alternatively, all personnel working on the project are drawn into a project team and report exclusively to the project manager. In practice a combination of these approaches is often found to be the best solution, and is by far the most common approach. However, this organizational framework risks breaking one of the tenets of good management - that of matching responsibility with authority. The project manager will be responsible for performance on the project but may lack sufficient authority where contributors report to their own line managers. This is one of many hurdles that the creation of a good project management environment must overcome.
Management Structure - Representation

It is advisable that every project involves representatives from three separate interested parties to deliver an endproduct that genuinely satisfies the requirements. These interests being the technical, the marketing or user, and the business perspectives. If the technical interest is ignored then a project may be attempting to produce an end-product that is not technically feasible. It is essential that the technical implications of a proposed project are fully understood. The project should have input from either the marketing or user departments - depending upon whether the project deliverables are intended for the marketplace or for use within the organization. If the business interest is ignored then, although the end-product may well satisfy the marketplace or users and be technically feasible, it may provide little or no commercial benefit to the organization.
www.getahead.uk.com
Project Team Fundamentals

Team working has been an important organizational issue for many years. However, the concept has historically described work within permanent functional teams such as sales, production and design. The rapid growth of project-based work has given rise to the creation of multi-disciplinary teams capable of rapidly accomplishing tasks which span the traditional internal boundaries present in many organizations. Successful team working requires careful consideration and design. Generally, the more that an organization has tended towards a traditional hierarchical structure, the greater will be the challenge of implementing effective inter-departmental project teams. Project teams can take on a variety of forms depending on the size of the project and the way in which it is staffed. Project environments range from dedicated and full-time project teams, through to instances where projects have little or no full time resources and operate by using only the resources from existing functional departments. Organizations that are project oriented tend to maintain a full-time dedicated project resource, which is generically termed a project office. Project office staff will tend to specialize in areas such as: planning and the monitoring of time, cost and performance against the plans. These staff will usually report to a single boss, who may be either a project manager or a project office manager Departmental staff will be recruited on the basis of the skills and expertise that they can bring to the project. However, the appropriate technical or business skills need to be complemented by an ability and willingness to function effectively in the project environment. They will report to the project manager but remain under the overall control of their own departmental, or line manager - they are therefore working in a matrix management environment. The appointment of departmental staff to projects should be a decision made jointly by the relevant project and departmental, or line, managers. The involvement of line managers in the appointments is important as they have the necessary experience to highlight critical areas of the project from a technical viewpoint. Furthermore, by involving line managers in the early stages of project planning they are more likely to develop a positive attitude to the project. Disagreements may result in the negotiations between the project and the line manager on both the level of staffing required by the project and possibly over the individuals to be assigned. However, only in situations where an impasse has been reached should senior management be asked to arbitrate.
Concerns of New Team Members

Anxiety among members of a new project team is almost inevitable. Personnel will be working with unfamiliar faces often in an environment that is still taking shape. This anxiety is typically focused on four key issues. If the project manager, or their assistants are unfamiliar to the team members then the team members will naturally be concerned about the managers leadership style and how it will effect their everyday work. If involvement with the project involves relocation, either within a building or further afield, then management should bear in mind that this often causes heightened anxiety and stress amongst project team members. Team members may be concerned about the nature of the project and whether or not it will match their own level of expertise and professional interests. Furthermore they might have private worries about the technical viability of the project and how its failure may reflect on them. The fair distribution of the workload may be an area of concern, as may the perceived level of proficiency and dedication of some of their new colleagues. One of the great challenges of project management is to bring together an effective team and bring it up to speed quickly. Anxiety among team members is natural and this needs to be addressed as early as possible so that project staff can focus on the needs of the project rather than on their own anxieties.
www.getahead.uk.com
Motivating Team Members

It is important for the project manager to arrange a one-to-one discussion with each team member in order to welcome them to the team and establish personal contact. Depending on the size of the project, this meeting could involve either the project manager themselves or the relevant sub-project manager. This initial discussion should be both short and informal with the aim of reducing anxiety and fostering a feeling of 'ownership' of the project by the team member. A useful strategy for nurturing project 'ownership' is to involve all team members in the planning and scheduling of the activities that they will be involved in. In smaller teams it may be realistic to involve all members in the planning process whilst in larger teams it may be necessary to restrict the involvement to team or section leaders. Developing a climate of open and frank communication will lead to an increased sharing of ideas between team members. They are then more likely to collectively develop more effective decision making and project control processes. Departmental staff may be motivated to join projects by a variety of factors. It is far better to encourage participation than to have to cajole or push staff into project work; as a positive attitude to the project will deliver numerous benefits in terms of staff motivation and performance. Projects have the potential to be seen as dynamic working environments, providing an opportunity to work with personnel from other areas of the organization and enabling staff to 'spread their wings' and experience a greater range of working practices. Often the people appointed to the role of project manager are held in high regard within the organization and may be viewed as rising stars. This can be a positive influence when recruiting personnel for the project - as people can be keen to be associated with talented managerial staff. Whilst projects are not generally regarded as being the best environments in which to gain training there are circumstances where projects necessitate the training of personnel to carry out their intended role. This can be used as a positive motivator - as staff are often enthusiastic to develop their skills, especially if the training relates to an area perceived to be in future demand.
Is Theory Y Management
For projects to function effectively the project manager must devote time and energy to creating an atmosphere that is conducive to teamwork. For managers familiar with leadership theory, autocratic leadership - as depicted by the theory X style is unlikely to prove a successful approach for project management. Project environments are likely to be significantly more successful under a democratic and consultative style, tending towards the theory Y approach. This style is more consistent with the fundamental principles of project management, where the key to success relies on effective lines of communication and the creation of a flexible and proactive working environment. Building the project team is one of the prime responsibilities of the project manager. It requires the skills of a well rounded manager to identify, commit and integrate the various skills required from the traditional functional organization into an effective project environment. All project teams rely for their success on the team members. A good team member will be reliable in meeting deadlines and honest when facing problems. They should also be able to follow leadership and direction and yet be sufficiently confident to make an active contribution and to take responsibility upon themselves.
www.getahead.uk.com
10
Project Life Cycles
Projects are temporary structures set up with the specific aim of delivering an identifiable end-product. All projects will therefore have an identifiable life cycle, the characteristics of which will vary according to the size and complexity of the project. A typical life cycle will run from the formal initiation of a project through to a post implementation review of the delivered end-product. This post implementation review is not shown as it is usually held some months after the project has been formally closed. There is often little agreement between industries, or even between organizations within the same industry, about the life cycle phases of a project. This is understandable because of the complicated nature and diversity of projects. A five-phase project life cycle model is illustrated on this screen. This model can be applied to a variety of project scenarios although the cost and duration of each phase will vary according to the particular project. The conceptual phase includes the preliminary evaluation of an idea. It is common for this phase to include a first cut feasibility study for the proposed project. This analysis should also include a preliminary risk assessment. The definition phase is primarily a refinement of those areas considered in the conceptual phase. The resources required by the project should be defined along with time, cost and performance estimates. Project estimation is a notoriously difficult task - especially in this early phase. However it is essential that costs are quantified, as this information is needed to establish whether or not the project should proceed. Once a project has received the funding and backing of senior management it can proceed to the production phase. This incorporates the production, or acquisition, of the end-product specified. This begins with the updating of detailed plans, started in the preceding phases and encompasses the identification and management of the resources required. This phase also includes the development of manuals, plans and other documentation that will support the end product in its live environment. The operation phase involves the integration of the end-product or service into the organizational environment. If the end-product was a marketable product then this phase would typically include the product life cycle phases of marketing and refinement. The divestment phase involves the reallocation of resources that are no longer required by the current project. The end-product of any project will have a finite lifespan and therefore its ability to generate revenue will be limited. The organization will usually need to run future projects to guarantee its revenue stream. It is therefore important to retain the services of staff and other resources that can be used in forthcoming projects. This phase also incorporates the post implementation evaluation of the delivered end-product, and this should serve as input to the conceptual phase of future projects. The use of resources over time will vary according to each particular project. Whilst it may be possible to characterize life cycle profiles within different industry sectors, this can give a false impression as individual projects can vary radically from the generic profile.
www.getahead.uk.com
11
The Gantt Chart

Gantt Charts - named after their founder Henry Gantt, are the preferred information media of senior managers, who usually find that the information portrayed in PERT charts is overly detailed. Gantt charts are simple to understand and easy to change, however they only provide a vague description of how the whole project is reacting as a system.
The PERT chart is an excellent start point for the production of a bar chart or Gantt chart, which is required in order to clearly show the start and finish dates for the major activities. PERT is an acronym for Program Evaluation Review Technique and is one of the most widely used graphical representations for project planning and control purposes. Modern software planning packages are able to present the project data in a wide variety of formats including numerical sequence, alphabetical and date order. In the example shown, the network information has been sorted and presented in date order using the early start values. When producing Gantt charts care should be taken that each distinct area is clearly definable - by applying an appropriate color or shading regime. The challenge to project management is to accurately identify and quantify the activities, or tasks, that are necessary in order to deliver the end-product on time and within budget. Various planning charts are used in practice, depending on the size and complexity of the project. Whilst the PERT chart is one of the most useful aids to effective project management, senior managers will not usually want to see this level of detail. When project management staff need to communicate information to senior management, Gantt charts, histograms and other graphical techniques are the preferred presentation format. Any plan, schedule or specification that will be circulated should be represented in a clear and unambiguous format. The notation used should be clear to both an in-house and an external audience. In order to do this, the three vital planning and control parameters - time, cost and performance should be summarized at an appropriate level of detail.
The Gantt Charts Limitations

The Gantt chart has three important limitations: Firstly, the sequencing and inter-relationships between the activities are not shown. Therefore, they do not represent a network of the activities. If one activity is accelerated or delayed it will be difficult to see the effect that this may have on associated activities. Secondly, the Gantt chart cannot show the results of either an early or a late start in the activities. It does not reflect true project status because elements behind schedule do not mean that the project is behind schedule. Finally the Gantt chart does not show the uncertainty involved in performing the activity, therefore questions concerning the minimum or maximum duration of the activity are not represented. Click the button to see a refinement of the Gantt chart, which overcomes some of these limitations. The logical bar-chart shows the logical relationships between the activities. Whilst this technique is useful, be aware that on larger projects the volume of activities may result in a cluttered presentation. Many variations of Gantt chart can be used to represent a broad spectrum of project information and in spite of its limitations the Gantt chart remains the most common presentation format for senior management.
www.getahead.uk.com
12
Resource Planning
Resource planning addresses the effective scheduling of the skills and resources necessary in order to deliver the products required by the project. Resource aggregation, leveling and smoothing refer to techniques that together should ensure that the project makes optimum use of the resources available. In project management terms all of the staffing requirements, money and physical objects that the project will consume or require are termed resources. Resource planning aims to ensure that the project is run efficiently, by keeping all of the dedicated project resources as fully utilized as possible. It also aims to facilitate the accurate prediction of the demands that will be placed on the project and enables the accurate identification of important issues such as potential bottlenecks. Resource planning is concerned with the effective scheduling of skills, experience, financial and technical resources necessary in order to deliver the products required. It is crucial technique to the success of the project and the work involved grows rapidly in complexity as the number of individuals and the required skills increase. Resource planning should be an iterative process, helping to refine the PERT chart by optimizing the use of resources throughout the project life cycle. The overall planning process involves a number of iterative steps beginning with the identification of the products that are required to deliver the overall end-product. This should be followed by identification of the resources needed and the sequencing of the activities required. The PERT chart should then be updated to reflect the resources and activities as they are identified. This is followed by assigning the activities and responsibilities to suitably qualified staff. With the shape and size of the project now visible, the total cost of staff and other resources for each planning period can now be calculated. Costs should be itemized by resource type, identifying the number of staff at each skill, or cost, level. Up to this point the planning process would normally have assumed one-hundred percent availability of staff to work on project related tasks. Thus a full-time person is scheduled for five full days each week - whilst in reality, they may not be available on this basis. Furthermore, this type of planning takes no account of non-productive time due to things such as unscheduled meetings, unrelated work tasks, coffee breaks etcetera. In practice, planners should also make allowances for holidays and contingency for sickness leave.
Resource Definitions & Allocation

Resources can be broadly divided into consumables and non-consumables. A consumable resource is consumed as it goes into a task, for example, when money is spent on paying contractors it cannot be used again. Nonconsumable resources can be used over and over again - manpower and equipment used on a project are obvious examples of non-consumable resources. It is often helpful to consider resource definitions, in order to define the capabilities, cost and productivity of different worker groups. This classification is normally conducted with reference to the skill profiles of staff. It is important to define the effort that each group can produce per unit of time in order to accurately match the task needs with the allocated resources. The various resource definitions may be supported by estimates of the quantity of each resource that will be available throughout the projects life cycle. This information is called a resource availability profile and these are often shown as graphs of the level of availability against time. With reference to the tasks, or activities, identified in the plans; the next job is to allocate resources to these tasks. At this stage each task should be dealt with in isolation - it would be premature to attempt to optimize the overall efficiency of matching tasks to the resources allocated. The allocation of resources to tasks should be carried out on a 'best estimate' of how to address the workload requirements. Three techniques can then be applied to ensure the practical and efficient use of resources.
www.getahead.uk.com
13
Resource Aggregation, Leveling & Smoothing

Resource aggregation involves compiling a day-by-day total of demand for each type of resource and representing this information in a histogram. The comparison of the daily demand for each resource type against the resource availability profile should highlight any problem areas, for example, a shortfall in the availability of a particular resource type at any point in time. Following resource aggregation, resource leveling should be carried out to ensure that the project never demands more resources than have been specified as being available. This typically involves the delaying of certain tasks in expectation of the release of resources being used. Resource leveling aims to keep all resource demands within the resource availability profiles. However if this has implications - such as the extension of the end-date of the project then these profiles may require adjustment, for example, by the securing of further resources of a given type. Resource smoothing is intended to smooth out the demand for each resource. The effect is to reduce the size of the peaks and troughs on the resource histograms - or as a more practical interpretation to improve the efficiency of resource utilization. Resource smoothing can be facilitated by a variety of different techniques. Adjusting the timing of activities within their float, by the moving of allocated resources between activities and by more radical approaches - such as the hiring in of contract staff and the pre-construction of certain products. Both the float and the critical path will need continual attention as the resource leveling and smoothing process proceeds.
Monitoring the Critical Path

A final point worth noting in the area of resource planning, especially in relation to resource smoothing concerns the critical path. Some planners tend to see the critical path as a sacred sequence of activities that should be left untouched whilst other activities are 'smoothed'. An alternative point of view is that the critical path results from a series of activities which have suffered from a lack of resources being allocated to them and therefore should be seen as the first line of attack. The correct interpretation will vary, depending on the characteristics of each project.
Converting Resources into Costs

When the resources have been optimally scheduled this information needs to be converted into costs. All nonhuman elements are included at this point, for example machine time, equipment purchase, equipment hire and consumables. The resulting table provides totals that should be compared to the figures in the overall project plan. If the constraints, or tolerances, of the plan have been exceeded then re-planning or reference to the project owner may be necessary. In long-term projects adjustment may even be made for economic indicators - such as the anticipated rate of inflation.
www.getahead.uk.com
14
Configuration Management - Introduction Configuration management is a method for administering an evolving, and often interrelated, set of products and project documentation. All of the products and documents that need administrative control are termed configuration items. The configuration item description record should contain the information needed to identify and track each configuration item throughout its development life cycle.
The application of effective procedures should ensure the accurate and up-to-date documentation and distribution of all relevant product components and project information. Configuration Management should be applied to projects of any significant size, and should be the day-to-day responsibility of a single individual. The configuration management plan should be produced as part of the project initiation document for the project in question. Where products constitute sub-assemblies of more complex products, the approach used must be able to track all such relationships, enabling the accurate analysis of all associated information. All of the products and documents that require the administrative controls of the configuration management method being used, are called configuration items. Initially the overall end-product can theoretically, be viewed as the only identifiable configuration item. However, an increasing number of configuration items will usually be identified as the end product is sub-divided into the manageable elements represented in the work breakdown structure. A configuration item description record should be used to record the information needed to identify and track each configuration item through its development life cycle.
Configuration Control
Configuration control is concerned with the procedures for the issue and submission of configuration items. These procedures should address both physical and electronically stored configuration items. Configuration audits consist of cross checking the configuration item description records with the current version of the configuration item as held in its development folder. In the first instance, a configuration item should be created and documented as the first version. The configuration item may then undergo a number of modifications as it is tested and errors corrected, or as changes are requested and these subsequent submissions should be reflected by an increasing version number. The first baseline for a configuration item will be established when the specification of the item has been prepared, reviewed and agreed. Subsequent baselines will normally be established at points at which the Configuration item is ready to be used as a basis for further work in which a major transformation of it will take place. A Release consists of a specified set of products from one or more base-lined configuration items, which are issued as a set for a specific purpose. Releases should be authorized by the project or sub-project manager.
www.getahead.uk.com
15
Configuration Management Plan

The configuration management plan should be produced as part of the project initiation document, for approval by the project owner at project initiation. Where appropriate configuration management should continue throughout the life of the delivered end-product, and therefore the approach adopted should be transferable to the client organizations operational and maintenance sections at the end of the project. If other projects within the organization are using a configuration management method then this should be seriously considered for the current project, particularly if the two projects share any areas of interest. The following typifies recommended minimum scope required of a configuration management method. However, this should be adjusted to suit the needs of each particular project. Synopsis & Purpose This should provide a brief overview of the plan and highlight any differences in approach to existing site standards - with a justification thereof. It should also explain the aim of the activities defined in the plan. Any dependencies on configuration management plans from other projects should be identified. References This serves to identify all other standards to be used by the configuration management method. Configuration Item Identification This section should specify the naming and numbering conventions to be used for all types of configuration items. Scope This should outline the full range of tasks in the plan, in particular it should consider all areas that have links with associated projects or that may be bringing in prefabricated components. Any special operating requirements should also be considered. It should also define which items are to be managed under the plan and which are outside the plans control. Definitions and Abbreviations This is a short glossary that should be produced to support the plan, if necessary. Responsibilities The clearest representation is a responsibility matrix, showing which role should carry out each activity in the plan. The role of configuration administrator will feature often. Filing This section defines in detail the filing structure to be used for each category of configuration item. This should cover hardware, software, documentation, human and machine readable items. Document Issue Procedures This should define the procedures to be used for issuing and distributing copies of all managed documents. Security This should define the access security measures for the master copies of all configuration items.
www.getahead.uk.com
16
The Configuration Administrator

When any member of the project team creates any new item of project documentation that requires distribution to a variety of other project staff, they should submit it to the configuration administrator, or whoever is designated as being responsible for administering the configuration management procedures, in order that they can decide whether or not it constitutes a configuration item. If the configuration administrator decides that the article does require the formal procedures of the configuration management method they should give it the status of configuration item. The configuration administrator may decide that the article does not require all the rigors of configuration management and therefore not create a corresponding configuration item. In this case the article should be distributed and administered outside of the configuration management system. As configuration items are identified, each should have a configuration item description record created for it which should then be forwarded to the configuration administrator for filing. The configuration item description record should contain all of the information needed to identify and track the item through its life cycle.
Issue & Submission Procedures

Issue and submission procedures are concerned with the submission of and access to the identified configuration items. These procedures will relate to administrative items as well as those pertaining to the evolving products. Without careful control over the issue and submission of configuration items the configuration management process can collapse. Due to the increasing use of computer networks to support project work, control can be significantly more difficult than for products and hardcopy documents. The use of password protected files and directories should help, but the recall of obsolete versions can cause problems. Only when the author of a new or revised product or document is satisfied that it is complete or ready for review should it be re-submitted to the configuration administrator. The submission procedure should not be used to introduce new configuration items. In relation to quality reviews, the administrator should be responsible for issuing a copy to each reviewer, in line with the issue procedures, and filing the original in the relevant development folder. The configuration administrator should never issue the master copies of baselined configuration items. It is important that current official copies are readily identifiable, to avoid any obsolete documentation being used as the basis of future work. The administrator should maintain an issue log for each configuration item, which records: the identity and version of documents issued, the name of the recipient, the authority for and purpose of the issue and the date of issue. When a document is the subject of an approved change request, the administrator should issue a copy to the appropriate person to carry out the work and notify all other copy holders of the impending change. On completion it should be passed back to the administrator, who should only then make it available for further changes. Ideally when a new version of a configuration item is issued, earlier and now obsolete, copies should be recalled and destroyed.
Configuration Audits
Configuration audits consists of cross checking the configuration item description records with the current version of the configuration item as held in its development folder. These audits are normally carried out ahead of each project review, although they can be requested at any time by the project manager or the project owner. Configuration audits should establish that : the current physical representation of each configuration item matches its current specification, that there is consistency in design between each configuration item and its parent, if there is a parent. Finally it also establishes that the documentation is up to date and all relevant standards are being adhered to. The configuration administrator should be responsible for producing all scheduled and ad hoc reports on the status of the configuration items at any given point in time. Typical reports that may be required include numbers of change requests and project exception reports opened during a specific period, closed during a specific period, those currently open and unresolved document update requests. Full details of this course are available at: www.getahead-direct.com or www.getahead.uk.com
17
Project Change Control

No matter how carefully planned a project has been, changes will need to be made as it progresses. These will result from both external influences as well as problems that arise within the project environment. This section introduces a formal mechanism for the identification and analysis of any potential problems, and a proven method for controlling change; from problem identification, to analysis and the taking of appropriate corrective action. The four main sources of project change are . . . Business changes, which may result from: changes in legislation, changes in government policy or changes in business strategy. Marketing or user changes, which may result from changes in the requirements of the customer, who may be either part of, or outside of, the organization. It is also possible that feedback gained during the review or testing of a product may show that it is inappropriate in some unforeseen way. Technical changes may be required as emerging technology may offer a better solution to that originally planned. Alternatively, technical problems may prevent a product from working in the way that it was supposed to. High level business decisions may change the basic terms of reference of the project - for example there may be a change to the overall scope of the project. All of these potential changes need a process to control them and their effect on the project. This process, called change control, should ensure that proposed changes are interpreted in terms of their potential effect on project timescales, costs, benefits, quality and personnel. Where there is a proposed alteration to the projects products, change control should: Analyze the change and assess its impact. Then prioritize and plan the necessary work, and finally control its implementation. It is important that no action is taken without the authority of the appropriate level of management.
Identifying Project Change

Any person associated with a project should be able to raise any concern they have at any time. The concern may involve a perceived problem or a suggestion for an improvement to some area of the work, documentation or project organization. This will require a standard form generically called the project exception report. All project exception reports should be reviewed at regular meetings. The meeting should recommend one of the following outcomes shown for each project exception report. A document update request (DUR) will be the preferred option where a product is found not to conform to its product description but where changing the product description is considered preferable to re-working the product in line with its original description. A change request (CR) will be the preferred option where there is a requirement to change the design or featuresof a product that currently agrees with its specification or product description. Rejecting a project exception report indicates that, after consideration, it is not felt to represent a significant concern.
www.getahead.uk.com
18
Change Control Mechanism
The change control mechanism shown represents one suggested approach. However, different project environments may wish to tailor it to suit their own particular requirements. A project exception report is raised by anyone as a result of a perceived problem or opportunity. These should be assessed at regular meetings, staged for that purpose. The reviewers, who should include all project co-ordinators, may decide that they require more information before a decision can be taken. If a change request or document update request is raised, then an impact analysis should be performed. This process looks at the knock-on effects of the change on other products, and also the effect if the changes are not implemented. The analysis will ideally be carried out from the business, marketing or user and technical viewpoints - as appropriate. The purpose of the impact analysis is to arrive at a balanced view of the effect of the proposed change on the projects ability to satisfy its mandate. This will enable project management to decide whether to proceed with the change or not. The appropriate project manager should use the impact analysis to assess the change in terms of its effect on timescales, cost, benefit, quality, personnel and risk and to decide at what level the decision to proceed should be taken. The appropriate project manager should then determine whether or not the proposed change will exceed the permissible tolerance. There are 3 possibilities: Firstly, that the impact of the change does not exceed the sub-project tolerance. In this case the decision rests with appropriate sub-project manager. Secondly, that the impact of the change falls outside sub-project tolerance but within project tolerance. In this case the decision rests with the overall project manager, who may wish to consult the project owner. Finally, the impact of the change may exceed the project tolerance - in which case the decision is the responsibility of the project sponsor.
www.getahead.uk.com
19
Change Control Forms

Here we explain the idea of using standard change control forms to raise and classify all project concerns. We also explain how to and process and analyze each of these forms - from origination to final classification.
The change control process begins with a project exception report being raised by a member of the project team. This signifies that someone has voiced a serious concern about some aspect of the project. It may be concerned with a perceived problem or a suggestion for an improvement to an area of the work, documentation or project organization. The project exception report should be recorded in an appropriate log, allocated a unique identifier and distributed to all relevant members of the project team. Designated members of the project team should investigate the cause of the project exception report in order that appropriate action can be recommended at the next meeting. All unresolved project exception reports are reviewed at regular meetings, called and chaired by the project manager and attended by all of the relevant team members. Following the meeting the project exception reports together with the recommended actions are forwarded to the project manager, whose responsibility it is to determine the status of each project exception report.
www.getahead.uk.com
20
Document Update Request

Once it has been assessed a project exception report may be classified as a document update request. This is a standard form that is used to update a product design to reflect how it is in its current implementation, rather than how it was in its original design. Even though the document update request indicates a change (update) to the documentation rather than a change to a product or procedure it may still warrant an impact analysis - in order to record the ramifications of the identified deviation on the project as a whole. A document update request can only be raised on the authority of the Project Manager. It should refer to the project exception report that originated it and should contain sufficient detail to enable the fault it is concerned with to be recreated. The document update request should then be passed to an appropriate person to analyze it. A technical member of the team, with assistance from others as required, should perform a technical analysis on the document update request and establish the resources required for its implementation. They should also assign the document update request with a priority rating - either high, medium or low. The technical team member should also conduct an impact analysis to ensure no implications of the proposed change have been overlooked. A copy of the document update request should then be returned to the project manager for further action. The project manager should decide whether or not they need to refer it to the project owner for consideration, or whether they themselves can determine its status. When the status of a document update request is changed from 'outstanding' - which is its original status, it should be returned to the configuration management system. The appropriate project manager is responsible for scheduling all of the work for approved document update requests. This work must take into account all of the changes to all of the configuration items that require change. This work should be monitored and if planned resources and/or deadlines may be violated then this should be brought to the attention of the overall project manager. On receiving a completed document update request the person responsible for the configuration management system should ensure that all of the products that should have been changed are returned and document this.
www.getahead.uk.com
21
Change Request
Once it has been assessed a project exception report may be classified as a change request. This is a standard form that is used to change a product design - to reflect a significant amendment to the original design. It records a proposed modification to the products to be developed, or a change in the management or technical approach adopted. A change request can only be raised on the authority of the project manager. The document should refer to project exception report which originated it and should contain sufficient detail to enable the fault it is concerned with to be recreated. The change request should then be passed to an appropriate person to analyze it. A technical member of the team, with assistance from others as required, should perform a technical analysis on the change request and establish the resources required for its implementation. They should also assign the change request a priority rating - either high, medium or low. The technical team member should also conduct an impact analysis to ensure no implications of the proposed change have been overlooked. A copy of the change request should then be returned to the project manager for further action. The project manager should decide whether or not they need to refer it to the project owner for consideration, or whether they themselves can determine its status. The appropriate project manager is responsible for scheduling all of the work for approved change requests. This work must take into account all of the changes to all of the configuration items that require change. This work should be monitored and if planned resources and/or deadlines may be violated then this should be brought to the attention of the overall project manager. On receiving a completed change request the person responsible for the configuration management system should ensure that all of the products that should have been changed are returned and document this. Also for any 'outstanding' or 'held-over' change requests they should ensure the return of any configuration items that were released for this, postponed, work.
Remember, the Document Update Request is a standard form that is used to update a product design to reflect how it is in its current implementation, rather than how it was in its original design. The Change Request is a standard form that is used to change a product design - to reflect a significant amendment to the original design.
www.getahead.uk.com
22
Project Planning Introduction

This website introduces a standard series of diagrams and documents that are essential for effective project planning, and a detailed but flexible planning architecture that can be adapted to the needs of projects of any size. Successful project management differs from general management in one key respect; it places a continual emphasis on planning. This is important as projects are often following an uncertain path that has not been previously followed or charted. Project management staff must think ahead and be capable of making decisions, often on the basis of what appears to be insufficient information. Organizations that run work as projects are increasingly adopting formal methods that will deliver consistency in the way in which projects are planned and run. These are usually specified in terms of project life cycle models and project management procedures that should be followed. Without such methods and procedures projects are often no more than a project in name. With little or no managerial or supervisory resource allocated to ensuring their successful outcome - these notional projects frequently under-perform or fail completely. Whilst offering many potential benefits such methodologies are often associated with high administrative and procedural overheads. The individual project managers ability to interpret and adapt the organizational approach will vary depending upon the organizational culture and the level of detail and degree of rigidity with which the organization aims to apply its project management 'methodology'. The development of a method that best suits the needs of an organization may take a while to perfect. This is, in fact, desirable as it permits a significant amount of in-house experience to be fed back into the fine-tuning of the method. The product based approach forwarded in this course places the emphasis on the identification, specification and development of the products required to ensure the overall success of the project.
www.getahead.uk.com
23
Standard Planning Diagrams

A standard series of diagrams and documents can be used to assist in the process of product based planning. These can act as a powerful aid to analyzing, scheduling and communicating different aspects of the overall project plans. The work breakdown structure is a product-oriented subdivision of all of the resources, including hardware, services and data that are required in order to deliver the required end-product. Each product can be described in detail in a product description. These are used to hold a variety of different data relating to either specific products or groups of related products. Product flow diagrams show the dependencies and derivation of inter-related products and the sequence in which they are to be produced, highlighting the production dependencies that exist between the required products. The PERT chart (Program Evaluation and Review Technique) details the activities needed, their start and finish dates and the time necessary for their completion. These diagrams are also referred to as activity networks. Care should be taken to ensure that all testing and quality review activities are included in the PERT chart. The final deliverable of the planning process is a set of agreed plans, which represent a formal undertaking to meet identified targets in terms of products, timescales, costs and quality. Senior managers will not usually want to see the same level of detail that is depicted in the plans and a variety of project graphics are available to represent the three vital planning and control parameters - namely: time, cost and performance.
The PERT chart is an excellent start point for the production of a bar chart or Gantt chart - that clearly shows the start and finish dates for the major activities. Gantt charts are simple to understand and easy to change, however they only provide a vague description of how the whole project is reacting as a system. Project management staff will need to establish the projects resource requirements, for any given period - possibly including the resources needed on a daily basis. The type of diagram that facilitates this is called a histogram and is another widely used project planning aid. The pie chart is another useful method of presenting summarized project information. The major drawback with pie chart presentations is that they do not permit comparisons as readily as linear methods of presentation - such as bar-charts.
www.getahead.uk.com
24
Project Plans
At the start of a project it is important that overall estimates of cost and duration are produced, to justify the underlying business case. For most projects four levels of plan should be sufficient to address the needs of the different levels of management involved. In order to be effective, every plan should be formally documented in a clear and recognizable format. The project plan should provide an overview picture of the project, enabling the project owner and the project manager to assess the viability of the project. It should also highlight any sub-projects, and the major activities and resources required by them. The sub-project plan is designed to provide a detailed view of each sub-project, enabling the sub-project manager to apply control on a day-to-day basis. The sub-project plans highlight the products, activities and resource requirements at a more detailed level than the project plan. Detailed plans are designed to provide greater detail about a specific activity than that shown in the sub-project plan, from which it is normally derived. The individual work plan is optional, and is used to define the tasks and responsibilities of a specific team member. It normally covers only a short period, e.g. production of a single product or a series of activities spanning one or two weeks. Project tolerances define performance limits within which different areas of the project can retain autonomy. It quantifies the deviation from the activity and budget schedule detailed in a formal plan, which is permitted before reference should be made to a higher authority. The resources and timescales detailed in a plan are considered to be desirable; but whilst operating within tolerance limits a project or sub-project is still considered to be 'in control'.
www.getahead.uk.com
25
Product Based Planning

Planning is the process of estimating, scheduling and assigning the projects resources in order to deliver an endproduct of suitable quality. Planning should focus on the activities necessary to deliver the intermediate products required in order to deliver the overall goal of the project (the end-product). The planning process involves a number of iterative steps: By analyzing the derivation and composition of each product the activities required to construct it should be determined. Having identified the activities required to construct a product, or products, the nature and magnitude of the required tasks should be determined. Once the tasks have been identified the resources required for their completion can be established. The activities should then be arranged in a sequence that optimizes efficient product delivery. In particular this sequence should take into account any interdependencies between the evolving products. When the required activities have been identified and sequenced they should be allocated to suitably qualified members of the project team. Here the cooperation of line managers will often be essential in order to secure the appropriate skills at the right time. Having determined the activities and available resources required to deliver the products, the timescales should be defined for discrete areas of the project. As the assimilated information grows, the planning documents should evolve. These will include the work breakdown structure, the PERT charts and ultimately the fully developed plans.
Product Based Planning - Illustrated

Every project should have an overall deliverable, or end-product. However, in order to deliver the end-product a series of intermediate products will usually be necessary. These products may be components of the overall endproduct, or they may be supporting products, for example, a maintenance manual. To illustrate the concepts behind product based planning we will consider a project being run by a small company to design, assemble and market a new camera. Three main product groups are used to represent this project at a high level representing the requirement for a design specification, production plans & schedules and a marketing campaign. The design products required are likely to include such items as: engineering drawings, component lists and any relevant production standards. The production products required are likely to include such items as component supplier lists, assembly instructions, and quality checklists. Finally, the marketing products required are likely to include such items as a promotional brochure, advertising scripts, sales information packs and so on. There will be three strands to the marketing campaign: a television advert, a magazine advert and a promotional brochure - which can be sent to enquirers and also used at the point of sale. In project terms each becomes an identifiable product - that will need to be analyzed, specified and designed. We will now consider the specification of the promotional brochure. As explained earlier products are often made up of component products. In producing the brochure a variety of components will be needed and each one may be produced by an individual or a team. The clear identification of each component product should facilitate an accurate estimate of the resources required in the production of the brochure. The identification of the required products requires a careful analysis and breakdown of the structure and composition of the overall deliverable - in this case the brochure. However, this process does not require any great specialist training or technical skill. Product identification is really about careful analysis.
www.getahead.uk.com
26
Planning Diagrams Overview

A standard series of diagrams and documents can be used to assist in the process of product based planning. These can act as a powerful aid to: analyzing, scheduling and communicating different aspects of the overall project plans. Work breakdown structures, product descriptions, and product flow diagrams provide an invaluable means of representing and monitoring the products and resources required by the project. The work breakdown structure is a product-oriented subdivision of all of the resources, including hardware, services and data that are required to deliver the required end-product. The projects end-product appears at the top of the work breakdown structure, with the products that are required represented hierarchically beneath it. The work breakdown structure can be split into a series of diagrams, representing discrete sub-divisions; such as product groupings or all of the products relating to specific subprojects. Product descriptions, each product can be described in detail in a product description. These are used to hold a variety of different data relating to either specific products or groups of related products. Product descriptions should be designed to reflect the details that are required; generally they contain information such as; The purpose of the product, the derivation of the product and its composition, standards for format and presentation and the products quality criteria. Product flow diagrams show the dependencies and derivation of inter-related products and the sequence in which they are to be produced. These diagrams highlight the production dependencies that exist between the required products and are useful in forming the basis of scheduling the work required. The PERT chart, or activity network, details the activities needed, their start and finish dates and the time necessary for their completion. It is developed from the product flow diagram by examining the tasks, and their inter-dependencies, that are required to produce the products. The resources required to complete each product should be identified in parallel to the evolution of the complete set of products and the PERT chart should be updated to reflect these. This is normally done by linking the task identifier to those resources required. These will include staff and all other resources - such as computer time, purchase or hire of equipment, materials etcetera. Care should be taken to ensure that all testing and quality review activities are also included.
www.getahead.uk.com
27
Work Breakdown Structure
The creation of the work breakdown structure should be one of the first steps in the planning process, once the requirements specification for the project has been written. The work breakdown structure should reflect the way the work will be performed and the way in which project costs and data will be summarized and reported. The work breakdown structure provides the framework on which costs, time and schedule performance can be compared against the budget - for each level of the work breakdown structure. The work breakdown structure enables the work to be broken down into smaller elements and this should result in the identification of all the major and minor activities required by the project. Many organizations use work breakdown structures in a standardized form, and this screen depicts a five-level indentured structure - which is a commonly used format for this diagram. The work breakdown structure is a product-oriented subdivision of all of the resources, including hardware, services and data that are required to deliver the required end-product. A project may consist of sub-projects which are in turn made up of tasks, sub-tasks and work packages. Projects are sub-divided in this way for one principal reason - ease of control. Having sub-divided the project, in order to devise a suitably detailed work breakdown structure, the project manager will then need to act as the integrator to ensure the practical and timely delivery of the various work elements required. The work breakdown structure should be designed and developed carefully as it will typically form the basis for a variety of other aspects of the project environment - for example: project costing, the validation of organizational responsibilities, risk analysis, the coordination of objectives and project control. Project managers normally manage at the top three levels of the work breakdown structure and also provide management reports at this level. Some organizations have attempted to standardize management reports by imposing a generic structure to the top three levels of the structure diagram across all projects. This approach may work in cases where an organization runs a large number of very similar projects - but it is not well suited to the majority of organizations - that run a variety of projects that differ fundamentally in some way.
www.getahead.uk.com
28
Work Breakdown Structure Work Packages

The work breakdown structure typically supports different types of managerial actions at different levels. For example the authorization and release of work is generally carried out at level 1, budgets are normally prepared at level 2 and schedules at level 3. Other characteristics that can normally be applied to different levels of the work breakdown structure include: The top three levels reflect project-wide efforts and should not be related to specific departments, whose efforts should be addressed at lower levels. Each element of work should be assigned to only one level of effort. At the lowest levels the work packages should be identifiable and homogeneous. The work breakdown structure should be accompanied by a description of the scope of effort required. It may be advisable for the project manager to liaise with the relevant line managers in determining the details pertaining to the effort that is required - they are often ideally placed to assist in this. The term work package is a generic name for a low-level task or job assignment - it describes a discrete piece of work and facilitates the monitoring and reporting of work in progress. Different industries and organizations have a variety of strangely named documents for authorizing and assigning work. However, whatever it is called, the work package is the critical component that facilitates management of the work breakdown structure. Work packages should be natural subdivisions of effort planned according to the way the work will be carried out, and it is quite common for them to be supervised and performed by the line managers - who will then report to the project manager at a higher level of the work breakdown structure. Work packages should also form natural subdivisions of cost accounts and are therefore usually the basic building blocks used in planning, controlling and measuring performance as the projects progresses. Work packages may be supported by additional documentation, which is generically termed a work package description to ensure that those carrying out, supervising and monitoring the work in progress are clear about exactly what is intended.
Work Breakdown Structure Illustration
This table illustrates a simple work breakdown structure and its associated numbering system. The first number represents the total project, the second represents the first sub-project, the third identifies a task within it, and so on. From this table it is easy to see that the component numbered 01-03-03 represents task 3 of sub-project 3. Because so many other aspects of the project depend on the work breakdown structure care should be taken to create an accurate and workable diagram. One of the most important tasks is to ensure that it contains the right number of levels - the consequences of having too many or too few should be apparent. Full details of this course are available at: www.getahead-direct.com or www.getahead.uk.com
29
A useful tip when generating a work breakdown structure is to consider each major work element in its own right. From a cost control perspective, cost analysis down to the fifth level of the work breakdown structure is often beneficial. However, the effort required to prepare cost analysis data to each lower level may increase exponentially and this monitoring resource should itself be identified and quantified.
Work Breakdown Structure Guidelines

The following guidelines should prove useful when developing the work breakdown structure for a project. Firstly, the work breakdown structure and any support documentation should be easy to understand. Secondly, work should not be subdivided arbitrarily to the lowest possible level. Work breakdown structure elements at the lowest control level should typically range from 0.5% to 2.5% of total project budget. Furthermore, you should be aware that the work breakdown structure can be developed to reflect the trust that you have in specific line groups, by leaving them the autonomy over specific areas of work. Finally, always remember that projects are dynamic working environments - so try to maintain flexibility in the work breakdown structure.
www.getahead.uk.com
30
Product Descriptions
The product description describes the purpose, form and components of a product. Product descriptions help in the production of accurate estimates of the resources needed in order to produce the required product. Product descriptions contain detailed design, content and quality information relating to a specific product, or group of products. The product description form describes the purpose, form and components of a product. They should be created as part of the planning process, to shadow the identification of products. They should also list, or refer to, the quality criteria applicable to that product. Each product description may either apply to a specific item, or to all of the products of a given group, or type. The components of a complex product may be described in separate descriptions, giving rise to a hierarchy of product descriptions. This hierarchy will reflect that represented in the work breakdown structure. At any time the ongoing analysis of products may lead to changes being made to the diagrams or documentation that was produced earlier on. The precise content that is required in a product description will vary from site to site. However, as a general guide they should include the sort of information shown on this sample form.
Product Descriptions - Illustrated

The clear identification of each component product should facilitate an accurate estimate of the work, and other resources, required in its production. The identification of products was illustrated earlier in this course, in the context of producing a new model of camera. The products required for the promotional brochure are shown on this screen. In this example we will isolate one of the minor product groups - the Photographs and illustrate the creation of product descriptions in this area. The product description shown relates to a single product - the photograph of the camera on the car dashboard. The title should contain the formal product name. The product number should be unique and consistent. The version number is used to reflect the current configuration item generation number. The purpose should contain a short descriptive text. The composition should list the content, or the structure and format of the product. A complex product may be described in full, or in terms of its component sub-products. The derivation should indicate any products, or other required input, to the production of the current product. The form holds information relating to the production media or method of the product. Quality criteria should detail the subjective criteria against which the product can be checked to confirm that it meets with the requirements. The quality method should describe the method, for example, formal/informal review, physical measurement etc., by which the quality conformance will be assessed. Staff responsible should list those people, or skills, required for producing, reviewing and approving the product. This is particularly important where an external quality review is planned.
www.getahead.uk.com
31
Product Flow Diagrams
Product flow diagrams reflect the required production sequence of the identified products. A simplified product flow diagram for a systems development project is shown on this screen. It shows the dependencies and derivation of inter-related products and the sequence in which they should be produced. Required inputs to the drawing of the product flow diagram are the initial work breakdown structure and product descriptions. Some of the products to be shown on the product flow diagram may already exist, either within the organization or externally, and these are represented by ellipses on the product flow diagram. Products to be created by the project are shown in rectangular boxes. The derivation of a product is shown by drawing a line to it from each of the products from which it is derived. When drawing the product flow diagram it is quite normal to identify either previously overlooked products or components of newly identified products. Therefore, the development of all of the product specification diagrams and documentation should be viewed as an iterative process. It is normal to start by generating a work breakdown structure and associated product descriptions. The production sequence of the products should then be represented on a product flow diagram. In turn, this diagram should serve as an important source of information when determining the activities required and their logical sequence as depicted on the PERT chart. At any stage the investigation may highlight products, issues, relationships or activities that were previously overlooked and that may well require the updating of earlier diagrams and documentation.
www.getahead.uk.com
32
PERT Charts
PERT charts contain detailed information relating to the activities necessary to produce the required products. PERT is an acronym for Program Evaluation and Review Technique and was developed in the 1960s on nuclear defense projects. Pert charts are also known as Activity Networks. The PERT chart should be developed from the product flow diagram by examining the tasks needed to produce the products required. The resources required to complete each product should be identified and the PERT chart should then be updated to reflect these. An alternative style of diagram to the PERT chart is the arrow diagram and both of these techniques have their advantages. The main difference is that on the arrow diagram the activity information is shown on the relational link, whereas the PERT chart shows activity information within the node, or activity box. The use of either technique should produce the same result. PERT charts have become established as the most popular planning technique and have been included in project management software packages.
PERT Charts Illustrated
This course concentrates on the PERT chart approach to project planning. PERT charts are made up of a series of activity boxes, each of which depicts a discrete activity or task. Each activity box may contain up to 7 items of information. The top line of the box reflects the earliest point at which the activity could start and finish. The center line should contain descriptive information about the activity and the bottom line should be used to reflect the latest start and finish times. In this example, activity A must be completed before activity C can begin as indicated by the line that joins the two activity boxes. Activity A requires 5 days and Activity C requires 4 days. This part of the project will therefore last 9 days. The earliest start time for activities right at the beginning of the network are set to zero. The earliest finish time for whichever input activity is the latest is used to establish the earliest start time for the dependent activity. In this example activity A is scheduled to be completed on day 5. Only then can activity C begin.
www.getahead.uk.com
33
PERT Charts Relationship Identification

In many cases an activity will be dependent on the completion of more than one preceding activity. In the example shown the two activities A and B must both be completed before activity C can begin. A requires 5 days, B requires 4 days and C requires 4 days. Activities A and B can be carried out in parallel as they are not dependent upon each other. In this example this part of the project will also last 9 days. Determining the relationships between activities can be a complicated process and may require a substantial amount of discussion involving numerous personnel across the various departments that may be concerned. The process of identifying relationships between the activities should only be concerned with logical requirements, in other words it should be assumed that there are no resource constraints when drawing the PERT chart. This issue has then to be addressed and appropriate adjustments made. Resolving resource shortfalls and conflicts is the scope of resource planning and scheduling. Diagrammers may find it useful to produce sub-diagrams and use these to conduct a brainstorming approach to identifying all possible relationships, prior to building the final network. The project will need to be monitored at various points to ensure that its business and technical integrity is being maintained - the PERT chart should also reflect these activities.
www.getahead.uk.com
34
GetAhead in Organizing Projects This 5 hour interactive multimedia training course is equivalent in scope to a two-day instructor led course. It will teach you all of the practical techniques needed to put the appropriate management and supervisory structure in place for projects of any size. This course is accredited by the Association for Project Management. At $29.95 or 19.95 this GetAhead in Organizing Projects training course represents outstanding value for money. Course Overview: This interactive multimedia training course is accredited by the Association for Project Management and NCC Education Services. It will teach you all of the practical techniques needed to organize and supervise projects of any size. You will learn how to clarify project objectives and place organizational structures in place to monitor the objectives within agreed tolerance limits. Team building, motivation and leading a project team are also covered in detail. The course will run on any multimedia PC with a sound card and is presented using a combination of specially developed 3D graphics, animation and interactivity. This provides a stimulating one-on-one multimedia learning environment that is packed with interactive exercises, case studies and questions. It is made up of self-contained sections, each representing approximately 15 minutes of training, which means that it can either be used intensively or be fitted into a busy work schedule. You will learn how to: Tailor the management and supervisory framework to suit the needs of each project. Apply the principles of effective matrix management to any number of project initiatives. Recognize and address the conflicting demands placed on members of the project team. Schedule the involvement of team members throughout the project life-cycle. Build and motivate an effective and efficient project team for each project initiative.
Buy all 3 Project Management courses for $79 or 49.
www.getahead.uk.com
35
GetAhead in Planning Projects This 5 hour interactive multimedia training course is equivalent in scope to a two-day instructor led course. It will teach you all of the practical techniques needed to carry out the appropriate degree of planning for projects of any size. It also covers project planning diagrams and a comprehensive hierarchy of project plans. This course is accredited by the Association for Project Management. At $29.95 or 19.95 this GetAhead in Planning Projects training course represents outstanding value for money. Course Overview: This 5 hour interactive multimedia training course is accredited by the Association for Project Management and NCC Education Services. It will teach you all of the practical techniques needed to plan projects of any size. You will learn how to select the most appropriate planning architecture to suit the needs of each individual project. The course also details the most widely used planning diagrams, including PERT charts (activity networks) and work breakdown structures. Resource planning and monitoring is addressed, including resource aggregation, leveling and smoothing. Finally, remedial planning and its associated activities are covered, in the event that a project deviates significantly from the planned schedule. The course will run on any multimedia PC with a sound card and is presented using a combination of specially developed 3D graphics, animation and interactivity. This provides a stimulating one-on-one multimedia learning environment that is packed with interactive exercises, case studies and questions. It is made up of self-contained sections, each representing approximately 15 minutes of training, which means that it can either be used intensively or be fitted into a busy work schedule. You will learn how to: Use the most appropriate set of support diagrams to optimize the planning process. Involve the relevant team members throughout the planning process. Carry out effective scheduling of all of the resources required by the project. Select a planning architecture that ideally suits the needs of each new project. Develop detailed plans incorporating PERT charts and critical path analysis.
www.getahead.uk.com
36
GetAhead in Controlling Projects This 5 hour interactive multimedia training course is equivalent in scope to a two-day instructor led course. It will teach you all of the practical techniques needed to design and implement the optimum control mechanisms for projects of any size. This course is accredited by the Association for Project Management. At 19.95 this GetAhead in Controlling Projects training course represents outstanding value for money. Course Overview: This interactive multimedia training course is accredited by the Association for Project Management and NCC Education Services. It will teach you all of the practical techniques needed to control projects of any size. You will learn how to select the most appropriate set of controls, to suit the needs of each individual project. The course explains and illustrates all of the widely used forms of project control from data collection and analysis to verification of actual progress to date. Project quality assurance is addressed throughout: from agreeing quality criteria and quality planning to formal reviews. In addition, configuration management and formal change control mechanisms are explained in detail. The course will run on any multimedia PC with a sound card and is presented using a combination of specially developed 3D graphics, animation and interactivity. This provides a stimulating one-on-one multimedia learning environment that is packed with interactive exercises, case studies and questions. It is made up of self-contained sections, each representing approximately 15 minutes of training, which means that it can either be used intensively or be fitted into a busy work schedule. You will learn how to: Select and apply a practical and effective series of project controls to each project. Integrate appropriate quality assurance procedures into all phases of the project. Implement effective reporting and change control regimes for each project initiative. Schedule the involvement of project team members at each control point. Apply proven techniques, including variance and EVA to measure progress against the plans.
www.getahead.uk.com
37
Project Management - Customer Reviews "cutting-edge ideas and hard-won wisdom" These three practical, easy-to-use training courses gives you instant access to the cutting-edge ideas and hard-won wisdom of today's leading experts in project management. In short, lively segments using real-world examples, they deliver the information you need to navigate complex project management issues. You'll find comprehensive descriptions of key concepts, tips on real-world applications, detailed case studies, the most sought-after skills explained in detail, and fully illustrated warnings on how to avoid pitfalls in the project environment. Dave Henderson, Manchester City Council, Manchester, UK "the course explains the time-tested principles of project management" The GetAhead Project Management series is a must for any professional working in today's increasingly project-oriented world. This comprehensive course presents managers and team members with proven techniques for managing projects, from establishing project objectives to building realistic schedule and cost projections. While it teaches the basic methods for defining, planning, and tracking a project, it also shows how to use these techniques to build stronger teams and lead all project participants, including the client and senior management. In an accessible, user-friendly format, the course explains the time-tested principles of project management that have worked on many of the worlds leading projects. Rosemary Charlesworth, Senior Lecturer, Oxford, UK "the tools and techniques necessary to spearhead your next project" The GetAhead in Project Management series provides a step-by-step, all-inclusive explanation of the techniques necessary to spearhead your next project, and bring it home on time, on budget, and at performance levels that will add directly to your company's bottom line. I bought this course for personal use and it is now standard project management training throughout our organization. Dr. Henri Olafsson, Data Scientific, Texas, USA "fundamentally changed the way I approach projects" This 3-CD interactive training course covers the core concepts and methodologies necessary to manage projects or participate within a project team. You will learn how to apply basic tools to effectively define a project and successfully manage the many elements of a project, such as the makeup of the project team, the project schedule, the budget, and produce accurate status reports. After 15 years of managing projects in an ad-hoc way this course has fundamentally changed the way I will approach all future project initiatives. Harry Northwood, Marconi Naval Defence Systems, Lillehammer, USA "directly comparable to attending face to face training courses" Ive bought all 10 GetAhead courses and I believe they all offer exceptional value for money they really are directly comparable to attending face to face training courses only at one twentieth the cost! The Business and Data Analysis courses have equipped me to carry out work that systems professionals charge over $500 per day for and they cost me under $50! I bought the courses privately, studied them and soon after managed to get an internal promotion that boosted my salary by 30%. Not only that, but once youve bought a course you can use it as many times as you like!! I think a lot of traditional training companies are in for a shock when word gets out. Thanks a million and good luck to all you guys at GetAhead, the courses certainly helped me to do just that! Scott Lazenby, WorldCom, New York, USA
www.getahead.uk.com
38

Project MGT 1

Diunggah oleh

Informasi Dokumen

Deskripsi Asli:

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Project MGT 1

Diunggah oleh

Hak Cipta:

Format Tersedia

This free downloadable QSheet (Quick-learn Sheet) introduces and explains an array of key issues that are fundamental

Full details of this course are available at:

Copyright Interactive Training Technologies Ltd All Rights Reserved

Full details of this course are available at:

Project Management Characteristics

Full details of this course are available at:

Keeping Sight of the Goal

The 3 Main Roles?

Full details of this course are available at:

The Matrix Management Approach

Matrix Management Needs Effective Communication

Full details of this course are available at:

Full details of this course are available at:

Full details of this course are available at:

Management Structure - Style

Management Structure - Representation

Full details of this course are available at:

Project Team Fundamentals

Concerns of New Team Members

Full details of this course are available at:

Motivating Team Members

Full details of this course are available at:

Project Life Cycles

Full details of this course are available at:

The Gantt Chart

The Gantt Charts Limitations

Full details of this course are available at:

Resource Definitions & Allocation

Full details of this course are available at:

Resource Aggregation, Leveling & Smoothing

Monitoring the Critical Path

Converting Resources into Costs

Full details of this course are available at:

Full details of this course are available at:

Configuration Management Plan

Full details of this course are available at:

The Configuration Administrator

Issue & Submission Procedures

Project Change Control

Identifying Project Change

Full details of this course are available at:

Change Control Mechanism

Full details of this course are available at:

Change Control Forms

Full details of this course are available at:

Document Update Request

Full details of this course are available at:

Full details of this course are available at:

Project Planning Introduction

Full details of this course are available at:

Standard Planning Diagrams

Full details of this course are available at:

Full details of this course are available at:

Product Based Planning

Product Based Planning - Illustrated

Full details of this course are available at:

Planning Diagrams Overview

Full details of this course are available at:

Work Breakdown Structure

Full details of this course are available at:

Work Breakdown Structure Work Packages

Work Breakdown Structure Illustration