This document discusses project management principles and processes. It covers topics such as the importance of project management, knowledge areas, project identification and planning, risk management, and project execution. The document provides examples of projects and defines characteristics that distinguish projects from routine tasks. It also discusses project life cycles, activities involved in project execution like requirements analysis and testing, and potential problems in software projects.

1. Project Management

2. Project Management
 Introduction
 Principles & Importance of PM
 Knowledge Areas
 Processes
 Project identification and Planning
 Organisational structure and issues
 PERT and CPM
 Resource management
 Risk management
 Quality management
 Contract management
 Project schedule using software
 Project execution
 Project closure
I

3. Great Examples
Olympic Games
Taj Mahal
Launching of a Product or Book
Vaccination Program
Building a Metro
Developing a commercial Software App
Launching a satellite in Space
Development of commercial aircraft

4. Project
• Non-routine tasks are involved
• Planning is required
• Specific objectives are to be met or a specified
product is to be created
• The project has a predetermined time span
• Work involves several specialisms
• Work is carried out in several phases
• The resources that are available for use on the
project are constrained
• The project is large or complex

5. Project Objectives
• Projects are undertaken to fulfill objectives by producing
deliverables.
• An objective is defined as
– an outcome toward which work is to be directed,
– a strategic position to be attained,
– a purpose to be achieved,
– a result to be obtained, or
– a service to be performed.
• A deliverable is defined as any unique and verifiable
product, result, or capability to perform a service that is
required to be produced to complete a process, phase,
or project. It may be tangible or intangible.

7. Project Management
Project Management is the dynamic process that utilizes
the appropriate resources of the organization in a
controlled and structured manner, to achieve some clearly
defined objectives identified as strategic needs. It is
always conducted within a defined set of constraints.

8. Importance of PM
• Meet objectives
• Satisfy stakeholder expectations
• Be more predictable
• Increase chances of success
• Deliver the right products at the right time
• Resolve problems and issues on time
• Respond to risks in a timely manner
• Optimize the use of organizational resources
• Manage constraints
• Manage change effectively
• Identify, recover, or terminate failing projects

9. Organization
• Systems:
– A system is a collection of various components that
can produce results not obtainable by the individual
components alone.
• Principles:
– Systems are dynamic
– Systems can be optimized
– System components can be optimized
– Systems and their components cannot be optimize at
the same time, and
– Systems are nonlinear in responsiveness

10. Organization – Governance
• Governance Framework:
– This framework includes but is not limited to: Rules,
Policies, Procedures, Norms, Relationships, Systems,
and Processes.
• This framework influences how:
– Objectives of the organization are set and achieved
– Risk is monitored and assessed, and
– Performance is optimized

11. Management Elements
Components that comprise the key functions or principles
of general management in the organization.
The key functions or principles of management:
 Division of work using specialized skills and availability
 Authority given to perform work
 Responsibility to perform work appropriately assigned
 Discipline of action
 Unity of command
 Unity of direction
 Goals of the organization take precedence over individual goals
 Paid fairly for work performed
 Optimal use of resources
 Clear communication channels

12. Factors in Organization Structure Selection
Major factors to consider selecting an organizational
structure:
 Degree of alignment with organizational objectives
 Specialization capabilities
 Span of control, efficiency, and effectiveness
 Clear path for escalation of decisions
 Clear line and scope of authority
 Delegation capabilities
 Accountability assignment
 Adaptability and Simplicity of design
 Efficiency of performance
 Cost considerations
 Physical locations, and
 Clear communication

13. Software Projects Vs Other types of
project
• Invisibility – Progress is not immediately visible.
• Complexity – Software products contain more
complexity than other engineered artefacts.
• Conformity – Traditional engineering projects
though complex are governed by physical laws
that are consistent. Software developers have to
conform to the requirements of human clients
• Flexibility – Software systems are likely to be
subject to a high degree of change. The ease
with which software can be changed is usually
seen as one of its strength

14. Feasibility study/plan/execution cycle
Feasibility Study
Plan
Project Execution
Is it worth
doing?
How do we do
it?
Do it!

15. Activities
• Feasibility study – investigates whether a
prospective project is worth starting – that it has
a valid business case
• Planning – Formulation of outline plan for the
whole project and a detailed one for the first
stage. Detailed planning for the later stages
would be done as they approach.
• Project execution – Often contains design and
implementation sub-phases

16. Project Execution
• Requirement analysis – Process of investigating what the
potential users and their managers and employers require as
features and qualities of the new system. These ‘customer-
facing’ requirements then have to be translated into technical
requirements from which the developers of the new system
can work
• Architecture design – This maps the requirements to the
components of the system that is to be built.
– Decision to be made about which processes in the new
system will be carried out by the user and which can be
computerized. This design of the system architecture thus
forms an input to the development of the software
requirements.
– A second architecture design process then takes place
which maps the software requirements to software
components.

17. • Detailed design – Each software component is made up of a
number of software units that can be separately coded and tested.
The detailed design of these units is carried out separately.
• Code and test – This could refer to writing code for each software
unit or could refer to the use of an application-builder. Initial testing to
debug individual errors.
• Integration – The individual components are collected together and
tested to see if they meet the overall requirements. Integration could
be at the level of
– Software where different components are combined,
– At the level of the system as a whole where the software and other
components of the system such as the hardware platforms and networks
and the user procedures are brought together
• Qualification testing – Testing the system, including the software
components to ensure that all the requirements have been fulfilled

18. • Installation – Process of making new system operational. Would
also include setting system parameters, installing the software onto
the hardware platforms and user training
• Acceptance support – Stage of resolving problems with the
newly installed system, error rectification, any extensions and
improvements
Case study

19. Project Life cycle
• Starting the Project
• Organizing and Preparing
• Carrying out the work
• Ending the Project

20. Process Groups
• Initiating
• Planning
• Execution
• Monitoring and Controlling
• Closure

21. Problems identified by Software
professionals
• Inadequate specification of work
• Management ignorance
• Lack of knowledge of application area
• Lack of standards
• Lack of up-to-date documentation
• Lack of communication between users and technicians
• Deadline pressure
• Lack of quality control
• Remote management
• Lack of training

22. Business Case
• Most projects need to have a justification or a business
case – effort and expense
• Cost – benefit analysis
For e.g.
• That development costs are not allowed to rise to a level
which threatens to exceed the value of benefits;
• That the features of the system are not reduced to a
level where the expected benefits cannot be realized;
• That the delivery date is not delayed so that there is an
unacceptable loss benefits

23. Requirement Specification
• Functional requirements
These define what the end-product of the project is to do.
• Quality requirements
These define about the end-product should do. These are still
things that the user will be able to experience.
• Resource requirements
This would keep a record of how much the organization is willing to
spend on the system.

24. Case Study
ABC College is a higher education institution which used to
be managed by a local government authority but has
now become autonomous. Its payroll is still administered
by the local authority and pay slips and other output are
produced in the local authority’s computer centre. The
authority now charges the college for this serve. The
college management are of the opinion that it would be
cheaper to obtain an ‘off-the-shelf’ payroll package and
do the payroll processing themselves.
What would be the main stages of the project to convert to
independent payroll processing by the college? Bearing
in mind that an off-the-shelf package is to be used, how
would this project differ from one where the software was
to be written from scratch?

25. • Project evaluation – All the costs that would be incurred by the college if it
were to carry out its own payroll processing would need to be carefully
examined to ensure that it would be more cost effective than letting the
local authority carry on providing the service.
• Planning – The way that the transfer to local processing is to be carried out
needs to be carefully planned with the participation of all those concerned.
Some detailed planning would need to be deferred until more information
was available, for example which payroll package was to be used.
• Requirements elicitation and analysis – This is finding out what the users
need from the system. To a large extent it will often consist of finding out
what the current system does, as it may be assumed that in general the
new system is to provide the same functions as the old. The users might
have additional requirements, however, or there might even be facilities
that are no longer needed.
• Specification – This involves documenting what the new system is to be
able to do.

26. • Design/Coding – As an ‘off-the-shelf’ package is envisaged, these
stages will be replaced by a package evaluation and selection
activity.
• Verification and validation – Tests will need to be carried out to
ensure that the selected package will actually do what is required.
This task might well involve parallel running of the old and new
systems and a comparison of the output from them both to check for
any inconsistencies.
• Implementation – This would involve the things like installing the
software, setting system parameters such as the salary scales, and
setting up details of employees.
• Maintenance/support – This will include dealing with users’ queries,
liaising with the package supplier and taking account of new payroll
requirements.

27. Overview of Step Wise planning
4. Identify the products and
activities
0. Select project
1. Identify project scope
and objectives
2. Identify project
infrastructure
3. Analyze project
characteristics
5. Estimate effort for each
activity
6. Identify activity risks
7. Allocate resources
8. Review/ publicize plan
9. Execute plan
10. Lower level planning
For each
activity
Lower
level detail

28. 1. Identify project scope and objectives
1.1 Identify objectives and measures of effectiveness in
meeting them
1.2 Establish a project authority
1.3 Identify stakeholders
1.4 Modify objectives in the light of stakeholder analysis
1.5 Establish methods of communications with all parties

29. 2. Identify project infrastructure
2.1 Establish relationship between project and strategic
planning
2.2 Identify installation standards and procedures
2.3 Identify project team organization

30. 3. Analyze project characteristics
3.1 Distinguish the project as either objective- or product-
driven
3.2 Analyze other project characteristics
3.3 Identify high-level project risks
3.4 Take into account user requirements concerning
implementation
3.5 Select general life-cycle approach
3.6 Review overall resource estimates

31. 4. Identify project products and
activities
4.1 Identify and describe project products
4.2 Document generic product flows
4.3 Recognize product instances
4.4 Produce ideal activity network
4.5 Modify ideal to take into account need for stages and
checkpoints Project
products
System
products
Module
products
Tested
integrated
software
Integration test
cases
Overall
specification
Management
products
Module
design
documents
Module code Progress
report

32. 5. Estimate effort for each activity
5.1 Carry out bottom-up estimates
5.2 Revise plan to create controllable activities

33. 6. Identify activity risks
6.1 Identify and quantify activity-based risks
6.2 Plan risk reduction and contingency measures where
appropriate
6.3 Adjust plans and estimates to take account of risks

34. 7. Allocate resources
7.1 Identify and allocate resources
7.2 Revise plans and estimates to take account of resource
constraints
8. Review/publicize plan
8.1 Review quality aspects of project plan
8.2 Document plans and obtain agreement