The Republic of Uganda - NITA IT... · Many fail at inception stage, others are not delivered on...

The Republic of Uganda

National Information Technology Project Management Methodology (NITPMM)

August, 2013

Version 0.6

i. National IT Project Management Methodology Version 0.6 Page 2

Document Version Control

Version Date Author Change Description

V 0.1 – 0.4 Jun 2013 Taskforce First Draft

V 0.5 July Taskforce Incorporated comments from consultative

and validation workshop

V 0.6 August Taskforce Included Quality Assurance and Control

function in the governance structure


Table of Contents

LIST OF ACRONYMS 5

LIST OF TABLES 6

LIST OF FIGURES 7

FOREWORD 8

ACKNOWLEDGEMENT 10

1. INTRODUCTION 12

Readership of the Methodology 12

Rationale of the IT Project Management Methodology 13

Objectives 13

Benefits of the Methodology: 14

Differentiating IT Project from Operational Activities 15

Project Classification 16

2. IT PROJECT MANAGEMENT FIT IN MDAS STRUCTURES 18

IT Project Management Concepts in MDAs 18

IT Project Governance 19

Project Organization and Reporting Structures 20

Project Key Stakeholders, Roles and Responsibilities 22

Project Personnel Competencies and Knowledge Areas Required 23

3. IT PROJECT MANAGEMENT METHODOLOGY 24

IT Project Management Methodology 24


Project Management Methodology User Interface 25

Programme and Project Management 25

Information System Acquisition 26

Project Lifecycle 28

Project Initiation Process group 29

Project Planning Process Group 31

Project Execution Process Group 32

Monitoring and Controlling Process Group 33

Project Closure Process Group 33

Project Management Tools and Techniques at each Stage 34

Operations and Maintenance (Transition to Support) 35

Project Documentation Management 36

Stage Gates Checklist 39

4. PROJECT INFORMATION SECURITY COMPLIANCE 42

5. PROJECT MANAGEMENT SUPPORT GUIDES 43

6. PROJECT MANAGEMENT SUPPORT TEMPLATES 46

7. PROJECT MANAGEMENT MATURITY MODEL 50

8. CODE OF ETHICS AND PROFESSIONAL CONDUCT 51

9. GENERAL PROJECT SUCCESS FACTORS 54

10. GLOSSARY 56

11. REFERENCES 58


List of Acronyms Acronyms Description

ISO International Standard organization

IT Information Technology

MDA Ministries, Departments and Agencies

NITA-U National Information Technology Authority in Uganda

PIP Project Implementation Plan

PIT Project Implementation Team

PIR Post Implementation Review

PM Project Manager

PMO Programme Management Office

SC Steering Committee

TMT Top Management Team

TOR Terms of Reference

WBS Work Breakdown Structure


List of Tables Table Description

1 Differentiating IT Projects from IT Operations

2 Description of Project Life Cycle Process Group

3 Sample Project Management Tools and Techniques used at each Project Stage

4 Initiation Stage Activities and Required Documentation

5 Planning Stage Activities and Required Documentation

6 Execution and Control Stage Activities and Required Documentation

7 Closure Stage Activities and Required Documentation

8 Stage Gate 1: From Initiation to Planning Stage

9 Stage Gate 2: From Planning to Execution Stage

10 Stage Gate 3: Execution to Closure Stage

11 Stage Gate 4: Closure Stage Support Stage

12 List and Description of Project Support Guide

13 List and Description of Project Templates

14 Description of Project Management Model


List of Figures Figure Description

1 Overview of IT Project Management Concepts in MDAs Environment

2 IT Project Governance Structure for Projects in a single MDA

3 IT Project Governance Structure for Projects involving Multiple MDA

4 IT Project Management Methodology

5 Project Management Maturity Model


Foreword The Government of Uganda has invested a lot in a number of IT related projects, however many of these

projects have not been delivered as expected. Many fail at inception stage, others are not delivered on time

and those which get delivered don’t meet expected objectives. Furthermore, the successful delivery of IT

projects in Government is critical in supporting strategic Government plans and service delivery to citizens.

In order to mitigate these challenges and meet the mandate to provide advice on IT Project Management

services to Government, National Information Technology Authority in Uganda (NITA-U) has developed this

National IT Project Management Methodology to provide guidance on how to manage IT projects from the

start to completion.

This methodology provides a structured approach to manage IT projects and programmes within

Government. It provides essential components of planning and management of IT projects and highlights

good practices that should be applied throughout the IT project lifecycle.

While these guidelines are relevant to all IT projects and or programmes regardless of their size and

complexity, they will require a high level of judgment from the users. The guidelines provide a starting point

to establish the project context, gain formal agreement to proceed and for considering the project

management methodology that is relevant to IT projects. It is built on the collective knowledge and

experience of IT project management professionals working within Government; and is intended to provide

guidance they could have provided on a consultancy basis. Project management support guides and

templates are also developed to further provide detailed guidance to users and ensure standardization. The

methodology also reflects on lessons learned from major Government IT projects implemented in the past.

These key learnings included the management of small and large projects and or programs and a move

towards adopting Project / Program Management practices within MDAs.

A taskforce, which included experienced project management professionals and practitioners in

government and private sectors, provided input during the development of this methodology. Join me to

thank the team for coming up with this first version.


NITA-U will periodically establish a Review Group that will review this National IT Project Management

Methodology (NITPMM) to reflect changes in IT project maturity levels at MDAs, policies and procedures, as

well as rules and regulations from the Government of Uganda.

The review process will involve all stakeholders through a participative process. Hence, the NITPMM is a

living document that can accommodate changes in conditions.

I am pleased to introduce the National IT Project Management Methodology Version 1, 2013 which is one of

the most vital tools for MDAs who wish to successfully deliver their IT projects and or programmes. Please

take time to look through this methodology, use it as your quick reference guide and as a supplement to the

training you will receive.

Many thanks,

James Saaka

Executive Director, National Information Technology Uganda


Acknowledgement The following people provided professional expertise and time during the development of this methodology. If it was not for their dedication this version could not have been available at this time. They deserve to be acknowledged for their contributions.

No. Name Designation Institution Role & Responsibility Towards Methodology Development

1 James Saaka Executive Director NITA-U Project Sponsor 2 Dr. Fredrick E. Kitoogo Director Planning,

Research & Development

NITA-U Project Owner

3 Abdul Nsubuga, PMP. Programme Manager NITA-U Project Manager / Content Developer

4 Peter Kahiigi, CISM, CISSP Director Information Security

NITA-U Project Quality Assurance

5 Gerald Kisongoch, PMP, RMP. Programme Officer NITA-U Content Developer

6 Rachel Nyatworo Programme Officer NITA-U Content Developer

The following project management professionals were assembled and formed a taskforce which peer reviewed the methodology to the current quality. We thank them for their expertise and time. No. Name Designation Institution 1 Samuel Baguma, PMP. Ass. Commissioner , MIS MOFPED 2 Ambrose Ruyooka, PMP. Ag Commissioner MOICT 3 Allan Kiwumulo Ag Manager MIS UNRA 4 Opio Nockline Manager IT Infrastructure URA 5 Petra Najjuka, PMP. Project Management Consultant LAP Marketing Consultants 6 Musa Musazi, PMP. Project Manager Warid Telecom During e-Government survey a number of MDAs indicated that they had a project management methodology they were following in delivering their IT projects. With that information, a targeted consultative workshop was organized for the following institutions; and their experts provided input to the process. We acknowledge their contributions and expertise they shared during the development of this methodology. No. Name Designation Institution

1 Monica Nyakaisiki Manager IT PPDA

2 Collin Babirukamu Head of IT / CIO NSSF

3 Patrick Ndahura Auditor OAG


4 Eric Kagoda Principal Officer, Data and Information Analysis

UNBS

5 Charlotte Tinaruhanga IT Officer State House

6 Jackie Namyalo System Admin NPA

7 David Kikabi ICT Manager Judicature

8 Herbert Wamboko Head, IT Electoral Commission

9 Martin Ssekajja Manager IT KCCA

10 Julian Rweju Business Analyst NITA-U

11 Philip Walera Manager, Architecture, Standards and Certification

NITA-U

Finally, validation workshop was organized and many senior IT personnel from MDAs participated and provided input. We acknowledge all their contributions and time towards the finalization of this version.


1. Introduction National Information Technology Authority - Uganda (NITA-U) was established by the Act of Parliament

(National Information Technology Authority, Uganda Act of 2009) and was operationalized in 2010. The

authority is charged with an overall mandate to coordinate, promote and monitor the development of

Information Technology (IT) in the context of social and economic development of Uganda. Among the

main functions of the authority is to provide advice on IT Project Management services to Government.

In order to operationalize this function, NITA-U set up a Programme Management Office (PMO)

department with the following objectives among others:

a. To develop a Project Management Methodology and Guidelines that would be used for IT Projects

in Government Ministries, Departments and Agencies (MDAs)

b. To set up governance models that would support the methodology

c. To provide IT Project Management support to MDAs

It is with this background that this IT Project Management Methodology has been developed. Project

management support user guides and templates are also available to provide detailed guidelines to IT

project stakeholders involved in IT project work in government.

Readership of the Methodology

1.1.1. This methodology provides guidance on concepts, processes, tools, governance and good

practices in IT project management that are important for, and have impact on, the

performance of IT projects in government.

1.1.2. The target readership for this methodology will include among others the following key

stakeholders:

a. Accounting Officers in Ministries, Departments and Agencies (MDAs)

b. Top Management Teams (TMT) at MDAs and project sponsors, in order to provide them with

a better understanding of the principles and practice of IT Project Management and to help


them give appropriate support and guidance to their project managers, project management

teams and project teams;

c. Programme Managers, Project Managers, Project Management Teams and Project

Implementation Teams, so that they have a common basis upon which to carry out IT project

work successfully.

d. Key stakeholders such as IT Development Partners, Suppliers, Contractors or Consultants

for use as a reference framework when involved in IT projects work within government

Rationale of the IT Project Management Methodology

1.1.3. IT project management in government have traditionally relied upon the individual strengths

of project managers (in many cases contract managers) to plan and execute a variety of

simultaneous IT projects. Project management expertise currently varies by team, with each

relying upon its own unique project management approaches and tools. While this has served

government relatively well in the past, we have reached a critical point where the number of IT

projects in government, coupled with the necessity to share resources across multiple projects,

has created the need for a more formal and structured approach to managing IT projects and

ensure that they are delivered on time, within budget and desired quality.

1.1.4. Out of the total National Budget, 25% of the funds are allocated to projects and programmes;

and some are IT related projects. However, there is no defined methodology to guide in the

implementation of such investments.

Based on the above background, this methodology is developed to provide guidance on

processes, procedure, best practices and standards in planning and managing IT projects to

achieve the intended national benefits.

Objectives

The methodology should assist all stakeholders who are involved in IT projects and or programmes in

government to successfully and repeatedly manage their IT projects end-to-end within a structured

and systematic approach.


The objectives of this methodology include the following among others:

a. Improve IT projects delivery success rate

b. Establish a secure structured Process - Provide a common, structured approach for initiating,

planning, executing, controlling and closing projects

c. Promote Consistency - Produce project management documents that are consistent across all IT

projects, thereby simplifying their management

d. Improve Resource Management – Outline the resources required for an IT project thereby

enabling MDA to better manage resources

e. Streamline and simplify IT project quality management and control practices

f. Make sure all IT projects follow regulatory, legislative and government compliance processes

g. Ensure proper planning with focus on key aspects like quality, risk management and change

management.

It is important to note that this methodology will work within the existing national legal, regulatory and

policy framework.

Benefits of the Methodology:

1.1.5. Using this methodology will bring several benefits and in turn offer a consistent, systematic

and repeatable approach that will:

i. Improve IT projects delivery success rates; and facilitate MDAs to realize

expected benefits; and minimize dependency to specific staff

ii. Align IT projects and programmes to ensure delivery within the expected

timelines, approved budgets and required quality

iii. Enhance interaction within stakeholders and help in aligning of stakeholders

roles and responsibilities

iv. Enable stakeholders use the same language while managing project work, thus

providing project and or programme managers and decision-makers with better

information for reporting, planning and decision marking


v. Provide project and or programme managers, project management teams,

decision makers with better information for reporting and planning

vi. Enhance economy and value for money in utilization of public resources in

critical IT projects

vii. Enhance accountability and transparency in IT project delivery, and

viii. Promote learning and continuous improvement in project documentation,

which will act as lessons for future projects

1.1.6. This methodology can be used for all types of initiatives and can be easily scaled according to

the size or complexity of the initiative. Before employing the IT Project Management

Methodology, however, users must assess whether the initiative under consideration is an IT

project or simply an operational activity.

Differentiating IT Project from Operational Activities

1.1.7. Most IT work in MDAs is defined as either a project or an operation. However, determining

this can be a challenge given that many routine, operational IT activities share characteristics

with projects but are not technically IT projects.

1.1.8. The first question a user of this methodology needs to ask and answer is, “Does this work or

initiative qualify as an IT project?” At the heart of the question is whether the initiative is

unique and temporary. In general, unique initiatives are not repeated and thus not routine or

operational in nature. If the initiative is not unique, then it is not an IT Project and the IT Project

Management Methodology does not govern the initiative–even though applying project

management technique may improve the respective process or deliverable. The project

initiation support guide provides details.

1.1.9. The table below compares four example activities that can be used to differentiate IT projects

from routine operational activities.


Table 1: Differentiating IT Projects from Operations Activities

IT Project Routine Operational Activity

Installing a new application or a full version upgrade Installing maintenance patches or releases

Installing a new IT infrastructure construction project Installing or maintaining of an IT infrastructure

Design and deploy a phase of the National Backbone

Infrastructure

Replacing a network equipment at the end of

product life

Activities are performed by temporary teams Activities are performed by a stable team

Project Classification

1.1.10. Project classification is an important aspect when initiating a project. Project classification

will determine whether the initiative will result into a small, medium or large project; and

appropriate documentation and activities of the project can be determined early to ensure

successful completion of a project with sufficient efforts.

1.1.11. Because of its importance, classification should occur while developing a business case or

during a feasibility study. The following are some of the attributes that can be used to classify a

project as small, medium or large:

a. Complexity of the project

b. Duration of a project

c. Budget at Completion

d. Project risk profile

e. Strategic importance

f. Political importance

g. Dependencies and Interrelated projects (Inter-ministerial)

h. Level of change management required

i. Reporting requirements

j. Programme (collection of related projects)


1.1.12. A Project Initiation Support Guide provides a detailed classification model and an intelligent

tool, which project initiators should use during the classification efforts.


2. IT Project Management Fit in MDAs Structures

IT Project Management Concepts in MDAs

2.1.1. Before developing this methodology, a survey was conducted in MDAs and selected private

companies. A detailed review of IT project management methodologies from other countries

was also undertaken. Throughout the development, the care was taken in mind the scope of

the methodology and existing legal, regulatory and policy framework of Uganda.

2.1.2. Project management requires significant coordination and, as such, requires each process

used to be appropriately aligned and connected with other processes within the governance

structures of the MDA.

2.1.3. Figure 1 below shows how IT project management concepts relate with existing MDA

governance structures. The strategy adopted by the MDAs will be the basis for identifying IT

project opportunities. The opportunities will be evaluated and documented into a concept note

and should be approved by the Top Management Team of the respective MDA.

2.1.4. Selected opportunities should further be developed into a business case or a feasibility study

performed, and could result in one or more IT projects that should provide deliverables in order

to realize the intended benefits. The benefits should be an input to realizing and further

developing the MDAs’ strategy.


Figure 1- Overview of IT Project Management Concepts in MDAs Environment

Source: ISO 21500: 2012(E)

IT Project Governance

2.1.5. In conformance with section 8 of the Public Finance and Accountability Act 2003, the

Accounting Officer shall control and be personally accountable for the success of all IT projects

in his/her domain. He / she will ensure that adequate controls are exercised over the incurring

of commitments; that effective systems of internal controls and internal audits are in place in

respect of all transactions and resources assigned to the project.

2.1.6. The successful management of IT Projects is dependent on significant coordination through

clear defined leadership, accountability and organisational structures which ensure all

processes and procedures are appropriately aligned and interconnected.


2.1.7. IT Projects governance should spell out clear leadership, organizational and reporting

structures; and processes that ensure that projects sustain and meet the intende objectives.

2.1.8. Roles and responsibilities must be clearly defined to avoid administrative issues. Project

governance is one of the critical success factors of project success, so it should be emphasized.

Separation of project governance and organizational/functional governance structures should

be considered for the success of the project.

2.1.9. The Project Governance and Reporting Structure Support Guide provides guidance on how

projects should be directed and controlled and includes subjects such as the following in

relation to IT projects:

a) Defining the management structure;

b) Stakeholder responsibilities and accountabilities;

c) Reporting hierarchy and escalation of issues or risks; and

d) Limits of authority for decision-making;

Project Organization and Reporting Structures

2.1.10. All IT Projects should have a defined project organization structure to ensure that all needed

commitments, reporting, roles and responsibilities are well defined to avoid administrative

challenges within a MDA. The organization structure below will be put in place for an IT Project

run in a single MDA.


Figure 2: IT Project Governance Structure for a Project in a Single MDA

2.1.11. The organization structure below should be put in place for an IT Project cross cutting

multiple MDA. A lot of care should be taken when identifying key MDAs for cross cutting IT

projects; and chiefdoms should be avoided in such projects.


Figure 3: IT Project Governance Structure for a Project Involving Multiple MDA

Project Key Stakeholders, Roles and Responsibilities

2.1.12. A successful project and or programme dependents on proper and full identification of

stakeholders (internal and external; direct and indirect) coupled with an effective stakeholders’

management and communication strategy. Stakeholders’ roles and responsibilities, influence /

power and interest should be clearly defined and managed. Stakeholder interfaces should be

managed within the project through the project life cycle.

2.1.13. It should be clearly understood that the project organization is a temporary structure that

includes project roles, responsibilities and levels of authority and boundaries that need to be

defined and communicated to all stakeholders of the project. The project organization may be


dependent on multi-sectoral mandates, interdepartmental or any other legal methodology

existing in government.

2.1.14. The IT Project Governance and Reporting Support Guide provide details for the two

structures.

Project Personnel Competencies and Knowledge Areas Required

2.1.15. IT Project management personnel should develop competencies in project management

principles, processes and proficiency in usage of tools in order to achieve project objectives and

goals. Each project team requires competent individuals who are capable of applying their

knowledge and experience to provide the project deliverables. Any identified gaps between the

available and required competence levels represented on the project team could introduce risk

and should be addressed.

2.1.16. The following knowledge areas should be developed for project personnel in order to

manage IT projects successfully among others:

a. System Development life cycle and models

b. Project Integration Management

c. Project Scope Management

d. Project Time Management

e. Project Cost Management

f. Project Quality Management

g. Project Human Resources Management

h. Project Communications Management

i. Project Risk and Issue Management

j. Project Procurement Management

k. Project Information Security Management

l. Project Stakeholders Management


2.1.17. Each of these knowledge areas has a Support Guide, which is providing detailed processes,

tools and techniques, good practices and examples. Please refer to these support guides for

detailed guidance. Furthermore, templates in the project management toolkit have been made

available to provide more information on these knowledge areas and expedite the

development of required project documentation.

2.1.18. However, understanding and applying the knowledge, skills, tools and techniques and good

practice are not sufficient alone for effective project management in general. Effective IT

project management requires that the project team understands and use knowledge and skills

from the following areas of expertise among others:

a. Communication skills

b. Application area knowledge, standards, and regulations

c. Understanding project Environment; including international and political environments

d. Interpersonal skills

e. Management and leadership Skills

f. Conflict / crisis management skills

g. Negotiation skills

2.1.19. Competency levels may be raised through professional development processes such as training, conferences, coaching and mentoring inside or outside an organization.

3. IT Project Management Methodology

IT Project Management Methodology

3.1.1. This methodology applies across the whole project lifecycle and should ideally be used for

any type of IT project, which may include among others: IT infrastructure and Information

System Development projects. Specifically, however, there are a number of key decisions to

make at the Project initiation stage, which will influence how the project will be managed

across all the subsequent stages of the lifecycle.


3.1.2. The project methodology in figure 3 illustrates the project life cycle, activities performed at

each stage, high level deliverables (inputs or outputs) expected depending on the project type,

controls and stage gates.

The output of one stage will be the input of the subsequent stage. Stage gates will be critically

evaluated before a project progresses from one stage into another; and sign off should always

be sought.

Project Management Methodology User Interface

3.1.3. All IT projects should follow a logical sequence of stages as illustrated in figure 4, with an

initiation as a start and closure as an end of the process; before transiting the project final

deliverables into operations and maintenance stage.

3.1.4. In order to manage IT projects efficiently during the entire project life cycle, a set of activities

should be performed at each stage with deliverables continuously monitored and controlled.

The number and type of activities that a project team completes during each stage will be

determined by the way a project will be defined and classified. Large projects will call for more

rigor than small project.

3.1.5. The methodology is structured into: Programme and project management, System

Development and project life cycle with expected activities at each stage, deliverables and

controls.

3.1.6. Stage gates or decision points are included to indicate where critical GO/ NO Go decisions are

expected. By the end of the last project stage, the project should have provided all expected

deliverables. Timely decisions are expected at each stage gate to minimize project delays.

Programme and Project Management

In circumstance where multiple projects are derived from a business case or a feasibility

study, the aspect of programme management will be emphasized in order to manage related


projects in a centrally and coordinated manner to achieve more benefits one could not get if

projects are managed discretely. The Programme Management Support Guide provides

details.

Information System Acquisition

3.1.7. For projects whose scope involves acquisition of a computerized information system, the

project planning team should agree on an appropriate System Development Life Cycle (SDLC)

model, identify and document all activities / tasks to be undertaken during project execution in

the project management plan (or inception report). A systems development support guide

provides further guidance, especially during project planning, execution and control.

3.1.8. Regardless of a selected SDLC model, during the project execution of the project

management plan, a Systems Analyst should collect business user requirements and analyse

them before a decision is made whether to develop the information system in-house or

procure off-the-shelve.


Figure 4: IT Project Management Methodology User Interface

Stage Gates

Project Initiation / Setup Project Planning Project Execution Project Closure Operations &

MaintenancProgramme Management

Project Management

System Acquisition

Activities

Deliverables / Out puts

Controls

Initiating Planning

Executing & Controlling

Requirements Solicitation

Analysis & Design Developing Testing

Training, Deployment &

Stability

Close OutTransion to Operations &

Maintenance

- Identify business needs- Develop Concept Note - Develop TOR (Scope, time, cost, quality) & establish project type (small or big)- Develop business case based on project type & TOR- Develop a project charter based on project type selected and business case; and appoint a Project Manager

- Project type selected- Approved Concept Note & TOR- Business case- Approved Project Charter- Appointment of PM- Commitment of Resources

- No approved business case no project (big projects only)- No approved project charter no project - No approved project charter no engaging resources to start project planning- No project Sponsor no project

- Baselined Project Management Plan

- Project planning activities must be base on approved scope of work- All estimates must be realistic and achieveable - Key stakeholders should be consulted during project planning activities- Project Implementation Plan should be baselined before project execution starts- Project Management Plan should be approved and resources committed before project execution.

- PM identify & define planning team- Develop detailed Project Management Plan

- Work Breakdown Structure- Project Schedule / Time Mgt Plan- Project Procurement Mgt Plan ( refer to PPDA)- Project Scope Mgt plan- Project Cost Mgt Plan- Project Quality Mgt Plan- Project Risk Mgt Plan- Project Communication Mgt Plan- Project Human Resources Mgt Plan- Stakeholders Mgt Plan- Project Governance Structure- Project Information Security Compliance Plan- Configuration Mgt Plan- Project Closure Plan- Project Transittion to Support plan- Change Mgt Plan

- Direct and manage baselined Project Management Plan and project charter- Complete analysis and technical designs- Conduct design reviews- Procure / acquire technology and infrastructure- Develop solution- Develop Test plan- Perfom quality assurance- Execute unit, system and user acceptance testing- Document testing results- Conduct user training- Monitor & control project actual work completed against planned & correcting variances- Verifications and validations

- Approved requirements- Procurement schedules updates- Project progress updates- Project deliverables (e.g. Technical designs, user acceptance testing plans and results, solution modules, user training materials, operations & maintenance plans), etc- Stakeholders approvals

- Scheduled work/activities timelinesmust be respected- Regular meetings must be organized and well documented- Any project scope change must follow a scope change management process -

- Implement Closure Plan- Transition to servive delivery - Document migration to operation plan- Create lessons learned- Achieve documents- Formalizing project acceptance and bringing to an ordery end- Develop As Built Document (ABD)

- Migration and conversion plan- Lessons learned- Operations guide- Project closure document- Stakeholders approval

- Product scope verificaion before closure- Project management verification before closure

- Execute Operation & maintenance plan- Post Implementation Review (PIR)(by Internal Auditor 3 month after project closure)- Business case benefit tracking and measurement- Benefit reporting- Evaluateing sustainability

- Operational system- Product or service

- Change management aasurance

Monitoring and Control

4321


Project Lifecycle

3.1.9. IT projects will go through five (5) process groups as defined by Project

Management Institute (PMI) namely: Initiation, planning, execution, monitoring &

control and closure. The monitoring and control process will be performed

throughout the project life cycle without a specific start or end. High level

activities performed at each stage, deliverables expected and controls at each

stage are illustrated in the methodology user interface in figure 3 above.

3.1.10. Table 2 below provides a quick description of the project life cycle process group

defined in the methodology user interface in figure 3.

Table 2: Description of Project Life Cycle Process Groups

Stage No. Process Group Description

1 Initiation Involves the processes required to go through to initiate, justify and

authorize a project or programme

2 Planning Involves the processes a project planning team should undertake to

define and develop a detailed project management plan. Enough

time should be allowed to define a detailed WBS and PIP. This is a

very important effort, which determines the successful delivery of a

project

3 Execution Involves processes to execute the plans defined in the project

management plan

4 Monitoring and

Controlling

This involves tracking, reviewing, monitoring and measuring progress

to identify variances (baseline- schedule, cost, quality) so that

corrective actions can be taken accordingly in order to meet

performance objectives defined in the project management plan. It

involves integrating change control, coordinating changes across the

project; Schedule control : controlling changes to the project

schedule; Cost control: controlling changes to the project budget;


Quality control: monitoring specific project results to determine if

they comply with set quality standards and identifying ways to

eliminate causes of unsatisfactory performance; Status performance

reporting: progress measurement and forecasting; Risk monitoring

and control: keeping truck of identified risks and how to

reduce/eliminate risks among others

5 Closure Involves bringing a project to an orderly end and to gain formal

acceptance of the project; before transferring outcome into

operations.

Contract close out: completion and settlement of the contract,

including resolution of any open snags/tasks/items; perform

administrative closure: documentation (As Built Doc - ABD, evaluating

the Project; compiling lessons learned in the project closure

document for use in future similar efforts. A project manager should

spearhead the development of a closure report; and must be signed

off as per the project governance in place

Project Initiation Process group

3.1.11. The first stage, which is very critical, is the initiation. At this stage, it is where

initiatives are developed and also determine the level of details that will be

required for the rest of the project life cycle. For example, it is from this stage

where an initiative is categorized as a project or not, and whether a project is

small, medium or large.

3.1.12. IT Projects will be born and initiated by MDAs based on their mandate (s),

strategies, government directive (s), or any other initiative which can result into

improving social and economic development through IT. Opportunities or

initiatives will be evaluated through a set of activities that provide formal


authorization to start a project. The organization should identify a project sponsor

to be responsible for project goals and benefits.

3.1.13. The goals and benefits of the initiative may result in a justification for the

investment in the project in a form of a business case or feasibility studies, and

that may contribute to a prioritization of all opportunities. The purpose of the

justification is to obtain organizational commitment and approval for investment in

the selected projects.

3.1.14. It should be noted that most approaches are unique to the circumstances when

it comes to managing IT projects. An IT project’s complexity, size and risk profile

will determine both the requirements for documentation and the activities to be

conducted by the project team.

3.1.15. The stage concludes when the sponsor signs off (Go / NO GO Stage gate 1) the

Project Charter, signalling that the project manager may begin the detailed

planning work required in the next stage. It will be in the interest of the sponsor to

ensure that the initiation stage is expedited to progress into the project planning

stage.

3.1.16. A project charter will be the main deliverable of project initiation stage. The

project charter template provides details.

3.1.17. Detailed guidance on classification, expected documents, roles and

responsibilities and best practices are contained in the project initiation support

guide.


Project Planning Process Group

3.1.18. On receiving a Project Charter, a Project Manager should quickly set up a

skeleton team of Subject Matter Experts (SME) study the project charter and

develop a detailed Work Breakdown Structure (WBS) to clearly define a

comprehensive project scope, and thereafter draft a Project Management Plan.

3.1.19. A kick-off meeting with Project Implementation Team identified in the draft

Project Management Plan should be organized to discuss the draft plan and get a

buy-in from people going to participate in the execution of the project.

Subsequent planning meetings should be organized by the Project Manager until a

final Project Management Plan is developed

3.1.20. A detailed Project Management Plan should be sufficient to establish baselines

against which project implementation should be managed and project

performance measured and controlled. This can only be achieved if the planning

team is properly resourced, motivated, making use of templates and lessons learnt

from previous projects. The project manager should identify key resources to

develop the different plans as listed in the methodology user interface illustrated

in figure 3 above.

3.1.21. The planning stage should not take more than 2 weeks for small project and not

more than a month for large/ complex projects. The planning phase is concluded

with a Steering Committee or project sponsor approval (Go / NO GO stage gate 2)

of the Project Management Plan for large or small projects respectively, signalling

that the project execution could begin.

3.1.22. It is critical that all staff in the MDA involved in IT projects clearly understand

their roles in the implementation of any IT project for optimal results. Sensitization


workshops on the implementation of IT projects will therefore be held for all

officers after project planning as a first activity in the implementation process.

3.1.23. The project planning support guide provides details.

Project Execution Process Group

3.1.24. The execution processes are used to perform the project management activities

and to support the provision of the project’s deliverables in accordance with the

project management plans. The actual work gets done; project team completes

the tasks outlined in the Project Implementation Plan (PIP) and develops project

deliverables.

3.1.25. The project manager takes lead of the project execution stage and has to ensure

that all activities are executed as planned with minimum surprises.

3.1.26. Duration of the project implementation should be determined from the PIP

baseline. The methodology user interface illustrates other tasks that are

performed during project execution.

3.1.27. The execution stage should be concluded when the entire project scope is

delivered to the satisfaction of the end users, project team, project manager,

sponsor, project owner and the Steering Committee. Approvals should be sought

(Go / NO GO stage gate 3)

3.1.28. The Project Execution Support Guide provides details.


Monitoring and Controlling Process Group

3.1.29. The success of IT project implementation depends significantly on how the

planned activities and output are effectively supervised, monitored and evaluated.

The monitoring and controlling processes should be implemented to monitor,

measure and control project performance against the baseline project

management plan. Consequently, preventive and corrective actions may be taken

and change requests made, when necessary, in order to achieve project objectives.

3.1.30. The project monitoring and control support guide provides details.

Project Closure Process Group

3.1.31. Projects are temporary in nature and a project team must complete the planned

activities in order to complete the project life cycle. Conducting the activities of

this stage is vital to continuous improvement efforts and successful transition of

the project deliverables.

3.1.32. After achieving acceptance of the project deliverables, the project

implementation team should develop a project closure report, document lessons

learned and archives project documentation for future use.

3.1.33. The project manager should transfer the project deliverable(s) to operations and

support staff, who will assume responsibilities to maintain the project deliverables

as an operational activity. Finally, the project team should be disbanded.

3.1.34. However, a project can be closed at any stage of the project life cycle because of

one reason or another. Whatever the circumstances, a project should undergo a

closure process.


3.1.35. The project closure support guide provides details.

Project Management Tools and Techniques at each Stage

3.1.36. There are several tools and techniques which can be used to perform or achieve

different deliverables at each stage of the project life cycle. In a table 3 below you

can find a sample of these tools and techniques. The project manager will be free

to use any other available automated support tools and techniques to achieve a

given deliverable.

Table 3: Sample Project Management Tools and Techniques used at each project stage

Tools / Techniques Initiation Planning Execution Monitoring

and Control

Closure

Work Breakdown

Structure (WBS)

√ √ √ √

Critical Path Analysis √ √ √

Project Information

Management Systems

√ √ √ √ √

Spread Sheet Software

such as Excel, etc

√ √ √ √

Project Management

Software tools such as

MS Project

√ √ √

Project drawing tools

such as Ms Visio

√

Meetings √ √ √ √ √

Expert Judgement √ √ √ √ √


Interview √ √ √ √ √

Focus Groups √ √ √ √ √

Facilitated Workshops √ √ √ √ √

Delphi Technique √ √ √ √ √

Operations and Maintenance (Transition to Support)

3.1.37. All projects have to be concluded and transfer the project outcomes into

operations and maintenance phase; and start realizing the benefits which could

have been specified in the business case.

3.1.38. The process of transiting from a project stage into operations, maintenance and

support must be well planned and executed throughout the project life cycle. A

support focal point should be identified and participate at all governance

structures (e.g. Steering Committee and PIT) to ensure that operations and

maintenance requirements are taken care of throughout the project. This will also

result in knowledge transfer and smooth handover. The Project Manager will be

accountable for ensuring that this is done.

3.1.39. The Project Owner takes responsibility of the outcome on closing the project.

Project implementation team should not get involved in the operations and

maintenance phase unless if the resources were strategically involved in the

project phase to ensure knowledge transfer and capacity building.

3.1.40. The operations and maintenance support guide provides details.


Project Documentation Management

3.1.41. Documentation throughout the project life cycle should be developed to

appropriate level and signed off. The table 4 provides guidance on minimum

documentation and activity effort required to complete this task based on project

classification.

3.1.42. Initiation Stage Activities and Required Documentation

Table 4: Initiation Phase Activities and Required Documentation

Activity Out put Small

Project

Medium

or Large

Project

Develop Concept Note Concept Note short form √

Concept Note long form √

Develop Business Case &

TOR

Business Case & TOR short form √

Business Case & TOR long form √

Preliminary Risk Assessment √ √

Appoint Project Sponsor √ √

Set up Steering Committee √

Develop Project Charter Project Charter short form √

Project Charter long form √

3.1.43. Planning Stage Activities and Required Documentation

Table 5: Planning Stage Activities and Required Documentation


Project

Medium

or Large

Project

Project Scope Definition Scope Statement Sign Off √ √


Project Manager Initial

work plan

Identify and define Planning

Team

√ √

Conduct planning kick off

meeting

√ √

Plan Schedule and

Resources

Work Breakdown Structure √ √

Project Implementation Plan

(PIP)

√ √

Resources Plan √

Procurement Plan √ √

Budget Plan √ √

Develop Supplemental

Plans

Risk Management Plan √ √

Communication plan √ √

Project Change and Configuration

Management Plan

√

Project Quality Management

Plan

√ √

Project Plans Approval Approval by Project Sponsor √ √

Approval by Steering Committee √

3.1.44. Execution and Control Stage Activities and Required Documentation

Table 6: Execution and Control Stage Activities and Required Documentation


Project

Medium

or Large

Project

Conduct Execution Kick-off

Meeting

Quality Assurance

Meeting minutes √ √


Project Implementation

Team (PIT) Mobilization

Set up a team of highly

motivated PIT

√ √

Execute Project Tasks Activity deliverables √ √

Manage Project

Procurement

Initiate required procurements √ √

Procurement Log √ √

Perform Project

Communication

Status Report, updates to

Sponsor

√ √

Status Report, updates to

Steering Committee

√

Track/Manage issues, Risks Issue and Risk logs √ √

Conduct Project Change

Management

Change Control Request √ √

Change Request Review √ √

Approve Change Request √ √

Change Request Log √ √

Scope Verification Scope Verification Reports √ √

Quality Assurance Quality Assurance Reports √ √

Project Deliverable

acceptance

Project Team √ √

Project Owner √ √

Project Sponsor √ √


3.1.45. Closeout Stage Activities and Required Documentation

Table 7: Closeout Stage Activities and Required Documentation


Project

Medium

or Large

Project

Conduct Closure Activities √ √

Create Closeout

Documentation

Lessons Learned √ √

Project Closure Report √ √

Transition Support to

Operation Staff

√ √

Perform Procurements

Audit

Procurement Audit Report √ √

Release Project

Implementation Team

Issue Project Completion

Certificates to PIT

√ √

Stage Gates Checklist

3.1.46. There are four (4) stage gates, which should be used as decision points to

progress a project from one stage into another. A Go or NO Go decision should be

given and a sign off from the Steering Committee and Project Sponsor should

always be sought.

3.1.47. The check list below provides guidance to ensure compliance before progressing

from a stage to the next one. A checklist for each stage gate is defined below and a

Project Manager will be accountable for ensuring that all documentation is

compiled, verified and filed in the project file.


Table 8: Stage Gate 1: From Initiation to Planning Stage

No Deliverables Required Available on File

1 Approved Concept Note

2 Approved Terms of Reference with crystal clear Scope

3 Approved Business Case

4 Approved Request for Proposal (RFP) (if applicable)

5 Governance Structure in place (Steering Committee Setup)

and Appointments with TOR issued

6 Project Sponsor Assigned and Appointment issued

7 Project Funds Committed

8 Project Human Resources Committed (including support

focal point)

9 Project Manager assigned and appointment issued

10 High Level Stakeholders List and Analysis

11 Approved Project Charter

12 Project Charter forwarded to Project Manager for Action

Table 9: Stage Gate 2: From Planning Stage to Execution Stage


1 Detailed Work Breakdown Structure

2 Detailed Project Implementation Plan

3 Detailed Phased Budget Work Plan

4 Human Resources Requirements

5 Procurement Plan (if applicable)

6 Risk log

7 Communication Plan

8 Planning Meeting Minutes


9 Transit to Support Plan

10 Quality Requirements (Indicators)

11 Change Management Plan

12 Information Security Compliance Plan

13 Stakeholders Analysis Log and Engagement Plan

14 PIT signed recommendations to Steering Committee

15 Decision how to acquire Information System (in-house or

procure consultants) (if scope involve Information System

acquisition)

16 Integrated Project Management Plan (Implementation

Manual)

Table 10: Stage Gate 3: From Execution to Closure Stage


1 Deliverables as defined in final TOR or Contract

2 Specification (Functional & Non-functional)Delivered

3 Documentation of Lessons Learnt

4 Updated PIP

5 Test results

6 Quality Requirements results

7 Progress Status Reports

8 Review Meeting Reports

9 Design Checklist



Table 11: Stage Gate 4: From Closure to Support Stage


1 User Acceptance / Validation Results and Sign Off

2 As Build Document (if applicable)

3 Operational Readiness Checklist

4 Change management plan

5 Closure Report

6 End User Agreement to Operate

7 Steering Committee Sign Off

8 Deployment and Stabilisation Checklist

9 Deployment Plan

10 Project Support Manuals


4. Project Information Security Compliance

Information Security Compliance Plan must be followed throughout the IT project life cycle

to reduce information security risks to acceptable levels. It should be noted that

Information Security transcends both electronic and non-electronic information (data

endowed with meaning) with the ultimate objective of supporting the attainment of

business objectives.

Security risk assessments should be conducted during the project initiation phase,

mitigation measures included in planning stage and controls implemented in the execution

stage of a project to ensure that any risks likely to affect the successful completion of the

project are responded to appropriately.


Any changes must also undergo security risk assessment to ensure that appropriate controls

are implemented.

Information Security Compliance Support Guide provides details.

5. Project Management Support Guides Project Management Support Guides should be used by project managers, project

management teams and other stakeholders throughout the project life cycle as references

and getting guidance on how to manage different IT projects aspects. The guides contain

methods, tools, techniques, good practices and critical success factor.

Table 8 provides high level description of IT Project Management Support Guides. Users of

this methodology should refer to individual guides for more detailed guidelines while

managing IT projects.

Table 12: List and description of Project Support Guides

No. Guide Purpose

1. Project Initiation Guide Provides the processes to go through when initiating a project,

initiative classification, expected documentation that should be

developed based on a given classification, guiding principles to be

followed in order to successfully go through this stage; and tools

and techniques to be used during project initiation.

2. Project Planning Guide Provided guidelines and processes required for planning a project

after a charter sign off

3. Project Executing Guide Provided guidelines and processes required for executing a project

after planning phase.

4. Project Monitoring and

Control Guide

Provide processes for monitoring and controlling a project to ensure

intended product/service and project objectives are realized.


5. Project Governance

Structure and Reporting

Guide

Provides project implementation governing structure and reporting.

Roles and responsibilities are defined and provides guiding

principles to ensuring governance is established.

6. Project Stakeholders

Management Guide

Provides strategies for managing project stakeholders in order to

deliver on their expectations.

7. Steering Committee

Support Guide

Focuses on selections of Steering Committee; and define their roles

and responsibilities.

8. Project Manager

Selections &

Responsibilities Guide

Provides guidelines on how an IT Project Manager should be

selected and his/her responsibilities defined.

9. Project Change

Management Guide

Provides processes and actions required for an organization to

understand, prepare for, implement and take full advantage of

significant change as a result of a project from initiation until

closure and during support.

10. Risk Management Guide Provides guidance on how to manage risks through the project life

cycle.

11. Communication Guide Is a guide that describes how you are going to communicate the

right messages, to the right people, at the right time. It sets out the

communications goals, stakeholders and strategies, as well as the

communications activities and timeframes

12. Quality Management

Guide

This guide will define coordinated activities to direct and control

quality of a project. It will provide a set of quality standards,

procedures and responsibilities

13. Project Closure Guide Provides guidance on the process of closing a project and transit it

to support

14 Project Scope

Management Guide

Provides guidance on the processes and tools used in project scope

management

15 Project Scheduling & To build a project schedule that consists of a work breakdown


Resourcing Guide structure, deliverables, milestone and corresponding resources (HR

& cost)

16 Project Estimating Guide This guide is designed to provide Project Managers with an

understanding of how to create and present a project cost and time

estimate appropriate to the stage of the project. The content is

designed to be applicable to projects of all types, and includes

guidance to help to create an estimate in accordance with key

characteristics of project size, risk and criticality.

The Activity Sheet “Develop Project Cost Estimate” provides a high

level overview of the process described in this guide.

17 Feasibility Study Guide This guideline is to be used in preparing a feasibility study for major

projects. A feasibility study creates a holistic justification for the

project and serves as a living document against which project

deliverables are measured during procurement and even after

implementation of the project

18 Project Information

Security Compliance

Guide

Provide guidance on how to ensure information security compliance

19 Programme Management

Guide

Provide guidance on how to manage multiple projects within a

Programme.

20 Project Baselining Guide This guide is intended to provide the Project Manager with

guidance creating a project baseline (how to baseline a project

schedule and budget with the project scope) and when to re-

baseline.

This document provides high level guidance on when and how to

baseline a project schedule and budget with the project scope. It is

assumed that the reader has knowledge of budgeting and

scheduling techniques.


21 Project Reporting Guide This guide is intended to provide the Project Manager with

guidance on how to monitor and report against project

performance and what action to take for projects off-track.

22 Testing and confirmation

Guide

This guide is intended to introduce the Project Manager to the

standard activities, deliverables and techniques incorporated in the

framework to enhance the effectiveness of testing and

confirmation. The content is drawn from a broader industry-base of

testing best-practices

23 Transition to Support

Guide

This guide provides the processes involved from project stage to

operations and maintenance.

6. Project Management Support Templates Project documentation is one of the most challenging and unpopular exercise by most IT

project management personnel, yet a very critical task throughout a project life cycle.

Furthermore, it is time consuming. In order to mitigate such challenges, templates have

been developed to expedite the process of project documentation and standardize IT

project reporting.

The table 13 provides high level description of IT Project Management templates, which

users should use to expedite project documentation process. Template can be accessed

from the IT Project Management Tool Kit.


Table 13: List and description of Project Templates

STAGE TEMPLATES

DESCRIPTION PERSON

RESPONSIBLE

Initiation

Initiator

Concept Note Describes an initiative for considerations

Project Proposal A Project Proposal is written to convince a sponsor that a

project needs to be initiated to solve a particular problem or

opportunity in the business. It describes in depth, the basis

upon which the project needs to be commenced, so that the

sponsor fully understands why it’s critical to the business and

what is involved. It also needs to outline the implications of

not approving the project, so that the sponsor is forced to

make a clear decision – to approve the project, or not.

Initiator

Terms of Reference This can also be referred to as the Product description. This is

used to gain agreement from the user on the projects scope

and requirements to define quality expectations,

specifications & define acceptance criteria for the project

Initiator

Business case (

products/ services)/

Feasibility Study

The business case / feasibility study details the justification

for undertaking, and for continuing, a project. The

justification for an organisational activity (project) which

typically contains costs, benefits, risks and timescales and

against which continuing viability is tested

The Business case presents an optimum mix of information

used to judge whether a project is and remains desirable,

viable and achievable and therefore worth investing in.

Business

Analyst and

Initiator

Project Charter A Project Charter is a document which outlines the purpose

of the project, the way the project will be structured and how

it will be successfully implemented. It describes the project:

Project

Sponsor


Vision, objectives, scope and deliverables (i.e. what we

have to achieve)

Stakeholders, roles and responsibilities (i.e. who will take

part in it)

Resource, financial and quality plans (i.e. how it will be

undertaken).

The Project Charter may also be referred to as a “Terms of

Reference (TOR)” or “Project Definition Report (PDR)”.

It is developed pre-project and is used to initiate a project,

hence the birth of a project.

Appointment letters

(SC & PM)

Appointment letters templates TMT

Planning

Project

Management Plan

Defines how the project will be undertaken by looking at all

aspects of the project plans: scope, schedule, cost, risk,

procurement, human resources, communication, and quality

management

Project

Manager

Project

Implementation

Plan

Defines procedures for the management of schedule, cost,

quality, risk, issues, communication, change control,

configuration management, health, environment, safety,

roles, responsibilities, organization and other subjects as

needed. It is a component of a Project Management Plan.

Project

Manager

Stakeholder Matrix

and Analysis

Defines stakeholders analysis, their roles and responsibilities Project

Manager

Risk Management

Plan Matrix

Defines risks and qualitative analysis Project

Manager

Communication

Plan

A Communications Plan is a document that describes how you

are going to communicate the right messages, to the right

Project

Manager


people, at the right time. It sets out the communications

goals, stakeholders and strategies, as well as the

communications activities and timeframes

Progress Status

/Progress Reports

The Project Status Report is a document that is used by

Project Managers for formal regular reporting on the status of

a project to the Steering Committee, Project Sponsor, Senior

Manager or other Key Stakeholders, depending on the size of

the project.

Project

Manager

Project closure

Report

A Project Closure Report is a document which formalizes the

closure of the project. It provides confirmation that the

criteria for customer acceptance have been met and requests

sign-off from the Project Sponsor to close the project.

Project

Manager

Quality

Management Plan

A register containing summary details of all planned and

completed quality activities. The quality register is used by

the PM and the Project assurance as part of reviewing project

progress

Project

Manager

Lessons Learned Document lessons learned Project

Manager

Post

Implementation

Review form

Three (3) month after the close of a project, each MDA must

complete two post implementation reviews: one with the user

and the other with project team. The reviews must then be

reported at the next project managers meeting.

The completed and signed reviews must be maintained in the

project file and also copied to Steering and Policy Committees

of the project.

Internal Auditor


7. Project Management Maturity Model In order to evaluate adoption of project management methodology by MDAs, the Project

Management Maturity Model (PMMM) illustrated in figure 5 will be used.

Figure 5: Project Management Maturity Model

Source: KLR Consulting Inc

Because government is desirous to have successful delivery of IT projects, it is important that

MDAs strive to be at level three or greater of the maturity model. The table 15 below provides

a description of the maturity model.

Table 15: Description of Project Management Model

Level Level Name Key Characteristics

1 Adhoc Each IT project handled differently

Highly dependent on project Manager

IT Project outcomes unpredictable

Little organization support for project management

Lessons learned are not gathered and passed on to other projects

2 Foundation Managed support for project management

Optimizing (5)

Integrated (4)

Managed (3)

Foundation (2)

Adhoc (1)

Consistent, basic approach to project planning and execution

Project- centred Organization

No formal Consistent process

Project portfolio management is Institutionalized and integrated into organization's business planning process

Consistent, comprehensive approach

Preferred levels for all Government IT Projects


Repeatable processes are applied to basic project management steps

IT Project outcomes are more predictable

Use of common tools and techniques for key project management

processes

3 Managed Senior management support for project management

Organization can efficiently plan, execute, integrate, control single IT

projects

Repository or previous projects experiences is maintained and utilized

Team members and project managers trained in project management

Consistent use of tools and techniques for project management

processes

4 Integrated Active senior management support for integration of business

planning and IT project execution

Organization can efficiently plan, execute, integrate and control

multiple IT projects

Database of previous project data is maintained and utilized

5 Optimizing Project management environment improvement is actively

encouraged

Flexible, project-centred organization structure

Career programme for project managers

Project management training is a key component in staff

development

8. Code of Ethics and Professional Conduct The Code of Ethics and professional conduct shall apply to all persons involved in IT project

work in government, especially the Project Steering Committee (SC) and Project

Implementation Teams (PIT). All stakeholders involved in IT project work should commit to

doing what is right and honourable at all times, make wise decisions, particularly when


faced with difficult situations where they may be asked to compromise their integrity or

values.

All key project stakeholders should sign the professional code of conduct and submit signed

copies to the project sponsor through the project manager. A template is available in the

tool kit.

The following values, defined by global project management community, should be

upheld: responsibility, respect, fairness and honesty.

8.1.1. Responsibility

Responsibility is stakeholders’ duty to take ownership for the decisions they make

or fail to make, the actions they take or fail to take, and the consequences that

result. Stakeholders should ensure:

a. All decisions and actions taken are based on the best interests of government,

public safety, information security and the environment.

b. They fulfil the commitments that they undertake – they do what they say they

will do.

c. When they make errors or omissions, they take ownership and make

corrections promptly.

d. When they discover errors of commission or omission caused by others, they

communicate them to the appropriate authorities as soon they are discovered.

They accept accountability for any issues resulting from their errors or

omissions and any resulting consequences.

e. They protect proprietary or confidential information that has been entrusted to

them.

f. Uphold the policies, rules, regulations and laws that govern their work and

profession. They should not engage in any illegal behaviour, including but not

limited to: theft, fraud, corruption, embezzlement, or bribery


8.1.2. Respect

Stakeholders should show a high regard for themselves, others, and the

resources entrusted to them. Resources entrusted to them may include people,

money, reputations, the safety of others, and natural or environmental

resources. Stakeholders should ensure that:

a. They avoid engaging in behaviour they might consider disrespectful

b. They conduct themselves in a professional manner, even when it is not

reciprocated

c. They do not act in an abusive manner towards others

d. They do not exercise the power of their expertise or position to influence the

decisions or actions of others in order to benefit personally at their expense

e. They respect the property rights of others

8.1.3. Fairness

Fairness refers to the stakeholders’ duty to make decisions and act impartially

and objectively. Their conduct must be free from competing self-interest,

prejudice, and favouritism. Stakeholders should ensure that:

a. They demonstrate transparency in their decision-making process.

b. They provide equal access to information to those who are authorized to

have that information.

c. They proactively and fully disclose any real or potential conflicts of interest to

the appropriate authorities

8.1.4. Honesty

Stakeholders should understand the truth and act in a truthful manner both in

their communications and in their general conduct throughout the project life

cycle. Stakeholders should ensure that they:

a. Are truthful in their communications and in conduct


b. Provide accurate information in a timely manner; including having the

courage to share bad news even when it may be poorly received

c. Make commitments and promises, implied or explicit, in good faith

d. Strive to create an environment in which others feel safe to tell the truth

e. Do not engage in or condone behaviour that is designed to deceive others,

including but not limited to, making misleading or false statements, stating

half-truths, providing information out of context or withholding information

that, if known, would render their statements as misleading or incomplete.

9. General Project Success Factors Whatever has been described in this methodology, if upheld, contribute to the successful

delivery of IT projects in Government. For bases of emphasis, below is quick reference to

some of these factors.

a. Understanding the project scope by all stakeholders

b. Top management support buy-in and availability

c. Constant availability of approved project funding

d. Setting up a dedicated (temporary) Project governance structure different from MDA’s

functional structure

e. Availability of skilled human resources to run IT projects

f. Implementation of a change management strategy

g. Project documentation at each project stage should be adhered to

h. Project big picture should be understood; Understanding the overall purpose and goal of

the project allows you to make decisions and resolve issues that arise

i. Project details should be closely managed; stay on top of the details

j. Decisions should be carefully and made promptly

k. Emphasis should be placed on project communication

l. Risk assessment and analysis should be carried out at every stage of the project


m. Stakeholders expectations that are in line with the project’s objectives should be

properly managed; spend quality time with stakeholders to ensure their expectations

are met and managed

n. Approvals and Sign-Offs on changes, plans or deliverables should be respected. Make

sure appropriate parties are okay with a project moving forward

o. Meetings should be held regularly. It is tempting to get together only when there are

big problems, but when status meetings, project reviews, and other meetings are held

regularly, it minimizes the risk of unpreparedness in case any problem arises.

p. Post-implementation review should always be done


10. Glossary For purpose of having a common understanding of terminologies used in this methodology, the

supporting guides and templates, the following definitions shall apply.

Activity: Identified component of work within a schedule that is required to be undertaken to complete

a project

Application area: Category of projects that generally have a common focus related to a product,

customer or sector

Baseline: Reference basis for comparison against which project performance is monitored and

controlled

Change request: Documentation that defines a proposed alteration to the project baseline scope

Concept note:

Configuration management: Application of procedures to control, correlate and maintain

documentation, specifications and physical attributes

Control: Comparison of actual performance with planned performance, analysing variances and taking

appropriate corrective and preventive action as needed

Corrective action: Direction and activity for modifying the performance of work to bring performance in

line with the plan

Critical path: Sequence of activities that determine the earliest possible completion date for the project

or phase

IT Projects: These are projects which will result into a product or service related to computing and

information Technology

Lag: Attribute applied to a logical relationship to delay the start or end of an activity

Lead: Attribute applied to a logical relationship to advance the start or end of an activity

Methodology: It is a collection of processes, methods and tools for accomplishing an objective.

Methodologies provide a checklist of key deliverables and activities to avoid missing key tasks. It can

also be defined as a set of guidelines or principles that can be tailored and applied to a specific situation.

In a project environment, these guidelines might be a list of things to do. A methodology could also be a

specific approach, templates, forms, and even checklists used over the project life cycle.

Project Charter: This is a major deliverable or output of the initiation stage. It specifies high level

project objectives, scope, timelines, cost, risks, stakeholders and used to appoint a Project Manager.


Approved project charter signifies that the project is officially authorized and it provides authority to

project manager to apply organization resources to project activities. Approved project charter gives

way for a project to proceed to the planning stage.

Project Implementation Plan (PIP): This is a detailed list of all activities as defined in the work

breakdown structure with defined estimated durations, dependencies and assigned resource to execute

each activity. It can also be called a roadmap.

Project Management Methodology: provides a roadmap for managing projects. Project methodologies

provide guidance to project teams to collaborate in tackling projects.

Preventive action: Direction and activity for modifying the work, in order to avoid or reduce potential

deviations in performance from the plan

Project life cycle: Defined set of phases from the start to the end of the project

Project: Is a temporary endeavour undertaken to create a unique service or product

Project Management: Is the application of knowledge, skills, tools and techniques to Project

activities to meet project requirements. Also defined as: as the planning, organizing, directing

and controlling of assigned project resources in order to accomplish a given objective within the

constraints of time, cost and quality.

Risk register: Record of identified risks, including results of analysis and planned responses

Stakeholder: Person, group or organization that has interests in, or can affect, be affected by,

or perceive itself to be affected by, any aspect of the project

Tender: Document in the form of an offer or statement of bid to supply a product, service or

result, usually in response to an invitation or request

Work Breakdown Structure (WBS): This the decomposing of a huge project activity or task into

small manageable work packages, which can easily be managed, timelines and costs estimated.

Work Breakdown Structure Dictionary: Document that describes each component in the work

breakdown structure


11. References List of standards this methodology is based on:

1) ISO 21500:2012 ( E )

2) Project Management Institute Body of Knowledge (PMI PMBOK) ver 4

3) PRINCE2

4) Selected project management frameworks and methodologies from different countries

and organizations

Date post:	08-Sep-2019
Category:	Documents
Upload:	others
View:	4 times
Download:	0 times

The Republic of Uganda - NITA IT... · Many fail at inception stage, others are not delivered on...

Documents