A General Overview Of IT Solutions Information

Technology Essay
ukessays.com/essays/information-technology/a-general-overview-of-it-solutions-informationtechnology-essay.php
The Cleveland Callback Project 2010, commenced due to an outbreak of domestic house fires
across the North East of England during April 2010. The investigation involved the Fire Investigation
Officers (FIOs) and Fire Prevention Officers (FPOs) WORKING on behalf of the Cleveland Fire and
Rescue Service.
The domestic fires occurred in former council owned houses which had been upgraded in the 1990s
to make them more appealing for residents to purchase. XXX Ltd. based in NEWCASTLE gained
the right to do the renovations on behalf of councils throughout the UK.
The investigations undertaken by the FIOs and FPOs revealed that the electrical component of the
central heating system that had been replaced during the refurbishment had been compromised.
The system was designed to include an automatic cut-out switch which would activate if the
electrical circuitry became overloaded and began to heat up. In most cases this system failed
completely and overheated the circuitry causing a fire. Further analysis revealed that the system
failed because of a design flaw which would result in the failure of each unit that was updated.
It quickly dawned on the Rescue Service that a potential threat awaited not only the residents of the
North East of England but the entire UK. This anxiety brought to life a major project known as the
Cleveland Callback Project.
The four main objectives of the project were to:
Identify all households upgraded by XXX Ltd. within the UK.
Contact these households by letter explaining how to identify the control unit.
In response to the letter, set up a temporary Call Centre to handle telephone calls of alarmed
households.
Arrange visits from FPOs and regional maintenance contractors to households to assess fire
potential and replace faulty control units.
To support these objectives, an IT solution was essential as the Callback Project was launched.
A department within the office of the Deputy Prime Minister known as the Fire Prevention Authority
(FPA) owned the project. From the FPA team, the Project Director was chosen by the Head of the
FPA. He spent about 40% of his time (2 days a week) on the project.
The senior figures in the FPA deemed a 3-4 month period was sufficient time to complete the project.
Hence, the go-live date was carded as Tuesday 31 August 2010.
The Finance Director and other senior figures of the FPA allocated 150, 000 as the project budget
which would cover all project costs such as, consultant and temporary call handler fees, new
hardware for the call center, APPLICATION software and call centre accommodation costs besides
any costs for Fire and Rescue personnel.
Following the decision to manage the project in-house, on the 4th May 2010 the IT Support Manager
recruited two IT Consultants (Jeremy and Taz) to WORK on the project who reported directly to
him. The two consultants were briefed with a broad overview of the project by the Project Director
and the Fire Prevention Specialist after which they immediately began to WORK on a solution, the

project was then considered live. From here on verbal progress reports would be given at regular
project meetings.
An office location was rented for the Call Centre which housed the IT consultants, Call Centre
Supervisor (Basil) and the Project Administrator (Sandy). The rest of the team was at the FPA main
building five miles away.
At a subsequent progress meeting in June, unable to meet the demands of the project, the IT
Support Manager increased the IT Consultants hours of WORK from 40 to 60 hours a week. Still
facing drawbacks with the project indicated by another progress meeting on Friday 6 August pushed
the go-live date to Monday 11 October 2010. At this time, the financial statement indicated that a
cost of 142, 450 had already been incurred. Unable to understand the unfortunate predicament of
the project, the Director of the FPA commissioned a separate expenditure account for a Project (not
IT) Consultant to be hired to perform a project audit and report to the Finance Director.
The Project Consultant began work on the 16 August 2010 by meeting with the Project Director who
referred him to the IT Consultants who knew more about the project. The IT Consultant, Jeremy then
explained the current progress of the project which left the Project Consultant with the necessary
information to develop a project audit report.

1.1 What is Project Management?

The Project Management Institute (PMI) 2008 states, Project Management is the APPLICATION
of knowledge, skills, tools and techniques to project activities to meet project requirements.
According to PMI (2008), a Project is a temporary endeavour undertaken to create a unique
product, service or result.
Project Management is process based where the processes overlap throughout the various phases
of the project. The processes are described as: Inputs, Tools and Techniques, and Outputs.1
The Project Management Body of Knowledge (PMBOK Guide) is the standard for managing most
projects across most industries. This standard outlines the project management processes, tools,
and techniques used to manage a project toward a successful outcome. This standard is a unique
guide in the project management field that is generally accepted as good practice.
For the PMI (2008), Project Management is accomplished by appropriately applying and integrating
42 project management processes which can be categorised into 5 basic process groups. The five
process groups are: Initiating, Planning, Executing, Monitoring and Controlling, and Closing. These
are explained using nine knowledge areas. They are:
Project Integration Management
Project Scope Management
Project Time Management
Project Cost Management
Project Quality Management
Project Human Resource Management
Project Communications Management
Project Risk Management
Project Procurement Management

Each of the nine knowledge areas contains the processes that need to be accomplished within its
discipline in order to achieve an effective project management program. The project audit will be
conducted using this framework.
For the PMI (2008), the role of the project manager is a challenging, high-profile role with significant
responsibility and shifting priorities. It requires flexibility, good judgment, strong leadership and
negotiating skills, and a solid knowledge of project management practices. A project manager must
be able to understand project detail, but manage from the overall project perspective. The project
manager or in this instance the Project Director is the person solely responsible for the success of
the project. In keeping with the PMBOK Guide (2008), he is in charge of all central aspects of the
project including:
Developing the project management plan and all other component plans.
Keeping the project on track in terms of the schedule and budget.
Identifying, monitoring and responding to any risk.
Providing accurate and timely reporting to project sponsors (FPA) of project scope.
Chiefly responsible for communicating with all stakeholders, particularly the project sponsor, project
team, and other key stakeholders.
It is evident in the Cleveland Callback Project that the chosen Project Director did not perform any
of the essential functions as a project manager and this was one of the first major downfalls of the
project.
Instead, a more suitable project manager should have been chosen to manage the project. As stated
by the PMI (2008), the project manager should possess the following characteristics:
Must have specific knowledge about the project management field and of the industry the project is a
part of thereby limiting any guess WORK .
Must be able to apply the project management knowledge to achieve the specific objectives to meet
performance targets on time.
Must possess personal behaviour which assists in successful completion of project. For instance,
the project manager must have an effective attitude to WORK , personality characteristics that
encompass leadership skills and the ability to motivate workers to meet the deadlines while properly
communicating all facets of the project to the important stakeholders of the project. After all, the most
essential task of the project manager is the ability to guide the project team while achieving project
objectives and balancing project constraints.

1.3 Project Organization

Projects don't just happen they are planned.1
Project organization as stated by Turner (1999) is the ability to marshal adequate resources
(human, material and financial) of an appropriate type to undertake the WORK of the project, so as
to deliver its objectives successfully. Gardiner (2005) states, it is about structuring and integrating
the internal environment through careful planning and organization design.

___________________________________
1 http://www.projectsmart.co.uk/work-breakdown-structure.html

PMI (2008) states that the way an organization is structured, its style and culture can have an impact
on the project. This is particularly useful for the Cleveland Callback project. The structure of the FPA
shows a weak matrix structure as indicated in figure 1.3 due to the fact that the Project Director
nominated by the head of the FPA was initially a member of the FPA team.
Also, the IT Support Manager was performing the Project Directors role when in fact he was a
functional manager. Hence, the FPA is operating as a traditional functional organization where the
role of the project manager is merely to coordinate the activities and not acting as a true project
manager. This created an issue of project authorization where decisions were made on behalf of the
project manager by other functional members of the team and were not beneficial to the project. In
the future, the FPA should have a proper organizational chart done that should be acted upon.
Also, the FPA should develop a strong matrix as shown in figure 1.4 where the project manager can
spend more time on the project; have full authority and a full time project management staff. As it is,
the project director is limiting the project by spending 40% of his time on the project and in charge of
a temporary contract staff which includes Sandy, Basil and the call centre staff. In the future, Maylor
(2010) asserts that the organization should have a Project Management Office (PMO) set up to
accommodate the project manager and the rest of the project team. The team should not be based
at a different location from the project manager as was done by the FPA.

Figure 1.2 Weak Matrix Organization

Source: Project Management Institute (PMBOK Guide) 2008
Figure 1.3 Strong Matrix Organization

Source: Project Management Institute (PMBOK Guide) 2008

Also, the decision making process for the time taken to complete the project and the project budget
were done utilizing a top-down approach with a centralized decision making process. For
Yale UNIVERSITY'S Victor Vroom and Philip Yetton (1970s), an organization should move away
from a directive or autocratic approach and adopt a participative approach by involving or consulting
the project team. The whole project team should develop the plan not just the project manager. This
ensures that the teams' experiences are taken into account and that everyone is fully committed and
has ownership of the plan. 2 This also ensures that the time to completion is appropriately
calculated and the budget is not over or understated. Since this was an IT project, the IT Consultants
should have been a part of the major decisions with regard to time and cost because the FPA would
not have expertise in the field of Software Development.
In developing the project audit report, the PMI (2008) framework which constitutes the five major
process groups and the nine knowledge areas of project management was referred to as the
framework that supports good project management practice. See Appendix D, Table 1.2 for an
overview of the framework.

1.4 Project Integration Management

PMI (2008) states that project integration management includes the processes and activities
needed to identify, define, combine, unify and coordinate the various processes and project
management activities within the project management process groups.

Looking at Appendix D, Table 1.3 shows the activities that the FPA should have performed in order to
carry out good project management practice and to have a well-integrated project throughout the five
main processes.
Firstly, in the initiating stage PMI (2008), there was never a project charter DOCUMENT showing
the formal authorization of the project or the initial requirements of the stakeholders (FPA)
expectations. However, the objectives were casually mentioned but the project charter serves as a
formal initiation of the project. At this stage, the project manager is chosen to allow his views on the
project to be expressed while the project charter is being developed. Also, the project manager can
make recommendations on which resources should be applied to which activities PMI (2008).
Usually the project sponsor is independent of the project team and has the duty of developing the
project charter or passing it on to the project manager. In this instance, the directors of the FPA were
the project sponsors and made all of the decisions pertaining to resource allocation in the initial
stages of the project. Therefore, it was highly unlikely that the project manager could have any input
in the project charter which was the first downfall of the Cleveland Callback Project.
On the same note, PMI (2008) states that expert judgment is need as a vital input when developing
the project charter. This expertise is used for any technical and managerial aspects of the project.
The FPA had no specialized knowledge on developing any IT software. Also, the chosen project
manager had no prior expertize in this field. So therefore, expert judgment was deficient. When the
Finance Director of the FPA realized this and mentioned, outsourcing the project to a professional
software house or exploring the procurement of a package solution she was scorned by the FPAs
IT Support Manager who assured the directors that the project would be a piece of cake and that
developing software systems was very easy compared to real work such as repairing troublesome
PCs. Therefore, in its conception the lack of expert judgment seemed to be a key weakness. The IT
Consultants; Jeremy and Taz should have been giving recommendations on the project from the
onset and other professional and technical associations, industry groups, subject matter experts and
the PMO (which was deficient as well) should have been consulted especially since it was deemed a
major project.
As soon as the project charter has been approved a more detailed DOCUMENT is prepared that
explains the project which is known as the The Project Definition Report (PD). The PD not only
provides detailed information on the project, but reports whether the project should proceed or not.
Some of the key areas it covers are the scope of the project, results of any feasibility studies, and
what it is intended to deliver. As well this document will identify the key people involved, resources
required, costs and expected duration as well as benefits to the business. 3 The FPA never
produced such a document and more importantly never did any feasibility studies. Their views were
always very optimistic. In the future, the FPA should do a SWOT analysis which was created by
Albert Humphrey (1960s and 1970s). This would evaluate the projects Strengths, Weaknesses,
Opportunities and Threats. See Appendix D, Table 1. for a SWOT analysis of the project.

____________________________________
3 http://www.projectsmart.co.uk/introduction-project-management.html
Looking at the planning stage, the PMI (2008) asserts there must be a project management plan
(PMP). In this plan the FPA should have DOCUMENTED the actions needed to define, prepare,
integrate and coordinate all subsidiary plans for the project. It states how the project is executed,
monitored, controlled and closed which is done by progressive elaboration throughout the project.

Once this plan is implemented it can only change when a change request is generated and
approved through the Perform Integrated Change Control Process. This plan encompasses all of the
five basic process groups as well as the nine knowledge areas. Figure 1.5 shows the outline of a
PMP.
The FPAs project director did not create a PMP nor did the IT consultant, Jeremy. Jeremy had
everything stored in his head. This is one of the major weaknesses of the project from its inception
since the project from here onwards depends on the PMP.
In the executing stage PMI (2008), the FPA should direct and manage project execution which is
the process of performing the WORK outlined in the PMP to achieve the projects objectives. Since
a formal PMP was not done, this directly affects the process of project integration management in
the executing stage. The activities that should have been done by the FPA include:
Performing the activities to achieve the project objectives.
Training and managing staff assigned to the project starting with the project director, IT support
manager, project administrator; Sandy and call centre supervisor; Basil.
Ensuring there are project deliverables after every project phase. A deliverable could be in the form
of a report.
Implementing the methods and standards from the PMP (assuming there was one).
Obtaining, managing and using resources such as: materials, equipment (Desktop PCs) and
facilities (Call Centre). Also, Project Management Information System software could have been
used for scheduling, costing etc.
Establishing and managing project communications channels from the Call Centre to the FPAs Main
Office located five miles away where the rest of the team remained.
Acquiring project data such as: cost, schedule, technical and quality progress and status to facilitate
forecasting.
Managing risk and implementing risk response activities.
Issue change requests and adapt approved changes into the projects scope, plans and
environment.
DOCUMENTING

lessons learned while implementing process improvement activities.

In addition, project execution requires WORK performance information about the completion status
of the deliverables which is routinely collected as the project progresses and fed into the
performance reporting process. This requires the scope, schedule and costs information which is an
input of the monitoring and controlling process group. However, the FPA has no WORK
performance measurement information which means that monitoring and controlling the project
would be compromised.
In the monitoring and controlling stage PMI (2008), there must firstly be monitoring and controlling
of project work. FPA did not track, review or regulate the progress of the project continuously to
assess if they were meeting the performance objectives. When they did at a progress meeting on
6th August, 2010 they realized it was too late by then and not much could have been done at that
point. Initially, FPA should have been monitoring the project by collecting, measuring and distributing
performance information. Control should have been exercised as a measure to know if corrective or
preventative action should take place. Time should have been monitored to ensure each project
phase was completed within the stipulated time-frame but since the project is going beyond the initial

Go-Live date then there should be further monitoring to ensure the second Go-Live date is met.
According to the PMI (2008), at the close of a sequential project phase there must be handoff of the
completed work product as the phase deliverable to start the next project phase. At this point, the
project should be reassessed to know if it should be changed or terminated completely. Therefore,
phase-end review can be conducted to authorize the end of the current phase and the start of the
subsequent one.
Furthermore, the FPA should have regular status reports at the progress meetings indicating if they
are able to complete activities to meet the milestone and forecasting to update the current cost and
schedule information.
If a PMP was done then updates could be made to know which areas needed the most resources to
be completed. The updates would be in the schedule management plan, cost management plan,
human resource plan, communications management plan, quality management plan, risk
management plan and procurement management plan.
The second aspect is Perform Integrated Change Control PMI (2008) which deals with reviewing
all change requests from inception to completion of the project. Managing change is done to ensure
the PMP, project scope statement and all other deliverables for a project are maintained by
incorporating only accepted changes. For instance, at a progress meeting in late June the IT
Support Manager authorized an increase in WORKING hours for Jeremy and Taz without a formal
change request being submitted. This increased the budget and showed that the project was running
late but due to informal change requests and invalid authorization, the project director had no idea
and hence, no change was made to the so-called PMP. Also, with the change initiated, there was no
estimation of time and cost impacts to complete the project; this would require new activity
sequencing and re-scheduling dates, resource requirements and analyzing risk response
alternatives. When approached to increase the working hours, the IT Support Manager should have
sent a formal change request for review to the Project Director.
Finally in the closing stage PMI (2008) is the close project or phase. This is where the Project
Manager would compare the project scope to the PMP to ensure all activities are complete before
officially closing the project. Unfortunately, the Cleveland Callback Project is far from completion and
cannot be closed.

1.4 Project Scope Management

For Turner (1999), project scope management includes ensuring that enough, but only
enough, WORK is undertaken to deliver the projects purpose successfully.
Prior investigation into the domestic fires created the four objectives of the project which gave the
collect requirements, (PMI 2008). Therefore, the stakeholders needs were clearly defined.
However, the project scope PMI (2008) was not clearly defined. After the FPA decided they needed
an IT solution there was no detail on the project or the product. They described the broad nature of
the system required to the consultants. The project scope statement is critical to the projects
success because it builds upon the major deliverables, assumptions and
constraints DOCUMENTED during the project initiation.
After which, the FPA should have created a WORK breakdown structure (WBS), a product
breakdown structure (PBS) along with an organization breakdown structure (PMI 2008). The WBS

subdivides the project deliverables into smaller, manageable components which is done alongside
the phases of the project life cycle.
To ensure monitoring and control, the FPA should according to PMI (2008), verify scope and control
scope. In verifying scope, the Directors of the FPA should have reviewed the deliverables
confirming it was completed satisfactorily and by doing this they would have known when the
problems began. By controlling scope, they would have managed the changes to the scope baseline
without having to take control measures at the end of the project.

1.5 Project Time Management

PMI (2008) states that project time management is the processes required to manage timely
completion of the project.
The first part of this process is to define activities in the project which was done by Jeremy through
an activity list. Although an activity list was done it did not have a detailed scope of WORK
description for each activity so that project team members knew what WORK was needed for
successful completion. In addition, a milestone list was given.
Secondly, Maylor (2010) asserts, having identified the activities through the WBS, the next step is
arranging them in a logical sequence and then estimating their time requirements. This was also
done by Jeremy however, according to the PMI (2008) for a more accurate activity duration estimate,
estimation uncertainty and risk should be considered. Moreover, if the FPA used the Program
Evaluation and Review Technique (PERT) they would have noticed that Jeremy gave an optimistic
activity duration which was misleading to them.
Thirdly, estimate activity resources was also performed by Jeremy. Lastly, develop schedule
where scheduling is the process that converts the plan into a specific set of dates for individual
activities to be started and finished, (Maylor 2010). Since this was not done, they could have
employed the use of Gantt Charts or network techniques such as, Critical Path Analysis (CPA) to
produce the schedule.
FPA should try to control schedule since leaving the schedule unchecked can result in having to
lengthen the project time. PMI (2008), the performance review tool could have been used to
measure, compare and analyze schedule performance such as actual start and finish dates, percent
complete and, remaining duration for work in progress. Using earn value management (EVM),
schedule variance (SV) and schedule performance index (SPI) or project management software
(Microsoft Project) would have shown the critical tasks such as: Prototyping, Implementation,
System Testing, Call Centre Training and Go-Live date were at risk. These were only 22% complete.
The total slack time could have been used to get the project back on track. In addition, when Jeremy
realized the project was running late and asked to increase the working hours a change request
should have been reviewed at this point by the project director. Given the approval, there should
have been project management plan updates made to the schedule baseline, schedule
management plan and cost baseline.

1.5 Project Cost Management

PMI (2008) states, project cost management includes the processes involved in estimating,
budgeting and controlling costs so that the project can be completed within the approved budget.
1.5.1 Estimate Costs:

PMI (2008) suggests when obtaining estimate costs expert judgment is always needed along with
historical data about similar projects. This was not done by the FPA. They used a top-down planning
and estimation approach.
Maylor (2010), top-down costing is done by senior management as seen in the FPA and a certain
amount of money is allocated to the entire project which needs to be split between the various
activities. Also, ballpark estimating was used which gives a rough approximation of the costs hoping
that it falls within range of the actual costs. In addition, they did not include any contingency costs.
1.5.2 Determine Budget:
The budget was also allocated by senior management using a top-down approach. Only three
project phases were thoroughly completed and the budget had almost reached the maximum. The
FPA did not use any standard budgeting techniques to obtain the figure. It was done spontaneously
and presently the budget is overstated with a significant amount of the project still to be completed.
1.5.3 Control Costs:
The FPA was not monitoring the status of the project and comparing it to the budget or managing the
changes to the cost baseline (PMI 2008). No one paid any attention to the financial statements over
the course of the project. Even when Jeremy and Taz started to WORK longer hours which
incurred further costs was not added to the budget. No monitoring was done on the actual project to
compare this to the expenditures incurred thus far.

See Appendix D, Table 1.5 for recommendations on project cost

management.
1.6 Project Quality Management
PMI (2008) states, project quality management include the processes and activities of the
performing organization that determine quality policies, objectives and responsibilities so that the
project will satisfy the needs for which it was undertaken.
1.6.1 Plan Quality:
In the project there was no DOCUMENTED plan for quality requirements or standards of the
project or the product (PMI 2008). For Maylor (2010), quality is ensuring there is stakeholder
satisfaction which the project should facilitate. However, one of the most important stakeholders of
the project (the residents affected by the defective control unit) is not provided with any sort of
quality since the project is nowhere close to completion. This is especially important since affected
residents could lose their houses and lives to the fires. Guaranteeing quality is maintained is
mandatory for this project.
1.6.2 Perform Quality Assurance:
The FPA failed to perform quality assurance practices that reduces waste and eliminates all the
processes that do not add value to the project (PMI 2008).For instance, cheap PC hardware was
bought for the call centre when this was inappropriate and a higher quality would have to be bought.
This wastage could have been eliminated from the start if better research was done. Also, eventually
they decided a project audit was needed which should have been done from the start but this action
is still necessary nonetheless.
1.6.3 Perform Quality Control:

PMI (2008) states, quality control are a continuous process that monitors the performance of
deliverables, cost and schedule. The FPA did not have a continuous process of quality control. There
was no control over the deliverables, the increasing cost only became an issue when the limit was
almost reached and there was no monitoring of the schedule to know the project was going to be
late.

See Appendix D, Table 1.6 for recommendations on project quality

management.
1.7 Project Human Resource Management
PMI (2008) states that project human resource management includes the processes that organize,
manage and lead the project team.
1.7.1 Develop Human Resource Plan:
According to PMI (2008), the FPA did not create an effective human resource plan. The project roles
and responsibilities were not documented in a formal responsibility chart. Also, there was no
establishment of reporting relationships except the IT Consultants reporting to the IT Support
Manager. There was no mention of training needs for project staff, team building strategies, plans for
recognition and rewards for the fire and rescue personnel WORKING on the project and how using
the members of the FPA to make up the project team would impact on the organization. There was
also poor human resource planning where the Project Director and IT Support Manager was not
qualified for their positions in the project.
1.7.2 Acquire Project Team:
The team was acquired in an unbiased selection process however; more consideration should have
been given to person who filled the Project Directors position.
1.7.3 Develop Project Team:
PMI (2008) states that teamwork is critical for the success of the project therefore, the project
director should have been able to motivate the team more effectively. Both the Project Director and
other senior members of the FPA such as the Director of Information Management according to
Lewin, Lippitt, & White (1939), adopted a Laissez faire leadership style where there was no
continuous feedback or supervision of project team. This failure to lead resulted in lack of control,
increase in the project budget and failure to meet the initial Go-Live date. Also, there was no team
integration. Jeremy and Taz were external staff and they were not properly integrated as part of the
project team.
1.7.4 Manage Project Team:
During the entire project, the Director did not perform any performance appraisals to ensure team
members were WORKING at their best PMI (2008).

See Appendix D, Table 1.7 for recommendations on project human

resource management.
1.8 Project Communications Management

PMI (2008) states, project communications management include the processes required to ensure
timely and appropriate generation, collection, distribution, storage, retrieval, and ultimate disposition
of project information.
1.8.1 Identify Stakeholders:
Identifying the stakeholders allows the project to the meet their needs (PMI 2008). The FPA only
identified the project sponsors and did not mention any of the other stakeholders in the project such
as: the owners of the houses with faulty control units, the media, environmental groups and other
pressure groups.
1.8.2 Plan Communications:
The FPA did not integrate a communications plan into their PMP which would ensure communication
existed between the team at the FPAs main building which included the Project Director and the
team five miles away at the Call Centre. This led to communications problems such as: delayed
progress information and lack of sensitive information to the public. There should be allocations in
the budget for a communication system and this should be revised regularly to
ensure APPLICABILITY (PMI 2008).
1.8.3 Distribute Information:
This should be done throughout the project life cycle and is especially important in the execution
process (PMI 2008). Distribution of information should have been a key activity in the weekly
progress meetings but this was not done because there was not any formal reporting of information,
in addition to, half the team (never the same 50%) ever attended (PMI 2008).
1.8.4 Manage Stakeholder Expectations:
According to PMI (2008), the project manager is responsible for managing stakeholder expectations.
This limits the risk that the project will fail to meet its goals and objectives due to any unresolved
stakeholder issues and decreases any disruptions during the project. This was not done by the FPAs
Project Director.
1.8.5 Report Performance:
The FPA did not have any formal performance reports. There was no collecting and distributing of
performance information including status reports, progress measurements and forecasts (PMI 2008).
The use of verbal progress reports employed by the team was as good as nothing. There was no
periodic analysis of the baseline data to actual data to understand and communicate the project
progress and performance as well as to forecast the results (PMI 2008). Not even a simple status
report was done to show the percent complete of the phases and the respective data for scope,
schedule, cost and quality.

See Appendix D, Table 1.8 for recommendations on project

communications management.
1.9 Project Risk Management
PMI (2008) states, project risk management includes the processes of conducting risk management
planning, identification, analysis, response planning, and monitoring and control on a project. This is
done to increase the probability and impact of positive events and decrease the probability and
impact of negative events in a project.

1.9.1 Plan Risk Management:

Software development is deemed as a high risk project and as such the FPA did not come up with a
risk management plan when forming the baseline of the project (PMI 2008). This allowed risk to be
kept unchecked.

1.9.2 Identify Risks:

There was no identification of risks done by the project manager, project team and risk management
experts. Therefore, throughout the project life cycle no risk identification was done since this is an
iterative process (PMI 2008). There were risks involved with cost, schedule, quality and scope in the
project.

1.9.3 Perform Qualitative Risk Analysis:

For Maylor (2010), the majority of risk management is based on qualitative data. Thus, the FPA did
not perform any risk analysis because the teams perception of risk was not gathered by the project
director and ranked to identify the highest risks on the project.

1.9.4 Perform Quantitative Risk Analysis:

According to PMI (2008), quantitative risk analysis follows qualitative risk analysis and is a numerical
representation of the risks involved. The FPA made no attempt to conduct a quantitative risk
analysis.

1.9.5 Plan Risk Responses:

After all the top priority risks have been identified, ways of reducing the risks are DOCUMENTED
(PMI 2008). Since the FPA made no allocations for risk there would be no planned responses to
missing the milestone, exceeding the budget and extending the project schedule. Even though they
hired a Project Consultant to audit the project as a contingency response, the implications are too far
gone and the project could fail.

1.9.6 Monitor and Control Risks:

This is done throughout the life cycle of the project to deal with any new risks that may surface.
Luckily, the FPA embarked on this process before it was too late. During a status report they realized
that a risk audit needed to be done by an external Project Consultant to analyze the costs, scope
and schedule of the project (PMI 2008).

See Appendix D, Table 1.9 for recommendations on project risk

management.
2.0 Project Procurement Management
PMI (2008) states, project procurement management include the processes necessary to purchase
or acquire products, services or results needed from outside the project team.

2.0.1 Plan Procurements:

The procurements for the project were not clearly DOCUMENTED . However, the FPA had the
option of buying the software system or building it in-house. Even though the IT Support Manager
was convinced the organization was capable of such a project further analysis and expert judgment
would have concluded that they should have bought a package solution or outsourced the project to
a professional software house. Also, due to poor procurement planning inferior PC hardware were
bought and new ones had to bought after which increased the cost.

See Appendix D, Table 2.0 for recommendations on project procurement

management.