Project Management


Control Point Ref #: projraab

Software projects are categorized according to the type of

Audit Steps
1) Determine the method that is used for categorizing software
projects (i.e., broad vs. specific categories).

2) Ensure that the categories used by your installation to
classify software projects which reflect the type of
development within your installation.

2.1) Identify the types of software development that is performed
by your installation based on broad or specific categories
and ensure that they are appropriate.

Examples of Broad Categories
New System Development
Third party vendor product install
Major Enhancements
Minor Enhancements
Emergency Change

Examples of Specific Categories
Control card changes
Execution JCL
Report Changes requiring no function (e.g., screen, file,
table) changes
Report Changes requiring function changes
Screen changes requiring no calculation or selection changes
Screen changes requiring selection changes
Program abend
Emergency Change

2.2) Ensure that software projects are being categorized by
reviewing a sample selection of projects.

Perform this step if broad categories used
3) Software projects are properly assigned to their

3.1) Determine if standards are available which specifies the
method used for selecting the appropriate category based on
the type of software project (i.e., total cost of project,
number of mandays, functional requirements of software

3.2) Ensure that software projects are being properly categorized
by reviewing a sample selection of projects.
F1 - Info Screen Ref # projraab
One of the requirements for Project Management is to track the
type of development that is required for each project. Categories
are used as means of assigning a software project to a logical
grouping which in most environments determines the phases,
deliverables, and deliverable components that need to be followed
or developed. Therefore, it is of great importance to ensure
that a software project as correctly categorized.

Software development can be categorized using the following

o Development activity can be structured in broad categories
which include: New System Development, Major Enhancements,
Minor Enhancements, Minor Maintenance, Major Maintenance,
Emergency Changes.

o Development activity can be organized in specific categories
which is tailored towards the specific activity that is
unique to your environment while maintaining some broad
categories. Some examples of specific categories could
include: Vendor Acquisition Software, JCL changes, direct
changes to data (i.e., programs which directly change data
which is used primarily after a data conversion),
Pre-Processors (e.g., used to alter data before it is
applied to the master or transaction files, report header
changes, extract reports.

A determination must first be made if the approach of utilizing
broad categories best serves your installation.

Since categories are used as a means of determining deliverable
requirements for particular group of software projects, that
should be the determining factor in the number of categories used
by your organization. Regardless of the category approach that
is used, it must reflect all of the types development activity
that is taking place.

When broad categories are used to define the type of development
activity (e.g., new system development, major & minor
enhancements, major & minor maintenance), a methodology must
exist for defining the method used for assigning a development
project a specific SDLC category, especially when the categories
consist of non-descriptive names as major or minor enhancements.
Common methods that are used for determining the appropriate
development category consist of: Number of mandays, total cost of
the project, functionality requirements of the software request.

The number of mandays should not be the only method used for
determining the category that a software project is assigned
since a change could take relatively short amount of time but
require substantial testing that would only be required for
projects that require a greater number of mandays. In addition,
unless a process is in place to track the actual time spent on a
project, this type categorization method can be circumvented.

Using the Total Cost of the Project alone is an ineffective way
of categorizing a software request since again minor changes
could require substantial deliverable requirements that would
normally be associated with projects that cost more.

Using the functional requirements of the request as the basis for
determining the category that is selected is the most effective
method for mapping the software request to its appropriate
category. However, detailed procedures would be required to
identify the various components of the functional change that
makes up a specific category.

When specific categories are used for categorizing software
requests, there less of a need to develop procedures for
determining how to map a software request to a category.

Definitions of Broad Categories
New System

This applies to any new system that is developed which is a very
general category since most new system would require all SDLC
deliverables to be developed. However, many installation break a
new system into many little projects which would not necessarily
require all of the SDLC deliverables to be developed.

Major/Minor Enhancements

This should be divided into two separate categories. Enhancements
is new functionality or a new subsystem that is developed for an
existing system.

Major/Minor Maintenance

This should be divided into two separate categories. Maintenance
includes bug fixes to previously developed systems or additions
to functionality that might have been excluded when the system
was previously developed which borders in interpretation to an

Emergency Fixes

When a program bug requires to be implemented immediately
bypassing the normal requirements of the maintenance category
that it would normally fall under a separate emergency fix
category is required.

Software Package Acquisition

When application systems are purchased from a vendor, it should
be under its own category and not part of New System since the
deliverables required to support its use in production would not
be of the same as a new system (e.g., no need functional and
system design specification). However, this category may need to
be further subdivided based on packages that can't be changed by
the user versus exits which allow user coding or the distribution
of source code which allow user customization.


The prototyping category can be used as a main category for
classifying software projects in determining deliverables that
are required or it can be a subcategory within each of the above
categories to further breakout the deliverables that are required
to be developed. For instance a major enhancement might always
require full design system specifications and full unit,
integration, system, and acceptance testing to be performed but
if the prototyping development approach is used each of the
mentioned deliverables will not require the typical component to
be developed for the deliverable or the deliverable may not be
required at all.

Control Point Ref #: projraac

The deliverables and SDLC phases that are required to be
performed for a project is documented at the onset of the project

Audit Steps
1) Ensure that the deliverables that are required to be
developed based on the categories that your installation
uses is formalized within the SDLC.

2) Ensure that there is a commitment to deliverables
immediately after approval of its development.
F1 - Info Screen Ref # projraac
The Software Development Life Cycle is made up various phases
which require deliverables to be developed. The SDLC
deliverables that are required and the actual phases that are to
followed is dependant on the type of development that is
occurring. For example, a report change that involves no changes
to the calculation or selection criteria which derives fields in
the report would allow the Analysis and Design phase to be
combined along with the deliverables that developed (i.e.,
functional specification, business specification,

It should be noted that the components that are required for a
deliverable can vary according to the type of development
activity. For example, the components of a system design
specification will require comprehensive flowchart and file
layouts for a new General Ledger system but no requirements would
be necessary for an enhancement which changes the calculation of
an individual data field.

There are various methods that can be used for documenting the
deliverables that are required for a Software Project. The
method that is used depends on how specific your SDLC is written
for the type of development that is taking place. Two of these
methods include:

o The first method is a closed end approach whereby specific
deliverables that are required to be developed are clearly
stated in the SDLC. More detailed approaches would consist
of stating the deliverables that are required based on the
manner that the software project was categorized. In
addition, beyond the deliverables that are required, the
SDLC phases to be performed and the specific components of a
deliverable can be specified in order to customize the
requirements of a software project.

o The second scenario is an open ended process where the SDLC
Phases/Phase deliverables/deliverable components for each
development category is not predefined and a determination
is made at the beginning of the project of the requirements

At the onset of a software project, an analysis must be performed
to determine the phases and deliverables that are required to be
developed for the software project. This commitment at the onset
of the project allows an accurate budget to be set and allows the
disposition of the project to be tracked.

The testing to ensure that these deliverables are actually being
developed is the compliance tests associated with the controls
within the SDLC main section review.

Control Point Ref #: projraad

Adequate standards are in place for the prioritization of
software requests which are being used

Audit Steps
1) Determine if standards are in place for prioritization of
software projects.

2) Determine the adequacy of the standards for the
prioritization software projects.

2.1) Is a sufficient number of priority levels used in order to
easily distinguish the requests that should be handled in
the future and what their specific order is.

2.2) Are the factors which effect a software request's priority
clearly stated.

3) Determine if the priority for a software request is formally

4) Determine if software requests were prioritized based on the
standards in place.

4.1) Review a sample of software requests and determine if the
priority assigned reflects what is stated in the standards.
F1 - Info Screen Ref # projraad
The prioritization of a software request is especially important
in an environment where there are more program requests then what
can be processed by the development staff based on the target
dates required for each request.

Prioritization levels need to be established which enable
software requests to be easily distinguishable in order to
determine the request that should be next handled. Therefore,
using a High/Low prioritization level is not sufficient since a
mechanism would need to be in place to distinguish which request
should be addressed next. Other methods used for managing
priorities, is assigning an order number to all requests in that
are to developed.

Based on the priority levels that are established, a development
schedule can be planned for the entire application area.

An example of factors which determine the assignment of a
software requests prioritization levels include:

o overall criticality to support the business
o availability of unique resources to meet the request (e.g.,
purchase a 4th generation development tools)

Control Point Ref #: projraae

A project tracking system is used to track all requests from the
point it is initiated to its completion

Audit Steps
1) Ensure that all projects initiated are tracked.

1.1) Determine if a project tracking system is in place.

1.2) Determine if the project tracking system tracks the
disposition of all software requests (i.e., approved or
unapproved) and provides the current status of the project.

1.3) Based on your sample select of projects ensure that it is
contained on the project tracking system.

If formal requests are not maintained there would be no method to
determine whether unapproved requests are being tracked.

1.4) Identify the current status of active projects and
determine whether the project tracking system has been
updated to reflect the phase being worked on.

2) Determine if there is a process in place to notify the users
writing when there software request has been denied.

2.1) Review all available documentation for the selected sample
of projects and determine if the users were formally
notified when there software request has been denied.
F1 - Info Screen Ref # projraae

User software requests should be tracked either manually or
automated but a determination has to be made one way or the other
if the project will be developed or not developed. There will be
cases, where the project is put on hold based on its priority
but it should not be used as a dumping ground in which the
project is never developed.
Control Point Ref #: projraaf
A project plan is developed and updated for each software project

Audit Steps
1) Select a sample of project plans and ensure that they
contain the following components:

o tasks that need to be performed

o task dependencies

o target dates for the completion of all tasks

2) Ensure that the project plan is being updated throughout the
life of the project.

2.1) Based on currently active projects, select a sample of
projects and determine whether their project plans were
updated based on target dates not met and new tasks that
need to be performed.
F1 - Info Screen Ref # projraaf
A project plan is used to identify the various tasks that are
required to be performed to complete the requirements of the
software request. The tasks that are contained in the project
plan can include components of an SDLC deliverable but is
primarily used for the tasks that do not fall under an SDLC
deliverables. In most cases, project plans would only be
required for enhancements and new system development.

Some examples of tasks that are contained in the project plan
includes analyzing disk space requirements for the datasets
being defined, making arrangements with courier for the delivery
of reports to users.

Audit Step Info
Unless you obtain a detailed understanding of the project
requirements it would be difficult to identify missing tasks from
the project plans.

Control Point Ref #: projraag

Problems related to a project are tracked and forwarded to
appropriate members of the development team

Audit Steps
1) Determine if problems associated with projects are

1.1) Ensure that there is a centralized tracking system which
records all problems associated with a project.

2) Determine if members of the development team are kept
abreast of the problems recorded and the disposition of its

3) Ensure that the disposition of a problem and its solution
being formally tracked.
F1 - Info Screen Ref # projraag
During the course of the development of a software request
problems arise which may require changes to the over project.
The problems that are discussed in this control do not relate to
debugging a program or problems that arise during the Testing
phases which are discussed in the SDLC Main Section.

Audit Step Info
Since as an auditor you are probably not well versed in the
problems associated with a project you will not be able to
identify in your compliance testing when problems are not being
reported. Instead you will only be able to determine whether the
standards of what should be reported are comprehensive enough.

A test to ensure that each of the team members are informed of a
problem is not possible. However, you can conduct interview with
the users and the other members of the development team to
determine how the members are kept informed (e.g., periodic
meeting addressing the status of software requests, manual or
automated problem tracking system)

Copyright 1991 - 2009, Audit Serve, Inc. All rights reserved. All Audit
Programs are copyrighted and may not be posted electronically or
redistributed unless written permission is granted by Audit Serve, Inc.
The Audit Programs may be used for internal use within organizations.
Audit Programs may not be resold.

AuditNet - The Global Resource for Auditors
General Data Protection Regulation Seminar

Audit Vision

Since 1991
Join 3,500 other subscribers

Copyright © 2015. All Rights Reserved.