Project Management-Project Report
Project Management-Project Report
Project Management-Project Report
School of Engineering Blekinge Institute of Technology Box 520 SE 372 25 Ronneby Sweden
This thesis is submitted to the School of Engineering at Blekinge Institute of Technology in partial fulfillment of the requirements for the degree of Master of Science in Software Engineering. The thesis is equivalent to 20 weeks of full time studies.
Contact Information: Authors: Andreas Ljungquist Bjrn Rosander E-mail: pt00alj@student.bth.se pt00bro@student.bth.se
School of Engineering Blekinge Institute of Technology Box 520 SE 372 25 Ronneby Sweden
ABSTRACT
Software engineering is the computer science discipline concerned with developing computer software. However, software engineering does not only include the technical perspective of producing software. It also involves management issues, such as planning, controlling, and monitoring a software project. A project typically embraces a structured set of activities, which are performed in a pre-determined sequence. The initial activity is generally the process of planning the project, which according to some is one of the most important and crucial efforts in order to achieve predefined objectives. Other states the opposite and claim that too much planning may obstruct development creativity. Current thesis explores the planning paradigm and the significance of planning efforts in the Swedish software industry. Contemporary literatures on software project planning are reviewed and presented. Moreover, the result of an empirical study, examining the relationship between project planning and project success, is presented. Keywords: Project engineering. success, planning, software
CONTENTS
ABSTRACT .......................................................................................................................................... 1 CONTENTS .......................................................................................................................................... 2 FIGURES .............................................................................................................................................. 4 TABLES ................................................................................................................................................ 5 1 INTRODUCTION ....................................................................................................................... 6 1.1 1.2 1.3 2 BACKGROUND........................................................................................................................ 6 PURPOSE AND OBJECTIVES .................................................................................................... 7 OVERVIEW ............................................................................................................................. 8
PROJECT PLANNING............................................................................................................. 10 2.1 THE PROJECT PLAN .............................................................................................................. 10 2.1.1 Why do we have a project plan? ..................................................................................... 10 2.1.2 Different types of project plans....................................................................................... 11 2.1.3 The form of a project plan .............................................................................................. 11 2.2 PROJECT ESTIMATION .......................................................................................................... 13 2.2.1 Why do we estimate?....................................................................................................... 13 2.2.2 What do we estimate? ..................................................................................................... 13 2.2.3 How do we estimate? ...................................................................................................... 15 2.3 RISK PLANNING ................................................................................................................... 18 2.3.1 Risk Concepts.................................................................................................................. 19 2.3.2 Risk Identification ........................................................................................................... 20 2.3.3 Risk Quantification ......................................................................................................... 20 2.3.4 Risk Response Planning.................................................................................................. 21 2.4 PROJECT PLANNING MANAGEMENT ..................................................................................... 22 2.4.1 Planning Management .................................................................................................... 22 2.4.2 Project Organizational Structure ................................................................................... 23 2.4.3 Process Models............................................................................................................... 24 2.4.4
2.4.3.1 2.4.3.2 2.2.3.1 2.2.3.2 Experience-based techniques ............................................................................................... 16 Algorithmic modeling .......................................................................................................... 17
3 4
PROJECT SUCCESS................................................................................................................ 27 3.1 4.1 4.2 PROJECT SUCCESS ASSESSMENT .......................................................................................... 27 OUR RESEARCH OBJECTIVES ............................................................................................... 29 OUR RESEARCH METHODOLOGY ......................................................................................... 29
Interviews............................................................................................................................. 29 The Project Plan ................................................................................................................... 31 Project Estimation ................................................................................................................ 32 Risk Planning ....................................................................................................................... 33
4.2.1.1
4.3.2 Project Success ............................................................................................................... 33 4.4 DISCUSSION AND CONCLUSION ............................................................................................ 34 5 QUANTITATIVE RESEARCH ............................................................................................... 37 5.1 5.2 5.3 RELATED RESEARCH WORK ................................................................................................ 37 OUR RESEARCH OBJECTIVES ............................................................................................... 38 OUR RESEARCH METHODOLOGY ......................................................................................... 39
5.4 DATA ................................................................................................................................... 39 5.5 MEASURES ........................................................................................................................... 40 5.6 DATA ANALYSIS AND RESULT .............................................................................................. 41 5.6.1 Correlation to achievement of Planning Goals .............................................................. 41 5.6.2 Correlation to Customer Benefits ................................................................................... 43 5.6.3 Correlation to Contractor Benefits................................................................................. 43 5.6.4 Project managers general view on project success ........................................................ 43 5.7 DISCUSSION AND CONCLUSION ............................................................................................ 43 6 7 CONCLUSION .......................................................................................................................... 45 REFERENCES........................................................................................................................... 46
FIGURES
Figure 1 Network diagram...................................................................................................21
TABLES
Table 1 System types used in function point estimation........................................................14 Table 2 Cost Factors ..............................................................................................................18 Table 3 Level of Project Planning (Project planning efforts) ................................................40 Table 4 Level of project success (Achievement of planning goals) ......................................40 Table 5 End-User Benefits (Represented by the project manager)........................................40 Table 6 Contractor Benefits ...................................................................................................41 Table 7 General project success.............................................................................................41 Table 8 Correlation between planning efforts and project success........................................41
INTRODUCTION
Due to an increasing market demand and a rapid expansion of technological possibilities, the pressure on the software industry is constantly growing. In order for the software companies to cope with frequently shifting conditions and the raising quality demands, they need to constantly improve the quality of their work. Obviously, these improvement efforts are also reflected in the planning activities. Project planning has become of great importance for software development, which has forced the industry to make fundamental changes of the planning paradigm [1]. Research points out that an important factor in project success is thorough planning in the early stage of the project life-cycle [1]. Consequently, the quite unstructured and shapeless planning of yesterday has today grown to be a more formal and organized activity. The long-term consequences of early cost- and time planning forces the industry to carefully examine the project scope and set up early coordination [3]. Some argue that too much planning may endanger the project [30] and moreover claim it may obstruct creativity [22]. However, although planning does not guarantee success, at least a minimum degree of planning is required, since lack of planning most likely will guarantee failure [22]. This thesis aims at exploring the project planning paradigm in the Swedish software industry. How do Swedish software companies define project planning? What different factors influence the choice of planning strategy? What is necessary to do in order to become successful in the project planning? Does the software industry have exactly the same view regarding project planning? Do they include everything that, according to literature, should be included in a project plan? Moreover, current thesis aims at analyzing the relationship between project planning and project success. Is there a clear correlation between the amount of planning effort and the level of success achieved? These are some of the questions which this thesis tries to answer. The research is based on both literature reviews and empirical studies. The empirical studies are divided into two parts; one qualitative research conducted at 10 different software companies located in Sweden, and one quantitative research based on a questionnaire that has been completed by 38 companies.
1.1
Background
We are two students completing our master of science in software engineering at Blekinge Institute of Technology in Ronneby, Sweden. Software engineering has emerged from the computer science field, but covers also issues such as management, human factors, estimation and control. A major part of project management is concerned with planning efforts. During our university studies weve continually been reminded of how important it is to carefully plan a project in order to achieve success. We have identified and experienced project planning and its underlying activities as difficult and challenging tasks. However, it has
never been proven to us that there exists a clear relationship between project planning and project success. We have therefore chosen to investigate the relation between project planning and project success.
1.2
Today, there exists an abundance of different strategies and approaches to plan a project. Weve chosen to mainly study what some of the leading and most influential authors and organizations, such as [5], [28], and [2], advocates. By investigating software engineering literature thoroughly we have identified four major parts in software engineering project planning. These parts are project plan, project estimations, risk planning and project planning management. We have chosen to present these parts as a basis for our research survey. We have chosen to start with the project plan, why we need it, different types of project plans and what kind of parts that can be included in a project plan. This part is followed by project estimations, and this part is divided into why, what and how we estimate. Estimations are followed by risk planning. Risk planning is divided into risk concepts, risk identification, risk quantification and risk response planning. The last part we have chosen to present is project planning management. This includes planning management, project organizational structure, process models, roles and responsibilities. All these parts have been identified from well recognized software engineering literature [5], [28] and [2]. Some of the contemporary literatures as well as parts of the industry claim that activities such as project pre-study and requirements elicitation are included in project planning. However, we have chosen to study the literature that does not regard these activities as planning activities. Thus, these activities are outside the scope of this thesis.
1.3
Overview
Chapter 2: Literary Survey Project Planning Current chapter presents a literary study of project planning and consists of the following sections: Section 2.1 Project Plan Describes the content and purpose of a project plan. Section 2.2 Project Estimation Describes why, what and how to estimate a project. Section 2.3 Risk Planning Describes how to identify project risks, how to quantify the risks, and how to develop suitable responses to the risks. Section 2.4 Project Planning Management Describes the planning management activities that need to be carried out during a project. Chapter 3: Literary Survey Project Success Current chapter presents a literary study of project success and consists of the following section: Section 3.1 Project Success Assessment Describes how project success is assessed and defined Chapter 4: Qualitative Research Current chapter presents the interviews conducted with ten software project managers and our analysis. The chapter is divided into the following sections: Section 4.1 Our Research Objectives Describes our research objectives and what kind of information we wanted to obtain from the interviews. Section 4.2 Our Research Methodology Describes our interview technique and the structure of the discussions. Section 4.3 Research Results Describes the results of our research. Section 4.4 Discussion and Conclusion Presents our Discussion and conclusion regarding the qualitative research. Chapter 5: Quantitative Research Current chapter presents a quantitative research conducted on 38 different companies and consists of the following section. Section 5.1 Related Research Work Presents work and result from similar investigations. Section 5.2 Our Research Objectives Describes our research objectives and what kind of information we wanted to obtain from the questionnaire.
Section 5.3 Our Research Methodology Describes our research methodology and the structure of our questionnaire. Section 5.4 Data Presents and describes the characteristics and criteria of the questionnaires used in our research. Section 5.5 Measures Presents the measures we received from the project managers. Section 5.6 Data Analysis and Result Presents our analysis and the correlation result we received. Section 5.7 Discussion and Conclusion Presents our Discussion and conclusion regarding the quantitative research. Chapter 6: Conslusion Current chapter presents our main conclusion drawn from this thesis.
PROJECT PLANNING
The every day life, now and then, consists of planned activities, carried out with the intention to achieve certain objectives. For example, going to the grocery store in order to do the weekly purchase is one of those everyday activities. Carrying out such ordinary activity also requires planning efforts. What groceries should I purchase? How do I get to the grocery store? What means of payment do I use? How do I get home again? Furthermore, my trip to the store is expected to last a certain time and the expenses for my purchase and for means of transports are also expected to be a specific amount. My visit at the grocery store also involves certain risks jeopardizing my objectives, I may forget money or my credit card, certain groceries are sold out, complications arise concerning transports, etc. If some of these risks become reality they will most likely become problems affecting my objectives, but may also jeopardize subsequent plans. In ordinary life, these mistakes are affordable, but lack of planning in industry may result in that huge amounts of money are lost, which moreover may result in that employees lose their jobs. Projects are an ancient phenomenon. People have been working on projects since the early days of organized work. For example, the Egyptian pyramids, the Greek Parthenon, and the Great Chinese Wall are early proofs of projects. A project may be defined as a planned undertaking, designed to achieve certain objectives within a given budget and within a specific time interval. The Project Management Institute (PMI) [2] defines a project as a "temporary endeavor undertaken to create a unique product or service". The words temporary endeavor implies that the efforts are time limited. A project is a set of limited resources, such as time, people, knowledge, money etc. and project planning is the key element to obtain control and utilization of these recourses, in the best possible way, in order to ensure fulfillments of the project objectives [4]. The results generated by the project planning phase should be compiled and documented as described in the following section.
2.1
2.1.1
Define key management reviews as to content, extent, and timing Provide a baseline for progress measurement and project control
The project plan is generally developed in the initial phase of the project and needs to be reviewed and agreed upon by all concerned persons. However, the plan is expected to change over time and is updated each time the actual progress differs from the plan or when project conditions changes, which require new approaches [28]. A carefully prepared project plan if properly followed and committed to, should lead to a successful project and eliminate many of the pitfalls inherent in the project management process [7]. It provides leadership vision and facilitates for management to utilize available resources efficiently [7].
2.1.2
2.1.3
1. Scope and Objectives - The scope and objectives of the project are generally set by extracted requirements. The scope is a statement defining the project and its deliverables and should clearly and concisely state project information such as, what it is, what it does, how much it will cost, and when it will be delivered [7]. The project scope has strong relationships to the project schedule and involved resources. Thus, modifications of the project may also affect the project scope. 2. Work Breakdown Structure (WBS) - A WBS is a deliverable-oriented grouping of project components that organizes and defines the total project scope [2]. Thus, the WBS divides the total scope into major work packages, which are
11
further subdivided into manageable work items to be accomplished in order to finish the project [8]. 3. Budget and Schedule - The budget and schedule of the project are based on established estimates (see section 2.2) [2]. Schedule development implies to determine start and finish dates for concerned project activities, which for example may be performed through simulations or mathematical analysis [5]. The schedule may be presented by Gantt charts, milestone charts, etc. and may be supplemented by supporting detail documents that include identified assumptions and constraints [5]. Cost budgeting implies to allocate the overall cost estimates to individual work items. The budget should be based on and supported by the WBS, project schedule, and the cost estimates [5]. 4. Risks - Planning for project risks should address issues that could jeopardize accomplishment of critical project objectives [2]. The planning process involves identifying project risks, quantifying the risks, and developing risk responses. The risk planning process is further described in section 2.3. 5. Monitoring and Reporting Mechanisms The purpose of monitoring mechanisms are to provide an understanding of the project progress in order to take appropriate corrective actions if project performance deviates from established plans. Monitoring involves monitoring actual values of planning parameters, such as cost, effort, and schedule. These values are compared to the estimates and possible deviations are identified [5]. Reporting mechanisms are concerned with collecting and disseminate performance information in order to provide involved stakeholders with status, progress and information about how resources are used to fulfill established objectives [2]. 6. Resources - The resources and quantities required in order to carry out the project should be identified and described [5]. Project resources come in various forms such as, personnel, funds, equipment, facilities, material, information etc. and the selection of these resources should be based on the established estimates [5][7]. Establishing resource requirements allow for several benefits such as, identification of resource shortage, identification of feasibility problems due to resource conflicts, etc. [7]. 7. Knowledge & Skills - Planning for knowledge and skills involves both training of project team and acquisition of knowledge from external sources. The knowledge and skills required to execute the project should be identified and the currently available knowledge and skills should be assessed [5]. With this information available, the deficiency of knowledge and skills is identified and mechanisms for providing this knowledge and skills are selected [5]. 8. Stakeholder Involvement - Stakeholders involved in the project should be identified and their functions requiring representation in the project should be defined. Furthermore, the level of interaction and the relevance of each involvement should be described [5]. An appropriate technique to handle this effort is to develop a two-dimensional matrix with stakeholders along one axis and project activities along the other axis [5]. As stated above, current subjects are recommended by [5], [28] and [2]. Obviously, a project plan may take various forms depending on the needs and purpose. The project plan is obviously developed when the developer has reached an agreement with the customer. Prior to such an agreement, the supplier must be certain that they are capable of undertaking a project. If the supplier doesn' possess the t 12
knowledge, skills or time to undertake the project, it' a waste of time to initiate s negotiations with the customer. To find out whether this is the case or not, effort and time estimates must be established. When this is settled and negotiations are initiated, the supplier must come up with a reasonable price for the product. The price must be compatible, cover the development costs and furthermore generate a desirable profit. In order to achieve this balance the project costs must be estimated. With all the estimates at hand, its possible to establish the project scope, a schedule and budget, resources required, and knowledge and skills required. The next section is concerned with project estimation; why estimation is important, what to estimate, and different techniques to apply in order to develop estimates.
2.2
Project Estimation
Project estimation implies to predict the effort required to successfully execute the project. Lack of project estimates makes the project boundaries quite vague. Estimates serve as a compass, navigating the project team throughout the project lifecycle. Making estimations are not difficult, but to establish accurate and realistic estimates is one of the most challenging and important activity in software development [9].
2.2.1
Why do we estimate?
There are several reasons to establish project estimates. Project estimates, generally, provide the project staff, management and other stakeholders with basic guidelines and settles the project scope. As mentioned above, estimates are also an important instrument to verify that the supplier is capable of undertaking the project and moreover provides for a price indication. Thus, accurate estimates are critical to both the software supplier and their customers. Underestimating the costs may lead to that the supplier may be forced to exceed the budget, abandon the time plan and decrease functionality and quality of the software [10]. However, overestimating may result in too many resources allocated to the project or that the supplier loses the contract in the bidding phase, because of a too high price [10]. Furthermore, estimates are important because [10]: Estimates can help to classify and prioritize development projects with respect to an overall business plan. Estimates facilitate to allocate resources to the project and how these resources will be used. Estimates make it easier to manage and control projects when resources are linked to real needs.
2.2.2
What do we estimate?
A project is based on specific requirements and preconditions that set the project scope. Relevant project characteristics to estimate are factors that somehow limit the project and strongly influence the project and the outcome. How much effort is required to complete the project? How much calendar time is needed to complete the project? What is the total cost of the project? [28]. In order to answer these questions it is essential to first estimate the size of the project. The overall size of the project is provided by estimating each work product generated by the project. Size Deliverable and non-deliverable work products 13
Everything produced and generated within the project are classified as work products. Thus, work products may be deliverables as well as non-deliverables and may be both documents and software. The size and complexity of these work products are required as inputs to further estimate effort, schedule and cost [5]. The size may be such as number of functions, function points, lines of code, number of pages, number of classes, volume of data etc. [5]. Size estimates are the most important software estimates [11]. The main reason for that is the inherent dependence of cost and quality on the size [11]. Development of large software systems obviously costs more and also involves more quality problems than smaller software systems [11]. Thus, Size estimation provides the basis for all further software estimation. As stated above, size may be estimated by predicting the amount of different software metrics, such as number of functions, function points, lines of code etc. Line of Code (LOC) is quite popular software metric to use in order to estimate the software size. However, since LOC is strongly dependent on the programming language and the programming style, this approach may involve uncertainties [11]. Different languages require different amount of code to implement a specific function and different code standards and programming styles expect a certain amount of code on one line. More reliable software metric, when it comes to size estimation, is function points, which measures the amount of software functionality that will be implemented in the software [11]. In order to estimate the number of function points, the occurrences of five system types are counted (see table 1.) [11].
System types Internal logical files (ILF) External interface files (EIF) Definition Logical groupings of data in a system that are maintained by an end user Groupings of data from another system that are used only for reference purposes Example Inventory issue records, payroll records, product sales.
Application data extracted and read from other applications, parameter data maintained outside the application Item description, employee data, External inquiries Allow users to select and payment data, logon screens, (UI) display specific data from display, browse user functions ILFs or EIFs External inputs (EI) Functions that allow users Screen input of a sale, a receipt, an to add, change, delete data appointment, an order; messages in ILFs from other applications External outputs Outputs of data that reside Account statements, weekly sales (EO) in ILFs and EIFs produced reports, bar coded labels, payroll by the user checks Table 1 System types used in function point estimation
The requirements specification is reviewed in order to identify all the system types and these types is individually assigned one of three complexity value - high, medium or low - which are determined on the basis of rules provided by the International Function Point User Group (IFPUG) [12]. The complexity values are then translated into weights that varies from 3 (for simple input) to 15 (for complex internal files). When all the weights are settled, theyre applied in the unadjusted function-point counts (UFC), which is given as:
5 3
UFC =
i =1 j =1
N ijWij
14
In which Nij and Wij represents the number and weight of types of class I with complexity j. Just to give an example, it can be mentioned that Microsoft word for Windows version 6.0 consists of approximately 5000 function points [13]. Effort Predict the total project effort With the size estimates at hand it is possible to estimate the project efforts. Estimating effort implies to predict the total project effort. How much time is required to produce the already estimated work products? In order to establish these estimates it can be wise to define a project life cycle and a Work Breakdown Structure (WBS) [5]. A WBS is a product-oriented structure that divides the overall project into an interconnected set of small and manageable components. The WBS makes it possible to identify and organize these components and facilitates to allocate efforts and responsibilities to each component [8]. A project life cycle defines how the different project phases are sequenced. The software community provides for several different lifecycle models, such as the waterfall model, XP, evolutionary model etc [28]. Other relevant factors to consider when making effort estimates are knowledge, skill, and training needs. Time Develop a project schedule When the effort estimates are available its possible to determine and develop a project schedule. The project schedule should provide for the start and finish time of defined tasks, the number of people involved in each task, and what their assignments will be [9]. The schedule should be translated into calendar time in order to make it more understandable and useful. Cost Estimate the complete project In order to make a cost estimate of the complete project, several factors must be considered, such as labor, hardware and software resources, training, and other supporting infrastructure needs [28]. The effort costs, which are the dominant cost drivers in most projects, may for example be salaries, social- and insurance costs etc. of involved staff [28]. However, effort costs must also take overheads into account. Overheads may be such as, costs of building, heating, lighting etc [28].
2.2.3
How do we estimate?
As stated above, it can be quite easy to come up with estimates, but to establish credible and accurate estimates requires experience and/or knowledge. The software community utilizes a number of different models and techniques to develop and establish estimates. Over the last 30 years several estimation techniques have been proposed, such as estimation by analogy, expert judgement etc., which is further described below. However, there is no simple way to establish accurate estimates. Despite the extensive amount of experience with estimation techniques, the accuracy of the existing estimation techniques is not adequate. Initial estimates are usually based on inadequate information in a user requirements definition. Moreover, the software to be developed may run on unknown computers or use new technologies, and the people in the project may also be unknown [28]. The estimation techniques of today are divided into two different categories: experience-based techniques and algorithmic modeling. Experience-based techniques are based on the project managers knowledge and experience, and may take previous projects into consideration [28]. Algorithmic models (also known as parametic models) are based on mathematical algorithms that use variables
15
considered to be major cost factors, such as the project size, resources, and other process and product factors [28]. 2.2.3.1 Experience-based techniques All experienced-based techniques rely on experience-based judgements by competent and experienced personnel. However, there may be significant dissimilarities between past and future projects. Many new development technologies and methodologies have been introduced in the last 10 years and if the developers havent worked with these new concepts, their knowledge and experience may not be of any value in order to develop credible estimates. [28]. Below follows a brief outline of four of the most common experience-based techniques. These techniques can be applied using either a top-down approach or a bottom-up approach. A top-down approach begins at system level by examining the overall functionality. The system-level activities such as integration, configuration management and documentation are considered [28]. The bottom-up approach, on the other hand, begins at the component level and decomposes the system into components. Thus, each component is estimated and together, these estimates add up to an estimate of the whole system. [28]. 1. Estimation by Analogy This experience-based estimation technique compares the current project with one or more similar projects that are completed [28]. Thus, the characteristics, such as effort, schedule and cost of the projects are known. Having done similar projects in the past and knowing its characteristics, estimates are established through analogy reasoning [28]. The strength of this technique is that it is based actual experiences and real project data. Thus, current method only deals with issues that actually occur in practice whereas algorithmic methods must cope with all possible problems [14]. The fact that this method deals with experienced and completed projects it is also capable of dealing with poorly understood domains. It avoids the problems associated both with knowledge elicitation and extracting and codifying the knowledge [14]. The weakness is obviously that its not always certain that there exists a similar project that is representative of the constraints, environment, functions etc. of the new software [28]. 2. Expert judgement Current method is the most commonly used method [11]. It bases the estimates on knowledge and experience of one or several experts [28]. Each expert establishes an estimate and the estimates are compared and discussed. This process is iterated until the experts have agreed upon an estimate [28]. So, who is an expert? People with knowledge in software development? People with experience within the estimation area? Well, according to [15] and [16] an expert is defined as a person that is familiar and has experience of software development in the current domain. The strength with current approach is that an expert with adequate experience may provide good estimates quite fast and relatively cheap. On the other hand, if the expert(s) doesn' possess sufficient experience and knowledge, the estimates will t most likely suffer from inaccuracy [28]. 3. Parkinsons Law This experience-based estimation technique is based on Parkinson' law, "work s expands to fill available time" and implies that the project cost is determined, not estimated, by the available resources rather than on objective assessments. For example, if the software to be developed should be delivered in 12 month and five
16
people are currently available, the effort is determined to be 60 (12*5) personmonth [28]. Obviously, this approach may result in large overruns. 4. Pricing to win This approach estimates the cost with the intention to set a good price. A good price implies a price that will win the project. Thus, the estimates are based on the customers budget rather than on their needs for certain functionality [28]. The strength of this approach is obviously that the supplier often gets the contract. However, the probability that the customer gets the software they require is quite small, since the costs dont reflect the work required [28]. 2.2.3.2 Algorithmic modeling Algorithmic estimation is based on the application of a cost model, i.e. mathematical formulas that have been derived through statistical analysis of completed projects [28]. In its most general form, the software cost may be expressed as [28]:
Effort = A SIZE B M
in which A and B represent constant factors that depends on organizational practices and the type of software that is developed. The SIZE represents the software size and may be expressed in either code size or function points. M is an effort multiplier which is determined by combining several cost factors [28]. The different Cost factors are divided into four different categories [18], Product factors: reliability, complexity, size of database, reusability etc. Computer factors: Execution time constraints, storage constraints, platform volatility etc. Personnel factors: programming capability, analyst capability, application experience etc. Project factors: use of software tool, required development schedule etc.
Each factor is rated on a six-point scale ranging from low to high importance (see table 2). Based on the rating, an effort multiplier is determined [18].
17
Cost factors Product Attributes RELY Required software reliability DATA Data base size CPLX Product complexity Computer Attributes TIME Execution time constraint STOR Main storage constraint VIRT Virtual machine volatility TURN Computer turnaround time Personnel Attributes ACAP Analyst capabilitiy AEXP Applications experience PCAP Programmer capability VEXP Virtual machine experience LEXP Programming language experience Project Attributes Use of modern programming MODP practices TOOL Use of software tools SCED Required development schedule
very low
Ratings
low nominal high
very high
extra high
0.87 0.87
These cost factors are applied in the COCOMO model, which is an example of an algorithmic estimation model. The COCOMO model is an empirical model that was developed by collecting data from a large number of different projects. The collected data was analyzed in order to find out formulas linking the software size and project factors to the development effort [28]. Further details about the COCOMO model can be found in [18]. The choice of estimation technique obviously depends on various circumstances and resources, such as knowledge, experience, data access etc. However, project estimation should always be based on several methods in order to compare the result. If the different approaches dont generate approximately the same result, the information available is not sufficient and consequently, actions should be taken in order to retrieve more useful information [28].
2.3
Risk Planning
As mentioned, estimations are a large part of project planning and naturally also a part of the project plan. However, along with estimations come risks. Therefore, it is natural for us to present risks after estimations. Moreover, this doesnt mean that risks should be handled after estimations. Risks are something that has to be considered during the entire project. We presented eigth activities earlier, in section 2.1.3, that could be used in a project plan. There is not a single activity that is 100 % free from risks. For example, work breakdown structure, could be risky if the work packages become too small or too big. Budget and scheduling could be an even bigger risk, though a bad plan can cause budget overrun which could cause
18
severe problems such as bankruptcy or loss of clients. Another risk is if the project members dont have the knowledge and skills that is demanded by the project. However, almost all risks are preventable and could be handled if the project team is prepared and have developed a risk plan for it. Risks are something that exists in all project, and not only in software projects. Even in the real life you meet risks more often than seldom. Back to the grocery example, if the designated grocery shop doesnt have youre planned ingredients for a specific meal, you have to re-plan and perhaps get something else that is more expensive. You can describe a risk as a chance for something in the project wont go as planned. Most of the damage of risks in project can be minimized by thorough risk planning or risk handling. The software engineering industry has been extra vulnerable due to the high complexity of the project tasks and rapid technology development. When activities has become a routine and have been performed by the same people many times before many risks can be eliminated simply trough experience from former project. This is unfortunately not a common case in software engineering projects since each project is a usually a temporary endeavor undertaken to create a unique product or service [2]. A risk is defined as an uncertain event or series of events, with an associated probability of occurrence and an associated negative impact or consequence if the risk is realized. From the moment the risk is realized it' no longer a risk, but a s problem [41]. The management and prevention of project risks must be carefully planned and documented. Potential project risks must be identified, quantified and moreover, risk responses must be developed [20].
2.3.1
Risk Concepts
If you generalize the image of risks, you could describe it as a function of the uniqueness of a project and the experience of the project team [41]. In many cases activities becomes routine in project when they have been performed by the same person or group many times before. The group or the individual becomes more confident and gets more knowledge within a certain area or activity. This leads to a gradually reduction of the risks surrounding the activity. The risks were perhaps identified as a major risks the first time they performed it and almost eliminated the third time. This also leads to that project manager or risk responsible can anticipate the range of potential outcome and manipulate aspects if the system design and project plan to achieve the desired outcome [41]. The first time a unique project is performed and the team is inexperienced within the area it is very difficult to anticipate risks, the risk likelihood and impact. This is of course a problem regardless the experience and routine. However, both the impact and likelihood can decrease with extensive experience. According to Nicholas [41] the notion of project risk involves two concepts: 1. The likelihood that some problematical event will occur. 2. The Impact of the event if it occurs. Risk is a joint function of these two variables, and the calculation is: Risk = f (likelihood, impact) In any given project with identified risks, both likelihood and impact can be established and should be considered risky when either one or both likelihood and impact is estimated to be large. If the impact will result in human casualty, like
19
aircraft navigation system, or large financial loss, like a stock market exchange system, the risk must considered risky even if the likelihood is extremely small. Even if risks cannot be entirely eliminated from projects [41], it can be reduced and you could also prepare for a possible impact in order to reduce the damage. This is where risk planning comes in [41].
2.3.2
Risk Identification
Identification of risks involves efforts to determine which risks are likely to influence the project, and moreover to document the characteristics of each risk. The identification process is concerned with both internal and external risks [26]. Uncertainties that the project team somehow is capable to control, such as cost estimates, are classified as internal risks whereas external risks are threats that are beyond the control of the project team, such as market shifts and government actions [2]. Risk identification can be achieved by identifying causes-and-effect (what may occur and the consequences of this event) or effect-and causes (what outcomes should be avoided or encouraged and how each might occur) [2]. There exist three important input mechanisms to the identification process Product description, Other Planning Outputs and Historical Information [2]. The product description covers the characteristics of the product and is of high importance for the identification process. For example, a product based on a proven technology involves less risk than a product that requires innovation and invention. Other planning outputs includes outputs generated from the planning process and should be reviewed to identify possible risks. Typical planning outputs to review may be the Work Breakdown Structure (WBS), estimates, staffing plan etc. Historical information is concerned with relevant data from past projects and may facilitate to identify project risks since this information reveals what actually happened. Potential sources of such information may be project files, commercial databases, staff knowledge etc. In order to identify project risks several methods and techniques may be applied, such as checklists, flowcharting, interviewing etc. Risk-oriented interviews with different stakeholders involved may facilitate to identify risks that are difficult to identify during the planning process. Generally, the risk identification process should generate outputs, such as the sources of risk, potential risk events, risk symptoms, and inputs to other processes. The sources of risks involves different categories of risk events that affect the project and may include requirements changes, design errors, poorly defined roles and responsibilities, poor estimates, and inadequate skills. The source description should generally cover (1) the probability, (2) the range of possible outcomes, (3) expected timing, and (4) expected frequency of risk events from current source. Potential risk events are discrete occurrences such as, natural disasters, team member departure etc. In contrast to common risk events, potential risk event are seldom application-area-specific. Risk symptoms are indirect appearances of actual risk events. For example, poor moral may be an early warning of a potential schedule delay. Risk identification may recognize needs in other process areas, which may be of great value for these areas. For example, the WBS may be too poor in order to achieve adequate risk identification.
2.3.3
Risk Quantification
Risk quantification is mainly concerned with evaluating the risks and their interactions in order to identify the range of possible project outcomes. By this
20
way, its possible to determine which risks that require certain responses. The following inputs are compiled and used in order to perform risk quantification: Stakeholder Risk Tolerance Sources of Risk Potential Risk Estimates
The risk quantification process may be supported by various tools and techniques, such as expected monetary values, statistical sums, simulation, decision trees, expert judgments etc. The expected monetary value is estimated with the help of the risk event probabilities and the risk event value, i.e. an estimate of the gain/loss if the event occurs [2]. Generally, the expected monetary value is used as a factor in further analysis because risk events may occur individually, or in groups, in parallel or in sequence. Statistical sums can be used to compute a range of total project costs. This range can be applied to quantify the risk of alternative project budgets or proposal prices [2]. Simulations are performed by using a representation or a model of a system in which the behaviour or performance of the system is analyzed. The most common project simulation is the schedule simulation using a network diagram to model the project duration (as seen in figure 2) [26]. The outcome of the simulation can be used to quantify the risk of different schedule alternatives, different project strategies etc. Instead of, or in addition to the techniques mentioned above, expert judgment may be used to quantify risks. For example, experts may assign the risks different probability and impact values based on experiences and knowledge.
The risk quantification process should generate information about which opportunities to pursue and which to ignore, as well as the threats to respond to and which to accept [2].
2.3.4
21
Risk responses may be developed in various ways. Utilizing products or services from external sources (procurements) may be an appropriate response for risks that exists because of lack of skills, knowledge, experiences etc [2]. Contingency planning is another method, which implies to define action steps to take if specific risk events should occur [2]. Furthermore, having developed alternative strategies makes it possible to change strategy and by this way prevent or avoid risk events from occurring. Current process should generate a risk management plan that covers the procedures and activities carried out to manage risks throughout the project life cycle. Moreover, the plan should assign responsibilities for managing different areas of risks. Contingency plans, alternative strategies, procurements etc. should be fed back into processes in other knowledge areas in order to improve these areas. Another typical output from current process is contractual agreements for insurance, services etc., which may be specified in order to avoid or mitigate certain threats.
2.4
2.4.1
Planning Management
A project managers overall responsibilities can be defined as bring a project completion on time, within the budget cost, and to meet the planned performance or end-product goals [21]. The project manager has responsibilities towards his project group, top-management, sub-contractors and of course, the customer. Without a satisfied customer, the top-management will not be pleased. This chain of command is usually described in the organizational structure at software engineering companies. Modern project managers works hard in order to reach the end-product goals in a rewarding manner, often with clear product goals welldefined in advance [22]. A project manager has, quite naturally, the main responsible for planning the project. However, the project manager must plan enough in order to reach a successful outcome. But, how do you know, as a project 22
manger, when its enough? Who can say that anything is good enough planned? According to most project managers it is impossible to know. Further, researches [22] states that too much planning can obstruct creativity and the quality of the product can suffer. At the same time, the lack of planning will, most definitely, guarantee failure. The success of a software project very much relies on good management and control system which allows development to satisfy the project objectives [24].
2.4.2
23
2.4.3
Process Models
Software process models are very commonly mentioned in software engineering literature and there exist numerous models and variations of models to choose from. A software process model can be described as a conceptual model that defines the sequence of activities to be followed for a software development process [Whitten]. Examples of software process models eXtreme Programming (XP), waterfall model, incremental, iterative, Scrum, RUP & PROPS. As mentioned there are numerous different models and variations of these models and it is of course up to each company to either adopt it to a hundred percent or just implement specific parts of it. When it comes to choosing a process model the company must consider some vital factors in order to find an appropriate model suitable for their very organization. Factors such as product complexity, project size, requirements engineering process, customer involvement during development etc are examples of factors that must be considered. Some of these models are free and some cost money in order to adopt. All models differ in some way. They have different procedures for management, risk handling, design, roles etc.
2.4.3.1
Waterfall The waterfall model might be the model that is most commonly used in software engineering project or at least the first published model for software development [28]. The model divides fundamental activities into stages in order to work them through one at the time. The first phase is the Requirements analysis and definition in which the systems services, constraints and goals are established in consultation with system users [28]. These issues are defined in detail and are used as a system specification, representing the basis for the development process. The second phase is the System and software design. This process partitions the requirements to either software or hardware systems and establishes an overall system architecture [28]. The third phase, Implementation and unit testing, the software design is realised as a set of programs or different program units [28]. The fourth phase is Integration and system testing, in which individual program units or programs are integrated and tested as a complete system in order to ensure that the software requirements have been met. The fifth and last phase, Operation and maintenance, is normally the longest of the five phases. The system is installed on its final destination and put into practical use. The maintenance work is concerned with errors that werent discovered during earlier stages in development. Improvements and new requirements are other examples of work that perhaps needs to be done. Remaining process models As mentioned earlier, there exist numerous models and variations of these models. The waterfall model is the first public model ever created for software engineering [28]. However, other process models have been developed over the years. Models like EVO, eXtreme Programming (XP), RUP, PROPS etc. has been created and is today well documented. The evolutionary model (EVO) interleaves the activities of specifications, development and validation [28]. An initial system is quickly developed from conceptual specifications. This system is then discussed with the customer in order further develop a system which satisfies the customer. eXtreme Programming, or XP, is a rather new developed process model and is originally developed by Kent Beck. XP is one of numerous agile or light-weight methods. XP differs a lot from traditional models like the waterfall model. XP uses a very simple form of project planning and tracking to decide what needs to be done and predict when the project should be finished [42]. The development is focused on business value and one of the core practices is to involve the customer throughout
2.4.3.2
24
the entire project, called on-site customer. There are no requirements specifications developed in the beginning, instead the customer presents desired features to the project team who then estimate them in order for the customer to prioritize the most important features from a business focus [42]. This phase is followed by iteration planning where the project team decides how many of these features they can develop in the next iteration. The customer then re-prioritizes or make up new features before the next iteration. XP uses short releases in order to avoid misunderstandings towards the customer and other stakeholders [42]. Rational Unified Process, or RUP, is mainly a process of developing high quality software and has pre-defined activities used to transform the customers requirements into a software system [39]. RUP can be presented as four major activities, Use-Case driven, Architecture-oriented, Iterative and Incremental [39]. Use-Cases are used throughout the whole process for requirements engineering as a starting point for analysis, design, testing and project planning. The architecture activity emphasis the importance to early create a stable architecture for the entire system. Iterative and incremental development means that the system is built stepwise and that the processes of requirements engineering, analyzing, designing, programming and testing are performed repeatedly. RUP also states that it is important to early identify risks and plan the development in order to eliminate these risks. PROPS are a project management model used mainly at Ericsson. PROPS stand for PRoject Operation and Planning System. One of the developers behind Rational Unified Model (RUP) has a history at Ericsson which probably is the reason for similarities between PROPS and RUP.
2.4.4
25
when the company makes a profit? The next chapter gives a brief outline of how project success is defined in contemporary literatures.
26
PROJECT SUCCESS
Most likely, there are several factors that contribute to a successful project. However, identifying these factors is not in the scope of this thesis. One of the main objectives of current thesis is, however, to explore the relationship between project planning and project success. In order to do so, we find it important to explore how success is defined, both in literatures and industry. Current chapter is devoted to give a brief outline of how the literatures define project success and how success is measured. Success may be defined as an achievement of something desired, planned, or attempted [38]. Thus, success is a result of achieving known objectives in order to satisfy a certain need or want. A project is consequently considered successful when its objectives are fulfilled [41]. Project objectives may involve multiple dimensions, such as time, cost, quality etc. However, although this is a quite common definition of project success and moreover corresponds to the reality in some cases, there are many examples where this definition is not enough [32]. These examples show that despite extensive delays and overruns, the project outcome may be a great business success [32]. Usually, project management is forced to make certain trade-offs which may affect established objectives, but if these trade-offs are mutually agreed upon by involved stakeholders, the project may still be successful [41]. An example is the Sydney Opera House, which took three times longer than planned and cost approximately five times higher than expected [32]. Today the Opera House is Australias most famous landmark. Another example is the first Windows software by Microsoft, which suffered from extensive delays and required additional staff to complete [32]. Today, 90% of all PCs use the Windows operating system. Research has proven that if a mutual agreement among involved stakeholders exists about how to judge project success, the likelihood for success is maximized [31]. If such agreement doesnt exist, the likelihood that different stakeholders exploit the project to achieve their own objectives is maximized [31].
3.1
27
These different approaches clearly show a disagreement about how to measure project success. This is, however, not unexpected since its quite natural that organizations, just as individuals, have different goals and objectives. [37] divides projects into two different categories strategically managed projects and operationally managed projects. The latter category is mainly focused on short-term results and emphasis on getting the job done according to established time- and cost objectives. Strategically managed projects, on the other hand, emphasis on business results in the long run and are focus more on customer needs, competitive advantages, and future market success. Strategically managed projects are, however, not very common [37].
28
QUALITATIVE RESEARCH
This part of our research aims at analyzing and discussing the project planning paradigm in the Swedish software industry by interviews with ten different project managers at Swedish software companies.
4.1
4.2
4.2.1.1
Interviews The interviews conducted were all face-to-face interviews and lasted between 1 1.5 hours. The interviews were based on two different interview styles. The first part of the interview was a so-called unstructured interview, which implies that project planning was discussed in general without any restrictions [43]. By this way, the risk of missing valuable information is reduced, since the interviewee is able to talk freely about the subject and is not obstructed by any pre-defined agenda. The second part was a structured interview, which means that the interview was based on a pre-determined set of questions [43]. By using this approach we were able to ensure that required information for our research was 29
retrieved. During the structured interview, the interviewees answered 26 different questions about project planning and project success. The questions were all based on the literary study presented above.
4.3
Research Results
This section is concerned with the results of our interviews. The results are presented in the same manner as our literary study. First we give an account for project planning in general. Subsequently, we present the interviewees conception of the project plan, project estimations and risk planning. Finally, we present the interviewees conception of project success.
4.3.1
Project Planning
The amount of effort that the software community invests in project planning differs quite much. The companies we interviewed invest a little less than 5% to 70% of the total project effort in project planning. Obviously, this quite large gap is a result of different environments, conditions and project characteristics, such as complexity, size, resources, assets etc. According to some of the interviewees, the share of planning efforts increase the smaller the project is and the more complex the task is. All interviewees state that the project manager is in charge of the project planning, which corresponds to the attitude of the literatures. Noticeably is that only one company continually involves the entire project team when planning the project. The most common approach is that the project manager performs the planning activity with temporary support from different experts, when it comes to such as estimations and evaluations of technical issues. Surprisingly, only one interviewee states that the project is planned in co-operation with the customer. The content of the project planning efforts in the industry is quite similar to what is described in the literature, in a smaller scale though and in most cases not as rigorous as the literature suggests. The literature presents a myriad of different methods and techniques to apply when planning a project. However, only a small fraction of these were actually practiced by the interviewees. Some of the planning techniques presented in the literatures are complex, time-consuming and expensive, such as algorithmic modelling. The techniques practiced by the interviewees are often simple and cheap, such as mini risk, expert judgements etc. All of the interviewees, except one, state that a project scope, i.e. the project characteristics, is developed in order to set the project boundaries. Approximately 80 % of the interviewees break down the work and develop a WBS (Work Breakdown Structure) in order to identify and organize relevant work packages. All of the interviewees perform some sort of estimation when planning a project, which is further described in section 4.3.1.2, and approximately 60 % of the interviewees work continually with risk planning, as described in section 4.3.1.3. However, only one of the interviewees states that the involvement of the stakeholders is carefully planned whereas 60% put a lot of effort in identifying project dependencies, such as logical dependencies (process and schedule dependencies), resource constraints (lack of knowledge, skills, personnel), subcontractors, customer staff etc. The literatures dont present dependencies as a separate planning activity, but include it in other activities such as schedule, WBS, supplier agreement etc. The three most influential factors to consider when
30
planning a project are, according to the interviewees, time-to-market, resources and external dependencies. All interviewees agreed on that project planning is one of the most challenging activities in software development. So, why is project planning so hard? Is it more difficult to plan software development projects than projects in other industries? Well, these questions are hard to answer and well discuss these issues further in section 4.4. According to our research, the most common problems in project planning are developing accurate estimates and handling external influences such as subcontractors, laws etc. The most common mistakes in project planning are the following: Basing decisions on assumptions (20%) Time optimism (60%) Lack of communication (20%)
These mistakes results, according to the interviewees, in delays, increased costs, decreased functionality, and bad image. The most common way to handle these mistakes is to initiate negotiations with the customer, hoping that the customer will understand and agree on a postponed deadline or decreased functionality. In order to prevent these mistakes from occurring, the interviewees state that the requirements must be reviewed more carefully and that the supplier and the customer must work harder to achieve mutual agreements and understandings. Obviously, major mistakes require re-planning. However, none of the interviewees have today any explicit strategy to handle re-planning of projects. All the interviewees as well as the literatures agree, however, on that re-planning occurs in all projects and is more or less inevitable. Re-planning may be a result of that either changes are requested by the customer or that follow ups are made by the project team. 40% of the companies say they apply formal change requests and 20 % of the companies apply consequence analysis before executing any changes. 4.3.1.1 The Project Plan The research shows that the industry and the literatures, roughly, have the same view on the project plan. According to the interviewees, a project plan should mainly consist of the following: Project scope Project objectives WBS Schedule Budget Possible risks Resources required Skills and knowledge required. Project dependencies
The literary study also includes such as Monitoring and reporting mechanisms, Stakeholder involvements.
31
The project plan is developed and completed prior to the project initiation, but should, according to the interviewees, be a document that is alive throughout the project. The document should reflect changes in the project and should be updated throughout the project cycle. Some of the main objectives with the project plan are, according to the interviewees, to guide the project team and to generate work instructions. The project plan should also facilitate and increase communication and moreover, generates an understanding among stakeholders. Some of the interviewees also emphasis on the process of developing the project plan, stating that the process in itself generates new ideas and reveals possible problems and difficulties. In order to achieve these objectives, its very important that the project team commits to the plan. Establishing commitment is a quite difficult task, but according to the interviewees there are some approaches that are effective. Its important that all personnel, involved in the project, feel participation and feel that they are entrusted with responsibilities. The interviewees recommend to, quite early, provide the personnel with work packages, time aspects, and responsibilities. The project should be orally presented and the different approaches should be discussed and questioned. Some of the interviewees also advocates for involving the whole project team when planning the project and states that, by doing so, the level of commitment is heavily increased. 4.3.1.2 Project Estimation Not surprisingly, as stated above, all the interviewees develop some sort of estimates in order to establish an outline of the project. Time, effort and cost are project resources that, according to all the interviewees, are estimated in all projects. However, only 20 % state that quality and material are estimated. Although, a broad selection of estimation techniques exists today, the interviewees apply quite similar approaches when developing estimates. 80 % apply expert judgement when estimating the project whereas 20 % use algorithmic models or estimation by analogy. One of the interviewees states that the estimates are usually surprisingly correct. As to the rest, the margin of error is approximately +/-10-30%. So, what makes this company stand out from the rest? Well, there are a few interesting observations worth mentioning. In contrast to the rest, this company fully involves the customer and the whole project team when planning the projects. Thus, the project manager does not plan the projects by him/her self, but strives to get as many inputs as possible from all involved in the project. However, when it comes to the estimation procedure, the company is not unique. They apply expert judgement like the majority of the companies. Possible margin of error of the estimates are, according to the interviewees, mainly generated by factors such as optimism, misjudgement of competence, complexity, and negligence. The main consequence of these misjudgements is a delayed project, which according to some interviewees, results in an increased cost. Not only does the software supplier have to deal with higher expenses, subsequent projects are also postponed and, in a worst-case scenario, even lost to other contractors. The only way to avoid this from happen is to add more resources to the project or cut down on the functionality. The solution to the matter is generally settled in negotiations with the customer.
32
4.3.1.3
Risk Planning Risk planning is, according to the literary study of high importance in software development. Remarkably, only 60 % of the interviewees practice risk planning. Those that dont, all agree that it would be a good and valuable asset to the project. Approximately 70% of those that practice risk planning apply a method called Mini risk. All possible risks are first identified. Most of the interviewees use a predefined collection of common risks for all projects, since risk events seldom are application-area-specific. Obviously, the risks may be identified for each specific project as well. The quantification process in Mini risk is similar to "expected monetary value", as described in our literary study. Thus, each risk is assigned one value reflecting the probability of occurrence and one value reflecting the consequence if the risk occurs, i.e. an estimate of the gain/loss if the event occurs. The risk value for each risk is calculated by multiplying the probability value and the consequence value. The result of the quantification process is analyzed and suggestions of how to reduce or eliminate the risks and expected outcomes are developed. According to the interviewees, the most common risks in software development are lack of resources, external dependencies, such as subcontractors, and vague requirements, which may lead to misinterpretations.
4.3.2
Project Success
As stated in section 3.1 project success mean different things to different people. This is also confirmed by the interviews. Our literary study describes project success as a result of achieving known objectives in order to satisfy a certain need or want. When we asked the interviewees to, by their own words, define project success, 40% of the interviewees defined it as fulfilling established planning goals, which may be considered quite similar to the definition from our literary study. 40% defines project success as fulfilling the contract, established between the customer and supplier. Indirectly, this definition also agrees with the literature, since the contract provides for the basis for most of the established goals. However, fulfilling the contract only implies to achieve what the contractor and the customer have agreed on regarding time aspects, cost, quality, deliverables etc. Fulfilling established planning goals also includes the contractors in-house objectives such as the ability to handle changes throughout the project, the wellbeing of the project team, improvements and acquirements of knowledge and skills, and the capability to manage acquired knowledge and skills. As stated in our literary survey (section 3.1), [36] suggests that the success attributes may be categorized into Things Related Attributes and People Related Attributes. Attributes related to things are scope, quality, schedule, and cost whereas attributes related to people are team morale and client satisfaction. With this definition in mind, we asked the interviewees who of the following dimensions of project success they find the most important: that all requirements are fulfilled, that all the planning goals are achieved, that the project is beneficial for the customer or that the project is beneficial for the contractor. All of the interviewees agreed on that the most important of these dimensions is that the project is beneficial for the customer. Yet, only one of the companies participating in our research regularly defines project success, prior to the project, in co-operation with the customer. So, how do the interviewees achieve project success? Which project activity is the most central for project success? According to our research, a well defined project 33
scope is the most important issue in order to achieve success. 60% of the interviewees claim that a well defined scope that is agreed upon and understood is the most central factor for a successful project. A project scope is a statement describing the work that must be achieved in order to deliver a system with specified functionality. Any work that is not defined in the scope statement is consequently outside the project scope. In order to define the scope, the deliverables are subdivided into components and a WBS (Work Breakdown Structure) is developed. Finally, the scope should be reviewed and accepted by all involved stakeholders. Some of the literatures, however, have a quite extensive view on how to manage the project scope. PMI (Project Management Institute) [2], for example, describes this process in five steps Initiation, planning, definition, verification and change control, which all includes several sub-practices. Further reading about this procedure can be found in [2]. PMI agrees with the interviewees and states that a proper scope is critical to project success and says further When there is poor scope definition, final project costs can be expected to be higher because of the inevitable changes which disrupt project rhythm, cause rework, increase project time, and lower the productivity and morale of the workforce
4.4
34
should produce the same product over and over again, estimation would be a lot easier. Thus, as long as the high level of complexity in software development remains, estimation efforts will probably remain a problem in software planning. Our investigations correspond to the literatures when it comes to estimation techniques; expert judgement is without a doubt the most commonly used method to develop estimates. This is quite logical, since current method is very simple and cheap and often bases the estimates on in-house knowledge and experience. External dependencies may be unpredictable and sometimes even unknown. Its therefore of high importance to consider and, if possible, to involve known dependencies when planning the project. External dependencies, possible to involve, may be such as sub-contractors, customer staff, end-users etc. Generally, our interviews confirmed that a high level of customer involvement when planning the project probably would improve and facilitate planning efforts. Several of the interviewees confirm the value of this approach, but surprisingly only one of the interviewees fully involves the customer in the planning phase. By involving the customer in the planning phase, the risks for misunderstandings and misinterpretations are naturally decreased, and moreover the customer commitment is increased. In any engineering project, a risk is the uncertainty of that an event and subsequent consequences occurs. However, in software projects the level of complexity increases the uncertainties of fulfilling the needs and desires of the customer. Yet, only 60% of the interviewees use a defined procedure to plan for risks. The rest apply more sporadic and spontaneous efforts or dont plan for risks at all. Some of the interviewees that dont apply defined procedures for risk planning could also give examples of projects that suffered severe consequences, such as contractual disputes and extensive delays, as a result of not identifying risks and develop risk responses in a proper manner. Yet, they could not state why they still dont plan for risks in a more structured way. For this reason, its obvious that the significance of risk management is quite underrated and that some organizations dont believe in it as an activity that will increase mission capability. According to the interviewees, project planning gets harder and requires more effort the more complex a project is and a project obviously becomes more complex the more complicated the mission is. Thus, development of complex software is hard to plan for and require more planning efforts. When analyzing the results of the interviews, we have identified software complexity to be the source to all planning difficulties and the most critical factor in order to achieve adequate project planning. According to the research outcome, software complexity originates from several sources. One of the reasons for complexity is that the software engineering is a quite new and immature discipline, which implies lack of experience and usage of undeveloped technologies and methodologies. This is also confirmed by several credible sources, such as SEI (Software Engineering Institute), SWEBOK (Software Engineering Body of Knowledge). The quite low age of the industry also implies little consensus and few standards. Another significant factor is that software can be applied in numerous different contexts, which implies that a piece of software may possess endless combinations of different characteristics and functionality. In this respect, software development differs from manufacturing of cars, buildings, computer hardware etc. The software concept itself possesses several characteristics which are complicated to handle. Software is changeable; it is quite easy to modify. Software is invisible; it is resided in the heads of the developers until quite late in the development cycle. A building, for example, that doesnt look like the plan can immediately be 35
identified. A software module, however, does not fulfil the requirements until its completed. Thus, its quite hard to measure the progress when its not visible. Since the software module isnt fully operable until it is completed, the customer may not be able to confirm that the developers interpretation of the requirements is correct. Thus, the software may satisfy a certain interpretation of the requirements, but not always as the customer desire. According to the interviewees, misinterpretation of requirements is quite common and may have severe consequences. Moreover, software is fully dependent on its environment, i.e. hardware and other software such as operating systems, which increases the complexity of software development even more. These issues and several more, add up to a very high degree of complexity and its quite obvious that this is the main reason why planning efforts are more difficult to achieve in the software industry.
36
QUANTITATIVE RESEARCH
This section present the result from the research questionnaire filled out by 38 project managers at different software companies in Sweden. They were asked to rate different items regarding the level of planning efforts invested in the project, achievement of planning goals, end-users benefits (customer point of view), contractor benefits and finally general about project success. One weakness of this statistical research is that it has been impossible for us to reach the end-users. In order to deal with this, we asked the project managers to be as objective as possible and answer some questions for their own clients. Another weakness is that questions concerned with the contractor benefits were answered by the project manager instead of the top management. However, we had a discussion with each project manager about this and they had an immense knowledge about financial and other benefits that the contractor can obtain from a successful project. Each person who participated in the research was asked to rate these items considering one specific project they recently finished. We also asked for project duration and how many project members who where involved. Each item was asked to be rated between one and five, and zero if it was not applicable for that very project.
5.1
37
and the end-user satisfaction of the delivered product is the three criteria Pinto and Mantel [34] propose to use when measuring project failure or success. Dvir et al. uses three different success criteria in his article An empirical analysis of the relation between project planning and project success. These criteria are Meeting planning goals which measures success at the project manager level, EndUser benefits which measures success from the end-user point of view and finally Contractor benefits which measures success at the contractors level. The last one includes two criteria from Shenhar, Dvir and Levys [32] last research on the subject, commercial success of the project and potential for features revenues. Shenhar, Dvir and Levy uses 13 success measurements divided into four sections: Meeting planning goals, Benefits to the customer, Commercial success and future potential. Other interesting material within the project success area is presented by J. Drew Procaccino et al. in Case Study: Factors for early prediction of software development success [45]. They state in their report that project managers can make more efficient and effective projects if they detect high-risk elements early. This is of course something we also discuss in our risk planning part. Some interesting data from their report shows that a project is more likely to successful if the project has a committed sponsor or sponsors and if the project manager are given fully authority to manage their project. They also discuss customer and endusers involvement and the importance of having a well-defined scope. C. Wohlin et al. presents a method for using subjective factors to evaluate project success in Subjective evaluation as a tool for learning from software project success [46]. This paper has some similarities with our thesis. They discuss project competence and project management performance and the difficulty to measure success in software projects. Further, they discuss how knowledge and experience of software developers, managers and customers may be captured and used.
5.2
38
Do they include everything that, according to literature, should be included in a project plan? Our ambition was to let project managers from Swedish software companies rate project planning issues and project success factors in order for us to analyze and identify the correlations between planning issues and project success factors. To achieve this we developed a questionnaire divided into five sections, which is further described in section 5.3.1.
5.3
5.4
Data
The data used in this quantitative research came from 38 project managers who were working at different Swedish software engineering companies. The project managers at these companies were asked to consider the latest finished project that they were responsible for. The project managers represented all stakeholders in this questionnaire survey, which in this case includes the end-users view. Our intention was to contact the end-users for each product but we soon realized that it was an impossible task due to the variety of project and the short amount of time. The project managers were asked to be as objective as possible when representing the end users. The contractors were also represented by the project managers, even though the top managers and project sponsors maybe would have a different view due to the different perspective they see things. However, our intention was not to get the top managers view, though we believe that they put more value to the financial parts of the project than the actual project execution even if they are very high correlated. In order to gather data for this research we sent an e-mail to 102 companies all over Sweden. 38 of these project managers filled out the questionnaire, 19 persons wrote an e-mail back and told us that they would not have anything to contribute to this survey. The remaining 45 companies didnt bother to answer at all. The criteria for the research participates were that the company developed some kind of software product and moreover that the software engineering should be the main focus of the project (research & development). Furthermore, we asked for project duration over 2 month with at least 5 project
39
members. The answers was given on the scale zero to five were zero represents Not Applicable, one represents poor, two represents fair, three represents moderate, four good and five very good. In order for us to receive the result we wanted, we developed a questionnaire divided into five sections. The four first sections are dedicated to investigate the relationship between project planning efforts and project success. The first section represents the planning effort invested in the project and consists of eight planning activities identified from the literature presented in section 2.1.3. The second section represents the achievement of the planning efforts, based on the same activities as in section one. The third section represents the end-users benefits and consists of eight elements identified from similar researches regarding project success [22], presented in section 5.1. The fourth section represents contractor benefits with eight elements also identified from the research of Dvir et. al. [22] also presented in section 5.1. The fifth and last section represents the project managers general view on the relation between project planning and project success. The items used in current section were items we came up with on our own. We believed that it would be interesting to get the project managers view on these items.
5.5
Measures
The following tables present the mean value of the result gathered from the questionnaire research. The standard deviation is also presented under the S.D. column. The correlations between the values are presented in section 5.6.
Table 3 Level of Project Planning (Project planning efforts) Measures Scope and Objectives Work Breakdown Structure (WBS) Budget & Schedule Risks Monitoring and Reporting Mechanisms Resources Knowledge & Skills Stakeholder Involvement Table 4 Level of project success (Achievement of planning goals) Measures Scope and Objectives Work Breakdown Structure (WBS) Budget & Schedule Risks Monitoring and Reporting Mechanisms Resources Knowledge & Skills Stakeholder Involvement Table 5 End-User Benefits (Represented by the project manager) Measures Satisfying end-user operational need
Min 1 1 1 1 1 1 1 1
Max 5 5 5 5 5 5 5 5
Min 1 1 1 1 1 1 1 1
Max 5 5 5 5 5 5 5 5
Min 1
Max 5
Mean 4.48
S.D. 1.50
40
End-product is in use End-product delivered in time End-product works as expected End-user capabilities are improved End-user felt involved in the project End-user satisfied with end-product End user satisfied with project Table 6 Contractor Benefits Measures Profit exceeded plans Profit exceeded similar projects New market penetration Created new market Created new product line Developed new technologies and infrastructures Developed new knowledge and expertise Generated positive reputation Table 7 General project success Measures Project success increase in proportion to planning quality. Too accurate planning obstructs creativity. There is a clear relationship between project planning and project success. Goal changes have a strong negative effect on project success Plan changes have a strong negative effect on project success
1 1 1 1 1 1 1 Min 1 1 1 1 1 1 1 1 Min 1 1 1 1 1
5 5 5 5 5 5 5 Max 5 5 5 5 5 5 5 5 Max 5 5 5 5 5
4.09 3.68 3.95 4.25 3.39 4.05 3.94 Mean 2.72 2.78 3.67 3.00 3.20 3.83 4.09 4.19 Mean 4.00 2.26 4.13 2.91 2.30
1.76 1.62 1.20 1.66 1.77 1.70 2.02 S.D. 1.60 1.59 1.87 1.73 1.90 1.93 1.20 1.44 S.D. 0.67 1.32 1.10 1.38 0.88
5.6
Table 8 Correlation between planning efforts and project success Planning achievement Customer Benefits 0.187166 Planning Efforts 0.664399
The following sections describe the correlation between planning efforts and the measures of project success in more detail.
5.6.1
41
Current section is dedicated to give an account for the correlation between efforts invested in planning and the actual achievement of planning goals established the planning phase. The correlation between invested planning efforts and related planning goals was very strong for all planning activities, except for one schedule and budget. However, this was quite expected. According to PMI Global Congress 2003, the Standish Group reports that 52.7% of software projects overrun by an average of 189%. Thus, schedules and budgets are commonly overrun and this may be an explanation for the quite low correlation of 0.22. The planning activity with the strongest correlation between the efforts invested and the actual achievement is planning for stakeholder involvement at 0.87 and on second place was risk planning at 0.68. The correlations for the achievements of planning goals are presented below: Scope & Objectives Efforts invested in defining scope & objectives had the strongest correlation to risk planning achievement at 0.47. Thus, a poorly defined scope makes it more difficult to achieve proper risk planning. This makes sense, since risks may be dependent on the project- and product characteristics. WBS (Work Breakdown Structure) Efforts invested in developing a WBS had the strongest correlation to the achievement of resource management at 0.43, which implies that resource management is dependent on how well the WBS is defined. This is quite logical since developing a WBS includes allocating resources to different work packages, which consequently involves identifying what resources that are required to succeed. Schedule & Budget Effort invested in schedule & budget had the strongest correlation with achievement of resources management at 0.59. This is quite obvious since scheduling implies to allocate resources, ensuring that you have the required resources when needed. Risk Planning Efforts put into risk planning had the strongest correlation to scope & objectives at 0.45, which means that the scope may be affected if risks are not properly planned for. Surprisingly, risk planning had a weak correlation to schedule & budget at only 0.23. Monitoring & Reporting Mechanisms As expected, the correlation between planning efforts put into monitoring & reporting mechanisms and the achievement of schedule & budget was very strong at 0.54. According to our literary survey, the schedule and budget are two of the main project characteristics to monitor and report status on, which doesnt make this a surprise. It also had strong correlation to resource management at 0.53 and risk planning at 0.49, which makes sense as well. The access to required resources must continually be monitored and potential risks must be reported. Resources The strongest correlation between efforts invested in planning and the actual achievement of planning goals is 0.67 and exists between planning for resources and realization of the scope. Thus, poor planning for resources may result in that vital resources disappear and the contractor may be forced to change or even reduce the scope of the project.
42
Knowledge & Skills Effort invested in planning knowledge and skills had the strongest correlation to achievement in risk planning at 0.48. This is rather logical since good knowledge & skills imply that you are aware of the existing risks and know how to prevent them or act if they occur. Planning for Stakeholder Involvement Planning efforts for stakeholder involvement did not have any strong correlation to the achievement of any other planning goals, but had, as stated above a very strong correlation to the achievement of itself.
5.6.2
5.6.3
5.6.4
5.7
43
development suffers from a high level of complexity. Obviously, the achievement of all planning goals suffers from this issue. However, these goals may, despite changes, be achieved by investing more time and money. Consequently, it is the budget and the schedule that fail in the end. Many of the interviewees state that they put a lot of effort in the initial estimates in order to establish credible budgets and schedules and are forced to discard many of these estimates when requirements and other project characteristics are changing. Efforts invested in planning for resources, monitoring and reporting mechanisms, and risks has several strong correlations to the achievements of the other planning goals whereas scope and objectives has surprisingly few strong correlations to the achievements of other planning goals. However, scope and objectives had some quite strong correlations to customer benefits, such as product- and project satisfaction. This confirms the theory of the literatures and the interviewees, stating that scope and objectives are of high importance for project success. The correlation between planning efforts and planning achievements was quite strong whereas the correlation between planning efforts and customer/contractor benefits was rather weak. These results are quite odd, since it implies that even though the planning goals are achieved, the project may not be beneficial for the customer and the contractor. Logically, achievements of the planning goals, such as fulfillments of the project scope, schedule, budget etc. also should imply customer and contractor benefits. Customer and contractor benefits are obviously dependent on other factors as well, such as the customers awareness of their needs or requirements misinterpretations etc., but instinctively it seems sensible that, for example, fulfilling established schedule and budget should be beneficial to both the customer and the contractor.
44
CONCLUSION
Project planning is necessary. Particularly in software projects, since the nature of software may be complex and unfamiliar. Even though our quantitative research showed that the correlation between planning efforts and project success is quite vague, its obvious that at least a minimum level of planning is required. Current hypothesis is strongly confirmed by the interviewees. The qualitative research showed that the amount of planning required and planning strategy is strongly dependent on factors such as domain knowledge, available resources, project characteristics etc. However, irrespective of these factors, all projects require estimates in order to establish the scope, allocate resources, develop a schedule and in most cases also settle a fair price. The importance and needs of other planning activities, such as risk planning are on the other hand mainly based on domain knowledge, project characteristics etc. Estimates however, are always required but are easier to develop if the developer possesses extensive knowledge within the domain. Estimation is, as stated earlier in this thesis, one of the most challenging tasks in the software engineering discipline. Naturally, the challenge grows in proportion to the level of complexity. Thus, complex and unfamiliar domains require thorough analysis in order to facilitate planning efforts. The software industry has to adjust their project planning level to project characteristics, domain knowledge etc. We have observed several companies plan their projects quite differently than what is recommended by the literatures. The research has also showed that different software companies have a very different view on project planning. Not only compared to each other, but also compared to the software literature presented in chapter 2. Yet again, the type of project and software company plays a vital role when forming a project plan, handling estimations, risks, resource allocating etc. We could also see that larger companies, like Ericsson, has a much more structured and documented way of performing a project. Resource allocating was one of the activities that were especially important since many projects were performed in parallel and every project manager wanted the best people for a specific project. The literatures have many opinions on what a project plan should cover. However, different companies have different needs and make their own judgment of what is necessary and important in order to succeed. One good example was one of the smaller companies we interviewed. They are a small but market leading company that almost ignored resource planning since they always allocate the same 5 people in every project. Moreover, because of lacking competition, the customers have no choice but to wait for the new product to come out, which decreases the importance of developing accurate estimations. However, some project planning is needed in order to know when to start new projects and if they finish before the next industrial fair. This kind of planning strategy would probably cause a disaster for larger software companies. Thus, even though software project planning is a proven necessity in modern software development, it is up to each company to develop their own project planning strategy in order to satisfy their needs.
45
REFERENCES
[1] Rahbar Faramarz Fred ; Rowings James E Jr, Top-down back-to-front project planning, 1998, pp PS1-PS7 [2] A Guide to the Project Management Body of Knowledge, 1996, Project Management Institute [3] Sarkar J.P , Software process and early project planning: issues, insights and lessons learned, 1998, pp C16/1-C16/8. [4] Sparrow I. H., Computer + Software Project Planning and Control, 1988, pp 25-29
[5] Capability Maturity Model Integration, Version 1.1, Staged Representation, 2002, Software Engineering [6] http://www.softwaredioxide.com [7] Soldano D. and Krueger L, Introduction to project management, 1994 [8] Mansuy John, Work Breakdown Structure: A Simple Tool for Complex Jobs, Cost Engineering, 1991, pp [9] Peters Kathleen, Software Project Estimation [10] Hareton Leung and Zhang Fan, Software Cost Estimation, Department of Computing The Hong Kong Polytechnic University [11] Stamelos, I. ; Angelis, L. ; Morisio, M. ; Sakellaris, E. ; Bleris, G.L., Estimating the development cost of custom software, 2003, pp 729-741 [12] International Function Point User Group (IFPUG), http://www.ifpug.org [13] Adhikari R., Approaching 2000, Information Week, 1996, pp 36-48. [14] Shepperd M. ; Schofield C , Estimating software project effort using analogies, IEEE Transactions on Software Engineering, 1997, pp 736-744 [15] Jrgensen M., A review of studies on expert estimation of software development effort, 2002 [16] Hughes Robert T, Expert judgement as an estimating method, 1996, pp 67-76 [17] Jrgensen M., Top-down and bottom-up expert estimation of software development effort, 2002 [18] Boehm B, B. Clark, E. Horowitz, C. Westland, R. Madachy, R. Selby, The COCOMO 2.0 Software Cost Estimation Model, 1996, pp. 2-17 [19] Oriogun, Peter K. A Survey of Boehm' Work on the Spiral Models and COCOMO IIs Towards Software Development Process Quality Improvement, 1999 pp. 53-62
46
[20] IEEE Standard for Software Project Management Plans. IEEE-SA Standards Board, 1998. [21] Simpson WD, New techniques in software project management. New York. John Wiley; 1987. [22] Dov Dvir, Tzvi Raz, Aaron J. Shenhar, An empirical analysis of the relationship between project planning and project success. International Journal of Project Management 21 (2003) 8995. [23] Andersen ES. Warning: activity planning is hazardous to your projects health! International Journal of Project Management. 1996;14(2):8994. [24] Ho Leung Tsoi, A Framework for Management Software Project Development. Software Quality Institute Griffith University. [25] Software Engineering Institute (SEI), Carnegie Mellon University, http://www.sei.cmu.edu/sei-home.html [26] Thompson T., Risk management solutions for new product technologies in the semiconductor industry, 2000, pp 49-54 [27] Parametric Cost Estimating Handbook, 1995, http://www.jsc.nasa.gov/bu2/PCEHHTML/pceh.htm [28] Sommerville Ian, Software Engineering, 6th edition., 2000 [29] Sommerville Ian, Software Engineering 7, 2004 [30] Mantel S, Meredith J, Shafer S., Sutton M., Project Management in Practice, 2001, John Wiley & Sons [31] Turner J. Rodney, The Handbook of Project-based Management, McGraw-Hill Publishing Company, 1999 [32] Aaron J. Shenhar, Dov Dvir, Ofer Levy and Alan C. Maltz, Project Success: A Multidimensional Strategic Concept, 2001 [33] M. Freeman and P. Beale, Measuring project success, Project Management Journal 1, pp 817, 1992 [34] J. K. Pinto and S. J. Mantel, The causes of project failure, IEEE Transactions on Engineering Management EM-37, pp 269276, 1990 [35] D. Baccarini, The logical framework method for defining project success. Project Management Journal, pp 25-32, 1999 [36] Parviz F. Rad, Project Success Attributes, Cost Engineering 45(4), pp 23-29, 2003 [37] A. J. Shenhar, M. Poli and T. Lechler, A new framework for strategic project management, Management of Technology VIII, University of Miami, Miami, FL, 2000. [38] http://www.dictionary.com
47
[39] Rumbaugh J. Jacobson I., Booch G. The Unified Software Development Process. Addison-Wesley, 1999. [40] Pinto JK, Slevin DP. Project Success: Definitions and measurements techniques. Project Management Journal 1988, 19. [41] John M. Nicholas, Project Management for Business and Technology, second edition, Prentice Hall, Loyola University Chicago. [42] http://www.xprogramming.com [43] Robson, Colin, Real World Research, Blackwell Publishers Ltd, 1993 [44] http://www.standishgroup.com [45] Procaccino J Drew ; Verner June M ; Overmyer Scott P ; Darter Marvin, Case study: Factors for early prediction of software development success. E Journal: Information and Software Technology year: 2002 vol: 44 issue: 1 pages: 53-62 provider: Proquest doc type: Journal paper [46] Wohlin, Claes ; Andrews, Anneliese Amschler, Prioritizing and Assessing Software Project Success Factors and Project Characteristics using Subjective Data. Journal: Empirical Software Engineering year: 2003 vol: 8 issue: 3 pages: 285-308 publisher: Kluwer provider: Kluwer doc type: Journal paper
48