See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/315169626

Project Management in Software Engineering

Technical Report · February 2016

DOI: 10.13140/RG.2.2.18949.96488

CITATIONS READS
0 4,271

1 author:

Muhammad Ahsan Nawaz

Hochschule Rhein-Waal
9 PUBLICATIONS 2 CITATIONS

SEE PROFILE

All content following this page was uploaded by Muhammad Ahsan Nawaz on 17 March 2017.

The user has requested enhancement of the downloaded file.

 Hochschule Rhein-Waal
Rhine-Waal University of Applied Sciences
Faculty of Communication and Environment
Degree Program Information Engineering and Computer Science, M. Sc.
Mr. Adnan Aziz

Project Management in Software Engineering

Report
WS 2015/16
Module ―Advanced Software Engineering‖

By
Muhammad Ahsan Nawaz (18790)
 2

Abstract
The software industry has become a key industry in many developing countries because of the
application of information technology in business, manufacturing and many other sectors.
Software development produces higher value addition compared to other industries with more
skilled human resources. Software project management is an interesting issue of both researchers
and managers. Software projects have a notorious reputation of poor performance in terms of
schedule, cost and quality assurance. There has been limited research on software project
management, especially in a context of developing countries. Consequently, this study will
concentrate on the role of planning for project success.
The conceptual framework in this study was developed to examine the critical role of planning in
software projects. This framework includes three important elements: planning factors, planning
performance and project outcomes. Planning factors are defined as human, management and
technical factors that involved in project planning. Planning was assessed by the performance of
four tasks, including defining requirements and specifications, estimating cost and time,
scheduling and risk analysis. Project outcomes were evaluated by five criteria: overall success,
qualitative benefits (such as improving project team ability, enhancing the company image
financial benefits), financial benefits, time and costs. In the framework, planning performance is
influenced by human, technical and management factors. Planning performance also related to
Project outcomes. This framework also proposed to analyze the influence of project
characteristics on the relationships between the planning factors and planning performance.
The research finding indicated that, there were not many significant differences between
software projects based on size, type and ownership. Smaller projects had better scheduling, less
budget excess, and better intangible benefits like improving project team capability, enhancing
the company image, etc. than bigger projects. Considering the ownership differences between
software projects, the significant differences mainly related to human factors. The project
manager effort, team member ability and customer involvement of software projects in foreign
companies were better than that in local companies.

Keywords:- Software project management, Project Planning, Risk management, Project staffing
 3

Table of Contents
1. Introduction ----------------------------------------------------------------------------------------------- 5
1.1. What is Management ------------------------------------------------------------------------------ 5
1.2. What is Project Management --------------------------------------------------------------------- 6
1.3. What is software Project Management ---------------------------------------------------------- 8
1.4. What is project -------------------------------------------------------------------------------------- 8
1.5. Purpose of SPM ------------------------------------------------------------------------------------ 9
2. Project staffing ------------------------------------------------------------------------------------------ 10
2.1. Project Planning ----------------------------------------------------------------------------------- 10
2.2. Types of Project Plan ----------------------------------------------------------------------------- 10
2.3. Activity Organization ----------------------------------------------------------------------------- 11
2.4. Project Scheduling -------------------------------------------------------------------------------- 11
2.4.1. Scheduling Problems ------------------------------------------------------------------------ 12
2.5. Bar charts & Activity Networks----------------------------------------------------------------- 12
2.6. Task Durations & Dependencies ---------------------------------------------------------------- 12
2.7. Activity Network ---------------------------------------------------------------------------------- 13
2.8. Gantt Chart ----------------------------------------------------------------------------------------- 13
2.9. Staff Allocation ------------------------------------------------------------------------------------ 14
3. Risk Management --------------------------------------------------------------------------------------- 14
3.1. Nature of Risk ------------------------------------------------------------------------------------- 14
3.2. Managing Risk ------------------------------------------------------------------------------------- 16
3.3. Risk Identification--------------------------------------------------------------------------------- 16
4. Conclusion & Future work ---------------------------------------------------------------------------- 18
References ----------------------------------------------------------------------------------------------------- 20
 4

List of Figures
Figure 1: what is Management? ----------------------------------------------------------------------------- 6
Figure 2: Elements of Management Activities ------------------------------------------------------------ 7
Figure 3: Activity Organization ---------------------------------------------------------------------------- 11
Figure 4: Project Planning ---------------------------------------------------------------------------------- 12
Figure 5: Activity Allocation ------------------------------------------------------------------------------- 13
Figure 6: Gantt chart ----------------------------------------------------------------------------------------- 13
Figure 7: Staff Allocation ----------------------------------------------------------------------------------- 14

List of Tables
Table 1: Types of Project Plan ----------------------------------------------------------------------------- 11
Table 2: Task Durations & Dependencies ---------------------------------------------------------------- 12
 5

1. Introduction
In software industry, many techniques of general project management are applicable to software
development. However, the software industry has also achieved a notorious reputation of poor
performance in terms of schedule, cost, and quality assurance. Estimating, planning, and quality
control processes are so bad that the majority of large system projects run late or exceed their
budgets. Many are canceled without ever reaching completion (Jones, 1998). This failure of
software is often referred to as the ―software crisis‖. This term refers to the fact that software
projects are frequently delivered behind schedule, cost more than the original estimates, fail to
meet user requirements, are unreliable, and virtually impossible to maintain (Chatzoglou and
Macaulay, 1996). A study in the USA found that 31 percent of software projects were canceled
before completion, and more than half the project’s cost an average of 189 percent more than
their original estimates (Whittaker, 1999). ―Software crisis‖ can be attributed to the poor
application of design approaches, but also to inadequate project management due to lack of
recognition and understanding of the real problems in software development (Ratcliff, 1987).
Many previous studies have indicated the role of project management for project success. The
results of Blackburn et al (1996) indicated that the methods employed to manage the project and
the people involved in the cross-functional process of software development tend to be more
important than the tools and technology. Although new technologies have been developed to
facilitate software development process, programmer’s knowledge and experience is still the key
to better software development. Therefore, managing the programmers and related stakeholders
in software development, is more important than the technology itself. In recent studies,
Aladwani (2002) found the positive significant relationship between project planning and project
success. Procaccino et al. (2002) also indicated the significant role of customer involvement and
support from top management to the success of a project. The more customer involvement and
top management support, the higher chance of project success.

1.1. What is Management

Basically, the management involves the following activities:
Planning- deciding what is to be done
Organizing- making arrangements
Staffing- selecting the right people for the job
 6

Directing- giving instructions

Monitoring- checking on progress
Controlling- taking action to remedy hold-ups
Innovating- coming up with new solutions
Representing- liaising with users, etc.
Project management is also defined as a strategic competency that has successfully been applied
in such high profile projects as the construction of silk root, organizing and managing

Figure 1: what is Management?

1.2. What is Project Management

Project Management is the art of maximizing the probability that a project delivers its goals on
Time, to Budget and at the required Quality. The art of planning for the future has always been a
human trait. In essence a project can be captured on paper with a few simple elements: a start
date, an end date, the tasks that have to be carried out and when they should be finished, and
some idea of the resources (people, machines etc.) that will be needed during the course of the
project.
 7

Project management is the application of knowledge, skills, tools, and techniques to project
activities to meet project requirements. Project management is accomplished through the use of
the processes such as: initiating, planning, executing, controlling, and closing. It is important to
note that many of the processes within project management are iterative in nature. This is in part
due to the existence of and the necessity for progressive elaboration in a project throughout the
project life cycle; i.e., the more you know about your project, the better you are able to manage
it. [1]

The term project management is sometimes used to describe an organizational approach to the
management of ongoing operations. This approach, more properly called management by
projects, treats many aspects of ongoing operations as projects to apply project management
techniques to the almost any human activity that involves carrying out a non- repetitive task can
be a project. So we are all project managers! We all practice project management (PM). But
there is a big difference between carrying out a very simple project involving one or two people
and one involving a complex mix of people, organizations and tasks. [1]

Here are some elements of Project Management:

Management

Planning Staffing Controlling

Directing Organizing

Figure 2: Elements of Management Activities

 8

1.3. What is software Project Management

When the plan starts to involve different things happening at different times, some of which are
dependent on each other, plus resources required at different times and in different quantities and
perhaps working at different rates, the paper plan could start to cover a vast area and be
unreadable. Nevertheless, the idea that complex plans could be analyzed by a computer to allow
someone to control a project is the basis of much of the development in technology that now
allows projects of any size and complexity, not only to be planned, but also modeled to answer
'what if?' questions.
The original programs and computers tended to produce answers long after an event had taken
place. Now, there are many project planning and scheduling programs that can provide real time
information, as well as linking to risk analysis, time recording, and costing, estimating and other
aspects of project control. But computer programs are not project management: they are tools for
project managers to use. Project management is all that mix of components of control,
leadership, teamwork, resource management etc. that goes into a successful project. [4]

Project managers can be found in all industries. Their numbers have grown rapidly as industry
and commerce has realized that much of what it does is project work. And as project-based
organizations have started to emerge, project management is becoming established as both a
professional career path and a way of controlling business. So opportunities in project
management now exist not only in being a project manager, but also as part of the support team
in a project or program office or as a team leader for part of a project. There are also
qualifications that can be attained through the professional associations.

1.4. What is project

A project is an activity with specific goals which takes place over a finite period of time. ―A
temporary organization that is needed to produce a unique and pre-defined outcome or result at a
pre-specified time using pre-determined resources‖

Projects are often implemented as a means of achieving an organization’s strategic plan.

Operations and projects differ primarily in that operations are ongoing and repetitive while
projects are temporary and unique. A project can thus be defined in terms of its distinctive
characteristics—a project is a temporary endeavor undertaken to create a unique product or
 9

service. Temporary means that every project has a definite beginning and a definite end. Unique
means that the product or service is different in some distinguishing way from all other products
or services. For many organizations, projects are a means to respond to those requests that cannot
be addressed within the organization’s normal operational limits.

Projects are undertaken at all levels of the organization. They may involve a single person or
many thousands. Their duration ranges from a few weeks to more than five years. Projects may
involve a single unit of one organization or may cross organizational boundaries, as in joint
ventures and partnering. [4]

Examples of Projects Includes:

 Developing a new product or service.

 Effecting a change in structure, staffing, or style of an organization.
 Designing a new transportation vehicle.
 Developing or acquiring a new or modified information system.
 Constructing a building or facility.
 Building a water system for a community in a developing country.
 Running a campaign for political office.
 Implementing a new business procedure or process

1.5. Purpose of SPM

The projects are designed to achieve specific targets defined in terms of aims, tasks or a purpose.
The nature and size of the project depends upon complexity of the task, realization of the aims
and scope of the purpose any organization wants to achieve. In short project has to be aimed for
achieving certain tasks in a given time frame.
The projects are always designed considering time constraints. Extension to the project
completion deadlines are always discouraged as time overrun, costs extra and in some cases
opportunity cost for not completing a project is too high.
Progressive elaboration is a characteristic of projects that accompanies the concepts of temporary
and unique. ―Progressively‖ means developing thoroughly in steps, and continuing steadily by
increments while elaborated means ―worked out with care and detail; developed thoroughly‖
 10

For example, the project scope will be broadly described early in the project, and made more
explicit and detailed as the project team develops a better and more complete understanding of
the objectives and deliverables. [5]

2. Project staffing

May not be possible to appoint the ideal people to work on a project.

 Project budget may not allow for the use of highly-paid staff
 Staff with the appropriate experience may not be available
 An organisation may wish to develop employee skills on a software project
• Here’s Bob. He’s a sophomore. He’ll be a member of your HazMat Rover team. He
doesn’t know much yet, but he can brew a mean cup of coffee and has a great
personality.
 Managers have to work within these constraints
• Especially when (as is currently the case) there is an international shortage of skilled
IT staff [3]

2.1. Project Planning

 Probably the most time-consuming, project management activity
 Continuous activity from initial concept through to system delivery
 Plans must be regularly revised as new information becomes available
• Beware of grumbling developers
 Various different types of plan may be developed to support the main software project
plan that is concerned with schedule and budget [3 ]

2.2. Types of Project Plan

Plan Description
Quality Plan Describes the quality procedures & standards
that will be used in a project
Validation Plan Describes the approach, resources & Schedule
used for system validation
Configuration Management plan Describes the configuration management
 11

procedures & Structures to be used.

Maintenance Plan Predicts the maintenance requirements of the
system, maintenance costs & effort required.
Staff development plan Describes how the skills & experience of the
project team members will be developed.
Table 1: Types of Project Plan

2.3. Activity Organization

 Activities in a project should be organized to produce tangible outputs for management to
judge progress
 Milestones are the end-point of a process activity
 Deliverables are project results delivered to customers

ACT IVITIES

Feasibility Requir ements Prototype Design Requir ements

study analysis development study specification

Feasibility Requir ements Evaluation Architectural Requir ements

report definition report design specification

MILESTONES

Figure 3: Activity Organization

2.4. Project Scheduling

 Split project into tasks and estimate time and resources required to complete each task
 Organize tasks concurrently to make optimal use of workforce
 Minimize task dependencies to avoid delays caused by one task waiting for another
to complete
 Dependent on project managers’ intuition and experience [3]
 12

Identify Identify activity Estimate resources Allocate people Create project

activities dependencies for activities to activities charts

Software Activity charts

requirements and bar charts

Figure 4: Project Planning

2.4.1.Scheduling Problems
 Estimating the difficulty of problems and hence the cost of developing a solution is
hard
 Productivity is not proportional to the number of people working on a task
• Adding people to a late project makes it later because of communication
overheads
 The unexpected always happens
• Always allow contingency in planning [3]

2.5. Bar charts & Activity Networks

 Graphical notations used to illustrate the project schedule
 Show project breakdown into tasks
• Tasks should not be too small
• They should take about a week or two
 Activity charts show task dependencies and the critical path
 Bar charts show schedule against calendar time

2.6. Task Durations & Dependencies

Task Duration (days) Dependencies
T1 8
T2 15
T3 15 T1 (M1)
T4 10
T5 10 T2, T4 (M2)
T6 5 T1, T2 (M3)
T7 20 T1 (M1)
T8 25 T4 (M5)
T9 15 T3, T6 (M4)
T10 15 T5, T7 (M7)
T11 7 T9 (M6)
T12 10 T11 (M8)
Table 2: Task Durations & Dependencies
 13

2.7. Activity Network

14/7/99 15 days
15 days
M1 T3
8 days T9
T1 5 days 4/8/99 25/8/99
25/7/99
T6 M4 M6
4/7/99 M3
start 20 days 7 days
15 days
T7 T11
T2

25/7/99 10 days 11/8/99 5/9/99

10 days
M2 M7 M8
T4 T5 15 days
T10 10 days
18/7/99
T12
M5
25 days
T8 Finish
19/9/99

Figure 5: Activity Allocation

2.8. Gantt Chart

4/7 11/7 18/7 25/7 1/8 8/8 15/8 22/8 29/8 5/9 12/9 19/9
S tart
T4
T1
T2
M1
T7
T3
M5
T8
M3
M2
T6
T5
M4
T9
M7
T10
M6
T11
M8
T12
F inish

Figure 6: Gantt chart

 14

2.9. Staff Allocation

4/7 11/7 18/7 25/ 1/8 8/8 15/8 22/8 29/8 5/9 12/9 19/9

Fred T4
T8 T11
T12
Jane T1
T3
T9
Anne T2
T6 T10

Jim T7

Mary T5

Figure 7: Staff Allocation

3. Risk Management

In risk management we are concerned with the risk of the development project not proceeding
according to the plan. Specially the project running late or over budget and with the
identification of the step that can be taken to avoid or minimize those risk. Some risks are more
important than others. Whether or not a particular risk is important depends on the nature of the r
risk, its likely effects on a particular activity and the criticality of the activity. High risk activities
on a project critical path are a cause of concern. To reduce these dangers, we must ensure that
risk are minimized or at least distributed over the project and ideally, removed from critical path
activities. [2]

3.1. Nature of Risk

For the purpose of identifying and managing those risks that may cause a project to overrun its
time-scale or budget, it is convenient to identify three types of risk.
 15

 Those caused by the inherent difficulties of estimation

 Those due to assumption made during the planning
 Those of unforeseen event occurring

Estimation Errors: Some tasks are harder to estimate then other because of the lack of
experience of similar tasks. Producing a set of user annuals is reasonability straightforward and
given that we have carried out similar tasks previously we should be able to estimate with some
degree of accuracy how long it will take and how much it will cost.

On the other hand, the time required for program testing and debugging, might be difficult to
predict with a similar degree of accuracy – even if we have written similar programs in the past.
Estimation can be improved by analysing historic data for similar activities and similar system.
Keeping records comparing our original estimates with the final outcome will reveal the types of
task that are difficult to estimates correctly.

Planning assumptions: At every stage during planning assumptions are made which, if not
valid, may put the plan at risk. Our activity network, for example, is likely to be built on the
assumption of using a particular design methodology – which may be subsequently changed. We
generally assume that, following coding, a module will be tested and then integrated with others
– we might not plan for module testing showing up the need or changes in the original design but
in the event, it might happen. At each stage in the planning process, it is important to list
explicitly all of the assumptions that have been made and identify what effects they might have
on the plan if they are inappropriate.

Eventualities: some eventualities might never be foreseen and we can only resign ourselves to
the act that unimaginable thing does, sometime happen. They are however, very rare. The
majority of unexpected events can, in fact, be identified the requirements specification might be
altered after some of the modules have been coded, the senior programmer might take leave, the
required hardware might not be delivered on time. Such events do happen from time to time and
although be like hood of any one of them happening during a particular project may be relatively
low; they must be considered and planned for.
 16

3.2. Managing Risk

The objective of risk management is to avoid or minimize the adverse effects of unforeseen
events by avoiding the risks or drawing up contingency plans for dealing with them. There are a
number of modules for risk management, but most are similar, in that they identify two main
components – risk identification and risk management. Which shows a task breakdown structure
for Barry Boehm calls risk engineering?

Risk Identification: consists of listing all of the risk that can adversely affect the successful
execution of the project.
Risk Estimation: consists of assessing the like hood and impact of each hazard.
Risk evaluation: consists of ranking the risks and determining risk aversion strategies.
Risk Planning: consists of drawing up contingency plans and where appropriate, adding these to
the project structure. With small project risk planning is likely to be the responsibility of the
project managers but medium or large project will benefits from appointment of a full-time risk
managers.
Risk Control: concerns the main functions of the risk managers in minimising and reacting to
problems throughout the project. This function will include aspects of quality in addition to
dealing with problems as the occur.
Risk Monitoring: must be an on-going activity, as the importance and like hood of particulate
risk can change as the project proceeds.
Risk Directing and Risk staffing: are concerned with the day-to-day management of risk. Risk
aversion and problem solving strategies frequently involve the use of additional staff and this
must be planned for direct. [6]
Whatever task model or whichever techniques are used, risk management will not be effective
unless all project staff are risk-oriented and are provided with an environment where they can
freely discuss the risk that might affect a project. All too often, team members who identify
potential risk at an early stage are seen as having a negative attitude. [2]

3.3. Risk Identification

The first stage in any risk assessment exercise is to identify the hazard that might affect the
duration or resource costs of the projects. A hazard is an event that might occur and will if it does
 17

occur, create a problem for the successful completion of the project, In identification and
analysing risk, we can usefully distinguish between the cause, its immediate effect and the risk
that it will pose to be the project. For example they illness of a team member is a hazard that
might results in the problems of late delivery of a component. The late delivery of that
component is likely have an effect on other activities and might, particularly if it is on the critical
path; put the project completion data at risk. [2]

A common way of identifying hazards is to use checklist listing all the possible hazards and
factors that influence them. Typical checklists list many, even hundreds, of factors and there are,
today, a number of knowledge-based software products available to assist in this analysis. Some
hazards are generic risk – that is they are relevant to all software projects and standard checklist
can be used and augmented from an analysis of past projects to identify them. These will include
risk such as mis-understanding the requirement or key personal being ill. There will also be
specific risks that are relevant to an individual project and these are likely to be more difficult to
identify without an involvement of the members of the project team and a working environment
that encouragement risk assessment. The categories of factors that will need to be considered
include the following.

 Application factor
 Staff factors
 Project factors
 Project methods
 Hardware/ software factor
 Changeover factor
 Supplier factor
 Environment factor
 Health and safety factor
 18

4. Conclusion & Future work

This study focused on planning in software projects in a developing country. This research issues
might be extended in other regions in the world. The extension of these research issues would be
a better comparison with a wider range of software projects of international regional context with
different characteristics like size, or type. It is also necessary to investigate the role of other areas
of project management in software projects like quality management, risk management or
conflict management. The problems of other stages like analysis and design, coding, testing or
deploying in software development are also the issues for further research. The results of the
exploratory study also suggest the important role of communication in project management. The
problem of changing customers’ requirements and the poor understanding of customers’
expectation are evidences for more emphasis on the impact of project communication on project
success.

This study failed to support some of the proposed hypotheses related to the effect of applying
techniques or methods and management styles on planning performance. Hence, there is a need
for further study on the influence of different techniques on project results.

This study focused on software development projects in professional software companies.

However, the research issues and the approach of this study could be extended to other kind of
developing organizations such as software development projects of other industries, for example
like consult anting or academic one. It could be also applied to other project types, like
information system project. Further researches may be conducted on the role of planning in other
types of projects.

 Good project management is essential for project success

 The intangible nature of software causes problems for management
 Managers have diverse roles but their most significant activities are planning, estimating
and scheduling
 Planning and estimating are iterative processes that continue throughout the course of a
project
 A project milestone is a predictable state where some formal report of progress is
presented to management.
 19

 Risks may be project risks, product risks or business risks

 Risk management is concerned with identifying risks that may affect the project and
planning to ensure that these risks do not develop into major threats.
 20

References

1. Mike Wooldridge, SOFTWARE PROJECT MANAGEMENT , available from:

http://www.cs.ox.ac.uk/people/michael.wooldridge/teaching/soft-eng/lect05.pdf/
[accessed 01 January 2016]
2. Boehm, B. (1989). Software Risk Management. Washington, DC, IEEE Computer
Society Press, available from:
http://agile.csc.ncsu.edu/SEMaterials/RiskManagement.pdf/ [accessed 20 December
2015]
3. Mel Rosso-Llopart, Project Planning & scheduling, available from:
https://www.cs.cmu.edu/~aldrich/courses/413/slides/5-planning-1.pdf/, [accessed 03 January
2016 ]
4. Project Management, available from:
https://www.cs.umd.edu/~atif/Teaching/Summer2013/12.pdf/ [accessed 05 January 2016]
5. Johan Gouws, Leonie E. Gouws, Fundamentals of software engineering in project management,
available from: http://www.feedforward.com.au/software-engineering-poject-sample.pdf/
[accessed 06 January 2016]
6. Software Design Document, Testing, Deployment And Configuration Management, And User
Manual of the UUIS, available from: http://arxiv.org/ftp/arxiv/papers/1005/1005.0169.pdf/
[accessed 07 January 2016]

View publication stats