Project Management in Software Engineering

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.

2.

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

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.

3.

4.

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

Risk Management --------------------------------------------------------------------------------------- 14 3.1.

Nature of Risk ------------------------------------------------------------------------------------- 14

3.2.

Managing Risk ------------------------------------------------------------------------------------- 16

3.3.

Risk Identification--------------------------------------------------------------------------------- 16

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

Staffing

Planning

Directing

Controlling

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 study

Requir ements analysis

Prototype development

Design study

Requir ements specification

Feasibility report

Requir ements definition

Evaluation report

Architectural design

Requir ements 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 activities

Identify activity dependencies

Estimate resources for activities

Allocate people to activities

Software requirements

Create project charts

Activity charts 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)

T1 T2 T3 T4 T5 T6 T7 T8 T9 T10 T11 T12

8 15 15 10 10 5 20 25 15 15 7 10

Dependencies T1 (M1) T2, T4 (M2) T1, T2 (M3) T1 (M1) T4 (M5) T3, T6 (M4) T5, T7 (M7) T9 (M6) T11 (M8)

Table 2: Task Durations & Dependencies

13

Activity Network

2.7.

15 days

14/7/99 M1

8 days

15 days

T3

T9

T1

5 days

25/7/99

4/7/99

4/8/99

T6

M4

M3

start

25/8/99 M6 7 days

20 days

15 days T7

T2 25/7/99

10 days

5/9/99

11/8/99

10 days

M2

T4

T11

M7

T5

M8

15 days T10

18/7/99

10 days 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 Fred

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

Jane

T1 T3 T9

Anne

T2 T6

Jim

T10

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]