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 ri