CPIS334 Software Project Management Chapter 1 Project Management

CPIS-334 Software Project Management Chapter 1: Project Management in the Software Development Environment

Book Essentials of Software Project Management By Richard Bechtold 2

PART I: OVERVIEW Chapter 1: Project Management in the Software Development Environment Two Directions: 1. How to plan and manage a successful project and 2. How to regain control of a project that has been overwhelmed by events 3

Software is not natural: ü It does not age, rust, decay, evaporate, vibrate or float. break, melt, ü The laws of nature do not apply to software. Purpose: ü To deliver result, products and services Ø On time & Ø Within budget 4

Motivation: ü An organization’s motivation for putting you into project management is to achieve maximum resource leverage (power, way of applying). ü If you are successful, then you are well-managed team. 5

Why do Project Management: ü When building and maintaining complex softwareintensive systems, well-managed teams perform more work in less time than a unmanaged or poorly managed teams. ü Management appears to be a relatively simple process, managing technology personnel involved in the design, development, deployment and maintenance of a software-intensive system in extremely challenging. ü Before understanding software management, we should know what is Project and PM. 6

What is a Project: ü A project is a temporary endeavor (assignment) undertaken to create a unique product, service or result. ü The temporary nature of project indicates a definite beginning and end. ü The end is reached when the project’s objectives have been achieved or when the project is terminated because its objectives will not or cannot be met, or when the need for the project no longer exist. ü Temporary does not necessarily mean short in 7 duration.

What is Project Management: ü Project Management is the application of knowledge, skills, tools, and techniques to project activities to meet the project requirements. ü Project management is accomplished through appropriate application and integration of planning, tracking, controlling and adapting. ü Managing a project typically includes: v Identifying requirement v Addressing the various needs, and v Resolving the projects obstacles. 8

To manage a s/w project, you must understand: ü The goal of the Project. ü The Project’s obstacles – prevent or hinder your project from achieving those goals. ü The resources and techniques available to you for overcoming these obstacles. 9

Project Goals: ü To clarify, negotiate, and communicate project goals within the organization in manner that best enables the overall organization to be successful. Level of Goals: 1. Lowest Level ü First line manager planning and directing the work of technical personnel in the design and development and maintenance of the software system. ü His main goal is to develop high quality software. 10

2. Next Higher Level ü Second line manager, who is planning, monitoring and directing development activities across multiple projects. ü Identifying and implementing steps that maximize reuse and efficient sharing resources across projects, and ü Thereby to increase the likelihood of success not only of an individual project but the entire line. 11

3. Highest Level ü A third line manager might oversee, a set of product lines that all relate to a particular industry. ü This manager may have dual goals of trying to ensure that Ø Each product line properly support the others, and Ø In combination, the product lines all deliver costcompetitive value within their target industry. Ø In view of the legitimate existence of multiple, sometimes conflicting goals, the communication and negotiation of shared success value and criteria with other managers and stakeholders are important. 12

Stakeholders ü Person or organization (for example, customer, sponsor, performing organization, or the public) that is actively involved in the project, or ü Whose interests may be positive or negatively affected by execution or completion of the project. ü A stakeholder may also exert influence over the project and its deliverables. ü In software PM, stakeholders provide after consulting: q Testing supports q Documentation supports and q Training Supports. 13

Project Obstacles: Project manager also involves overcoming obstacles that hinder or prevent the attainment of project goal. Classic software project management obstacles are: 1. Unstable goals 2. Inadequate funding 3. Inadequate requirements 4. Unstable Requirements 5. Poorly understood requirements 6. Poor planning 7. Insufficient time 8. Insufficient Technical resources 9. Insufficient Human Resources 10. Resource Conflicts 14

How to overcome Project Obstacles: 1. Stabilize the goals 2. Negotiate requirements 3. Put more efforts into planning 4. Arrange the resources into a team structure 5. Provide accurate estimates of required time to complete the tasks 6. Ensure that project progress with a minimum of interference or conflicts with other groups. 15

What is Resources: Resources are meant for making provisions in cost and schedule, to accommodate for consequences of risks events. ü Risk events are classified as “Unknowns” and “Known Unknowns”. ü UU are risks that were not identified and accounted for, where as KU were identified and provision were made for them. ü Provision for UU are in management resources while KU are accommodated in contingency resources. 16

Project Resources ü Ability to negotiates ü Co-ordinates ü Lead the project personnel needs and capabilities ü Their fears and concerns ü Motivates them or acts as an incentives ü How to shape them into teams and ü How to provide them with what they need to be successful ü You must lead your team, both direction and setting examples – as a team – you secure project success. 17

Different approaches to Project Management: ü There are several approaches ü No two manager approach project management in the same way ü We examine software project management approaches from the perspective of Ø Discipline Ø Direction ü Any Project Manager can approach management responsibilities with varying degrees. 18

Different approaches to Project Management (continued): ü Flexible management discipline versus more strict discipline ü Sparse (thin, light) management direction or guidance versus detailed direction. ü There are four (4) approaches to software project management after combining these extremes. 19

Different approaches to Project Management (continued): 1. Flexible discipline and sparse direction 2. Flexible discipline and detailed direction 3. Strict discipline and sparse direction 4. Strict discipline and detailed direction 20

Figure 1: Approaches to Project Management 21

Matrix Management ü Flexibility regarding management discipline ü Provide fair degree of detailed management control and oversight. ü Its set up to share management responsibilities equally among two or more managers. ü Flexible management attitude because it impacts on one or more other managers. ü This environment requires considerable communication, negotiation, and compromise. 22

Administrative Management ü It is quite detailed and relatively inflexible & is often useful management approach if you have good group of skills people. ü Most of the decision passed to higher management, in absence of group decision making. ü Example, more technical knowledge but no interest to take management responsibilities. ü In this case you work with technical leader in developing schedules, budget, and effort estimates, and you effectively handle all other tasks. 23

Technical Management ü TM is somewhat strict with regard to management direction because decisions are tightly bound to technical constraints & objectives. ü Amount of direction is comparatively sparse. ü Most of your time free for design, development, and other technical or engineering activities. ü If you have a comparatively less experienced team, you will make most of the technical decisions and usually look to other technical managers for any decision support you need. 24

Research Management ü Highly flexible management style coupled with a relatively sparse amount of management direction. ü RM allows the experts on the team to make more of the decisions. ü The team usually contributes extensively to any planning or schedule activities. ü When the team cannot come to consensus, you will typically raise the issue of the managers above you and wait for their decision. 25

Nominal Management ü A nominal management approach is characterized by a generally balanced approach between flexible and strict and between sparse and detailed management direction. ü In the absence of other factors, this is typically the best approach to take initially. ü As the management needs of the project team and the overall organization become more apparent, you can modify your approach accordingly. 26

Team Leader ü A flexible style and relatively sparse management direction. ü The team itself often makes most of the low-level management decisions. ü TL is referred to as a self-managed team. ü All team members participate in decision making process. ü These management types are clearly a simplification of the great diversity of management alternatives. 27

The challenging Environment of Software Development Part of the motivation for the numerous approaches to software project management is the extreme diversity of software projects, which is directly attribute to challenging environment. Following are the characteristics of challenging environment: 1. Software is unnatural 2. There are no natural limits to software complexity. 3. Key solution decision-makers have negligible background in the problem domain. 4. Key problem decision-makers have negligible background in the solution domain. 28

5. Technical or tool specialists understand very little outside their specialty. 6. Staffing authorities overrely on specialists (especially with regard to development tools). 7. Theoretically, virtually nothing is impossible to implement in software. 8. Customer needs change faster than software development tools. 9. Software development tools change faster than software development methods. 10. Software development methods change faster than management discipline. 29

Software is Unnatural To understand how to manage a software project successfully, you need to appreciate the magnitude of the software challenge and the major characteristics of the challenge. ü The laws of nature do not apply to software. ü It does not age, rust, decay, break, melt, evaporate, vibrate or float. ü The fact that software is unnatural leads a huge problems. One of the significant is the fact that successful engineering principles from other principles often work poorly. ü Because, these principles works on laws of nature. 30

No limits to complexity ü There are no natural limits to software complexity. ü For example, a construction company that builds single storey houses would never consider to attempting to build a 20 -storey office complex. ü But, software company will always attempt to develop a software that are 2 times more complex than anything they have built before. ü In software, there is often an attitude that nothing is too complicated – if we can eventually get it to work. 31

Lack of Domain Expertise ü Characteristics 3 & 4, cover lack of problems and solution domains. ü Expertise in the problem domain consists of direct experience with the understanding of the problem that the software system is intended to solve. ü For example, accounting software – expertise includes understanding of general ledger, a/c payable & receivable, payroll, purchase order, inventory and other areas related to accounting. 32

Lack of Domain Expertise (continued) ü Expertise in solution domain consists of experience and understanding in the tools and techniques that will be used to solve the problem. ü The problem is not necessary that the project lacks sufficient expertise, but the problem is more likely that key decision makers lack the expertise. ü Decision makers simply need o defer certain decisions to those who have the expertise to make the most informed decision. 33

Overspecialization ü Developers often tend to become accidentally overspecialized. ü This occurs because the developer has a particular skills. ü For example, in a recently released development tools – that the company wants to leverage. The company keeps putting the developer on projects that require the use of that specific tool. ü As time goes by, new tools appear, but most organizations do not have the time or the inclination to cross-train. 34

Overspecialization (continued) ü Eventually the developer is extremely adept in that one aging tool but has had almost no exposure to or experience in anything else. ü As personnel become increasingly specialized, moving these people between projects or using them at all on smaller projects becomes more difficult for companies and managers. ü Multi-disciplined and multitalented personnel are easier to leverage but are quite difficult to find. 35

Overreliance on Specialization ü The software industry tends to hire people with specific tool or other specialized experience. ü A person specialized in one area who has very little understanding of anything else. ü One reason of this overreliance is that determining whether someone has two years of experience with a specific tool is easier than determining whether a person is a senior software engineer. ü It is much easier to make hiring decision. 36

Nothing Seems Impossible ü In software development, the question generally is not whether something can be done. ü If it seems like it could be done, it almost certainly can be done. ü The questions are, is there enough time, and is there enough money? ü But when you look at some of the spectacular failures associated with extremely complex systems, such as: v The modernization of large federal government agencies 37

Nothing Seems Impossible (continued) v Automation of airports or mass transit systems & v Immense telecommunications projects ü Then it appears that practically speaking, some project rally are impossible. ü They are not impossible in principle, but the magnitude, complexity, duration, plan design, and attempts at implementation all combine to render the project’s goals effectively unachievable. 38

Fast Pace of Change ü It is crucial to understand the impact of change on the software development environment. ü No other industry is subjected to the rapidity of change that is common in software engineering. ü Figure 2: change occurs at different rates within the various elements of the software engineering environment. ü The rate of advancements in technology is so fast that the typical customer only partially understand what its company will likely need a year from now & frankly has no idea what it will need 5 yrs from 39 now.

Figure 2: Fast Pace of Change 40

Fast Pace of Change (continued) ü Software tool providers are simply not able to keep up with the rate of change in th needs of their software development customers. ü These new tools and technologies almost always afford a new and improved way to perform software engineering processes and methods. ü As per the Gartner group study, 90% of all software project fail, due to ill-designed as per requirements. ü Out of every 100 projects starts, there are 94 restarts. In US, 175, 000 IT development projects, 31% are canceled outright before completion. 41

What is Project Management? 1. Find and hire the right people 2. Ensure that they have the tools they need. 3. Keep up with the latest Technology. 4. Develop and maintain comprehensive plans. 5. Negotiate compromises with other managers and stakeholders. 6. Make presentations to execute managements. 42

What is Project Management? (continued) 6. Spend sometimes with each of the project personnel during the summer picnic and other office events. 7. per the Gartner group study, 90% of all software project fail, due to ill-designed as per requirements. 8. Out of every 100 projects starts, there are 94 restarts. 9. 175, 000 IT development projects, 31% canceled outright before completion in USA. are 43

What is Project Management? (continued) At its essence, project management consists of four Simple things: 1. Planning 2. Tracking 3. Controlling 4. Adapting 44

1. Planning ü Planning is fortune-telling that is as you develop a project plan, you are attempting to predict the future. ü In the software industry, planning is exceedingly difficult & becomes exponentially more difficult as the duration of the project increases. ü Developing an accurate project plan is so difficult, many software project managers simply operate with no plan at all. 45

1. Planning (continued) ü They tell project personnel to work as fast as possible for as long as possible, and the manager spends virtually all his or her time responding to an endless succession of problems. ü This type of management style is often referred to as “firefighting”, but that term is grossly misleading. ü It is far more accurate to refer to it as “Arson”. ü On some projects, the development and maintenance of project plans could easily require 50% or more of your time. 46

1. Planning (continued) ü The plan is a reflection of your best attempt to anticipate what is going to happen. ü So that you can have the necessary resources available when you need them. ü Without a plan: v You have no strategy and no means for reliably tracking closure toward your project goals. v The project is just a daily succession of accidents and reactions to accidents. 47

2. Tracking ü Once the plan is in place, use it continuously to track the project ü Tracking involves collecting status data and updating the various parts of the plan to reflect the latest developments. ü Collecting this data can range from a formal system to metrics to informal weekly meeting with project personnel. ü Most of Project Managers tracks at least hours worked, Money spent & % of the project completed. 48

2. Tracking (continued) ü He also tracks defect density, milestones achieved, staff turnover and any other items that help him for achieving additional insight into the efficiency, effectiveness and overall health of the project. ü Tracking depends on he achievement of discrete and objectively verifiable events. ü For example, when a programmer is working on a software module, do not bother asking that programmer what the % completion rather than “Is design complete, module ready for inspection or module ready for integration testing. 49

2. Tracking (continued) ü If there is any problems tracking these modules, so divide into sub-modules & track the separate modules. ü The key to tracking is to have data available that are sensitive enough to developing events that you get the earliest warning possible ü And yet not so sensitive that the data result wild fluctuations and repeated false alarms. 50

3. Controlling ü Controlling the project is where everything converges to determine success or failure. ü You can have a perfect plan, and you can perform impeccable (perfect) tracking, but it is all useless unless those efforts contribute directly to successful control. ü Project controls includes all efforts and activities that are intended to establish, develop, manage, motivate and coordinate the human resources on your project. ü You also control nonhuman resources such as computer 51

3. Controlling (continued) ü computers, s/w tools, useful docs, training videos etc. ü A key ratio of evaluating the effectiveness of your project control efforts is the ration of actions taken in anticipation of events to actions taken in reaction to event. ü Control is the key element of software project management. ü You are leading the project, not chasing it. 52

4. Adapting ü Under ideal circumstances, when your project’s performance deviates significantly from the plan, you perform a number of corrective actions in order to restore the originally planned performance. ü In this situation, adjust your plan that it more accurately reflects what is actually happening. ü Either options, adjusting performance to match the plan or adapting and updating the plan to match performance is perfectly acceptable. ü The primary thing you want to avoid is a persistent uncorrected divergence betn the plan & performance. 53

The role of the Project Manager in today’s Software-Intensive Environments p ü The activities of Planning, tracking, controlling and adapting are certainly activities that are common across all types of project management. ü The problematic environment of software development projects are commonly staffed with uncommonly intelligence people. ü Successful s/w teams should have smart people who are talented, educated and experienced. 54

The role of the Project Manager in today’s Software-Intensive Environments – contd… p ü The PM role is not to control each person but to lead the experienced team through each successive project lifecycle phase and navigate around the obstacles. ü Once an operational plan is in use, most of your efforts at project control will focus on removing obstacles. ü Your goal is to do everything possible to allow your team to make the greatest progress possible. ü Doing this right, you maximize the likelihood that your project will be a success. 55

Where to Start ü There is another paradox (impossibility) regarding project management. ü To develop a plan properly, you need answers to numerous questions about the characteristics of the project, associates technologies and the people with whom you will interact. ü Where you start as a project manager is typically by doing everything in parallel. ü You start the planning process even though you know there are major influences whose impacts you cannot 56 yet estimates.

Where to start (continued) ü You start searching for answers while you plan, and revise the plan as those answers become apparent. ü All these activities occur in parallel and none of them complete until the project is over. ü However, if you are on a project that looks like it is out of control or does not have a plan that is both usable and current, then the answer to where to start is easy. ü Before, you do anything else, you have to start developing a usable plan. 57