EVALUATION OF THE I.T.

PROJECT MANAGEMENT IN
GSIS: A STUDY AND ANALYSIS OF ITS CURRENT
STATUS
Chapter I: THE PROBLEM AND ITS BACKGROUND

Background of the Study

The Government Service Insurance System (GSIS) as designed in its charter is a social
insurance institution under a defined benefit scheme created under Commonwealth Act
Number 186 that was passed on November 14, 1936, and later amended under Republic
Act No. 8291 on June 24, 1997.
Its mandate is to secure the future of all employees of the Philippine government. It
provides and administers a pension fund that has the following social security benefits:
compulsory life insurance, optional life insurance, retirement benefits, and disability benefits
for work-related accidents and death benefits.
GSIS utilizes effective Information Technology (IT) systems, tools and services to efficiently
perform its’ mandate, maximize productivity and to support and improve its services to its
members and beneficiaries. A considerable portion of its yearly budget is allocated for the
acquisition and maintenance of IT resources, building and improving IT infrastructure, and in
the design, development and maintenance of information systems required in carrying out
vital programs and support functions.

While the potential benefits and opportunities that technology can yield are widely
recognized, the organization should also understand and manage the risks associated with
implementing new technologies. Key business risks in implementing new information
systems projects include the following:

1. Inadequacy of project management procedures.

This could lead to a poorly designed system that does not meet the needs of the
business or end users, unclear responsibilities, lack of communication, inadequate
monitoring, and undetected deviations from project scope. These directly impact the
budget and timelines of the project.

2. Inadequacy of system implementation procedures.

This commonly results from poor planning, absence or insufficient user testing,
system issues not being resolved, inadequate security measures, lack of
communication, inadequately designed automated controls. These matters directly
impact on the functionality of the system, productivity and cooperation of end-users,
data integrity, completeness and accuracy and the exposure of the data/system to
unauthorized access, unauthorized disclosure or theft.

3. Return on investment or the perceived benefit are not realized or not timely realized
and the project fails to meet management’s expectations.

Among the challenges and concerns is the alignment of IT strategy with the organization’s
business strategy (i.e. how IT can be positioned to support, sustain and extend GSIS
strategies, goals and business objectives). Ideally, the projects should meet the purpose
and requirements of the process owners and users and make the IT support functions more
effective and efficient.

Management policies, standards and practices should also be in place to ensure that
selected IT projects are carried properly to ensure the success of the business operations
that it supports. Hence, this review of the IT project implementations.
Internal reports in 2015 identified that the risks to the complete and on-time implementation
of IT system development projects were primarily due to the gaps and weak controls in
project oversight and project management, particularly:
• Absence of well-defined criteria and project baseline requirements
• Absence of established process and guidelines for conducting post-implementation
reviews
• Absence of a separate and independent enterprise-wide project management office
and policy

The concerned units have formally responded and pledged their compliance to the
recommendations as a result of the said report and their compliance has been monitored
and completed. However, no study was made on whether said compliance was enough to
prevent delays or underutilization of system development projects.
Theoretical Framework
There is no explicit theory on project management. However, it is possible to find
statements from the PMBOK® Guide or the work of leading scholars on project
management that approximate the definition of a theory or from which a theory can be
deduced. This foundation can be divided into a theory of project and a theory of
management.
Table 1: The underlying theory of project management

The theory of project is provided by the transformation view on operations. In the

transformation view, a project is conceptualized as a transformation of inputs to outputs.
There are a number of principles, by means of which a project is managed. These principles
suggest, for example, decomposing the total transformation hierarchically into smaller
transformations, tasks, and minimizing the cost of each task independently. The
transformation view has its intellectual origins in economics. The popular value chain theory,
proposed by Porter (1985), is one approach embodying the transformation view. An explicit
production theory based directly on the original view on production in economics has been
proposed by a group of scholars led by Wortmann (1992). However, mostly the
transformation view has been implicit—so embedded in thinking and practice that it has
formed the basis of an invisible, unspoken paradigm that shapes behavior.
The PMBOK® Guide divides project management processes into initiating, planning,
execution, controlling, and closing processes. Let us concentrate on the core processes of
planning, execution, and controlling (Exhibit 1). A central idea is that these processes form a
closed loop: the planning processes provide a plan that is realized by the executing
processes, and variances from the baseline or requests for change lead to corrections in
execution or changes in further plans.
Exhibit 1. The Closed Loop of Managerial Processes in Project Management
according to the PMBOK® Guide
The Theory of Planning
The planning of projects is thoroughly described from the point of view of different
knowledge areas in the PMBOK® Guide. The planning processes are structured into core
processes and facilitating processes. There are ten core processes: scope planning, scope
definition, activity definition, resource planning, activity sequencing, activity duration
estimating, cost estimating, schedule development, cost budgeting, and project plan
development. The output from these processes, the project plans, make up an input to the
executing processes.
The planning processes dominate the scene in the PMBOK® Guide: in addition to the ten
planning processes, there is only one executing process and two controlling processes. The
emphasis is on planning, with little offered on executing especially.
Comparison to theories in the general field of operations reveals that the perspective is that
of management-as-planning (Johnston and Brennan 1996). Here, it is assumed that the
organization consists of a management part and an effector part. Management at the
operations level is seen to consist of the centralized creation, revision, and implementation
of plans. This approach to management views a strong causal connection between the
actions of management and outcomes of the organization. By assuming that translating a
plan into action is the simple process of issuing “orders,” it takes plan production to be
essentially synonymous with action.
The Theory of Execution
How is the project plan executed? On this aspect, the PMBOK® Guide is puzzlingly brief-
worded. The only direct reference to the actual interface between plan and work is with
regard to work authorization system, which is presented by four sentences:
A work authorization system is a formal procedure for sanctioning project work to ensure that
work is done at the right time and in the proper sequence. The primary mechanism is
typically a written authorization to begin work on a specific activity or work package. The
design of the work authorization system should balance the value of the control provided
with the cost of that control. For example, on many smaller projects, verbal authorizations
will be adequate.

The underlying theory of execution turns out to be similar to the concept of job dispatching in
manufacturing where it provides the interface between plan and work. This concept can be
traced back to Emerson (1917). The basic issue in dispatching is allocating or assignment of
tasks or jobs to machines or work crews, usually by a central authority. According to a
modern definition, job dispatching is a procedure that uses logical decision rules to select a
job for processing on a machine that has just come available (Bhaskaran and Pinedo 1991).
Obviously, dispatching consists of two elements: decision (for selecting task for a
workstation from those predefined tasks that are ready for execution), and communicating
the assignment (or authorization) to the workstation. However, in the case of project
management, that decision is largely taken care in planning, and thus dispatching is reduced
to mere communication: written or oral authorization or notification to start work. Here, the
underlying theory seems to be the classical theory of communication (Shannon and Weaver
1949), where a set of symbols (voice or written speech) is transmitted from sender to
receiver.
The Theory of Controlling
The PMBOK® Guide divides the core process of controlling into two sub-processes:
performance reporting and overall change control. Based on the former, corrections are
prescribed for the executing processes, and based on the latter, changes are prescribed for
the planning processes.
Here we consider only performance reporting, based on performance baseline, and
associated corrections to execution. They clearly correspond to the cybernetic model of
management control (thermostat model) that consists of the following elements (Hofstede
1978):
• There is a standard of performance.
• Performance is measured at the output (or input).
• The possible variance between the standard and the measured value is used for
correcting the process so that the standard can be reached.
This thermostat model is identical to the feedback control model as defined in modern
control theory (Ogunnaike and Ray 1994).
In summary, project management seems to be based on three theories of management:
management as planning, the dispatching model, and the thermostat model. Management-
as-planning has been the widely held—even if most often implicit—view on intentional action
in organizations up to now (Johnston and Brennan 1996). The dispatching model, closely
associated with management-as-planning, has been common in industrial engineering from
the beginning of the 20th century. Likewise, the thermostat model has been the dominating
view on management in the 20th century (Giglioni and Bedeian 1974). These ideas were all
current when project management emerged. Together they form the theoretical foundation of
present management practice.
Conceptual Framework
Project management means exactly what the two terms suggest. It is effectively working to
coordinate and manage individuals to work towards a common goal or objective to complete
a task. Project management requires that one apply their personal knowledge, skills, tools,
and techniques towards an activity in order to meet the requirements of a project assigned.
Project management involves planning, scheduling, and controlling of all of the combined
activities in order to ensure successful completion of project objectives. There are three
concepts that are part of any project no matter what type of project is being worked on.
These three concepts include project processes, project life cycles, and project management
systems.
Project processes are essentially the organizing tool of project management. Understanding
the project process means understanding who is responsible for performing a certain
process and during what phase of the project process activity should be performed.
There are five project process phases:

 The first is the initiative process. In this phase, the project is approved and
brainstorming occurs to find the best available way to complete the project.
 The second project process phase is the planning process. In this phase, objectives
and goals of the overall project completion are defined and refined in order to ensure
the goals are achievable and realistic.
 The third project process phase is project execution. This is the part of the project
management phase where activity to complete the project is actually carried out.
 The fourth project process is actually carried out through the duration of the entire
management process. This is the controlling process and in this part of the process,
the project manager ensures that the project is on track to completion by a certain
deadline.
 The final project process phase is the wrap-up process. In this phase of the project
process, the project comes to an end. The project manager is responsible here for
wrapping up the entire process.

Project Life Cycle

No matter what the specifics of the project, every project has a project life cycle. The project
manager must successfully understand and navigate through each phase of the project life
cycle to ensure successful project completion. There are four phases in every project life
cycle. The first phase is the concept phase. This is the phase where hard evidence such as
graphs, charts, statistics, and other hard data is analyzed to help with successfully
completing the process. The next phase in the project life cycle is the planning phase. In this
part of the project life cycle, the project team along with the project manager decides how to
best complete the project and develops a plan for that completion. The following phase is the
execution phase. This is the part of project management where the plan for completion is
actually carried out. The final phase of the project life cycle is the closeout. In the closeout
part of the phase the project comes to an end and the project team parts ways to complete
other projects waiting in the wings.
Project Management Systems
The last key concept or component of project management is understanding project
management systems. Project management systems entail knowing all of the components of
project management. These components include the human component, the cultural
component, the organizational component, the methodological component, the information
component, the planning component, and the control/management component.
In order for the project to be managed successfully, the project manager and the project
team alike must understand the human component. This means that they must know how to
deal with people and understand “people issues." They must be skilled in the art of
negotiation, interpersonal communication, motivating, team-building, and politics to a
degree. In order to successfully manage a project, a project manager must be skilled in the
concept of understanding cultural components that may exist on his or her project team. This
includes knowledge and acceptance of different cultural beliefs, values, attitudes, behaviors,
and traditions that may be present within the project environment.
Understanding the organization component means knowing how to manage, organize, and
hold others accountable for project completion. Knowledge of the methodological component
is successful also for project completion. This entails having knowledge about the tools
available to the project team that can help keep track of budgets, schedules and things of
this nature during the project life cycle.
The information component is essential to capturing the knowledge of the project. This
entails recording the process of project completion so everyone is on the same page. The
recording of the information can also help to complete projects in the future of a similar
nature. Knowledge of how to plan the project is also extremely important to project
completion. Without a plan, the project is like a sailboat lost in a typhoon; it has no particular
direction and no way to get to a certain point even if the direction were provided. Therefore,
knowing how to plan is a key concept to any type of project management task.
Lastly, the control or management component is absolutely essential. After all, what is a plan
without some sort of management or control to steer it in the right direction and ensure the
project stays on course. Therefore, this is an essential concept of project management.
Without this concept, even with a good plan a project could be led astray never to return
back on track. Knowing how to take charge and when to take charge is absolutely
imperative.
Statement of the Problem
The study aims to determine the:
1. Status of IT Projects (Assets Under Construction) included in the GSIS Annual
Procurement Plan (APP) for Fiscal Years 2016 to 2018;

2. Compliance with existing guidelines, processes and procedures in the

management of IT projects from Fiscal Years 2016 to 2018.

Hypothesis
If the GSIS Information Technology Services Group and the concerned units complied with
the selected recommendations from the internal report on IT project management, then the
risk of delays and/or underutilization of projects will be mitigated.

Scope and Limitations of the Study

The review covered the evaluation of the status as of December 31, 2018 of projects that
were included in the GSIS Annual Procurement Plan (APP) for the years 2016-2018. Per
record, the number and approved budget of ITSG projects recorded under “Asset Under
Construction” (AUC) which were included in the APP for the Fiscal Years 2016 to 2018 are
summarized below:

Table 1: Annual Budgets for the Years 2016, 2017 and 2018

The evaluation and review of ITSG projects were limited to the available procurement
documents from GSIS Bids and Awards Committee (GBAC) and project records from ITSG.
The nature of procurement e.g. goods and services or consulting were lifted/based on the
GBAC classification.
Significance of the Study
The Government Service Insurance System (GSIS) is committed to provide quality service to
its members, pensioners, and other constituents for all their social security benefits and non-
life insurance needs. For this to be possible, GSIS relies heavily on Information Technology
for the delivery of efficient, secured and timely services to all its members and pensioners.
The management of IT projects should be appropriately and effectively designed to enable
continuous delivery of services. Failure to do so could lead to delays in implementation of
necessary upgrades/updates to the system which could adversely affect the quality of its
services. An effective assessment of the current status of IT project management will enable
GSIS officials to make the necessary and rightful decisions as to the administration of IT
resources.
Definition of Terms
APP – Annual Procurement Plan
Asset under Construction (AUC) – these special form of tangible assets. They are usually
displayed as a separate balance sheet item, requiring separate account determination and
their own asset classes. During the construction phase of an asset, all actual postings are
assigned to the AUC. Once the asset is completed, a transfer is made to the final fixed
asset.
Information Technology (IT) – the technology involving the development, maintenance,
and use of computer systems, software, and networks for the processing and distribution of
data.
PMBOK® Guide – PMBOK stands for ‘Project Management Body of Knowledge’. It provides
guidelines for managing individual projects. It defines project management and related
concepts and describes the project management life cycle and related processes.
Project Life Cycle – the Project Life Cycle refers to the four-step process that is followed by
nearly all project managers when moving through stages of project completion. This is the
standard project life cycle most people are familiar with. The Project Life Cycle provides a
framework for managing any type of project within a business. Leaders in project
management have conducted research to determine the best process by which to run
projects. It has been found that following a project life cycle is critical for any services
organization.
Project Management – is the practice of initiating, planning, executing, controlling, and
closing the work of a team to achieve specific goals and meet specific success criteria at the
specified time. The primary challenge of project management is to achieve all of the project
goals within the given constraints.
Chapter 3: RESEARCH METHODOLOGY

Method of Research

Description of Respondents

The research procedures were done in coordination with the following operating units of
GSIS:

1. Information Technology Services Group (ITSG) - responsible for the management

of the overall Information and Communication Technology services of GSIS. ITSG is
in charge of defining the technology roadmap through research and development of
which to continuously improve the IT services. It ensures that all IT requirements of
the various stakeholders are complied with.

2. GSIS Bids and Awards Committee (GBAC) – responsible for advertising/posting

the invitation to bid/request for expression of interest; conduct of pre-procurement
and re-bid conferences; determining the eligibility of prospective bidders; receiving
bids; evaluating bids; undertaking post-qualification proceedings; resolving motions
for reconsideration and protests; recommending awards of contracts to the Head of
Procuring Entity (HOPE) or his duly authorized representative, and ensuring that
GSIS abides to the standards set forth by RA 9184 and its RIRR.

3. Materials Management Department (MMD) – responsible for planning, organizing

and controlling the flow of materials from their initial purchase through internal
operations to the service point through distribution.

4. Controller Group (CG) - responsible for the recording and reporting of all GSIS
financial transactions in accordance with the Philippine Financial Reporting
Standards and government and accounting and auditing rules and providing analysis
thereon; the preparation of the proposed GSIS Operating Budget, and the
administration and control of the approved budget; as well as the maintenance of
Financial Information Systems Module.

Research Instrument
Evaluation and analysis of the compliance to recommendations for the improvements to the
management of IT projects was performed. Interviews with concerned ITSG and GBAC
personnel directly or indirectly involved in the project, project users, document custodian and
the business process owners/users were conducted when deemed necessary.

Data-Gathering Procedure

The procedures included obtaining the records and understanding the proposed projects for
the years 2016-2018 from the Information Technology Services Group (ITSG), GSIS Bids
and Awards Committee (GBAC), Materials Management Department (MMD), and the
Controller Group (CG). Evaluation of IT policies and processes which are relevant to the
procurement of ITSG and ISO projects was performed.
Chapter 4: PRESENTATION, ANALYSIS, AND INTERPRETATION OF DATA

As per accounting records, the number and approved budget of ITSG projects recorded
under “Asset under Construction” (AUC) which were included in the GSIS Annual
Procurement Plan (APP) for the Fiscal Years 2016 to 2018 are summarized below:

Table 1: Annual Budgets for the Years 2016, 2017 and 2018

A previous 2015 internal report stated that the common source of delays for the application
system development projects is the finalization of business requirements.
“Per verification, business requirement specifications identified as part of
the Terms of Reference (TOR) in the procurement of the project mostly
contain general statements regarding the application system to be
developed or enhanced. The detailed business requirements and
specifications are obtained by the vendor during project implementation. As
such, the requirements gathering and analysis based on business users’
needs, and the design phases are compressed in the limited project
duration. In most instances, the business requirements continuously change
even in the development and user acceptance testing stage. This is the
common cause of scope creeping and delays in project development
projects.”

The report also cites the following reasons for delays, based on interviews validated by
inspection of available documents:
Attributable to the Organization
1. Additional/Changes in business
requirement or required deliverable
2. Dependency to other project or system
3. Extension / Additional Testing activities
4. Testing activities (QAD and ISO) not
previously considered
5. Performance Tuning as required by GSIS
6. Additional Training Requirement
7. Post Implementation activities requirement
8. IT Infrastructure/ IT Applications Issues
Attributable to Vendors
1. Failure in data gathering, workflow
documentation, unit testing and developing
of scripts
2. Failure in the implementation of the
Project
3. Late delivery of Hardware and Software
Components
4. Delay in the installation and configuration
of HW/SW
5. Late submission of required project
documentation
To address the causes of delays in future projects, the same report recommended that the
project proponents:
1. Require business process owners to coordinate with the project
managers in the preparation of detailed business requirements for
new or major system enhancements after the proposed project has
been approved. The business requirements and specifications should
be discussed, prepared in detail, and signed off even before the
project is procured.
2. Use the business requirements and specifications as one of the bases
by ITSG to estimate the required man-days and the adjusted project
cost that should be allocated to the project.
3. Revisit previous project implementations, relevant training
documentations and industry experiences on IT project implementations
and, based on the information gathered, prepare a guide in the
determination and preparation of pertinent project information for
inclusion in the project Terms of Reference (TOR) such as the duration,
baseline requirements and estimated cost of a proposed project.
4. Require key personnel performing project management functions to
attend project management trainings to enhance their skills and
competencies;
5. Require Project Managers to strengthen monitoring mechanisms to
ensure timely completion of projects or to enable early detection of
delays and recommend remedial measures or request for project time
extensions.
6. Ensure that project timelines and resource requirements (e.g. hardware
and personnel for testing) are properly planned, scheduled and
coordinated with the concerned units. Potential schedule slippage
should immediately be coordinated to enable the units to make the
necessary adjustments.
7. Ensure that estimated duration for Quality Assurance, post-
implementation reviews and related activities be included in the
Terms of Reference (TOR) and properly taken into account in
determining project duration.

From 2016 to 2018, seventeen (17) procured information technology projects have been
implemented. Out of these only two were delayed.
Project Project Type Expected Actual No of Remarks
No. Date of Completion Days
Completion Date Delayed
1 Infrastructure - Hardware 4/8/2017 3/15/2017 -24 Complied
2 Infrastructure - Hardware 2/11/2017 2/10/2017 -1 Complied
3 Infrastructure - Hardware 7/5/2016 6/14/2016 -21 Complied
4 Infrastructure - Hardware 8/27/2016 8/25/2016 -2 Complied
5 Infrastructure - Hardware 9/2/2016 6/10/2016 -84 Complied
6 Infrastructure - Hardware 9/4/2016 6/11/2016 -85 Complied
7 Infrastructure - Hardware 3/4/2017 12/16/2016 -78 Complied
8 Infrastructure - Hardware 7/25/2017 5/17/2017 -69 Complied
9 Infrastructure - Hardware 12/18/2017 11/28/2017 -20 Complied
10 Infrastructure - Hardware 5/3/2017 3/30/2017 -34 Complied
11 Infrastructure - Hardware 6/21/2017 4/26/2017 -56 Complied
 12 Infrastructure - Hardware 8/5/2017 6/19/2017 -47 Complied
13 Infrastructure - Hardware 9/7/2018 9/3/2018 -4 Complied
14 Infrastructure - Hardware 10/15/2018 10/15/2018 0 Complied
15 Infrastructure - Hardware 6/22/2018 6/22/2018 0 Complied
16 Infrastructure - Hardware 11/28/2016 1/9/2017 42 Delayed
17 Sofware Development 3/31/2018 5/30/2018 60 Delayed
18 Sofware Development 6/28/2019 OG Delayed
18 Infrastructure - Hardware 2/20/2019 12/28/2018 -54 Complied
19 Infrastructure - Hardware 3/27/2019 1/17/2019 -69 Complied
20 Infrastructure - Hardware 2/2/2019 12/21/2018 -43 Complied
21 Infrastructure - Hardware 1/15/2019 12/28/2018 -18 Complied

To test the hypothesis that compliance to the recommendations issued would prevent delays
in project implementation, the following procedures were performed:
1. Conduct an understanding of the project management procedures from the ITSG
Project Management Manual and existing project documentation;
2. Formulate test attributes from the project proponents’ responses to the
recommendations.
3. Inspect each project’ set of project documentation whether the said document exists
or whether the action described was performed.
4. Document the results of the inspection.
5. Assess whether the hypothesis is true or not based on the following criteria: For
every existing document or documented plan of action, the risk of delayed project
implementation is lowered.

Upon reading and understanding the project management manual, the test attributes
translated from the recommendations are as follows:
Recommendation No. Test Attribute
1 Require business process owners to coordinate with Detailed business
the project managers in the preparation of detailed requirements are found in the
business requirements for new or major system Terms of Reference and are
enhancements after the proposed project has been approved prior to project
approved. The business requirements and planning.
specifications should be discussed, prepared in detail,
and signed off even before the project is procured.
2 Use the business requirements and specifications as No. of Man-days required are
one of the bases by ITSG to estimate the required computed based on detailed
man-days and the adjusted project cost that should be business requirements.
allocated to the project.
3 Revisit previous project implementations, relevant Instructions in the preparation
training documentations and industry experiences on IT of the TOR can be found in
project implementations and, based on the information the Project Management
gathered, prepare a guide in the determination and Manual
preparation of pertinent project information for inclusion
in the project Terms of Reference (TOR) such as the
duration, baseline requirements and estimated cost of
a proposed project.
4 Require key personnel performing project management Project managers have
functions to attend project management trainings to project management training
enhance their skills and competencies; certificates.
5 Require Project Managers to strengthen monitoring Project status is updated in
mechanisms to ensure timely completion of projects or the system for project
to enable early detection of delays and recommend management and status
remedial measures or request for project time reporting.
extensions.
6 Ensure that project timelines and resource Communication and
requirements (e.g. hardware and personnel for testing) escalation plans are included
are properly planned, scheduled and coordinated in the project management
with the concerned units. Potential schedule slippage plan.
should immediately be coordinated to enable the units
to make the necessary adjustments.
7 Ensure that estimated duration for Quality Assurance, Activities in testing, quality
post-implementation reviews and related activities assurance, and post-
be included in the Terms of Reference (TOR) and implementation reviews are
properly taken into account in determining project included in the Technical
duration. Specifications of the Bid
Documents and the project
management plan.

Please see Appendix XX for the results.

Our procedures resulted showed that all projects complied with the
recommendations cited above. However, after monitoring each project’s progress
up, two projects resulted in delayed implementation and one is still currently on-
going.

The reasons based on documents inspected and interview performed are as follows:
Project No. Project Type Reason for Delay
16 Infrastructure - Hardware
17 Software Development Complexity in module that
was unanticipated due to
difference in description
18 Software Development No proper turnover during
change in leadership

The following should also be noted:

- There is still no standard level of detail in creating business requirements.
- Number of man-days required for each project depends on estimates and
projections by interested vendors. There are no clear-cut baseline per
requirement or requirement type, i.e. function, program, etc.
- Communication and escalation plans are included in the project management
plans for each project but changes and updates are communicated less
formally, through emails and minutes of meetings.
- Our procedures did not measure the skills and attitudes of project managers.
However, the current policy recognizes project management as “other
 activities”, adding to the risk of less focused monitoring of project
implementation.

Conclusion:
Based on the inspection of projects implemented from 2016 to the first quarter of 2019, If the
GSIS Information Technology Services Group and the concerned units comply with the
selected recommendations from the internal report on IT project management, then the risk
of delays and/or underutilization of projects can be mitigated.

Recommendations:
The procedures performed in this study are limited and may require additional in-depth
validation with team members outside of the IT group. Hence, the following
recommendations:
- The current project management manual and processes should be improved
based on the information and experience from past projects
- Post-implementation audits should be conducted for each project to discover
root causes for delays and good practices that resulted in on-time, and even
early implementation.
- Management should explore the possibility of establishing a separate project
management unit with sole purpose of project oversight
- .

Sources:
https://iglcstorage.blob.core.windows.net/papers/attachment-8ef324db-750a-40c3-9c17-
273db32b54e2.pdf

https://www.pmi.org/learning/library/underlying-theory-project-management-obsolete-8971

https://www.brighthubpm.com/project-planning/53125-key-concepts-in-project-management/