documentation of spm

1

Project Management in Software Engineering

1

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

Term Paper

WS 2015/16

Module ―Advanced Software Engineering‖

By

Muhammad Ahsan Nawaz (18790)

2


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. There

were minor differences between software projects by type, such as commercial, made to order, and

outsourcing.

3


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 ------------------------------------------------------------------------ 7

1.4. What is project --------------------------------------------------------------------------------------------------------- 8

1.5. Purpose of SPM -------------------------------------------------------------------------------------------------------- 9

2. Project staffing ---------------------------------------------------------------------------------------------------------------- 9

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 ----------------------------------------------------------------------------------------- 11

2.5. Bar charts & Activity Networks--------------------------------------------------------------------------------- 12

2.6. Task Durations & Dependencies -------------------------------------------------------------------------------- 12

2.7. Activity Network ------------------------------------------------------------------------------------------------------ 12

2.8. Gantt Chart ------------------------------------------------------------------------------------------------------------- 13

2.9. Staff Allocation -------------------------------------------------------------------------------------------------------- 13

3. Risk Management ----------------------------------------------------------------------------------------------------------- 14

3.1. Nature of Risk --------------------------------------------------------------------------------------------------------- 14

3.2. Managing Risk --------------------------------------------------------------------------------------------------------- 15

3.3. Risk Identification ---------------------------------------------------------------------------------------------------- 16

4. Conclusion & Future work ---------------------------------------------------------------------------------------------- 17

References --------------------------------------------------------------------------------------------------------------- 18

4


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 -------------------------------------------------------------------------------------------------------- 11

Figure 6: Activity Allocation ------------------------------------------------------------------------------------------------------ 13

Figure 7: Gantt chart --------------------------------------------------------------------------------------------------------------- 13

Figure 8: Staff Allocation ---------------------------------------------------------------------------------------------------------- 14

List of Tables

Table 1: Types of Project Plan --------------------------------------------------------------------------------------------------- 10

Table 2: Task Durations & Dependencies ------------------------------------------------------------------------------------ 12

5


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

Directing- giving instructions

Monitoring- checking on progress

Controlling- taking action to remedy hold-ups

6


6

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.

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;

7


7

i.e., the more you know about your project, the better you are able to manage it.

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.

Here are some elements of Project Management:

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

Organizing

Staffing

Management

Planning Controlling

Directing

Figure 2: Elements of Management Activities

8


8

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.

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 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.

Examples of Projects Includes:

9


9

• 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‖

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.

2. Project staffing

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

10


10

• 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

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

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

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

11


11

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

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

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

Evaluationreport

Prototypedevelopment

Requirementsdefinition

Requirementsanalysis

Feasibilityreport

Feasibilitystudy

Architecturaldesign

Designstudy

Requirementsspecification

Requirementsspecification

ACTIVITIES

MILESTONES

Estimate resourcesfor activities

Identify activitydependencies

Identifyactivities

Allocate peopleto activities

Create project

charts

Softwarerequirements

Activity chartsand bar charts

12


12

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

2.7. Activity Network

13


13

Figure 5: Activity Allocation

2.8. Gantt Chart

Figure 6: Gantt chart

2.9. Staff Allocation

start

T2

M3T6

Finish

T10

M7T5

T7

M2T4

M5

T8

4/7/99

8 days

14/7/99 15 days

4/8/99

15 days

25/8/99

7 days

5/9/99

10 days

19/9/99

15 days

11/8/99

25 days

10 days

20 days

5 days25/7/99

15 days

25/7/99

18/7/99

10 days

T1

M1 T3

T9

M6

T11

M8

T12

M4

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

T4

T1

T2

M1

T7T3

M5

T8

M3

M2

T6

T5

M4

T9

M7

T10

M6

T11M8

T12

Start

Finish

14


14

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.

3.1. Nature of Risk

For the purpose of identifying and managing those risks that may cause a project to overrun its

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

T4

T8 T11

T12

T1

T3

T9

T2

T6 T10

T7

T5

Fred

Jane

Anne

Mary

Jim

15


15

time-scale or budget, it is convenient to identify three types of risk.

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.

3.2. Managing Risk

The objective of risk management is to avoid or minimize the adverse effects of unforeseen

16


16

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.

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.

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 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.

17


17

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

4. Conclusion & Future work

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.

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.

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

18


18

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.

References http://www.cs.ox.ac.uk/people/michael.wooldridge/teaching/soft-eng/lect05.pdf

http://www.capterra.com/project-management-software/

http://agile.csc.ncsu.edu/SEMaterials/RiskManagement.pdf

https://www.cs.cmu.edu/~aldrich/courses/413/slides/5-planning-1.pdf

https://www.cs.umd.edu/~atif/Teaching/Summer2013/12.pdf

http://www.feedforward.com.au/software-engineering-poject-sample.pdf

http://arxiv.org/ftp/arxiv/papers/1005/1005.0169.pdf

file:///C:/Users/Mian%20Ahsan/Downloads/Thayer-SE-Proj-Mgt.pdf

documentation of spm

Documents