Chapter 13: Project management II – Managing the project to its conclusion

Chapter learning objectives

Upon completion of this chapter you will be able to:

• describe the contents and importance of a project plan for organisations in general
• describe, for an organisation in general, the implications of project-based teams, the roles of the main team members (project manager and sponsor) and how they might overcome typical problems preventing the project from being successful
• describe how projects can be monitored with respect to risks, issues, slippage and changes and how appropriate responses can be devised
• explain the need to integrate gateways and benefits management into formal monitoring of projects
• discuss different types of project reviews such as post-project reviews, project implementation reviews and lessons learnt reviews
• describe how projects can be successfully concluded, including the benefits of end-project reviews and benefits realisation
• explain the typical uses of project management software.

1 Introduction

The previous chapter focused on the first element of projectmanagement - project initiation. This chapter covers the remainingelements, all the way through to project completion.

2 The project plan

Alongside the benefits realisation plan and business case coveredin the previous chapter, the project team will also need a detailed planfor resources, timings, interim targets etc. This will be the projectplan.

Importance of a project plan

A project plan aims to ensure that the project objectives areachieved within the constraints of quality, cost and time. Planning isessential – it helps to:

• communicate what has to be done, when and by whom
• encourage forward thinking
• provide the measures of success for the project
• make clear the commitment of time, resources (people and equipment), and money required for the project
• determine if targets are achievable
• identify the activities the resources need to undertake.

The plan is likely to be recorded as an element of a Project Initiation Document (PID).

Project Initiation Document (PID)

The PID is a formal, detailed document which contains planning information extracted from other sources such as

• business case
• the dissemination plan
• the risk assessments
• Gantt charts, etc.

It contains all the information necessary for the execution of the project.

It is more operational than a business case document and its focusis very different. The business case is aimed at gaining projectapproval whereas the PID is aimed at ensuring that an approved projectis successfully completed.

It will give guidance to the project team on what is expected fromthe project, when it is expected, and what level of performance isexpected. It will have detailed plans (such as Gannt charts), controlplans for when risks arise, responsibilities for tasks etc.

Also, it is not a one-off, pre-project document like the businesscase document. It is likely to be constantly revised and updatedthroughout the project life to reflect key changes and projectcompletion phases. However, this can be a problem in a project as oftenthe PID is updated and changed but it moves further away from theoriginal business case and objectives. Benefits management becomes evenmore important when this occurs.

Typical contents might include:

• a purpose statement (project drivers)
• project and investment objectives
• a scope statement
• project deliverables (part of the product breakdown structure, explained later)
• cost and time estimates
• benefit and change owners
• chain of command
• team responsibilities
• project gateways, performance measures and results (updated regularly)

Contents of a project plan

For a large project the contents of the plan will be made up of several parts:

Details on the contents of a project plan

To provide an overview of the project the project plan will include the following.

• Background to the project – a summary of the background to the project (and how it builds on previous work) and the need for it (and why it is important).
• Aims and objectives – a list of the broad aim or purpose of the project, and the specific objectives you intend to achieve.
• Overall approach – a description of the overall approach you will take to achieve the objectives outlined above, including:
  • strategy and/or methodology and how the work will be structured
  • important issues to be addressed, e.g. interoperability
  • scope and boundaries of the work, including any issues that will not be covered
  • link to critical success factors.
• Project outputs – a list of the tangible deliverables (including reports) your project will create, and the less tangible knowledge and experience you hope to build and share.
• Project outcomes – a list of the outcomes you envisage and what change they will stimulate or enable.
• Stakeholder analysis using Mendelow's power-interest matrix – a list of the key stakeholder groups and individuals that will be interested in your project outcomes, will be affected by them, or whose support/approval is essential, both within your organisation and in the community, and assess their importance (low/medium/high).
• Risk analysis – a list of the factors that could pose a risk to the project's success and an assessment of their likelihood and severity, and how you will prevent them from happening (or manage them if they occur). Cover the types of risks listed and any others that apply.
• Standards – a list of the standards the project will use.
• Intellectual property rights – an indication of who will own the intellectual property created by the project and a list of any owned by third parties that will be incorporated into project outputs, when/how you will obtain permission to use them, and any implications for project outputs after the project ends.

The project resources part of the plan will contain detailsof the project partners and project management with a brief descriptionof the project management framework, including:

• organisation
• reporting relationships
• decision process
• the role of any local management committee.

The detailed part of the plan will outline:

• the project deliverables and reports
• when they are due
• the phasing of the work and any dependencies.

It may also contain a Gantt chart, diagram, or flowchart toillustrate the phasing budget. It may alternatively include a productbreakdown structure (covered later).

The evaluation plan will indicate how you will evaluate thequality of the project outputs and the success of the project. It willlist the factors you plan to evaluate, questions the evaluation willanswer, methods you will use, and how success will be measured.

The quality plan will explain the quality assuranceprocedures you will put in place to ensure that project deliverablesmeet quality expectations and acceptance criteria. A separate qualityplan is required for each deliverable (see chapter 11 for more detail):

The dissemination plan will explain how the project willshare outcomes and learning with stakeholders. It will list theimportant dissemination activities planned throughout the project –indicating:

• purpose
• target audience
• timing
• key message.

The exit and sustainability plans should explain what willhappen to project outputs at the end of the project (including knowledgeand learning). They will focus on the work needed to ensure they aretaken up by the owners and any work needed for project closedown, e.g.preservation, maintenance, documentation.

The sustainability plan will list any project outputs that may havepotential to live on after the project ends, why, how they might betaken forward, and any issues involved in making them sustainable in thelong term.

Product break down structure

A project is thought to produce at least one 'product' – whetherthat product is a physical one (such as a text book) or a more abstractone such as an improvement in a lending process of a bank. In order toensure that each element of a project is controlled and managed, theproject may be described or drawn using a product breakdown structure.

A product break down structure breaks a product down into itscomponent points in the form of a hierarchical chart. Each product maybe broken down by sub-product and then further broken down by activity.

For example, if we were to examine Kaplan's classroom based tuitioncourses (this would be the product), the sub-products for this wouldbe:

• Exam text
• Class notes
• Classroom delivery
• Assessments
• Exam kit
• Mock exam

This shows the order in which sub-products must be provided. Forexample, it will be important to have class notes before the classroomdelivery can take place and likewise it will be important for studentsto attend some classroom delivery before they can attempt theassessments.

Each sub product could then be broken down by activity. For example, the activities involved in creating the exam text may be:

• Obtain the official syllabus
• Obtain the official texts
• Create the material
• Edit the material
• Obtain examiner/ exam body approval
• Print the text
• Deliver the text

Planning and control can then be focused on each sub-product andeach activity. For example, schedules can be created, risk can beassessed, responsibility can be allocated, targets set etc.

This may therefore be a vital element of the project plan.

3 Project execution

Executing consists of the processes used to complete the workdefined in the project management plan to accomplish the project'srequirements. Execution process involves coordinating people andresources, as well as integrating and performing the activities of theproject in accordance with the project management plan. The deliverablesare produced as outputs from the processes performed as defined in theproject management plan.

Managing and leading projects

Projects require people with different skills to work together in aco-ordinated way. The project team consists of individuals broughttogether purely for undertaking a specific project. Teams will cutacross functional boundaries, giving rise to 'matrix' organisations. Thesize of the team and the period of their existence will be determinedby the nature of the project.

Matrix structures

Projects are often interdisciplinary and cross organisationalreporting lines. The project team is likely to be made up of membersdrawn from a variety of different functions or divisions: eachindividual then has a dual role, as he or she maintainsfunctional/divisional responsibilities as well as membership of theproject team.

Test your understanding 1

Consider what advantages and disadvantages a matrix structure (studied in chapter 8) might bring to project teams.

Team members

A team member is selected to join the core team because of theirspecialist knowledge or expertise. They are usually drawn from afunctional department and therefore have a further responsibility inrepresenting that department. Some of the roles taken on by team membersin organisations include:

• Specialist or technical expert – brings specialist knowledge and advice to the team.
• Representative – as part of the core team, the member represents their 'home' department and as part of the project team communicates the project team's views and decisions when back in their 'home' department.
• Monitor and change manager – will monitor their progress against the plan appropriately and regularly and as changes are identified will ensure that the full implications have been assessed before the changes are agreed and implemented.
• Problem solver – will be faced with many problems during any project and will be required to solve them by drawing on the resources of the project team and their 'home' department and through the use of problem-solving techniques.

Assembling team members

There are two methods for assembling team members:

• the first approach is to use specialist project staff who are seconded to the project and removed from their existing roles. This may be backed up by external consultants who fill in any skills gaps. This approach is likely to lead to an efficient project which is completed quickly. However, there may be a lack of buy-in from line managers and staff who may resent a lack of involvement in the key project decisions.
• the second approach is to 'add on' the project to existing duties for operational staff. In this way staff would complete the project alongside their existing duties. This may mean that the project takes longer to complete but it should benefit from decision makers being closer to the decision point and from improved staff buy-in.

Project sponsor

The project sponsor or project facilitator will normally be a senior member of the management team.

• They are often chosen as the person with the most to gain from the success of the project and the most to lose from the failure of it.
• Their job is to direct the project, and allow the project manager to manage the project.

Typical roles of a project sponsor

The roles taken on by project sponsors in organisations include:

• gatekeeper – choosing the right projects for the business means ensuring that only projects that support the business strategy are started and that they are of sufficiently high priority and have clear terms of reference
• sponsor and monitor – steering the project by requesting regular meetings with the project leader and giving advice and guidance
• supporter and coach – provides practical support for the project leader, especially if they are taking on a project that is larger or more significant than they have handled before
• decision-maker – if decisions are required that are outside the scope of the project then the project sponsor will make the decision on behalf of the organisation
• champion or advocate – involves informal communication with other senior managers to ensure that they continue to have an objective view of the importance of their project in relation to other projects within the business
• problem solver – when the team faces problems that it is unable to solve or does not have the skills or experience to solve
• resource negotiator – a project's success will depend on the availability of the right resources at the right time. In cross-functional projects the sponsor may provide assistance in negotiating resources around the company.

The project manager

The project manager is the person appointed by the organisation tolead the team, and manage it on a day-to-day basis. Primarily theproject manager's responsibility is to deliver the project and to ensurethat effectiveness and efficiency are achieved across the entireproject.

Typical roles of a project manager

Some of the roles taken on by project managers in organisations include:

• Team leader – will spend time building the team, motivating individuals and ensuring that the project has a clear purpose and that every core team member understands that purpose.
• Planner and co-ordinator – will ensure that the team creates a realistic plan and will often consolidate the individual team members' plans into a full project plan. They will then co-ordinate the activities of the team to meet that plan and deal with changes in a systematic way.
• Task manager – involves clarifying the goals of the project and ensuring that every action is moving the project towards those goals.
• Communicator and relationship manager – will take the lead in proactively communicating the project in an appropriate way to all the stakeholders and manage the relationship with key stakeholders to ensure their needs are being met.
• Problem solver – will be faced with many problems during any project and will be required to solve them through team problem- solving techniques.
• Monitor and change manager – will put controls in place to ensure the project progresses against the plan and is monitored appropriately and regularly.
• Budget manager – will involve setting up the budget and then monitoring its use to ensure the best use of resources.
• Meeting manager – most project teams only meet as a team during project meetings so it is very important that each meeting is well managed.

While there are clearly overlaps, there are some important differences between a project manager and a 'normal' line manager:

• line managers are usually specialists whereas project managers are often generalists
• line managers operate close to the technical tasks in their departments, whereas project managers may have to oversee work in many different areas
• line managers exercise direct supervisory authority, whereas project managers facilitate rather than supervise team members.

Problems faced by project managers

Typical problems faced by a project manager will include:

• managing staff who are assigned to the project part-time and have responsibilities in their 'home' departments
• managing the relationship with the departmental managers who have staff on the project team
• managing the size of the team given variable resource requirements throughout the project life cycle
• dealing with specialists in areas where the manager is not an expert.

4 Project monitoring and control

Monitoring the project

The purpose of the project monitoring, reviewing and controllingprocess is to track all major project variables and to ensure the teamis making satisfactory progress to the project goals.

Performance measurements can include:

• Expenditure (cost)       
• Schedule (time) performance – avoiding schedule slippage is a key objective
• Scope measures – both product scope and project scope
• Functional quality
• Technical quality performance
• Issue management performance
• Client satisfaction measures.

Performance measures

Monitoring the project

Performance measurements can include.

• Expenditure (cost) – starts with the establishment of budgets and as the project progresses, decisions regarding procurement, design, development, deployment, etc., will be assessed with respect to their impact on expenditures. Actual expenditures will be compared to a baseline, and any variances will be reported to management for corrective action.
• Schedule (time) performance – refer to the timely completion of project deliverables as compared to a baseline schedule defined in the project plan. The schedules will identify all of the project's stages, phases and activities assigned to each team member, mapping them to a timeline that measures key milestones (dates) that are used to keep track of work progress. Avoiding schedule slippage is a key objective.
• Scope measures – are primarily concerned with product scope (the set of functions and features that characterise the product or service) and project scope (work that must be accomplished to deliver the product/service with the specified functions and features). Scope is measured based upon the degree of compliance of baseline product/service features and functions with proposed project deliverables (the means used for their delivery).
• Functional quality – refers to the quality or correctness of the products, and/or services, features/functions delivered as a result of the project.
• Technical quality performance – refers to the technical infrastructure that provides the foundation for product and service delivery. In the case of an IT project, such indicators as system availability, downtime, problem resolution, and response time and network utilisation would measure technical quality performance.
• Issue management performance – refers to the identification and resolution of issues or exceptions that are impacting the successful delivery of the project. Issues can be related to communications, human resources, contracts, product/service features and functions, etc. The purpose of issue management is to ensure that all matters requiring resolution, decisions or direction are addressed as soon as possible to avoid negative consequences on project objectives and deliverables (cost, schedule, scope or products/services).
• Client satisfaction measures – include client perceptions on various aspects of achieving a high degree of client satisfaction with implementation support or with operational products/services.

Monitoring and reviewing performance – a well-constructed planwith clear deliverables should make it very easy to track progress. Theproject manager should set up mechanisms whereby the team regularlyreviews what tasks have been completed or delayed and what the impact ison the rest of the plan.

• The diagram below shows a typical review loop indicating activities that occur once only, daily, weekly and at the end of each phase

Phase boundaries are key points at which a number of aspects of theproject can be reviewed.

• Is the business case for the project still valid?
• Is the project meeting its objectives?
• Has the risk situation altered?
• Should the project progress to the next phase?

Project gateways

This process is aided by specific project gateways. This will bereview points that are planned for critical points in the project. Thereviews will also ensure that the business case which justified theproject is still valid at this stage.

If problems are identified then project control measures and corrective action will be necessary.

Further details on project gateways

The purpose of a Gateway Review is to help increase the chances ofsuccessful delivery for projects. It is not an audit but is a real-timeassessment of the potential for project success. It allows the projectto change course or address issues that have the potential to underminethe objectives or affect the projected benefits.

It can also provide evidence to stop projects that are severely offcourse or badly misaligned with business objectives. Gateway Reviewsprovide important assurance to benefit owners that rigorous independentassessment of the project is taking place.

Gateway Reviews are normally carried out by a person/persons who isnot involved in the actual project. This gives an independence to thereview. In larger organisations and projects a specialist review teammay be created.

A review can only be a snap-shot of the programme or project as itis at the point at which the review takes place. As such,recommendations are based on the evidence presented and on theinterviews that take place. The review process is intended to besupportive and forward looking and will take future plans into accountbut only as future intentions, rather than actualities.

Threat identification

The following can threaten the success of a project. Identifyingthese in advance can help reduce the risk of slippage and otherpotential problems:

• Poor management
• Poor planning
• Lack of control mechanisms     
• Unrealistic deadlines     
• Insufficient budget
• Moving targets

Threat identification and slippage reduction

The following can threaten the success of a project. Suggestionsare included as to how to minimise the slippage involved with thosethreats.

• Poor management – many project leaders will be from technical backgrounds and they may not have the proper management skills for controlling large projects. Project leaders should be properly trained so that they have managerial skills as well as technical skills. They should not be given large critically important projects until they have proved themselves on smaller exercises.
• Poor planning – managers have not made use of the various planning methods available: network analysis, PERT, Gantt charts. They have not broken the project down into its various activities and estimated a time and cost for each.
• Lack of control mechanisms – it is essential to be able to monitor the progress of projects, otherwise it is impossible to decide whether they will meet cost and time budgets. Reporting mechanisms and review dates should be set out in advance.
• Unrealistic deadlines – there is often pressure from users for projects to be completed quickly. Project teams, particularly if they have had to win the job competitively, may have suggested times that are unrealistic. Project managers must look critically at the deadlines. They should identify the critical activities of the project and ensure that these do not slip.
• Insufficient budget – too few people are employed on the project, inadequate hardware is bought, the cheapest (not the best) solutions are always sought. Of course, organisations cannot ignore costs and should try to get good value for money. However, it is important to be objective about what a given cost budget can produce by way of project outcomes. If money is tight, it might be better to do a smaller project thoroughly than a larger one poorly.
• Moving targets – the project specification keeps changing as the project progresses. This will certainly add costs and delay to the project. Users' requirements should be thoroughly examined and the analyst should check understanding before the project is started. Techniques such as structured walkthroughs and prototyping will help here.

Project control

Controlling the project means:

• taking early corrective action when needed
• balancing project effort
• looking for where effort can be reduced
• making changes early rather than late.

Measurement of all relevant variables is important both formanagement information and also for the specification of 'what kind' and'how much' corrective action is necessary.

Examples of corrective action include:

• 'fast tracking' – a project management technique used to ensure that projects are completed within the shortest time possible, often by doing some activities in parallel that would normally be done in sequence (such as design and construction)
• 'crashing' – Project crashing is a method for shortening the project duration by reducing the time of one or more of the critical project activities to less than its normal activity time. The object of crashing is to reduce project duration while minimizing the cost of crashing
• adding additional resources (people, money, time, etc.)
• scope reduction
• compromising quality
• adopting higher risk but potentially better approaches
• employee/contractor disciplinary actions (negative reinforcement)
• employee/contractor incentives (positive reinforcement)
• pep talks and other motivation, etc.

Some corrective actions tend to be more tactical, and some more strategic.

Test your understanding 2

Printplus Inc is a printing company that has recently begunimplementing a new computerised job costing system. The project managerwho had started the project is now no longer with the company. You havebeen asked to step into the role of the project manager and complete thetask of implementing the new system.

(a)Briefly describe the key factors that you will need to review in order to get to grips with the current status of the project.

(b)Identify possible threats to timely completion of the project, and state briefly how they can be minimised.

5 Project completion

The final stages of a broadly successful project can be mostrewarding. It is at this stage that people can finally see therealisation of plans and objectives.

Project success and failure

Successful project management can be defined as having achieved the project objectives and benefits

• Within the allocated time period
• Within the budgeted cost
• At the desired performance or specification level
• While utilising the assigned resources effectively and efficiently
• With customer confirmation of expectations
• Without disturbing the main work flow of the organisation

Reasons why projects succeed:

• Project Sponsorship at executive level
• Good PID and business case
• Strong project management
• The right mix of team players
• Good decision making structure
• Good communication
• Team members are working toward common goals

Reasons for projects failure:

• Failure to align project with organizational objectives
• Poor scope
• Unrealistic expectations
• Lack of executive sponsorship
• Lack of true project management
• Inability to move beyond individual conflicts
• Internal politics

The barriers to project management success are:

• Project complexity
• Customer's special requirements and scope changes
• Organisational structural and systemic resistance
• Project risks
• Changes in technology

A Post Project Review (PPR)

This happens at the end of the project and allows the project team to move on to other projects. It typically involves:

• acceptance by client
• review of outputs against goals
• disbanding the team and 'tying up loose ends'
• performance review
• determination of lessons learnt
• formal closure by the steering committee.

Contents of a post project review (PPR)

• Acceptance by client – the outputs of the project should be successfully transferred to the project's clients or users. It is important at this stage to follow the dissemination plan.
• Review of outputs against goals – the project team should be able to illustrate that the project has delivered its planned outputs and that outcomes can reasonably be expected to flow from them. It is important at this stage to follow the evaluation plan.
• Disbanding the team and 'tying up loose ends' – it is important to ensure that all project activities are satisfactorily completed and project teams should be gradually wound down. It is important at this stage to follow the exit and sustainability plan.
• Performance review – for large projects this may be a useful way of identifying issues and concerns that could be relevant to other projects. This could include an assessment of against the quality plan. Other key areas to review include the following:
  • Technical performance review (was scope of project achieved?).
  • Cost/budget performance.
  • Schedule performance.
  • Project planning and control.
  • Team relationships.
  • Problem identification.
  • Customer relationships.
  • Communication.
  • Risk evaluation and assessment of risk management policies.
  • Outstanding issues.
• Lessons learnt that relate to the way the project was managed should contribute to the smooth running of future projects. A starting point for any new project should be a review of the documentation of any similar projects undertaken in the past.
• Formal closure by the steering committee – the project steering committee cannot disband until the project's outcomes are seen as achieved, or the project is classed as unsuccessful.

Post Implementation Review (PIR)

A PIR is an essential component of the benefits managementprocess. It checks whether benefits, including these set out in thebusiness case or PID, have been achieved and identifies opportunitiesfor further improvement. Without a PIR, a business cannot demonstratethat its investment in the project was worthwhile.

PIRs are often an on-going element of project management toensure that benefits are managed and realised. When benefits are notachieved, recommendations are provided to make further improvements tothe processes or systems. The PIR may also discover new benefits thatcan be derived and put plans in place to achieve these.

Comparing the PPR and PIR

For most projects, a PIR is undertaken when there has beensufficient time to demonstrate the business benefits of the new project.For a major programme of change there may be several PIRs over time.The review will normally involve the project manager, senior managementrepresentatives and, where used, internal benefits management experts.

The PPR and PIR are related but have different objectives. The PPRis a one-off exercise at the end of a project with the key objective oflearning lessons and feeding them into the organisation's projectmanagement processes and procedures for the benefit of future projects.

The objective of the PIR is to ensure that the maximum benefit isobtained for the organisation through the new project, and to makerecommendations if the benefits are not obtained. Every project isdifferent, but it is typical to perform a PIR two to twelve months aftercompletion of the project.

The PPR focuses on the performance of the project, whilst the PIR focuses on the performance of the product of the project.

A PIR would typically involve the following analysis:

• the achievement (to date) of business case objectives (effectively a gap analysis)
• costs and benefits to date against forecast
• other benefits realised and expected
• areas for further development
• consistency of the project with the overall business strategy
• the effectiveness of revised business operations (functions, processes, staff numbers etc.)
• ways of maximising benefits and minimising costs and risks
• the sensitivity of the business product/service to expected business change
• stakeholder satisfaction (both internal and external).

Benefits realisation review

A benefits realisation review is vital because a project cannot besaid to be successful until management is assured that all the benefitspromised at the evaluation stage can be shown to have been subsequentlyrealised.

Ward and Daniel identify a number of elements of a benefits review:

• to determine and confirm which planned benefits have been achieved
• to identify which expected benefits have not been achieved and to decide if remedial action can be taken to still obtain them or if they have to be foregone
• to identify any unexpected benefits that have been achieved and any unexpected 'disbenefits' that have resulted
• to understand the reasons why certain types of benefits were or were not achieved and provide lessons for future projects
• to understand how to improve the organisation's benefits management process for all projects.

A necessary part of this process will that each benefits ownershould prepare a statement detailing and evidencing the extent to whichthe benefit was achieved or reasons for its failure.

Reasons why change fails to deliver benefits

• vision and objectives either not clear or shared and owned
• benefits/outcomes not adequately owned, tracked and reported
• portfolio of programmes not all aligned to organisation's mission or strategy
• business change ignored or undervalued
• projects/programmes seen as delivering a capability rather than benefits
• making the right investment decision; to make the right investment decision we first need a clear understanding of what needs to be done and why it needs to be done now.

Lessons learnt review

One important element of this stage is to perform a lessons learntreview. A formal meeting should be held to determine what can be learntfrom the project. For example, it might consider the effectiveness ofproject control measures or the reasons for failures in businesschanges.

A formal action plan should be created to ensure that, in futureprojects, the positives can be recreated and the negatives avoided. Thisshould feed into future benefit realisation plans. They may even beformalised into codes of practice for the organisation.

Often, for this process to be useful, and especially for long andlarge projects, managers need to record lessons learnt and reasons forsuccess and failure as they go along.

6 Project management software

The planning and control of the project will be assisted throughthe use of appropriate software. The type of output produced by thepackage will vary depending upon the package being used e.g. FastPLANand Winproject.

They may be used in a variety of ways.

Planning:

• The ability to create multiple network diagrams.
• The ability to create multiple Gantt charts.
• The ability to aid in the creation of the PID.

Estimating:

• The ability to consider alternative resource allocation.
• The ability to create and allocate project budgets.
• The ability to allocate time across multiple tasks.

Monitoring:

• Network links to all project team members.
• A central store for all project results and documentation.
• Automatic comparison to the plan, and plan revision.

Reporting:

• Access to team members.
• Ability to create technical documents.
• Ability to create end of stage reports.

Advantages:

• Improved planning and control.
• Improved communication.
• Improved quality of systems developed.

Further details on project management software

Project management software recognises that there is a sequence in which activities need to be performed.

The software package will require four items of information.

• Duration of each activity.
• Dependencies of activities.
• Resources available.
• At what stage the resource will become available.

When choosing project management software, or indeed any software package, it is important to:

• determine requirements of organisation including its current and future needs
• document requirements including the essential functions/important/wish list
• review all available packages to identify three/four products which meet the essential functions and fall within budget
• have a demonstration of the packages on a trial basis if possible
• select a package including 'roll out' strategy with installation, training, etc.

7 Chapter summary

Test your understanding answers

Test your understanding 1

Advantages

• The key advantage of a matrix structure is effective coordination of multi-disciplinary teams through the project teams. This should ensure that decisions will require less amendment when implemented as all perspectives have been incorporated from the beginning.
• Matrix structures allow project teams to be created and changed relatively easily and quickly, giving extra flexibility to respond to market developments.
• Employees will also benefit from the matrix approach as they will learn new skills and have to adapt to solving a range of problems outside their functional specialisms.

Disadvantages

• The main problem with matrix structures involves clarifying responsibilities and demands made on employees. Employees may feel stressed and confused when conflicting demands are made by functional and project managers.
• This is usually resolved by having frequent meetings between functional and project heads, taking up time that could used more effectively elsewhere. In some organisations functional heads have felt that their authority is diluted and project heads given priority.
• Linked to the above, staff appraisal becomes more difficult with a matrix structure.

Test your understanding 2

(a) The following key factors should be considered in reviewing the current status of the project.

• Time. The progress reports on the project should be reviewed, to determine whether or not the project is currently on target for completion within the expected time. An assessment should be made as to whether the remaining tasks can be completed by the original deadline.
• Resources. I shall also need to identify the resources that have been allocated to the project. Resources include both human resources and computer equipment/time. Having established what resources have been made available, I should then make an assessment of how sufficient or effective these are for achieving the project goals.
• Cost. I should look at the original budget for the project and review this in the context of the actual costs incurred to date. I should then try to make a sensible estimate of the further costs that will be incurred in completing the project.
• Quality. The project plan should be reviewed to find out whether or not any quality standards were agreed for the intermediary stages of the project. If they were, I need to establish whether or not these standards are being met.

(b) The following may be identified as key threats to completion of the project on time.

Rating :	Ratings & Comments  (Click the stars to rate the page)

Tags: