ICT Standards and Guidelines

Segment 202

Software Applications

The Project Definition

Document
(Version 2.0)
Table of Contents – Project Definition Explained
1.0 Introduce the Project...............................................................................1
1.1 The Project Definition Data Page.........................................................1
1.2 The Global Objectives of the Ministry or the Agency...............................1
1.3 The Purpose of the Project.................................................................1
1.4 Alternatives and Options....................................................................2
1.5 Background and History of the Project.................................................2
1.6 Required Research............................................................................3
1.7 Identify the Stakeholders...................................................................3
1.8 Critical Success Factors (CSF).............................................................4
1.9 User Profiles....................................................................................4
2.0 General Analysis of Requirements............................................................5
2.1 Business Objectives and Goals............................................................5
2.1.1 Identify the Business Objectives of the Project............................5
2.1.2 Identify Business Goals of the Project........................................6
2.1.3 Identify the Exclusions.............................................................6
2.2 The Current System (AS IS)...............................................................6
2.2.1 How to do it with UML?............................................................7
2.3 Identify Stakeholders Requirements....................................................7
2.4 The Status of the Business Processes..................................................8
2.5 Analysis of Requirements...................................................................8
2.5.1 How to do it with UML?............................................................8
3.0 The Scope of the Project.........................................................................10
3.1 Determine Whether to Develop or Acquire the Software.......................10
3.2 Identify the Deliverables of the Project...............................................10
3.2.1 The Deliverables List.............................................................11
3.2.2 The Features of Each Deliverable.............................................11
3.2.3 Exclusions............................................................................12
3.3 The Product Solution Concept...........................................................12
3.3.1 A Note on Software Architecture..............................................12
3.4 Project Constraints and Assumptions.................................................13
3.4.1 Project Assumptions..............................................................13
3.4.2 Constraints..........................................................................13
3.5 Establish Project Standards..............................................................14
4.0 Risk Management...................................................................................15
4.1 Risk Analysis Table..........................................................................15
4.2 Risk Response Planning...................................................................15
5.0 Project Measurements............................................................................16
5.1 Volumes and Loads.........................................................................16
5.2 Estimated Schedules.......................................................................16
5.3 Estimated Costs..............................................................................16
5.4 Evaluate the Project........................................................................17
5.5 Identify Performance Indicators........................................................17
5.6 Assess the Impact of the Project.......................................................17
6.0 Early Planning Activities.........................................................................18
6.1 System Deployment........................................................................18
6.1.1 How to do it with UML?..........................................................18
6.2 Team Requirements........................................................................19
6.3 Configuration Management...............................................................20
6.4 Quality Planning..............................................................................20
 6.5 Communications Planning................................................................20
6.6 Training Requirements.....................................................................21
7.0 Related Project Issues............................................................................22
7.1 Pending Issues to Resolve................................................................22
7.2 Terminology and Glossaries..............................................................22
7.3 Project Document Repository............................................................22
7.4 Attachments and Appendices............................................................23
1.0 Introduce the Project

This section provides an introduction to the project, its general purpose, scope and the
problems or opportunities it is meant to address. It also presents some background
about the project.

1.1 The Project Definition Data Page

This is a standard form to be filled as and when the Project Definition is built. It has such
data as:

 The project name

 The project version
 The department issuing the project
 The names of the persons involved in its preparation
 The tracking history showing the changes that took place on the document and
who made the changes

The Project Definition Template contains a the Document Data page.

1.2 The Global Objectives of the Ministry or the Agency

Whether the project documents will be reviewed only internally or for external use, it is
important to be in full agreement on the global objectives of the Ministry or Agency.
These usually change with time and with the introduction of new legislation and social
conditions.

In this section, present a brief summary of the Ministry or Agency’s charter, objectives
and long term vision.

1.3 The Purpose of the Project

Projects are usually initiated when either a problem has to be solved or responded to or
when an opportunity arises. Other projects arise to respond to mandatory conditions.

In this section, state the purpose of the Project. The following questions can be asked:

 What is the project about or what is its mission?

 Who wants the project?
 Why do they want it?
 When is the project to be completed?
 Who is the main champion or the person who will be the main driver behind it?
 Can it be confirmed that that the project meets the global objectives of the
Ministry or the Agency?

Example:
”The World Bank requires the use of a set of project management reports collectively
called LACI. The LACI Reports module needs to be developed and interfaced with the

Project Definition Document (With Explanations) Page 1

Ministry’s already running Project Control System. The project consists of a development
effort starting from requirements analysis and proceeding through the full cycle of
design, coding, testing and implementation. The World Bank is the main driver behind
this project and expects it completed before the next interim review”.

The statement should be brief and should quickly indicate the scope and nature of the
project.

1.4 Alternatives and Options

List the various alternatives and options that may arise in this project.

Example:
The Department Director wishes to investigate two different paths: inhouse or
outsourced development.

Example:
Different options result in different functions, pricing or scheduling and so the Project
Manager would need to study these when tuning the Project Triangle (Functions,
Schedule and Budget). Examples:

 Functions: the set of reports may be replaced by a report generator.

 Costs: consider the option to acquire leased equipment at a later stage.
 Timing: consider the option of developing documentation in parallel with the
testing rather than after full acceptance.

Remember that at this stage, only broad alternatives are to be considered. During the
Planning Phase, detailed alternatives and options be considered and selected from.

During the rest of the Project Definition, whenever applicable, use the listed alternatives
to further analyze such issues as:

 Costing
 Scheduling
 Goals
 Risks
 Quality control
 Users
 Etc

1.5 Background and History of the Project

Each project has a specific history, the steps that lead to the current position. In this
section, present the background of the project.

Example:
“During the past two years, there have been many attempts to develop a robust
attendance analysis system. There are 3 Ministries already using such modules with 2
others considering its development. Some were developed internally. Others were
outsourced. Two were developed in Arabic while the others were part of an existing
package developed in English.”

Project Definition Document (With Explanations) Page 2

1.6 Required Research

There are cases where the Agency might need to do some research before proceeding.
The reasons for such research are the following:

 To analyze the requests of the users

 To research the uses and applications of new technologies
 To survey a specific situation such as the volumetrics of an attendants system:
how many staff in each location?

Prepare a summary of any brief research already completed and the findings.

Moreover, if more detailed research is required, it would be a good place to state such
requirements and indicate when such research would be done: during the Initial or
during the Planning Phase.

1.7 Identify the Stakeholders

Stakeholders are any persons or parties that have a vested interest in the project. These
could be any of the following:

 Owner or Sponsor or Champion

 Management
 Internal customers
 The Agency as a whole
 The financier: Agency / Ministry of Finance / Donors
 Internal users of the project’s products
 The Project Manager
 The Project Team
 Suppliers / Contractors
 Opponents of the project
 The community
 The citizen
 Innocent third parties
 The private sector
 Auditors (Internal / External)
 The Human Resource Unit
 The Quality Assurance division
 Etc

List all stakeholders and identify their interest (Positive or negative) in the project. It is
only by determining who the stakeholders are that the Project can ensure that their
expectations can be analyzed and met.

Project Definition Document (With Explanations) Page 3

1.8 Critical Success Factors (CSF)

These are the objectives that, if all else fails, the project must meet. In other words, it
must meet these objectives as a minimum for it to succeed.

The items are critical to those who will benefit from the project and to those with the
responsibilities for judging success criteria, ie, all stakeholders.

The purpose of listing the CSFs is:

 To clarify in the minds of the project team and service managers what the
essential benefits are that the project will deliver.
 To identify the CSFs so that their risks can be analyzed.

Prepare a list of all Critical Success Factors.

1.9 User Profiles

Define the audience of the product or its users by following these steps:

1. Identify the groups in question: users, accountants, citizens and managers

2. State the goals of each group or what they hope to achieve by using the product
or the service.
3. Analyze their competence if that is relevant to our project.
4. In case the project is to be phased, it would be of interest to identify the users by
phase.

Example:
“One group is presented: the system will be used by our technical team. They consist of
around 20 engineers. They hope to have access to project data as well as documents
such as technical drawings and specs. Most of the engineers are computer literate. They
only require training on the actual product itself. At a later stage, it may be possible to
open up the use of the application to the consultants working with the engineers.”

Example:
“The Agency’s Library will be used by category 1, 2 and 3 staff. They hope to have
access to all research material, survey results and works completed in other
non-governmental agencies. These users are not used to desktop PCs and will require to
be PC competent. At a later stage, the Library may be opened to persons from other
Agencies.”

Project Definition Document (With Explanations) Page 4

2.0 General Analysis of Requirements

All projects exist to meet the requirements of the stakeholders. This is easier said than
done. Requirements Analysis is one of the key areas in any project and is often the
cause of poor results. The reasons are many:

 No analysis takes place

 Unclear requirements are noted
 Requirements are noted but are conflicting from one stakeholder to the next
 Requirements are not realistic
 The analysis is carried out by persons not capable of such work
 The analysis is carried out but the results are not approved
 The results are approved but there is no quality control scheme that defines how
to confirm that requirements have been met
 Etc

This section covers the activities carried out in the Initiation Phase for Requirements
Analysis. The results of this analysis are not the final results for the Analysis. The final
agreement on what is really required is eventually stated in the Project Plan.

This analysis is a preview and is used to establish other elements in the Project
Definition.

Forward Look: there is a corresponding but much more elaborate set of activities for
the Analysis of Requirements in the Project Planning phase.

2.1 Business Objectives and Goals

This is the financial or administrative side of the project. It highlights the reasons the
project is required. It quantifies them when possible. It is the basis for assessing the
feasibility of the project.

2.1.1 Identify the Business Objectives of the Project

Objectives are the aims or targets that should be met by executing this project. They
answer such questions as:

 What is to be achieved?
 When to achieve it?

These Objectives can be operational, financial, organizational, etc.

Examples:

 A Library Control System has the following objectives: controlling the

documentation, providing knowledge sharing and setting up a peer review
scheme.
 A Donor Management System aims at implementing a project management
system that controls all costs and expenditures of all our donors.

Project Definition Document (With Explanations) Page 5

  The Studies Database Application aims at setting up a profile for each study
carried out in the Government, the project would avoid duplication and allow
quick access to previous information.

2.1.2 Identify Business Goals of the Project

Goals are different from Objectives. Objectives are the business targets. Goals are the
set of measures that will confirm that objectives have been reached within a specific
period.

Goals are therefore, “Measurable objectives”. They must have a defined measure and
the time within which to achieve it.

Examples:

(The following examples include Objectives as well as Goals)

 We want to introduce Office Technology to improve communications by reducing

the number of printed memos by 50% during the first year.
 The Procurement Workflow introduced aims at reducing the bidding cycle from 3
months to 6 weeks. This should be achieved 1 year after the start of the system.
 Launching a web site for the dissemination of information to the citizens aims at
the reduction of face to face and telephone inquiries by 40% in the first 2 years.

2.1.3 Identify the Exclusions

As important as the Objectives and Goals of the project are the non goals or what is not
to be included. This is a very important section as it avoids a lot of risks by stating early
all the features (Functions) or activities (Such as training, maybe, or maintenance) that
should not be included.

This is the Project Manager’s way of ensuring that there are no “hidden” assumptions or
“implied needs”.

Note: Do not include exclusions for Products as these are included in Section 3.2.3. Only
exclusions for the system should be listed.

Examples:
The Library will not include business magazines, only technical journals.
The campaign will only cover Beirut and not the rest of our cities.

2.2 The Current System (AS IS)

This section presents a general review of the current system or the “AS IS” system. The
purpose is not to analyze the system as in most cases, it would be changed. The purpose
is to note down the baseline from which the change is to be made.

Another purpose would be to ensure that the scope of the system or process being
automated is clear.

Project Definition Document (With Explanations) Page 6

A separate Technical Paper introduces Business Modeling and discussed the uses
and applications of the various UML diagrams that can be used in a Software Engineering
Process.

2.2.1 How to do it with UML?

1. Define the scope of the business system: where it starts and ends, what it
includes and what is excludes.

2. Identify the Use Cases of the system. The Use Cases identify the functionality
required from the system in question. They answer questions such as: What does
the system do? What Actors does it respond to? At this stage, there is no need to
identify use cases related to technical issues such as log on, log off, backup, etc.
Only the Use Cases related to the functionality or use of the system are to be
identified.

Should any Use Case not be clear, it can be described in text form, but very
briefly.

3. Identify the main Actors using the Use Cases. These are the persons or systems
outside the required system that trigger the Use Cases. Each Actor has an
observable and measurable benefit from one or more of the se Cases.

4. Plot the Actors and Use Cases on a Use Case Diagram.

5. Identify the main Business Objects or Classes. Describe some of them if they
need to be clarified. Again, this is a broad definition of the Classes. At this stage,
the methods and behavior (Methods) for each Class are not defined. The purpose
of identifying Business Objects is to ensure that there is a clear understanding of
the workings of the system.

Remember that the above shows WHAT the system does and not HOW it does it.

The above UML model is sufficient to define the functions of the system.

Forward Look: there is a corresponding but much more elaborate set of activities for
Modeling the Current System in the Project Planning phase.

2.3 Identify Stakeholders Requirements

There are different stakeholders for each system. Stakeholders hold the system in view
of the benefit it gives them. Their requirements are therefore critical as these are the
parties that will eventually return and demand the requirements from the working
system.

This section contains any type of requests a stakeholder (internal customer, end user,
management and so on) might have on the system to be developed.

It also contains references to any type of external sources to which the system must
comply such as:

 Statement of work
 Bidding documents

Project Definition Document (With Explanations) Page 7

  Mission statements
 Problem statements
 Business rules
 Laws and regulations
 Legacy system description and documentation
 Business models

Identify the known requirements of the Stakeholders at this stage.

2.4 The Status of the Business Processes

At this stage, it would be generally known whether the Ministry or Agency is satisfied
with the system as it is. It would also be known whether the Ministry or Agency see any
reason to change the current system due for example, to changing circumstances, laws
or organization.

In this section, the Project Definition should indicate the following:

 Whether improvement or change is required in the business processes or not

 The nature of the required change
 The reason for the required change
 The purpose of the change

Forward Look: there is a corresponding but much more elaborate set of activities for
the Improvement of Business Processes in the Project Planning phase.

2.5 Analysis of Requirements

This section presents a general review of the required system or the system “TO BE”.
The purpose of this section is the following:

 To determine the scope of the new or required system

 To identify all the known requirements of the stakeholders
 To generate the first draft model of what the system should do.
 To determine whether process improvement or reengineering is required

A separate Technical Paper introduces Business Modeling and discussed the uses
and applications of the various UML diagrams that can be used in a Software Engineering
Process.

2.5.1 How to do it with UML?

1. Define the scope of the new or the required business system: where it starts and
ends, what it includes and what is excludes. This may differ from the AS IS
system.

Example:
In the new stock system, we will be controlling the shelf and bin locations.

2. Revise the main Use Cases of the AS IS system and plot them on a diagram.

Project Definition Document (With Explanations) Page 8

3. Identify the main Actors of the required system.

4. Should any Use Case not be clear, it can be described in text form, but very
briefly.

5. Identify the required Business Objects. Describe some of them if they need to be
clarified.

Remember that the above shows WHAT the required system does and not how it does it.

Forward Look: there is a corresponding but much more elaborate set of activities for
the Required System in terms of Functional and Technical Design and Specification. This
will be presented in the Project Planning phase.

Project Definition Document (With Explanations) Page 9

3.0 The Scope of the Project

The Project Scope defines the activities that limit the project or that fall within the
responsibilities of the Project Manager to complete. This covers all deliverables of the
project.

Examples:

 All development will be carried out internally

 Development will be carried out internally. However, the Agency will acquire a
commercial library of standard interface classes.
 The web site will be implemented using a server with an Internet Service Provider
(ISP) and not our own server to improve reliability, performance and accessibility.
 All graphics will be outsourced to a graphic design agency.
 The application will be operated by the vendor for 2 years the last 6 months of
which will be a handover period.

3.1 Determine Whether to Develop or Acquire the Software

Although at this stage, it may be too early to decide what the mode of the software will
be, it is important to state all the criteria that are known that will help in making such
decisions as:

 Will the software application be standard enough to be available in the market,

off the shelf?
 Will other Agencies or Ministries have applied the software and can then provide
us with the application to use?
 To what extent will available software need to be customized?
 If the software is to be developed, will it be better to develop it internally or to
outsource it?

The procedure for answering the above questions is presented in the Main Document for
software applications.

3.2 Identify the Deliverables of the Project

Products are often confused with Deliverables. In common usage, products are usually
given more importance than the Deliverables of the Project.

Products are the actual applications that the Project hopes to produce or build or
acquire.

Deliverables are ALL that the project hopes to provide its customer with. These include
warranties, maintenance, documentation, training and other commitments. (Some may
call these “Services” which are like products).

The segment shall refer to all the above as “Deliverables”. A typical list for a software
application that is developed by a software vendor is the following:

 The software in object code

 Users manuals

Project Definition Document (With Explanations) Page 10

  License for use
 Installation instructions
 Implementation support
 Warranty
 Maintenance
 Support
 Training
 Other documentation (Tutorial, demos, etc)
 Source code
 Etc.

3.2.1 The Deliverables List

Deliverables consist of the application itself as well as the items needed to use and
operate it. These may be applications, products, systems or services or a combination of
these. They can also be other commitments to be undertaken such as documentation,
training, maintenance, etc.

This section consists of a list of all known deliverables (As some may not be known at
this stage). For each deliverable, the following data elements should be identified:

 Deliverable name
 Features of the item (See details below)
 Description of the deliverable
 The phase during which the item is delivered
 Acceptance criteria
 Assigned to (Team Member Name if available, otherwise a generic role)
 Delivery date
 Estimated date of delivery

Again, note that the above information may not be available for all deliverables at this
stage.

3.2.2 The Features of Each Deliverable

This section should list all the functions or features of the product or the service or the
system that the project aims to produce.

For various reasons, you may have different functions and features to introduce. List all
such alternatives in this section.

There is no need for details here, just a list of all features that should be in the product.
This is the first statement of the “Product Scope”.

Examples A General Accounting System made up of the following modules . . .

One CD containing all software products in object code

Warranty for 1 year
Maintenance for 3 years after the completion of the warranty
Two sets of printed training manuals
Installation procedures

Project Definition Document (With Explanations) Page 11

3.2.3 Exclusions

Exclusions are important because they warn against what some stakeholders might
assume will be delivered.

Examples:

 The software training manuals will only be delivered in Arabic not in English
 The training will cover the users and not the software developers
 No source code will be delivered with the item
 The web site will not include payments.

3.3 The Product Solution Concept

This section defines how the product is to be introduced to solve the problems listed in
the earlier section. The Product Solutions Concept applies to the Project Scope It
answers such questions as:

 What technologies can be used?

 What development platforms?
 Databases?
 Software Architecture?
 What technical approaches to follow?
 What engineering methods to use?

Examples:

 The current release of the database will be used. It will upgraded to the most
recent release when enough experience is gained with the new version.
 Existing units will be converted to be object oriented. This will be carried out in
phases to ensure a smooth transition.
 Due to a global agreement with company X, their Server is recommended though
there is no restriction to use it. This will reflect itself in lower overall costs.
 All user interface API calls will be using standard library X which has been used in
the earlier application.
 Multi-tier technology will be used.

It might be too early to define Product Solutions at this stage. Sometimes internal
customers may request it because there are constraints such as legacy systems,
standards or commercial agreements. In some cases, the Product Solutions are very
clear. In others, there would need to be a list of options.

3.3.1 A Note on Software Architecture

As the size and complexity of software applications increase, the design goes beyond
defining data and control flows. The problem becomes a matter of designing the
structure of the overall system. This is called System Architecture.

Structures or architectures include addressing such issues as:

 Global control issues

Project Definition Document (With Explanations) Page 12

  Communications protocols
 Physical and logical distribution of system components
 Scaling issues
 Performance issues
 Interfaces and data exchange

Many of the above issues are usually assumed when designing systems such as
multi-tier architecture, etc. Others need careful solution planning.

Software architecture relates to the Product Solutions concepts that are to be identified
in this section. At this stage, state whatever is known or projected for software
architecture.

3.4 Project Constraints and Assumptions

Most projects are subject to assumptions and constraints that are related to one or more
sides of the Project Triangle: scope, schedule or budget. It is important to identify these
constraints and assumptions early in the life of a project, first to reduce the risk and
second, to analyze the resulting trade-off’s that such assumptions and constraints
require.

3.4.1 Project Assumptions

Assumptions are usually accepted truths or aspects of a project that are not clearly
voiced or stated. Most of the time, they reflect “implied” requirements of stakeholders
that are not openly identified.

Assumptions may therefore lead to misunderstandings and disputes.

Examples:
“Management assumes the team will be disbanded after the project”.
“The internal customer assumes there will be training before the delivery of the
application”.
“The tax structure is assumed to remain unchanged throughout the duration of the
project”.

List all the known assumptions here. At a later stage, the Risk Management activity will
need to address these constraints to ward against their occurrence.

3.4.2 Constraints

Describe the principal constraints and limitations under which the project must be
conducted. Constraints cover all aspects of the project and affect the 3 sides of the
triangle. Such constraints as the following should be investigated:

 Environment
 Timeframes and deadlines
 Skill levels
 Resource availability
 Budget
 etc.

Project Definition Document (With Explanations) Page 13

Examples:
“The software must be implemented before the next eGovernment workshop”.
“The team has no Java experience while the acquired libraries are all Java based”.
“Funding is only available for upgrading the application and not for new development”.

List all known constraints here. At a later stage, the Risk Management activity will need
to address these constraints to ward against their occurrence.

3.5 Establish Project Standards

The purpose of this activity is to look forward towards the use of any existing or to new
standards.

These may be working standards for such processes as design, development and the
communications (Social not electronic) of the whole project such as:

 Modeling standards: how much to use of the UML?

 Which Case Tools to use for Modeling, ERD, etc?
 Testing standards: which methodology to follow?
 Programming standards
 Error handling
 Naming of components, variables, etc
 Security standards
 Configuration Management
 Quality Assurance
 GUIs: buttons, colors, screen layout, screen practices, reports, etc

At this stage, the Project Definition document simply needs to identify these standards.
No attempt at this stage is made to document them or start planning for their use.

Project Definition Document (With Explanations) Page 14

4.0 Risk Management

The Risk assessment document follows the structure of presented in the Risk
Management segment. Risk Management is one of the few sections in the Project
Definition document that has to be completed in detail.

Complete the activities required by the Risk Management processes presented in the
above mentioned segment.

The end result of this section is the following:

 The list of all risky events that are identified at this stage.
 The data elements required for each event as per the Risk Event Form in the Risk
Management segment
 The Risk Analysis Table showing the Top Ten risks
 Any Risk Leverage computation carried out on specific events

Risk Analysis will be reviewed when commencing with the next phase: Planning.

4.1 Risk Analysis Table

Prepare the Risk Analysis Table as per the procedures defined in the Risk Management
document. This table will include a list of all events that may damage the product or the
project. For each event, there will be a set of parameters to be computed such as the
following example:

Event Probability Impact Exposure

(Out of 100%) (Out of 10)
Changing Technology 80% 6 4.8
Stoppage of Funding 40% 10 4.0
Changing Standards 60% 6 3.6
Developer Disloyalty Risks 60% 6 3.6
Bugs in Development Tools 40% 8 3.2
Changing Specs 30% 6 1.8
Improperly Trained Users 30% 6 1.8
Total Project Exposure 22.8

4.2 Risk Response Planning

Depending on the nature of the risky event, there is a need to develop plans to respond
to such an event if it takes place.

There are four types of responses defined in the Risk Management segment. These are
briefly:

 Risk Prevention or Avoidance

 Risk Mitigation
 Active Risk Acceptance
 Passive Risk Acceptance

Each type of response will eventually affect the project plan.

Project Definition Document (With Explanations) Page 15

5.0 Project Measurements

Various measurements need to be known when defining the project. At this stage, the
level of detail is not too deep. Whatever is known has to be listed. In some cases, and
depending on the project, specific measures have to be analyzed or researched.

5.1 Volumes and Loads

This covers the following workload measurements which are all related to the sizing of
the software application or the IT system:

 The size of the master files

 The number of transactions per hour, day or month: these may have to be
grouped by location or by department or by software unit or component
 The number of users: again, grouped by location or by software unit or
component
 The number of pages to be printed per month
 The expected number of hits on the web site

The above volumetrics have a direct effect on the following:

 The distribution of the PCs

 The speed and capacity of various items affecting performance

The later Planning Phase will need to have accurate figures for the above. At this stage,
these can be general and indicatory.

5.2 Estimated Schedules

At this stage, the following needs to be estimated:

 Major milestones
 Durations of critical activities

The Planning Phase will have to have an accurate knowledge of the scheduling of all
activities in the project.

5.3 Estimated Costs

At this stage, the following needs to be prepared:

 A list of all resources in the project: labor, material, equipment, subcontracts or

direct costs
 Estimated costs of the resources
 A list of all tangible or quantifiable benefits

Whatever information can be provided to prepare the eventual Cost Benefit Analysis
should be identified in this Section.

Project Definition Document (With Explanations) Page 16

The Planning Phase will have to have an accurate knowledge of the costs of the
individual elements of the project.

5.4 Evaluate the Project

Prepare financial evaluations of the project which can be any of the following:

 Feasibility studies
 Discounted cash flow (NPV and IRR)

Prepare the same for alternative projects or alternative paths within the project.

Note: the choice between different alternatives, options or projects can be subjected to
an Evaluation and Selection process as presented in the Selection and Evaluation
Framework segment.

At this stage, the above analysis should be sufficient to allow a decision as to whether to
continue or not.

5.5 Identify Performance Indicators

Performance Indicators are used to assess the performance of various aspects of the
software project. Software itself, has a major set of metrics such as the number of bugs
per developer, per unit, etc. The configuration management process has a fair number of
performance indicators described in the related segment. Risk Analysis has its own, also
described in the Risk Management segment.

Software Metrics is a wide area and is out of the scope of this segment. There is a
section in the Appendix that presents a general set of major metrics required for a
software application project.

In this section, indicate whatever PIs are known. More details will need to be defined
during the Planning Phase.

5.6 Assess the Impact of the Project

By now, a global view of the project should be had. The impacts of the project can then
be identified. Some of these may need to be catered for in advance:

Organizational issues
Legal necessities
Technical necessities
Competitive or strategic advantages
Management requirements
Political requirements

Also include in this section the impact of the current project on other projects in the
Ministry or Agency.

Project Definition Document (With Explanations) Page 17

6.0 Early Planning Activities

The following sections are essentially planning functions. However, they are indicated
because some of these issues may be known in which case they can be listed. If they are
not, there is no real need to list them.

Furthermore, the Planning Phase results in a document: the Project Plan. It will have the
same structure as the Project Definition document but in must more detail. The following
sections will be elaborated then.

6.1 System Deployment

Most software applications will probably be setup on a network. The current technology
requires a very careful and intricate deployment of software components on a network.
Furthermore, the project itself needs to define where specific servers and PCs are
located.

Indicate in this section what is known about the deployment of the software and
hardware component.

A separate Technical Paper introduces Business Modeling and discussed the uses
and applications of the various UML diagrams that can be used in a Software Engineering
Process.

6.1.1 How to do it with UML?

The UML has two major diagrams called the Implementation Diagrams:

 The Deployment Diagram: Defines the components in the software application

and their relationships: libraries, executable programs, database engines,
databases, office tools, etc.
 The Component Diagram: Defines where the different components are placed and
is essentially a way of describing the layout of the technical parts of the system:
servers, hubs, stations, computers, units such as scanners, printers, etc.

The initial Use Cases defined earlier will determine much of the infrastructure. However,
the technology policies of the Ministry or Agency are also of importance (Performance,
modernization, compatibility with legacy systems, etc). Finally, cost and lead time
considerations come into such infrastructural issues as:

Operating systems
RDBMS’s
Architectural categories: client/server, multi-tier, central system
Web servers
Other types of specialized servers
WAN’s and LAN’s

The deliverable of this activity should include any justification needed to move from the
current to the new infrastructure.

In this section, whatever is currently known can be modeled in general terms.

Project Definition Document (With Explanations) Page 18

6.2 Team Requirements

By the start of the Planning Phase, most of the key players in the team should be in
place. The following information can be listed, if known:

Define the team structure

Identity of team members as generic roles specifying any that are known
Define the responsibilities of each member
Define the relationship between team members
Define the reporting lines
State where the team will reside

During the Planning and the Building Phase, all of the above would need to be elaborated
and determined in detail.

Project Definition Document (With Explanations) Page 19

6.3 Configuration Management

As Configuration Management is an essential part of any project, at this stage, the

Project Definition Document should contain a brief look into how this process is to be
implemented in the project. (Refer to the segment that presents Configuration
Management in full).

Such elements as the following may need to be identified:

 How is Configuration Management to be applied?

 Any specific software products to be used?
 Will the project follow any specific configuration identification scheme?
 What is the standard operating procedure for Change Control?
 Who are the authorized issuers of Change Requests?
 Who is on the Change Control Board?
 Etc

Again, at this stage, whatever is known is entered. At a later date, the Project Plan will
completely define this process.

6.4 Quality Planning

A key process in project management is Quality Management. It would be a bit too early
to define and plan Quality at this stage. However, as with the other topics in this main
Section, whatever is already known about Quality Planning can be entered.

Note that Quality Management is a separate segment that should be consulted for the
whole process of Quality Planning, Assurance and Control.

6.5 Communications Planning

One of the most important issues in Software Projects is the broad communications that
should be followed. This is part of Quality Assurance as well.

Communications Planning covers all channels and media used to share and manage
information in a project. It would be a bit too early to define and plan Communications
at this stage. Whatever is already known about Communications Planning can be
entered.

Communications planning develops a set of items to be communicated for which the

following six questions need to be answered:

1. What information is needed?

2. What Level of urgency?
3. Who needs it?
4. When or how frequently is it to be produced?
5. In what Form or way will it be sent?
6. Where is it to be kept?

Use the Communications Planning form which can be downloaded from OMSAR's web
site for ICT Standards and Guidelines.

Project Definition Document (With Explanations) Page 20

6.6 Training Requirements

In a software project, training is varied and can be applied to a variety of human

resources such as developers, network administrators, users, management and auditors.

It is not possible at this stage to define the full requirements for training. However, as in
all other topics in this section, whatever is known should be stated:

 Who to train?
 How many?
 What is their competence?
 What type of training is required?

Eventually, in the Planning Phase, more detailed plans consisting of schedules and costs
will need to be presented.

Project Definition Document (With Explanations) Page 21

7.0 Related Project Issues

The following issues are important to define. They are needed and would be updated
during the Planning Phase.

7.1 Pending Issues to Resolve

Throughout the Project Definition Phase, the Project Manager or whoever is preparing
the Project Definition Document will compile a list of issues that remain unresolved.
These should be listed and shown as part of the Project Definition Document.

A typical Microsoft Access™ database was prepared for use as an Issues Register. This is
available on OMSAR’s website for downloading and use.

7.2 Terminology and Glossaries

Most projects are one time efforts and would hence introduce new terms or
understandings. This is especially true if the internal customer is using his own
terminology, acronyms and abbreviations.

In order for all stakeholders to understand what is being said, list all terms that should
be defined.

7.3 Project Document Repository

Identify the location (Electronic or otherwise) where all project templates, standards and
documents are kept:

Standard Operating Procedures (SOP’s)

Microsoft Project templates
Word / Excel documents to be reused by the Team
Forms and Charts
Technical standards

The Project Definition Document must define an inventory of all these forms identifying
their use Identify their location. At a later stage, this could be part of the Configuration
Management scheme.

Project Definition Document (With Explanations) Page 22

7.4 Attachments and Appendices

Many documents will already be collected for the Project Definition. However, in order
not to destroy the flow of the “Definition”, it is best they be kept in the Appendix section.
Such documents as the following may be attached:

Technical diagrams
Data sheets
Customer RFP’s, Tenders, etc
Drawings that support your arguments
Costing sheets
User lists, locations

Project Definition Document (With Explanations) Page 23