ACKNOWLEDGMENT

Thanks to the Almighty God for bringing me this far.

And to all those who assisted me especially my tutor.

Maame Ama Tanoa Boateng.

1
TABLES OF CONTENT

TASK 1
Overview
Project management……………………………………………………5
Definition……………………………………………………………….5
Benefits of using a project management development lifecycle……….6
The Waterfall Model……………………………………………………7
The Boehm’s Spiral Model……………………………………………..8
Comparing and contrasting the difference between each model, their
strength and weakness………………………………………………….10

TASK 2
Overview
Configuration management…………………………………………….11
Functions of configuration management……………………………….11
o Configuration Planning
o Configuration Control
o Configuration Status accounting
o Configuration Identification or Verification…………………….12
Benefit of Configuration management…………………………………13
Configuration control process………………………………………….13
Forms for Authorisation of changes to software design…………….15-16

TASK 3
Introduction
Risk …………………………………………………………………… 17
Process of risk analysis …………………………………………..……18
Risk Evaluation ………………………………………………………..20
Risk Estimation…………………………………………………………20
Using risk to asses the impact of problems…………………………….20
Work example of Risk matrix………………………………………….22
Contingency planning process…………………………………………………23

2
TASK 4
Introduction

Procurement…………………………………………………………….24

Formal procurement process for goods and services…………………..25

Checklist of criteria……………………………………………………..27

TASK 5

Introduction

Visual communication
Value of visual methods to capture and communicate project works…29

Activity network and an aspect of website design and development…31-32

REFERENCING

BIBLOGRAPY

APPENDIX

NOTES

3
ABSTRACT

In project management, it is important to learn lessons from past

projects. On completion, every project should be reviewed to
understand what worked well and did not, and the lessons learned
should be recorded.

These lessons should be carried forward into the future projects. By

doing this, there is a continual improvement in project processes and a
great likelihood that projects will come in on time, budget and be “fit
for purpose”. Experience to project planning, monitoring and control

4
TASK 1

Overview

PROJECT MANAGEMENT
As a discipline, project management developed from different
fields of application including construction, engineering, and
defence.

DEFINITION
Project Management is the application of knowledge, skills, tools
and techniques to project activities to meet project requirements.

Project management is quite often the province and responsibility

of an individual project manager.

This individual seldom participates directly in the activities that

produce the result, but rather shires to maintain the progress and
productive mutual interaction of various parties in such a way that
overall risk of failure is reduced.

Scope
Q
Scope
ua
lit
y

Cost Time

5
The time constraint refers to the amount of time available to complete a
project. The cost constraints refer to the budget amount available for the
project. The scope constraint refers to what must be done to produce the
project’s end result. These three constraints are often the competing
constraints: increase scope typically means increase time and increase cost ,
a tight time could mean increase and reduced scope, and a tight budget could
mean increase time and reduced scope..

BENEFITS OF USING A PROJECT MANAGEMENT

DEVELOPMENT LIFECYCLE.

Project Development lifecycle (PDL) is the process of delivering software as

a continuously repeating cycle of inter-related steps definition, design,
development, testing, deployment and management.
The benefits are;

 Increase productivity, as team shares best practice for development

and deployment, and developers need focus only on current business
requirements
 Improve quality, so the final application meets the needs and
expectations of users.
 Breaks boundaries through collaboration and smooth information
flow; communication should be flexible to adopt contributions from
the workforce.
 Accelerates development through simplified integration, there by
allowing management, users and stakeholders to have a touch of the
system.
 Cuts maintenance time by synchronizing application and design
 Maximize investment in skills, processes, and technologies
 Increases flexibility by reducing the time it takes to build and adapt
applications that support new business initiatives.

6
THE WATERFALL MODEL
The waterfall life or model was the first attempt at the definition of a
software development lifecycle. To follow, one proceeds from one phase to
the next in a purely sequential manner as shown in the diagram below.

After the last two stages are completed that is, implementation and
integration phases, the software product is tested and debugged. Any fault
introduced in earlier phases are removed, then the software product is
installed, and later maintained to introduce new functionality and remove
bugs.

The diagram below illustrate the Waterfall Model;

7
BOEHM’S SPIRAL MODEL
This extends the ideas of prototyping and iterative development but it also
recognise that one of the major problems that is faced in any development
project is an initial lack of understanding of the scope and technical
difficulty of the project.

The Boehm’s Model explicitly includes a risk analysis stage at each rotation
of the spiral. The risk analysis provides the information needed to help
management decide whether to proceed.

The final loop of the Spiral is effectively equivalent to a conventional

Waterfall Linear development lifecycle. However, by the time this is
reached, the development team (and business manager) will have a very
good understanding of the problem they are attempting to solve and the
requirements for the system.

The diagram below illustrate the Boehm’s Spiral Model;

8
9
COMPARING AND CONTRASTING THE DIFFERENCE BTWEEN
EACH MODEL, THEIR STENGTH AND WEAKNESS.

 Waterfall model is non-iterative development approach but Boehm’s

spiral is iterative.

 The waterfall model brings no formal means of exercising

management control over a project and planning control and risk
management are not covered within the model itself.

 It is difficult to estimate time and cost for each phase of the waterfall
model but is not difficult for the Spiral model.

 The Boehm’s spiral model combines the features of prototyping and

the waterfall model for which the waterfall model is a linear process.

 The process of the Boehm’s spiral model phases exhibit constant

testing from design, implementation and verification phases required
to validate the phases preceding but for waterfall model testing and
debugging is done after after implementation and integration phases.

REASONS TO CHOOSE ONE MODEL

I will choose the Boehm’s spiral model because the final loop of the spiral is
effectively equivalent to a conventional waterfall linear development
lifecycle.

Also it extends the ideas of prototyping, iterative development and explicitly

includes risk analysis at each phase of the rotation of the spiral.

10
TASK 2

OVERVIEW

CONFIGURATION MANAGEMENT
A project is part of a programme a configuration management has
greater importance. No business entity can be fully efficient or
effective unless it manages its resources, particularly if the
resources are vital to the running of the organisation’s business.

In terms of information technology and telecommunication, the

term configuration management has the following meanings;

1) The management of features and assurances through control

of changes made to hardware, software, firmware,
documentation, test, test fixtures and test documentation of
an automated information system, throughout the
development and operational life of a system

The main goal of configuration management is to;

I. Identify
II. Control
III. Maintain
IV. Verify its versions.

Configuration management gives the project management team

precise control over the projects assets. Configuration management
consist of Five (5) basic functions.

11
CONFIGURATION PLANNING
Planning configuration management activity is the critical component in
configuration management process. Identifying activity is most important
step in configuration management plan phase. Time and effort invested in
this specific step guarantees an increased potential for success.

CONFIGURATION CONTROL
This phase concerns the management of changes to configuration items
during the software product life cycle. The process starts when new changes
are identified with a change request. Change request can be initiated by users
and developers of the software. A standard procedure for handling change
request should be created. This document should describe the formal
procedures for the deposit and recording of change request, for evaluation of
cost and impacts, and finally for the acceptation, modification, or rejection
of those, request.

CONFIGURATION STATUS ACCOUNTING

To control the configuration items, it is essential to record and report about
the current state of affairs. An automated system will be used to capture and
report all relevant information during the life cycle of a software
configuration item. The collected information will be used as input for the
development team, the maintenance team, project management, and quality
assurance activities. Reports can be periodic or ad-hoc. The feedback can be
used to improve the system.

CONFIGURATION VERIFICATION OR AUDIT

Product deliverables are subject to many regulation, guidelines, constraints,
plans and procedures. On a regular base this compliance should be checked
by configuration audit. This activity covers an independent evaluation of the
conference of the configuration item under study. Audits are conducted
following standard (detailed) process descriptions.

There are three (3) fields of interest for audits;

a. Functional configuration
b. Physical configuration
c. In-process audits of the product baseline.

12
CONFIGURATION IDENTIFICATION
The goal of this activity is to identify the product items that need to
be controlled; this is based on the product structure modelling
process. This is the process of breaking down the product
(baseline) into several parts and items (software configuration
items). Also identification schemes are created for configuration
items and their versions (part of versions and variant management).
All the controlled items should be stored in a central
Configuration Library. This centralised space keeps track of all
versions and documentation of related software configuration
items.

BENEFITS OF CONFIGURATION MANAGEMENT

Configuration management benefit the organisation in various ways;

• Control – management offers the opportunity to review, approve, and

incorporate changes to the configuration item. It provides a standard
method for traceable and controlled changes to the baseline version of a
configuration item.
• Management – Configuration management provides a process of
automatic identification and guidance of configuration items in their
whole life cycle.
• Cost savings – using configuration management, cost savings can be
realized throughout the whole lifecycle of a configuration. By actively
defining, tracing, and auditing configuration items, failures can be
detected early, and corrective action can be taken. No confusion in task
division can occur
• Quality - Deliverables are checked continuously during the software
development process. By checking the human-work in an automate way.
The level of compliance of deliverables with predefined requirements can
be maximized

13
CONFIGURATION CONTROL PROCESS

As explained earlier Configuration Control is made up of processes these

are;
• Change control request
Describes a procedure used to ensure that changes (normally, but not
necessary, to IT systems) are introduced in a controlled and coordinated
manner. It aims to ensure that all changes are assessed and approved by
management before their implementation.

- Change request
1. Record / classify
2. Assess
3. Plan
4. Build / Test
5. Implement
6. Close / Gain Acceptance
A formal request is received for something (usually in the client’s
to be changed, known as the “Change Initiation”).
- emergency updates

• Release control
• Variant handling.

14
 FORMS FOR THE AUTHORISATION OF CHANGES TO
SOFTWARE DESIGN

JIKMOIMIO
CUSTOMER SURVEY FORM REGISTRATION

First Name *

Last Name *

Email *

Organization *

Phone *

Required Field *

15
 CUSTOMER SURVEY

To help us better serve your needs. Please take a moment to answer the following
questions. All information is confidential as describe in our Privacy Policy.

What is your primary job function? You may select from the list or enter your
own job function

What feature do you like most about the design?

How many paper forms does your organization receive per month from
customers / general public?

How many people are employed at this location and in your entire
organization?

How many statements, bills or other forms does your organization send to
customers per month.

Summit the form for analysis of you specific requirement

16
TASK 3

INTRODUCTION

RISK
William J. Stevenson p.197, 2005, wrote in his book (Operations
Management) that, an environment in which certain future events
share probable outcomes is risk or certain parameters have
probabilistic outcomes in known as RISK.

Risks are inherent in projects. They relate to the occurrence of

events that can have undesirable consequences, such as delays,
increase costs, and an inability to meet technical specifications. In
some instances, there is the risk that events will occur that will
cause a project to be terminated.

The probability of occurrence of risk events is highest near the

beginning of a project and lowest near the end. However, the cost
associated with risk events tends to be lowest near the beginning of
a project and highest near the end.

Good risk management entails identifying as many potential risks

as possible. Analyzing and assessing that risk, working to
minimize the probability of their occurrence, and establish
contingency plans (and funds) for dealing with any that do occur.

Once risks have been identified, each risk must be evaluated to

determine its probability of occurrence and the potential
consequences if it does occur. Both quantitative and qualitative
approaches have merit.

17
Risk reduction can take a number of forms. Much depends on the
nature and scope of a project. “Redundant” (Backup)
Systems can sometimes be used to reduce the risk of failure. For
example, an emergency generator could supply power in the event
of an electricity failure.

Risk is an opportunity, and a competitive weapon (NCC IAD

Managing Business Project p.153, 2002).

PROCESS OF RISK ANALYSIS

Is a set up in the risk management process. Risk analysis may be
the most important step in the risk management process, and may
Also be the most difficult and prone to error. Part of the difficulty
of risk management is that of the quantities in which risk analysis
is concerned can be very difficult itself. Uncertainty in
measurement is often large in both cases.

The process of risk analysis are as classified;

(i) RISK IDENTIFICATION

Some projects needs to be considered for implication of
risk will be documented in the feasibility reports and
projects plans derived from these.

It is necessary to identify all possible risk which might

be internal or external.

Internal Risks- Threats such as;

• Inadequate resources

18
 • Unrealistic deadlines
• Lack of commitment
• Use of contractors
• New approach
• Geographical split.

External Risk- these risk originate outside the

immediate project environment; they are often difficult
to identify, yet they have under reaching impact

External Risk – such as;

• Organisational policies
• Supplier financial stability
• No experience in the business area
• Dynamic business environment
• Legislation
• Resource conflicts]
• Market forces
•
There are other methods that needs to be considered
- Intuition/ experience (interviews and brainstorming)
standard questionnaires and checklist
- Experts/expert systems
- External specialist.

19
(ii) RISK EVALUATION
Is the process of deciding whether the level of each risk
is acceptable or not and, if not, what actions can be
taken to make it more acceptable
It covers:
a. Assessing the acceptable level of each risk
b. Generating alternative paths of action for risk
which do not meet acceptable criteria;
c. Sorting the risk into a final order of priority
d. Crossing-referencing them to the identified
education potions.

(iii) RISK ESTIMATION

Is a procedure for determining how important each risk
is based upon an assessment of its likelihood and
consequences to the project and the business.
In determining this, a simple method is to award each
risk one of three categories, High, Medium or Low.

20
USING RISK MATRIX TO ASSESS THE IMPACT OF PROBLEMS

A tool used in the Risk Assessment process, it allows the severity of the risk
of an event occurring to be determined. A risk is the total of each of the
hazards that contribute to it. The risk of any particular hazard H, can be
defined as it probability, p, multiplied by its consequence, c. in layman’s
terms; how likely it is to happen and how bad it would be if it happened.

Hazard = PH * CH.
Therefore the total risk, R, of an event, e, is the sum of the n potential
hazards that would results in that event.

n
R E = Σ Hi
i=0
The consequences can be defined as;
• Catastrophic – Multiple Deaths
• Critical – One Death or Multiple Severe Injuries
• Marginal – One Sever Injury or Multiple Minor in juries
• Negligible – One Minor Injury

The probability is identified as ‘certain’ likely,’ Possibility,’ Unlikely and

‘Rare’. However, it must be considered that very low probability may not be
very reliable.

21
WORK EXAMPLE OF RISK MATRIX

Negligible Marginal Critical Catastrophic

Certain High High Extreme Extreme

Likely Moderate High High Extreme

Possible Low Moderate High Extreme

Unlikely Low Low Moderate Extreme

Rare Low Low Moderate High

Any company or organisation would calculate what levels of Risk they can
take with different events. This would be done by weighing up the risk of
event occurring against the cost to implement safety and the benefit gained
from it.

22
CONTIGENCY PLANNING PROCESS.

Is a common source of establishing errors is in the failure to appreciate

additional cost bound t arise as a result of design errors, production
mistakes, material or component failures etc. the degree to which these
contingencies will add to project costs depends on the soundness or
otherwise of engineering concepts etc.

Since they are inevitable, an allowance must be made to cover such

unforeseen circumstances. Performance on previous projects is usually a
reliable pointer.

• Escalation
This may be defined as the difference between the final cost or latest
estimate and the original definitive estimate. Factors which contribute to
cost escalation are;

1. inefficiency
2. inflation
3. characteristics of two information
4. changes in the contract
5. forms of contracts
Some of these escalations are avoidable, others are not, and thus an
allowance must be made the project estimate under contingencies.

23
TASK 4

INTRODUCTION

PROCUREMENT

It includes all activities required in order to get the product from the
suppliers to it final destination. It encompasses the purchasing function,
stores, traffic and transportation, in coming inspection and control and
assurance. Salvage and environmental issues (as they are related to
materials) as a part of procurement. Porter regards Procurement as a support
activity.

In October 1999, in the introduction to the Procurement Business Strategy,

“It is simply no longer acceptable to treat the supply of goods and services
as an administrative issue, it can and should be a potent force to make
competitive gains and generate significant financial benefit”.

New terms such as Supply Chain Management and Value Chain

Management have become common place in the procurement world. In
those areas where these ideas have been applied they have been consistently
successful. Yet while this experience exist within a Group, it is clear that the
transformation we need in people’s commercial behaviour across all of our
organisations.

To achieve a change, there need to be improvement in commercial skills to a

level that is commensurate with best technical skills and there must be
teamwork to obtain the combined benefits and excellence.

24
 FORMAL PROCUREMENT PROCESS FOR GOODS AND
SERVICES

All activities need to be performed in such a way that the total value
generated by the company is more than the sum of its costs.

Based on these observations the conclusion is that procurement may provide

support to the following:

• PRIMARY ACTIVITIES
The procurement function should be able to meet the material
requirements related to inbound and outbound logistics. And often
more importantly, related to operations. Operations may have a
different structure among manufacturing companies. Usually
manufacturing processes can be characterised according to the
following categories.

1. Make (and distribute) to stock (MTS). Standard products are

manufactured and stocked; customers are serviced from an end
product inventory. Production is on dedicated machinery, often in
large batches. Materials requirement planning (and therefore also
planning of purchased products) is based on sales forecasts.

2. Make to order (MTO). Products are manufactured from raw

material or the purchased components inventory after a customer
order has been received and accepted. This is common in
situations with very large or customer-specific products ranges
(e.g. packaging materials) or bulk products that are very
expensive to stock (e.g. insulation materials).

3. Engineer to order (ETO). All manufacturing activities from

design to assembly and even purchasing of the required materials
are related to a specific customer order. Production is usually on

25
 multipurpose machinery. Requiring highly skilled operators, for
example large customer-specific installations.

Primary activities are also referred in to some books as

‘PRODUCTION BUYING’ or ‘BUYING OF PRODUCTION
ITEMS’. This area usually gets most attention from management.

 Support activities
Procurement processes may be also related to supply products
and services for the other support functions some examples are
the buying of

 Laboratory equipment for research and development;

 Computer hardware and software for the central computer
department;
 Lease-cars for the sales force and senior management;
 Office equipment for accounting;
 Food and beverages for the catering department;
 Cleaning materials for housekeeping, etc.

Again procurement function aimed at the support activities may be very

different in character. Some of the purchases to be made are routine
purchases (maintenance, repair and operating suppliers (MRO-suppliers) and
may be repetitive and low in value. Other purchases may have a ‘project
character’ and may be unique and high valued (investment goods, capital
equipment, buildings).

In general this type of purchases will be referred to as ‘non production

buying’ or ‘general expenses’. They may be classified into: MRO-suppliers,
investment goods and services. The high variety of this type of purchases
makes it extremely difficult to support these by one uniform computer
information system and / or buying procedure. The character of this type
purchases also explains why professionalism in purchasing usually is low.

26
CHECKLIST OF CRITERIA
1. Are all criteria expressed in measurable terms?
2. Have all levels of users. Operations and those for maintenance been
canvassed for their criteria?
3. Do the user criteria cover the following areas?
COST
a. development cost
b. operational cost

PERFORMANCE
a. major functions to be performed
b. ease of use
c. quality of user staff required
d. response times
e. documented turn around times
f. availability of the system
g. quality and accuracy
h. error trapping
i. error reporting and recovery
j. mean time between failures
k. mean time to repair
l. security

CAPACITY
a. volumes of data to be compressed.
b. Volumes of permanent data to be stored
c. Volumes of transient data to be stored

4. Do the operations criteria include?

a. hardware utilisation;
b. machine type and model
c. memory
d. storage
e. network
f. times 27
g. support requirements
h. data preparation
 Times
Output distribution
Recovery and re-run options
Documentation
Backup and recovery

PRICE should not be necessarily the main criteria for selection because the
deliverables should basically based on the specific requirement and it fit for
the purpose it was designed for or it must also check for consistency
between the specification, data models and other user documents as well as
ensuring that the product function will be acceptable to the user. The
external interface of the products should be put under scrutiny.

28
TASK 5

INTRODUCTION

Visual communication
VALUE OF VISUAL METHODS TO CAPTURE AND
COMMUNICATE PROJECT WORKS.

Is the conveyance of ideas and information in forms that can be read or

looked upon.

Primarily associated with two dimensional images, it includes: art, signs,

photography, typography, drawing, graphic design, illustration, colour and
electronic resources.

Recent research in the field has focused on web design and graphically
oriented usability. Graphic designers use methods of visual communication
in their professional practice.

It enables users to visualize, analyze, and communicate all aspects of an

organization, including the who, what, where, when, why, and how things
are done.

This information can then be viewed by all stakeholders of the organization

-- including its workers, management, and outside vendors (depending on
the level of access they've been granted) -- who can then get answers to
questions about the organization's architecture in the form of visual
diagrams, textual information, pie charts, and other dashboards.

29
To capture information about all aspects of an organization, users of System
Architect build visual models using numerous industry-standard notations,
such as the ;

• Business Process Modeling Notation (BPMN) for business process

models.

• Organizational Charts to model the organizational hierarchy

• Functional Hierarchy diagrams to model the functions that a business
performs.
• The Unified Modeling Notation (UML) to model application designs
• Logical and physical relational data models to capture database
designs, network architecture diagrams to model the organization’s
information technology, data flow diagrams to model how data is sent,
stored, and transformed in an organization, and so forth.

30
AN ACTIVITY NETWORK AND AN ASPECT OF WEBSITE DESIGN
AND DEVELOPMENT

A B

C D

Design stage of a Website showing high level view

A- 5 days
B- 9 days
C- 13 days

31
32
REFERENCE

 Arjan J. van Weele 2000

Purchasing and Supply Chain management

Analysis, Planning and Practice 2n edn

 NCC Education Limited 2001

Systems Development

 William J. Stevenson

Operations Management 11th edn

33
BIBLIOGRAPHY

 Arjan J. Van Weele 2000

Purchasing and Supply Chain management

(Analysis, Planning and Practice) Second Edition

Business Press, Berkshire House 168-173 High Hold born, London.

WC1V 7AA.

 NCC Education Limited 2001

Systems Development.

The Towers, Towers Business Park

Wilmslow Road, Didsbury

Manchester M20 2E3, UK.

 Operations Management :From Ideal of Risk ; William J. Stevenson

Eleventh Edition 2005

 INTERNET

34
 Encyclopedia: www.en.wikipedia.com

APPENDIX

Royce’s final model

The “sashimi” model

Barry W. Boehm’s is known for many contributions to software

engineering, he was the first to identify software as the primary
expense of future computer system, and he developed
COCOMO,the spiral model, wideband Delphi, and many more
contributions through his involvement in industry and academia.

35
NOTES

36
NOTES

37