Monitoring And Reporting Mechanisms Information Technology Essay

A lot of literature exist on project planning and project success. This chapter is going to look at these existing literature to establish a foundation for this dissertation and will build upon it. Projects management in the past centered on managing cost, time and quality. However in recent times, project management has evolved to include the management of scope, risk and benefit (PRINCE 2, 2009). These six aspects have to be managed if a project is to be successful. To achieve this, a project manager has to at least have a mental plan of how the project is to be undertaken and how success will be defined (Dvir et al, 2003). Projects usually have stakeholders, from the customer funding the project to the designated User and anyone who can/will potentially influence the project. These stakeholders need to be managed as well as their expectations (Gwillim et al, 2005). Success continues to be a contentious topic amongst researchers and professional alike. This has led to the absence of an agreed definition or criteria by which to assess project success (Tallon et al, 2000). This dissertation hopes to build on existing research work by establishing the relationship between planning effort and project success.

This literature review will look at literature on project planning (as it concerns project plans, risk, stakeholder management, estimation etc) and project success perceptions and proposed frameworks.

2.2 PROJECT PLANNING

Project planning involving budgeting and task scheduling has become a dominant part of project management literature and forums. The Association of Project Management (APM) through its Body of Knowledge (APMBOK) promotes planning as a pillar of effective project management. Looking back at the definition of a project as defined by the PMI (2005), some keywords stand out such as ‘temporary’ and ‘unique’. These words suggest that resources/efforts are time limited and that no two projects are entirely the same. Projects in the real world are faced with constraints such as time, cost (funding), risks, expertise, technology etc. Hence, project planning has become a vital project management function as it facilitates the management, organization, control and utilization of these limited resources with the aim of effectively realizing the goals for which the project was undertaken in the first place.

2.3 THE PROJECT PLAN

“A plan is a comprehensive document which shows when, how and by whom a specific target or set of targets is to be achieved. These targets will include the project’s products, timescales, costs, quality and benefits” (PRINCE 2, 2009).

A project plan is a formal document which has been appropriately approved, is consistent and is based on the project’s requirements and adequately calculated estimates; which clearly describes the essential project guidelines. The main purpose of creating a project plan is to provide support for effective co-ordination and management of the project

(PMBOK, 1996).

Project plans are created to act as a guide for the management of a project. A very important element of a project plan is that it represents a physical documentation of most planning decisions as well as the assumptions upon which those decisions are based (Burke, 2003).

It is also a communication tool which helps to ease communication between stakeholders, although this depends on the plan being easily understood by all stakeholders.

In general, a project plan should delineate all major management reviews with regards to scope, quality and schedules and should also define an agreed baseline for the determination of progress and control (Soldano & Krueger, 1994). It portrays management’s vision for the project and it aids the efficient use of available resources at hand.

In many cases, a project plan is created in the initiation phases of the project and is adopted only after all required stakeholders have reviewed it and agreed upon its current form. Project plans tend to change as the project progresses and this is usually due to the fact that as project conditions change, the project team tend to change tactics (Carnegie, 2002). This is done to respond to changes and hence the project plan is updated each time there is a disparity between planned scenarios and actual outcomes ( Sommerville, 2001).

It is assumed that if a charily drawn up project plan is accurately adhered to, it should result in a successful project (Soldano & Krueger, 1994).

Sommerville (2000) suggests that a main project plan be created for all projects (IT, construction or any other project) and in addition, a various number of other area-specific plans be created to support the main project plan. Such additional plans may include:

A Quality Plan: This contains all project quality criteria, standards and procedures.

A Configuration Plan: This contains configuration management process aimed at providing necessary support for the project.

A Maintenance Plan: This contains forecasts of possible cost, schedules and requirements.

A Validation Plan: This contains all issues regarding system validation such as validation processes, schedules and required resources.

A Staff Advancement Plan: which contains all issues regarding staff development such as skills that are currently available, skills needed and how growth and experience will be achieved.

It is important to note that the creation of these plans does not guarantee project success (Carnegie, 2002). And so some researchers argue that if these plans do not guarantee success then why invest so much effort in planning in the first place (Myers, 1994).

2.4 PRINCE 2: A TAKE ON PROJECT PLANS

PRINCE 2 further defines a plan as “a document describing how, when and by whom a specific target or sets of targets is to be achieved. These targets will include the project’s products, timescales, costs, quality and benefits” (PRINCE 2, 2009). It goes further to suggest that effective project management depends on the effectiveness of the planning process, as a lack of a plan results in a lack of project control. The planning process as required by PRINCE 2 prompts the project manager, his/her team to develop a mental image of what the project would be like. As they try to anticipate different elements of the project during the planning stage, they identify potential threats, pitfalls and opportunities and suggest ways to manage them.

2.4.1 Levels of Plans

Here, “levels” refers to different levels of detail, scope and planning horizon. The planning horizon refers to the phase/time for which it is most possible to plan accurately (PRINCE 2, 2009). This is due to the fact that the further a plan goes, the more difficult it becomes to accurately plan.

Three levels of plans are recommended by PRINCE 2 namely:

The Project Plan

The Stage Plan

The Team Plan (not compulsory).

2.4.2 Project Plan:

The project plan is created during the initiation stage and it describes when and how a project is going to achieve its quality, cost, time and scope targets. It also shows the project’s main activities and main products as well as the resources required for the project to achieve set targets. The project plan supplies vital information (such as timescales, milestones and costs) to the business case (PRINCE 2, 2009).

PRINCE 2 requires that the project plan should support the overall plans of corporate/program management.

2.4.3 Stage Plans:

As the project is broken down into manageable stages, plans are created for each management stage. A stage plan although similar in content to the project plan contains minute details and covers a shorter period than the project plan. Every aspect of the plan is broken down to a level where it can be used by the project manager to manage the day-to-day activities of the project.

Whereas the project plan is created during the initiation stage (and updated throughout the project), each next stage plan is created close to the end of the current stage. Stage plans have the obvious advantage of being created after learning from the outcome of the previous stage(s). Hence, as accuracy is likely to increase with a shorter planning period, stage plans are likely to be more accurate and as they cover a shorter period and are created close to when activities for the stage will be undertaken. Stage plans are created to span within a planning horizon (PRINCE 2, 2009).

PRINCE 2 requires that a project must have at least 2 stages: an initiation stage and any other stage(s).

2.4.4 Team Plans:

A team manager is solely responsible for creating the team plan (each team manager may create his/her own team plan). Team plans cover the execution of work packages being handled by the team but does not necessarily have a prescribed format. A team plan may contain all integral information required to execute the work package or may just show only schedule information for the team to achieve. Team plans therefore may differ from team manager to team manager.

PRINCE 2 allows for team plans to be optional depending on the scope and complexity of the project.

2.4.5 PRINCE 2: Plan Requirements (For Project & Stage Plans)

Composition:

Should contain vital prerequisites which must be available for the plan’s success.

Dependencies which are external but can influence the plan.

Assumptions which form the basis upon which the plan is been created.

Integrated lessons from previous projects of a similar orientation.

Budgets for cost, time, change and risk.

Schedule which may be Gant charts, PBS, WBS, tables, bar charts etc.

Agreed tolerances for scope, time and costs.

Product description of products which fall under the stage for which the plan is being created.

Ways in which the created plan will be monitored and controlled.

Format and Presentation:

A plan can be created as a spreadsheet, PowerPoint slides, Word Documents, single document or as part of the Project Initiation Document (PID).

Quality Criteria:

Plans should be achievable.

Only after adequate research and consultation should estimates be made.

Seek agreement from Team Managers that their section covered from the plan is achievable.

Plans should carry adequate detail, although PRINCE 2 does not say what actually is “adequate” (not too much/not too little).

Plans should complement corporate standards and legal requirements and incorporate lessons learnt from previous projects.

Plans should sustain the QMS (Quality Management Strategy), CMS (Communication Management Strategy), RMS (Risk Management Strategy) and CMS (Configuration Management Strategy).

Derivation:

When creating different levels of plans, the following may be consulted for vital information:

QMS (Quality Management Strategy),

CMS (Communication Management Strategy),

RMS (Risk Management Strategy) and

CMS (Configuration Management Strategy)

Registers, logs and the Project Brief.

2.4.6 Exception Plans

PRINCE 2 recommends the use of an Exception Plan which is created to replace an already created plan which has deviated from agreed tolerance. The exception plan can only replace an existing plan only when the appropriate management level approves it (PRINCE 2, 2009). The Project Board approves an Exception Plan to replace a Stage Plan while Corporate/Programme Management approves an Exception Plan to replace a Project Plan (if it is beyond the authority of the Project Board).

An Exception Plan should be as detailed as the plan it is replacing and should incorporate the “actual” from the previous plan and continue till the end of the plan which it replaces. Also, Team Plans can not be replaced by an Exception Plan as in the event of a significant deviation, the Team Manager notifies the Project Manager (by raising an issue) who then resolves it or issues a new Work Package (PRINCE 2, 2009).

2.5 GENERAL FORMS OF PROJECT PLANS

Project plans are created in various forms which are usually dependent on the size and orientation of the project as well as the project methodology being used.

Different researchers suggest various forms and contents of project plans. Below is a summary of some of the common propositions on Project Plan composition:

Project Objectives/Scope:

A plan should contain the objectives of the project i.e. what the project hopes to achieve (Sommerville, 2000). Scope refers to the summation of all the project’s products and the coverage of the requirements (PMBOK, 2005).

Project Budget/Schedule:

Scheduling involves determining the time required to complete specific project Work Packages/activities. A total of these respective times give the total project schedule. This can be determined with the aid of mathematical analysis or computer/practical simulations (Carnegie, 2002).

Budgeting involves the allocation of the total cost estimates of the project to specific Work Packages/activities. The basis for budgets should be the cost estimates, Work Breakdown Structure as well as the project schedule (PMBOK, 2005). Both budgets and schedules should be based on meticulously established estimates (Carnegie, 2002).

Risks:

When planning, risks need to be identified which could endanger or enhance (in the case of an opportunity) the project’s success (PRINCE 2, 2009). Not only should these risks be identified but they should also be quantified, analyzed and assessed for proximity, probability of occurrence and impact (APMBOK, 2005). PRINCE 2 however does not address the issue of unidentified risks.

Work Breakdown Structure (WBS):

A WBS is essential because it helps breakdown the project’s overall scope into vital Work Packages (Mansuy, 1991). These Work Packages may be broken down further into small manageable work activities which have to undertaken to complete the project (PMBOK, 2005).

Stakeholder Involvement:

Carnegie (2002) suggests that every plan should identify all stakeholders and define their functions, representations as well as their requirements/expectations. It is also suggested that the plan should go further to reflect the importance of each stakeholder’s involvement and interaction. This can be done by creating a matrix (two- dimensional) which shows stakeholders on one side and their respective project function on the other.

Monitoring & Reporting Mechanisms:

Project plans should describe the mechanism(s) through which progress can be measured against projected targets so that corrective actions can be taken where necessary (Gibson et al, 2006). Monitoring mechanisms ensure that actual conditions/values of vital project parameters are monitored for any significant deviations from planned values/estimates. Such parameters include project costs, time, quality and scope.

Reporting mechanisms on the other hand involves the collection and circulation of vital project information so as to keep stakeholders informed about actual performance via status reports, setbacks, accomplishments, risks and resource utilization (PMBOK, 2005).

Knowledge and Skills:

Plans should describe the skills a project requires and how those skills will be acquired. This can be through training of project staff or through external sources (recruitment, consulting etc). During planning, the available skills and knowledge need to be assessed so as to know what is required in terms of training or outsourcing & consulting (Carnegie, 2002). Having the knowledge and skills information handy could help in the early identification and management of knowledge/skill deficiencies. This can aid the achievement of project success (PMBOK, 2005).

Project Resources:

Soldano et al (1994) and Carneige (2002) insists that every project plan should identify and describe the project resources (quantity, specification, etc.) required to successfully execute the project. These resources may be staff, raw materials, machinery, funds, facilities or even vital information with which the project is to be executed. This enables the project team to identify missing resources, potential resource shortages and other resource-related risks/needs.

Many project management experts and bodies of knowledge agree that irrespective of the planning method, plan format or project size, a project plan should be well detailed and cautiously put together to facilitate the achievement of project goals (Dvir et al, 2003).

One interesting word which keeps coming up through most existing literature is “Estimate”. A lot of estimates seem to be made for most aspects of a project plan.

2.6 PROJECT ESTIMATION

Project estimation refers to the process of forecasting the required efforts/resources to successfully deliver a project. Making estimates is rather easy but making accurate, grounded and realistic estimates is quite an uphill task for most projects.

Project estimates help make project boundaries/constraints quite clear, helping the project manager and his team to make decisions through out the project’s life cycle.

2.6.1 The Need for Estimation

Stamelos et al (2003) suggest that project estimation gives all stakeholders the justified project basic guidelines and resolves the issue of project scope. Estimating accurately is important as it assists the Project Manager to plan effectively and control the project (Burke, 2003).

As a project progresses, the accuracy and quality of estimates can be improved due to the availability of more accurate information. The Project Manager needs to make some vital decisions before this accurate information becomes available. He may need to urge the company to enter into financial/contractual commitments at the tender/bidding stages meaning that “accurate estimates” need to be made from all the imperfect and inconclusive information available at the pre-project phase (Burke, 2003).

Estimates also help to verify if a prospective supplier will be able to embark on the project (Leung and Zhang, n.d).

Overestimating may lead to an over-allocation of resources to a project or may even lead to loss of the bidding war to win a contract due to a high price relative to other bids. On the other hand, underestimating will likely lead to cost overruns, late completion, low quality and functionality and even project abandonment (Schwalbe, 2004).

According to Leung and Zhang (2000), estimates:

Help Corporate Management prioritize projects with respect to the organization’s overall business plan.

Facilitate resource allocation (to different projects) and resource utilization.

Ease the management and control of projects (by linking the right resources to the right/actual needs).

2.6.2 What Is Estimated?

Estimation is usually based on vital project characteristics which can affect and limit the project outcomes. These characteristics include cost, scope, effort, time etc. Before the project begins, the Project Manager must ask some vital question. How much will it cost to execute this project? How much time is required to execute this project? How much effort does this project require to be completed? To answer these questions, it is necessary to estimate the size of the project i.e. the total summation of all the Work Packages needed to be completed for the project (Sommerville, 2000).

2.6.3 Estimating Entire Project Size:

Estimating the size of a project is one of the most important issues in project estimation. It involves estimating the amount of work products needed to be delivered by the project. These include those produce within the project (Deliverables) and those produced externally (Non- Deliverables) (Carniege, 2002).

For example, in Software projects, size can be measured in terms of volume of data, number of functions, memory of database, number of function points, code lines and so on. The obvious importance of size estimates is that it is an integral building block of other estimates and as such more effort needs to be put in to ensure its accuracy (Schwalbe, 2004).

Software metrics used for size estimation include:

The LOC (Line Of Code):

This is one of the commonest software metrics used when making estimations for software projects’ size. Its drawback is hinged on the fact that it solely relies on the programming style and language which means it is prone to uncertainties as different programming languages are known to require diverse amounts of programming codes.

Function Points (FP):

This is a more reliable software metric used to estimate software project size. “Its reliability is due to the fact that it is able to measure the amount of software functionality required to be implemented in the software” (Stamelos et al, 2003). The number of FP is determined by counting the occurrence of the following system types:

System Types

System Definition

Examples

Internal Logical Files (ILF)

A logical grouping of system data which are maintained by an end user.

Payroll and Inventory issue records etc.

External Interface Files (EIF)

Another system’s grouping of data used for reference purposes only.

Extracted third party application data etc.

External Inquiries (UI)

Allows data to be selected/displayed from EIFs/ILFs by users

Employee/payment data, screen logons etc.

External Inputs (EI)

Allows ILF data to be changed, deleted or added by users.

Third party messages, screen input of receipts, orders etc.

External Outputs (EO)

Data output produced by user in ILFs/EIFs

Payroll checks, reports on weekly sales, statements of accounts etc.

Table 1 Function Points Estimation (System types used)

(Adapted from Stamelos et al, 2003)

2.6.4 Estimating Required Effort

After the size of the project has been estimated, the effort required to execute the entire project can be estimated also. Effort required refers to the total effort required to execute the entire project (work which needs to be done, skills required, knowledge, training needs etc).

Tools for estimating effort required include:

Work Breakdown Structure (WBS)

“A WBS is a product-oriented structure which breaks down the whole project into a stream of connected small and manageable work packages” (Mansuy, 1991).

A WBS helps to identify all different components of a project and also helps to facilitate the organization and allocation of resources to each component. It also facilitates the visualization of the project life cycle which shows how the project how the project is to progress from one phase to the other (sequentially).

For software projects, there exists different life cycle models (XP, Evolution and the Waterfall).

2.6.5 Estimating Time Required

With size and effort estimates generated, it becomes easier to determine the time estimates. Time-estimates have to do with the schedule of the project (start and finish dates for different Work Packages/tasks). Time estimates/schedules are developed in terms of days so as to make it understandable by all parties (Peters K, n.d).

2.6.6 Estimating Project Cost

This involves estimating the cost for the overall project i.e. a combination of individual cost such cost of resources, cost of infrastructure, cost of labor etc. Also, overhead costs form an important part of cost estimates and should be taken into account (Somerville, 2004).

2.6.7 Estimation: Approaches

Different existing literature agree that producing accurate estimates can be an uphill task as it involves trying to predict the future when you have limited amount of information. Developing any estimate can be easy, but getting it accurate involves a lot more than wild guessing (Hughes, 1996). A wide range of estimation techniques/approaches exist today, some which were developed over 25 years ago. Although the concept of estimation has been in existence for many years with a variety of techniques, inaccurate estimates continue to be created time and time again. This may be due to the fact that these techniques are based on the use of available data which might be inaccurate, inadequate, outdated or just a guess (Stamelos et al, 2003).

In software development, the project team has only little information (which is not adequate enough) during the User-Requirement Definition Stage and hence face an uphill task in satisfying those requirements (Rumbaugh et al, 1999).

Different estimation techniques exist and can be grouped into 2 major classes which are:

Algorithm Modeling Techniques and Experience-Based Technique.

Algorithm Modeling Techniques:

This group of techniques is based on mathematical algorithms which use distinct variables which represent critical project factors such as cost, size materials manpower etc. These mathematical algorithms and formulas are generated by thorough statistical analysis of similar projects which have been completed. For example, for a software project, a formula needs to be derived from a similar software project which has been completed. Such a formula may be presented by:

Effort = A Ã- SIZEB Ã- M (Sommerville, 2004)

Where:

A = Constant factors

B = Constant factors (A & B are dependent on type of software and organisation)

SIZE = size of software (Function Points/ Code Size)

M = Effort Multiplier (derived from combining cost factors)

It is important to note that the above formula has been expressed in its simplest form and may be more complex and diverse. To get M, cost factors need to be combined and rated from I to 6. Examples of such factors include staff capability, constraints (time, storage etc), reliability, complexity, size etc.

Ratings

Cost Factors

Very low

Low

Nominal

High

Vey high

Extra high

Product Attributes

RELY

Required Software reliability

0.75

0.88

1.00

1.15

1.40

DATA

Data base size

0.94

1.00

1.08

1.16

CPLX

Product Complexity

0.70

0.85

1.00

1.15

1.30

1.65

Computer Attributes

TIME

Execution time constraint

1.00

1.11

1.30

1.66

STOR

Main storage constraint

1.00

1.06

1.21

1.56

VIRT

Virtual machine volatility

0.87

1.00

1.15

1.30

TURN

Computer turn-around time

0.87

1.00

1.07

1.15

Personnel Attributes

ACAP

Analyst capability

1.46

1.19

1.00

0.86

0.71

AEXP

Applications experience

1.29

1.13

1.00

0.91

0.82

PCAP

Programmer capability

1.42

1.17

1.00

0.86

0.70

VEXP

Virtual machine experience

1.21

1.10

1.00

0.90

LEXP

Programming language experience

1.14

1.07

1.00

0.95

Project Attributes

MODP

Use of Modern Programming Practices

1.24

1.10

1.00

0.91

0.82

TOOL

Use of software tools

1.24

1.10

1.00

0.91

0.83

SCED

Required development schedule

1.23

1.08

1.00

1.04

1.10

Table 2: A Cost Factor Table

(Adopted from Sommerville, 2000)

Experience Based Techniques

This technique depends on the experience and exposure of highly regarded personnel who have worked on similar projects before. Although these techniques are used a lot even today, they have an obvious flaw. Projects are different and a project completed today will most likely differ in terms of conditions/constraints from that of tomorrow (Sommerville, 2004). The introduction of new technology is another factor which affects the credibility of this class of technique. Personnel though experienced may never have worked with the new technology or recently developed programming language and so might make wrong estimates based on their obsolete experience.

Examples of experience based techniques include:

1. The Famous Parkinson’s Law:

Parkinson’s Law states that “work expands to fill available time” (Stamelos et al, 2003). This law suggests that estimates are made based on available resources not on project objectives assessment. For example, to build a house which has to be completed in 6 months with six staff available, the effort is estimated as 36(6Ã-6) staff per month.

This approach will most likely lead to time and cost overruns (Stamelos et al, 2003).

2. Analogy:

This method is based on a comparison between similar projects upon which estimates are made. For example, for constructing a shopping mall, estimates are based on already completed shopping malls (data is compared to determine probable cost, schedule etc).

Its advantage is that it is based on real life projects and real data. Its drawback is that it is inadequate for dealing with new domains which have not occurred regularly in the past.

3. Expert Analysis:

This refers to the making of estimates based on the experience and know-how of experts in the related project scope/orientation. A wide range of experts may be contacted to make their estimates which are then analysed and repeated till a common consensus is reached by all involved.

Its limitation lies in the definition of the terms “Experienced” and “Knowledgeable”. Its strength lies in the speed with which an expert can make estimates (Stamelos et al, 2003).

4. Winning-Pricing:

This approach is based on making estimates while intending to arrive at a good (winning) price for the project. This ends up with estimates based on what the client is willing to offer (Sommerville, 2004). The advantage is that the bidder is more likely to get the job by placing a price-competitive bid. The disadvantage of this approach is that it puts the project resources under a lot of strain and will most likely result in project failure. This usually leads to cost and schedule overruns, quality slips etc.

2.7 PLANNING AND RISK

Risk refers to issues/uncertainties which are likely to result in a failure to achieve set out objectives of a project (PMBOK, 2005).

Estimates form an integral part of project plans and with estimates come uncertainties and with these uncertainties come risks.

Risk management is an iterative process spanning the entire life cycle of the project. This is due to the fact that risks continue to be identified through out the project and there needs to be a constant effort to implement the right risk response ( avoid, reduce, transfer etc) if success is to be achieved (Burke, 2003). When a risk is identified, it ceases to be a risk and becomes a problem/issue (Nicholas & Steyn, 2008).

As a project team continues to repeat a series of functions, they tend to become more familiar with the job and build confidence and know-how. It follows that the level of risk tends to reduce as the team continues to repeat the same job over a long period of time.

A risk may have been seen as a major project risk when the project team identifies it for the first time but as they continue to encounter the same risk/set of risks, it is perceived as a minor risk and may even be eliminated as time goes by.

Nicholas & Steyn (2008) suggest that risk is a duo-concept notion i.e. it involves firstly the probability that a negative event will occur and secondly, the impact of the event if it occurs.

Mathematically, Risk = f (Probability, Impact)

For projects, the higher the value of probability and impact, the greater the risk and hence greater effort must be committed to manage it. Sometimes, probability factor might be low but impact factor relatively high. In such a case, the risk (although less likely to occur) needs to still be regarded as high risk. For example, where impact might result in death, business bankruptcy etc, the risk although less likely to occur needs to be regarded as high risk due to its ability to adversely affect the project.

Risk management process as discussed by various experts such as Cooper et al (2005), Burke (2003) etc involves some basic functions which are:

Risk Identification:

This involves the efforts employed to determine the risks associated with the project. These risks are to be recorded along with their characteristics. Some of the identified risks could be internal or external (like government laws changing). Internal risks may be controlled by the project team but external risks cannot.

To achieve a thorough identification process, the following mechanisms can be utilised:

1. The Product Description

2. Use of Historical Data

3. Outputs from planning process.

A product description helps in identifying products of the project. The project plan contains the project product description while the stage plans should contain the different products of that stage. A product description also provides the quality tolerance for the product (PRINCE 2, 2009).

Risk Assessment:

This involves analysing identified risks and prioritizing them based on their proximity, impact and probability of occurrence (Cooper et al, 2005). Risk assessment determines how each risk is classed depending on the organization’s/project’s risk appetite. Also, risk assessment goes further to investigate not only the risk but its source.

Some risk assessment tools which can be used to analyse risks include:

Probability Trees

Statistical sums

EV (Expected Value)

Schedule Simulation

Pareto Analysis

Probability Impact Grids

Response Planning (Mitigation Strategy):

This involves strategic planning on the way to tackle each particular risk. PRINCE 2 suggests that the project team can choose to adapt any of the following responses:

Avoid (For threats)

Reduce (For threats)

Fallback (For threats)

Transfer (For threats)

Accept (Threat)

Share (For threats or Opportunities)

Exploit (For Opportunities)

Enhance (For Opportunities)

Reject (For Opportunities)

Implementation:

Whatever the response strategy chosen, it needs to be implemented effectively in order to achieve the desired outcome. A good strategy implemented poorly will most likely result in unachieved goals (Cooper et al, 2005). On the other hand, a poor strategy can be well implemented and still not give the desired result. Hence, risk management is an iterative process which needs to be continued over and over till the desired outcome is achieved.

2.8 STAKEHOLDER MANAGEMENT

This is defined as the methodical process of identifying, analyzing and planning of ways in which to effectively influence, negotiate and communicate with all project stakeholders (APMBOK, 2006).

Project stakeholders play a very important role in defining the criteria by which the success of the project will be judged. Hence, it is important that these stakeholders are identified and their interests and ability to influence the project analyzed. The Project Manager has to develop plans to manage their interests and powers effectively to achieve success (APMBOK, 2006).

The APM (Association of Project Managers) suggests the use of a stakeholder grid to further grasp stakeholder relationships with the project.

Good stakeholder management ensures the proper maintenance and utilization of stakeholder’s positive interests in the project as well as eradication/minimization of their negative interests (APMBOK, 2006) Difficulties may likely arise in stakeholder management due to the inconsistency of various stakeholders’ views during different phases of the project as their attitudes, roles, perceptions and allegiances change. Hence, stakeholder management should be an iterative process utilizing the project’s communication strategy as a control tool (Neely et al, 2002).

2.9 THE CONCEPT OF SUCCESS

For many years, project managers, organisations and researchers have tried to capture the real meaning of project success but it has proved a difficult and evasive notion. This is probably due to the fact that success has different meanings (Freeman, 1992). According to Wilson & Howcroft (2002), the acknowledgement of success and failure is perceived as a social achievement which is highly dependent on the perception of the subject. Hence, it is difficult to define and measure project success since it bears different meanings to different people. However, success is a critical concept when planning projects (Christenson & Walker, 2004). Although the failure of IT projects is widespread (Love et al, 2005), there is still the lack of an agreed definition of project failure/success (Irani et al, 2001).

Myers (1994) proposes that success is achieved when an IT system is seen as successful by stakeholders. Although this notion seems very logical and simple, perceptions are subject to expectation which might be unrealistic (Szajna & Scammel, 1993). A paper by Daniel Kahneman (n.d) on the theory of prospects explains that our human psychology is responsible for the usual optimistic expectations concerning project budgets, time and quality. Wilson & Howcroft (2002) suggest that a project sponsor is likely to perceive success as the survival of the project. Thus, even when a project fails to perform optimally in terms of time, budget and quality; it may still be regarded as a successful one based on a survival criteria.

2.9.1 Assessing Project Success

A review of existing literature shows the lack of an accepted framework to assess the success of projects as there seemed to be differing perspectives. According to Freeman and Beale (1992), the meaning of project success differs to different people. Different literature also suggest different ways to assess project success.

Freeman and Beale (1992) suggest that 6 different dimensions be considered when assessing project success. These dimensions are:

Business Performance

Efficiency of Execution

Ability of Manufacturer

Technical Execution

Personal Growth

Customer Satisfaction (Managerial/Organisational Performance)

Pinto and Mantel (1990) suggest that project success should be based on the following:

Satisfaction of the Client

Seeming Project Value

Implementation Process Quality

Also, Baccarini (1999) proposes a Logical Framework Method (LFM) for assessing project success. The LFM assesses project success from 2 distinct bases which are: Project Management Success and Project Product Success. Project Management Success pays attention to the process through which the project is managed while Project Product Success focuses on the effects of the final product of the project. An integral part of the LFM is that it utilizes a hierarchal framework of project objectives which are:

Strategic Goals

Project Benefits

Project Outputs

Project Inputs

These four objectives are linked with a “How”, “Why” logic (i.e. Means and Ends).

For example, an organization undertaking a project, are likely to have their strategic objectives and hence comes the question: how do we achieve this strategic objective? The answer to this question should be the Project’s Benefits. The next question is how do we achieve these benefits? The answer should be the Project’s Outputs. Next question is how do we get these outputs? And the answer should be the Project’s Inputs.

To make this logic a bit clearer, lets take a project been undertaken by a Luxury Cruise Company to build their biggest cruise liners. The company’s strategic objective is to be the leader in luxury cruise holidays in Europe (this should form the Project’s Strategic Goal). To achieve this, they need to attract more of the holiday market share and become the clear market leader in the cruise liner industry (this should form the Project Benefits). To achieve these benefits, they need a new cruise liner with a 570 passenger capacity finished with unparalleled luxury and record breaking speed (this should form the Project Output). To achieve this output, the company needs to invest ₤85 million over two years in a new cruise liner (this should form the Project Inputs). If this logic works backwards as well as forwards, it is likely that there will be a better understanding and a logical expression of the project’s objectives (Baccarini, 1999). The strategic goal and Project Benefits need to be investigated outside of the project by asking the questions: Are we doing the right project? Will it solve our Problems? Is there a better alternative?

The Outputs and Inputs need to be investigated within the project by asking: Are we executing this project right? Are we utilizing inputs well enough? Will we deliver the agreed product(s)? This becomes a function for the project team (Turner, 1999).

The use of the Logical Framework Method could provide a clearer understanding and communication of the project objectives. It could also facilitate the efficient allocation for responsibility for achieving each level of the project’s objectives (Yourker, 1998).

An obvious omission to this framework is that it does not consider the project’s objectives in terms of the User. This however is a commendable strength of PRINCE 2 as it focuses on the User.

2.9.2 IT Projects And Success

Cooke-Davies (2002) suggests that project management success is only concerned with and can be measured by project costs, time and quality, while project success can only be measured against the achievement of the project’s entire objectives. He adds that project management success is secondary to and may facilitate project success.

Although project management success is secondary, it is relatively easier to measure due to its relative simplicity and the ability to measure it at the end of the project (Judgev & Muller, 2005). Projects which are successful are more likely to “give emphasis to project success rather than project management success” (Baccarini, 1999).

IT projects success can be perceived as a mishmash of IT system success and success of project implementation (Espinosa, 2006).

Ballantine et al (1999) suggests that IT system success can be broken down into 3 levels which are:

Technical Development Success

User Development Success

Business-Benefit Delivery Success

On the other hand, Saarinen (1996) recommends that IT system success be viewed as a “4-Dimesnsional Construct” made up of:

Development Process Success

User Deployment Success

Product Quality Success

‘Impact On Organization’ Success

Also, DeLone & McLean (1992) suggested six elements of IT system success (which were later refined in 2004) which consist of:

Quality of system

Satisfaction of User (difficult to measure)

Quality of information

Quality of service

Net Benefits (User and Business )

Usage

A lot has been said about user satisfaction being an important measure of IT success but many argue that it lacks credible theoretical foundation (Gaitan, 1994). This notion is supported by Goodhue (1995). Again, although the concept of usage as suggested by DeLone and Mclean (1992) is widely accepted as a condition for IT success (Saarinen, 1996), its limitation lies in the fact that some IT systems do not require regular and extensive usage (Wixom & Watson, 2001). For example, data warehousing does not require extensive usage.

Moreover, it is rather wise for organizations undertaking pioneering strategies to anticipate and absorb some degree of project failure (Thomas & Fernandez, 2008). Also, it is important for these organizations to recognize that when certain failures occur in implementing systems, business and organizational success can still be achieved by converting initial failures into organizational and project / strategy learning (Irani, et al, 2001).

Due to the obvious problems associated with defining success, many projects are undertaken without a clear and unambiguous statement of what will be viewed as success. Equally, just being able to visualize what the project is destined to achieve serves as an important driver of successful project management (Christenson & Walker, 2004). Therefore, consulting and agreeing on a definition of success, with all project stakeholders (pre-project and at intermediate stages) has been proposed as an ideal project management function (Judgev & Muller, 2005).

Net benefits of a project concentrate on the total impact of an IT system and so stands out as the most important criteria for measuring IT success (DeLone & McLean, 2004). Nevertheless, “success criteria in terms of the projects’ benefits delivered are the exception, not the rule, and in a lot of cases, measures of project success are defined post project implementation or never at all” (Lubee & Remenyi, 1999).

This is supported by PRINCE 2, which states that it is impossible to measure the total benefits of a project during the life cycle of the project. A few benefits can be measured during the project, but total benefits can only be measured post-project. To this effect, PRINCE 2 proposes the use of a Benefits Review Plan, which states the how and when project benefits (expected by a senior user) can be measured (PRINCE 2, 2009). Benefits are not easy to measure, and most times, end up being different to those which were anticipated when the IT project was initially proposed (Farbey, et al. 1992). This brings to light, the issue of whether project success is supposed to be measured against the agreed original estimates, an amended set of targets or a different set of performance setbacks.

Also, it is common to find a reluctance to carry out ex-post evaluation due to the existence of political agendas (Smithson & Hirchheim, 1998). This is due to the perception of managers that ex-post evaluations are conducted as a “witch-hunt” to find failures and then lay blames and cause embarrassment. This results in a profound disincentive to conducting ex-post evaluations and learning from past events (Gwillim et al, 2005).

In short, project managers having a well defined understanding of what needs to be achieved to attain project success is likely to facilitate the achievement of the rather elusive target called ‘project success’. Although present literature tackles the issues of understanding the causes of IT failure and even proposes techniques to improve IT success (Wilson & Howcraft, 2002), only very few literature examine the process of defining IT project success. Also, they do not evaluate the effect of these definitions/measurements on the project outcomes (Thomas & Fernandez, 2008). Perhaps, this is due to the inconsistent nature of “success”.

2.10 RESEARCH QUESTIONS

This research study aims to provide answers for the following research questions:

To what extent does project planning effort influence project success?

What is the relationship between project success and planning quality?