NATIONAL INFORMATION TECHNOLOGY AUTHORITY - UGANDA

IT Project Management Methodology

Project Initiation Support Guide

Version 0.3

Project Initiation Support Guide Ver 0.3 Page 1

Table of Contents
1 INTRODUCTION ...................................................................................................................... 3
2 PROCESSES INVOLVED AT PROJECT SETUP / INITIATION ............................................ 3
2.1 Classification of an Initiative ............................................................................................ 5
2.2 Expected Documents ...................................................................................................... 8
2.2.1 Concept Paper ............................................................................................................... 9
2.2.2 Terms of Reference (TOR)/ Statement of Requirements (SOR) .................................. 9
2.2.3 Business Case ............................................................................................................. 11
2.2.4 Project Charter ............................................................................................................ 12
2.3 Project Classification Vs Required Documentation ....................................................... 13
2.4 Guiding Principles at Initiation Stage ............................................................................ 13
3 TOOLS AND TECHNIQUES.................................................................................................. 14
3.1 Project Classification Tool ............................................................................................. 14

2
1 Introduction
Project initiation is the first stage in the project management life cycle; and the main
objective is to build up an initiative from inception until a stage when it is clear that the
outcome can result into a unique product or service. This guide provides the processes
to go through when initiating a project, its classification, expected documentation that
should be developed based on size or complexity, guiding principles to be followed in
order to successfully go through this stage; and tools and techniques to be used during
project initiation. This stage is critical to the success of the project and determines how
much rigor will be required for the proceeding processes; so enough effort and
expertise should be invested at this stage.
IT Projects initiatives will be born and initiated by MDAs to create a unique product or
service based on government policies, strategies, directive (s) or any other triggers,
which may result into improving social and economic development through ICTs. Such
initiatives will go through a justification process, get executive sponsorship and secure
authorization as projects. The initiators will take full responsibility to document and
seek approval of a project charter as the final deliverable at this stage under the
guidance of a project sponsor. Initiators should be in position to classify the initiative
either as small, medium or large using criteria described latter in this document before
final decision to be made by MDA’s Top Management Team (TMT).
An approval will be required from the project sponsor before an initiative progresses to
the second phase of the life cycle.

2 Processes Involved at Project Setup / Initiation

Initiators will initiate concept notes and or thematic/technical papers, which will
describe the intended initiative, its rationale, objectives, benefits, indicative (high level)
costs and duration; and present it to MDA’s TMT for considerations. Refer to expected
content of the concept note in section 2.1.1. TMT will analyze the concept note or
thematic/technical paper to establish whether it answers and or is aligned with the
MDA’s strategic objectives, strategic goals or government directive (s). Understanding

3
the initiative’s goals and preliminary documentations from the initiator will help TMT
categorize / classify initiatives.
The following process should be followed during project initiation stage and the
responsible resources:
Process 1: Project Initiation Process

Table 1: Narrative of the process

Process Description Deliverable Responsible
Stage
1 An Initiator will develop or document an Draft concept Initiator
initiative. Enough reference and paper
benchmarking information should be
consulted.
2 A concept paper should be reviewed by Concept paper Head of
the Initiator’s functional management unit Functional

4
 e.g. Directorate for completeness of the Mgt Unit,
concept before submission to MDA’s TMT e.g.
Director
3 On approval by functional management TMT Accounting
unit, it is presented to TMT for Recommendati Officer
consideration ons
4 On approval by TMT, a Steering Committee Appointed Accounting
(SC) is setup and Project Sponsor named to Steering Officer
lead the SC depending on the initiative Committee &
classification defined in section 2.1. Project
Sponsor
5 Under the supervision of the SC (headed Draft TOR, Biz Project
by Project Sponsor), the Initiator develops Case and Sponsor
project documentation like TOR, Biz case Project charter
and Charter as per project classification.
6 SC supervises the development of all docs Final TOR, Biz Project
and should be approved by SC. Case and Sponsor
Project charter
7 Sign off of all initiation documentation and Approved TOR, Accounting
appointment of a Project Manager. For Biz Case and Officer
large projects, SC should present these Project charter
documents to TMT

2.1 Classification of an Initiative

One of the major problems facing IT projects is the extent to which the key elements of
the project management methodology should be prepared, and the level of detail in any
of those elements. This guide provides attributes to consider when deciding on the
extent to which you are going to use the methodology. A rational decision has to be
made on how to manage the project in the most suitable way. However, an IT project

5
which is multi-ministerial; the application of project management methodology to its
fullest extent should seriously be considered.
There are many factors that could be taken into account such as funding requirements
(both CAPEX and OPEX), level or degree of risk, duration, technology requirements,
number of key stakeholders and the skill level of the project team when classifying an
initiative. It will be the responsibility of TMT to determine the classification of an initiative
or project on presenting a concept paper by the initiator. The following 10 criteria may
be used to assist in determining the classification of an IT project undertaken within
Government.
Table 2: Project Classification
No Attributes Small Projects Medium Projects Large Projects
1 Complexity Simple project Project scope with few Project scope with
scope, solution facets to integrate, many facets to
easy to achieve solution easy to achieve integrate, solution
and few and many stakeholders difficult to achieve
stakeholders involved and many high profile
involved stakeholders involved.
2 Duration <= 3 Months <= 12 Months >12 Months
3 Budget at
Completion <= 250,000 <= 1,000,000 >1,000,000
(USD $)
4 Risk profile Low Medium High
5 Strategic Internal interest Some direct impact to Affects service
importance only to MDA service delivery and/or delivery and/or
relates to low priority directly relates to key
initiative for government initiatives of
strategic plan government strategic
plan.
6 Political Not significant Some political Major political
importance political implications implications
implications
7 Dependencies Low risk Medium risk Major high risk
and dependencies or dependencies or dependencies or
Interrelated interrelated interrelated projects or interrelated projects
projects (Multi projects or no affects existing or affects existing
sectorial) impact on government operating government
existing systems operating systems
government
operating
systems

6
8 Level of Impact a single Impacts across section of Impact a number of
change department in a departments in a MDA MDAs or whole of
management MDA government
required
(Multi sector)
9 Reporting Internal to MDA Limited reporting Many reporting
requirements only and update channels; required to channels; required to
stakeholders keep key stakeholders always consult key
regularly is informed and satisfied stakeholders, keep
required them informed and
satisfied
10 Programme Single IT project May contain IT and non- Contain IT and non-IT
(collection of IT scopes. E.g. BPO scope. E.g. NSIS
related (Solution, building (Hardware & software
projects) infrastructure, strategy, supply, install and
etc.) commission, building
infrastructure, mass
registration, etc.)

Using table 2 will result in a number of options under large, medium and/or small
columns. The evaluation below will be applied:
Table 3: Classification Analysis Interpretation
Project Criteria Comments
Classification
Large 1) Selection of an option indicating that the project Mandatory
affects service delivery and/or directly relates to key
initiatives of government strategic plan – Attribute
No.5; and
2) Selection of an option indicating dependencies Mandatory
and Interrelated projects (Multi sector) – Attribute
No.7; and
3) Any Three or more options in the large column Any other three
options in large
column
Medium 1) Any one option selected in the large column ; and Mandatory
2) Any Four or more options selected in the Medium Any four options in

7
 column medium
Small Remaining combinations

After the initial classification of the project is assessed, make appropriate allowances for
other (qualitative) factors and adjust the classification of the project accordingly.
Document all assumptions made during this decision.
After the initial classification of the project is decided, the amount of project
management activity and documentation required can be determined. For small
projects, all documentations should be brief while detailed for medium and large
projects.
2.2 Expected Documents
The following section provides guidance on documents expected at project setup /
initiation stage. However, as a first step, the Initiator should establish the classification
of that initiative: small, medium or large and this will help in deciding the level of
details expected for the documentations to be developed thereafter.
For example, small projects documentation should be brief. Project documentation
templates for small and medium/large are available in the tool kit to help reduce on
overhead and get started quickly.

These documents below are expected for all projects regardless of classification;
however appropriate details should considered with the help of templates designed.
These documents can be developed in parallel or simultaneously depending on
resources availability. However, this guide recommends the following sequence:

Concept Business Project

TOR/SOR
Paper Case Charter

A merger of concept paper and TOR/SOR is possible. However, all IT projects should
have a business case and thereafter a project charter.

8
 2.2.1 Concept Paper
A concept paper will be the first document; high level, which should be used to
conceptualize a born idea, mandate or directive from government. It should be
developed by Subject Matter Experts (SME) from appropriate user department in a MDA
in consultations with internal and external stakeholders. The concept should cover the
following areas; however the level of detail will depend on the project classification:
i. Introduction (include the classification of that initiative and the results of the
evaluation)
ii. Major and specific objective
iii. Scope of work
iv. Planned activities and timelines
v. Indicative budget and potential funding source.
vi. Expected inputs
vii. Expected outputs
viii. Expected benefits
ix. Contributions to the functions/objectives of the MDA
x. Roles and responsibilities
xi. Background or reference documents
A concept paper or thematic/technical paper should be presented and approved within
the user department before its presentation to Top Management Team (TMT) or Agency
Board (where applicable) for consideration. After TMT (or board where applicable)
approval, detailed terms of reference should be developed. Concept paper templates
for small and medium/large initiatives are available to help you expedite the
development of this document.

2.2.2 Terms of Reference (TOR)/ Statement of Requirements (SOR)

Detailed Terms of Reference (TOR) must be developed to specify a comprehensive
scope statement of the initiative. Effort is expected to be put in at this stage to ensure
that the TOR/SOR covers all the work required for the product or service to be acquired,

9
 and only the work required, to complete the initiative successfully. It is further
recommended that a mention of what is not included in the scope is paramount in
managing stakeholders’ expectations.
The scope statement should cover the following areas and details should depend on the
project classification:
i. Product or service scope requirements – should include the technical features,
functional and non-functional that characterize a product, service or results
ii. Project scope requirements – the work that needs to be accomplished to deliver a
product, service or results with specified features and functions. For example
project management requirement, logistics requirements, procurement
requirements, project outcome operations & maintenance support requirements
etc.
iii. Assumptions on which the scope is based
iv. A high level Work Breakdown Structure (WBS) and its dictionary. This will enhance
stakeholders’ understanding of the intended product or service.
v. How scope verification will be ensured on completion of project deliverables.
vi. How scope quality control will be carried out; regarding correctness of deliverables
and how they will meet the quality requirements for product or services.
vii. How scope control will be ensured – monitoring the status of the project and
product scope; how to manage changes to the scope baseline to avoid scope creep.
The above mentioned will constitute a baseline scope statement for the initiative; which
will be monitored, verified and controlled throughout the project lice cycle. It is
important to note that the completion of a:
I. Project scope will be measured against the Project Management Plan (PMP) –
ref to project planning stage for details of the PMP.
II. Product or services scope will be measured against the product or services
requirements which should be well defined in TOR
It is extremely important that scoping sessions are organized under the guidance of a
Project Owner and key stakeholders to define the initial scope in detail. A scope should

10
always be signed off by the Head of function initiating the project; and a business case
thereafter should be developed based on the signed off scope of work.

2.2.3 Business Case

A business case document should be developed to justify the viability, bankability and
feasibility of the intended initiative; technically, commercially, politically, socially and as
well as risk responsive. All initiatives should have a business case based on the
approved TOR.
The business case should cover the following areas and details should depend on the
project classification:
a. Project overview
i. Project description
I. Project scope
II. Goals and objectives
III. Project viability: bankability, technically, commercially, politically,
socially, risk responsive and operational
b. Project economics (CAPEX and OPEX)
c. Project implementation timelines
d. Proposed source of funding
e. Project benefits: social, economic, mandate or political – government mandate
f. Project performance and evaluation criteria
g. Project risks and mitigation strategies
h. Environmental Impact Assessment
i. Project critical success factor
j. Major project milestones
k. Project governance structure
l. Identification of high level stakeholders (internal & external)
m. Approvals

11
The business case development should be supervised and approved as described in the
process 1 above. Templates for both small and large projects should be used to
expedite their development respectively. Refer to the Project Feasibility Support guide
for more details.

2.2.4 Project Charter

The project charter will be the final output in the project initiation stage, which must be
used as a tool to authorize the project to move into planning stage. It is a summary of
all documentations developed at initiation stage. Templates for both small and large
projects should be used to expedite their development respectively.
The project charter should cover (high level) amongst others the following areas:
a. Project overview
b. Project objective
c. Project Scope of Work (SoW)
a. Product or service scope of work
b. Project scope of work
d. High level deliverables and milestones
e. High level timelines estimates
f. Project Budget at Completion (BAC) estimates
g. High level project risks and mitigations
h. List of key stakeholders
i. Project manager selection and appointment
j. Sponsors commitment of resources
k. Sign off and approval
The project charter development should be supervised and approved as described in the
process 1 above. Templates for both small and large projects should be used to
expedite their development respectively.
It is only after the project charter has been signed off that the project manager will be
allowed to engage resources in the planning of the project.

12
2.3 Project Classification Vs Required Documentation
The documents described above should be either brief or detailed depending on the
scaling of the initiative. The table below should be used to determine the level of detail
required:
Table 4: Project Initiation Documentation requirements
No Documentation Small Projects Medium Projects Large Projects
1 Concept Paper Brief (1 -2 Pages) Detailed Detailed
2 TOR/ SOR Brief; may be Brief Detailed
combined with
concept paper
3 Business Case Not Necessary; Brief (Short form) Detailed (Long form)
may be combined
with concept paper
4 Project Charter Brief (short form) Brief (short form) Detailed (Long form)

For a small project, the project sponsor should approve all documentations. For
medium projects, the steering committee should approve; and large projects should be
approved by the steering committee and accounting officer.

2.4 Guiding Principles at Initiation Stage

a. No Business case no project
b. No project charter no project
c. No Steering Committee no project
d. Each project must have a Project Sponsor
e. Each project must have a Project Owner
f. Approved project charter will be a prerequisite for starting on the detailed
project planning phase.
g. A Steering Committee may be nominated at the approval of concept paper.
h. A Steering committee will review the business case; and may approve or reject
it. The reason for rejection should be clearly spelt out.

13
 i. Idea generation should be followed by the concept paper creation. A project
Owner must provide administrative responsibility for this process. For obvious
initiatives (or directives) a concept paper and business case may be combined.

3 Tools and Techniques

3.1 Project Classification Tool

An Initiative Classification tool, which is based on the description in section 2.1 of this
guide could be used to evaluate and determine if the initiative will result into a small,
medium or large project. This tool will support project initiators in decision making and
to determine a level of documentation and rigor required for a proposed project.

Project Classification
Tool

14