CPIS334 Software Project Management Chapter 3 Developing Plans

CPIS-334 Software Project Management Chapter 3: Developing Plans

Overview • Developing Preliminary Plans – Feasibility Analysis – Project Initiation – Preliminary Planning • Developing Intermediate Plans – – – – – 10/7/2020 Project Organization Product-Oriented Project Organization Market-Oriented Project Organization Function-Oriented Project Organization Matrix-Oriented Project Organization Project Staffing Environment and Tools Estimation Work Breakdown Structures (WBS) Resources Breakdown Structures Detailed Requirements Analysis 2

Overview contd… • Developing Detailed Plans – Estimating Product Size – Estimating Project Effort – Scheduling Milestones – Scheduling Resources – Leveling Loads • • Developing A Risk Management Plan Organizing The Project Plan Maintaining The Project Plan Developing A Staffing Plan 10/7/2020 3

Developing Preliminary Plans • Development of the project plans tends to occur in multiple passes. In developing the project plan, you will regularly be revising, adjusting, and revisiting the various sections as more of the project details are discussed, documented, and communicated to others. • On each pass through the plan, you will: – Add missing material – Revise existing material – Identify and resolve internal inconsistencies – Identify and prioritize remaining planning activities 10/7/2020 4

Preliminary Planning • Near-term details will be easier to capture than more distant ones. e. g. parts of the plan covering next 3 to 6 months include more detail than parts covering months 12 through 18. • One of the first determinations you must make when undertaking preliminary planning is whether or not the project is even feasible. Once feasibility analysis has been established, project initiation and preliminary planning can be undertaken. 10/7/2020 5

Feasibility Analysis • Feasibility Analysis aims to ensure that none of the expectations associated with the project is far beyond historical precedence. • when you start project planning: – the inputs are the high-level requirements for the software system – the outputs are the estimates of how long it will take and how much it will cost 10/7/2020 6

Assessing Expectations • • • maximum cost maximum overall calendar duration maximum personnel resources available Maximum computational resources available limitations on training limitations on salary levels limitations on ability to hire external personnel limitations on ability to select internal personnel limitations on modern tool acquisition or usage need for research breakthrough need for early proof of project success need for technology breakthrough 10/7/2020 7

Project Initiation • Project initiation consists of the set of one-time activities you need to perform to begin more detailed project planning activities. • Project initiation serves as an initial gate that helps ensure that: – those sponsoring or funding the project have approved the initial release of funds and the accumulation of expenditures – those responsible for planning and management of the project tentatively agree that the project appears feasible 10/7/2020 8

Preliminary Planning • Preliminary Planning consists of: – determining the structure and organization of the project plan – then documenting within the plan: – any currently known project goals – requirements – constraints – milestone dates – resource needs – risks – any other planning-related information 10/7/2020 9

Plan Areas • your plan will have sections covering most or all of the following areas: – Purpose and scope of the project – Goals and objectives of the project – Listing of all acronyms used in the project plan, and an explanation of those acronyms – Listing of all supporting documentation or published works referenced in the plan, and a brief description of their content – Summary description of the products or services to be provided – Summary description of the customer and any relevant history regarding the customer – External or internal standards with which the project must comply – Description of the lifecycle or lifecycles selected for the project and a rationale for the selection – Any documented procedures, methods, and techniques for managing, developing, maintaining, or supporting the software, the software project, or project-related artifacts. 10/7/2020 10

Processes Descriptions • Documentation may include descriptions of the processes for: – software size estimating software effort estimating – software planning project tracking and oversight – configuration management quality assurance – subcontract solicitation mgmt subcontract acquisition mgmt – requirements management software design – software development software inspection – software integration testing system testing – system deployment problem or change request tracking and management – status reporting technical documentation development – user documentation development training material development. – Size and complexity estimates for all SW Work breakdown structure 10/7/2020 11

Processes Descriptions contd… – Resource breakdown structure Estimates of the project resource requirements – Estimates of the project costs – Estimated use of critical computer resources, including those in the: • development environment • in-house test environment • field test environment • customer environment – Tools that will be used to support these procedures, methods, and techniques, and the rationale for their selection and use – Detailed listing and supporting descriptions of all software and related products to be developed and services to be delivered – Project schedule, including major milestones and reviews, resource requirements, and critical path analysis – Identification, evaluation, and management of the project’s risks – Documentation of the project’s software engineering facilities and any additional support tools. 10/7/2020 12

Preliminary Plan • As a general rule, you should try making certain sections quite brief, rather than eliminating them altogether. • During preliminary planning, you should generally lay out the entire plan, even though most of it will be blank. 10/7/2020 13

Developing Intermediate Plans • Documenting your initial version of the: – – – Project organizational structure Project staffing profile Tools you will need Work and resource breakdown structures Any other information • This will help you construct the final detailed plan • This plan at this stage needs to be highly flexible • Don’t try to get things perfect • It represents a draft version of the plan at a given moment in time 10/7/2020 14

Project Organization • There is a variety of choices for organizing project. • Generally, projects are formed to support one of four overall business models: – Product-Oriented – Market-oriented – Function-Oriented – Matrix-Oriented 10/7/2020 15

Product-Oriented Project Organization • The same team performs the majority of the activities necessary to develop and deliver the product. • Different people on the team have different specialty areas. • The team is generally kept together throughout the duration of the project. • On smaller teams, its helpful to have people who demonstrate a variety of skills. • Multipurpose team members make it easier for you, as the project manager, to distribute work • evenly. 10/7/2020 16

Market-Oriented Project Organization (Customer-Oriented) • Market-Oriented Project s are organized so that they are highly responsive to nontechnical objectives, constraints, and considerations. • Projects that are managed by nontechnical personnel, or projects whose managers are directed by nontechnical personnel, are likely following a market-oriented paradigm. • This type of project organization works well when: – requirements are unknown – competition is extremely aggressive – there is a need for very fast reaction times to factors external to the project 10/7/2020 17

Function-Oriented Project Organization • Function-oriented projects are organized to allow personnel to focus on whatever they are best at doing. • There is a requirements group, a design group, a documentation group, a test group, and other groups for whatever functional specializations are necessary. • Therefore, if you are the project manager for the code development team, your team consists entirely of software coders. If documentation needs to be developed, another group does it. Likewise, when integration or system testing is needed, a different group carries it out. • The advantage to this approach is that it allows people work within a group where they can find help and advice easily. • The disadvantage is that intergroup conflict—and a corresponding decrease in overall efficiency. 10/7/2020 18

Matrix-Oriented Project Organization • Matrix-oriented projects strive to use two different organizational paradigms with the objective of maximizing the strengths of both while minimizing their weaknesses. • For example, a company may be using a hybrid of product-oriented and function-oriented paradigms. Every project member has two managers: one responsible for getting product on the street, and one responsible for ensuring that the documentation group is used as efficiently and effectively as possible. • In practice, matrix management usually works best when the assignment of who has final authority on what types of decisions is clearly documented. • How to select a project Organization: – There are, of course, numerous variations regarding project organization. If you are unsure which organization would work best on your project, use the product-oriented paradigm. A team of people who are all working together, sharing complete responsibility for development of the product, and led by a single, competent project manager, has excellent potential for being a highly successful team. 10/7/2020 19

Project Staffing • Situations that usually happen when it comes to project staffing: – Project personnel have been assigned to you by executive management, and you have no choice – You can swap existing project personnel with other personnel within the company – You can augment internal project personnel by hiring additional resources from outside the company – No resources and you must hire everyone from outside the company • Options for finding people to staff your project: Recruitment ad in your company newsletter or a local paper Obtaining referrals from existing company personnel participating in a job fair posting openings to the internet or to local colleges and universities – retaining a search agency – – 10/7/2020 20

Environment and Tools Estimation • Examples of the activities types you need to consider: 10/7/2020 – project planning and tracking – configuration management – software size estimation and design – defect tracking – integrated software development – software testing – team communication tools – internet/web access 21

Environment and Tools Estimation • Many companies have a standardized set of tools • You face the decision when considering tools between: – More mature tool – Leading edge tool • Tool selection factor: – Your own familiarity – Your team member’s familiarity 10/7/2020 22

Work Breakdown Structures • Documenting the overall work to be performed by – developing Work Breakdown Structure (WBS) • WBS is a decomposition of the entire project effort into smaller pieces • You need a very high-level idea about how you are going to build the system • You need a preliminary design 10/7/2020 23

Partial WBS 10/7/2020 24

Work Breakdown Structures • you could attach the following boxes to “test code”: – test core features – test support features – conduct performance tests – conduct abuse tests. 10/7/2020 25

WBS Example: 10/7/2020 • How many boxes do I need? 26

Resource Breakdown Structures 10/7/2020 • Focus on the organizations, divisions, programs, projects, teams, and individuals who will be performing the work • A common problem, the organizational relationships of who manages whom, who reports to whom, and who supports whom become highly confusing • It is helpful if the resource breakdown structure shows a similar decomposition to the WBS 27

Detailed Requirements Analysis • requirements tend to shift throughout the project as customer’s problems tend to shift as fast as technology does • Revisit the existing requirements regularly and evaluate their: 10/7/2020 – relevancy – objectivity – completeness – consistency – testability 28

Developing Detailed Plans • There is no clear boundary between the intermediate and detailed planning. • Starting analyzing issues relating to the: – size of the system being built – estimated costs – expected schedule of activities – remaining details necessary to complete the software project plan 10/7/2020 29

Estimating Product Size • one of the most difficult tasks to perform accurately • size estimates have a huge influence on cost, effort, and schedule estimates • made using a variety of units, including: – thousands of source lines of code (KSLOC), – function points, – objects, – screens, and – unique graphical elements. 10/7/2020 30

Software Sizing Techniques • Vary from formal, database-driven, historically derived size estimates, to the highly informal guessing by a project manager (This product will likely be twice as big as the last one we did). • The Delphi technique is – a good compromise between having hard data and making guesses – used to answer questions that cannot be answered (ex. What will be the Dow Jones average be after two years from now) 10/7/2020 31

Delphi Process – Ask a variety of knowledgeable people to develop their own best answer to your question – Have them meet in a group where each individual presents his or her answer and what it is based on – there are no discussions , no interruption – you end the meeting and ask each person to reassess his or her answer – After they have worked individually to develop what they now consider to be the most accurate answer, they meet again. – Everyone simply states their latest opinion on what the answer is, and why they arrived at this answer. – The process is complete when the group is more or less in agreement, or when you think that subsequent iterations will not have much influence on the answers you are given. 10/7/2020 32

Using Delphi Technique • To use Delphi technique for software size estimations, identify a group of people who you think are capable of making relatively good guesses regarding possible software size. Ask them to study any known information and to estimate the size of modules, objects, subsystems, or other system components. • When the smallest estimates are at least 75 percent of the average and the largest are below 125 percent of the average, you may have an average that is good enough to use. • For larger Delphi groups, you can establish a rule where you eliminate, for example, the two smallest and two largest numbers before you apply the 75 percent-125 percent test. 10/7/2020 33

Estimating Project Effort • When estimating effort, you need to account for a variety of factors – Software size – Software complexity – Team experience with the problem domain – Team experience with the solution domain • programming language • development environment • support tools (configuration management, diagnostic, etc. ) – Application of productivity tools – Use of in-progress product and process quality evaluations – Intended quality thresholds during post-development testing 34 10/7/2020

Estimating Project Effort ( Cont. ) • The key problems is determining how you weight their relative impact. • Cost estimation tools assert that if the results end up being wrong, then you should just adjust the coefficients until they yield accurate results – determine the relative correlation between estimation inputs and resulting outputs – major problem is the existence of nonlinear and nonarithmetic relationships between inputs and outputs. 10/7/2020 35

Estimating Project Effort ( Cont. ) • Software development rarely offers the luxury of repeating near-identical projects even when historical data is available • Numerous new factors introduces variables that reduce predictive confidence to unreliable levels • Consider using a multiple-build lifecycle if you are highly uncertain about your effort estimates • Subsystems generally have similar characteristics 10/7/2020 36

Scheduling Milestones • Schedule showing major project milestones and indicating, in detail, when the various activities will occur and who will be performing them. • A simple method is to build a precedence network 10/7/2020 37

Precedence Network • Start with a list of activities to be performed (lowest level boxes from WBS) • For each activity: – estimate its duration from • size estimates, • effort estimates • availability of resources – indicate any predecessor activities • activities that must be completed before the given activity can start. 10/7/2020 38

Activity Requirements Code A Duration 12 Predecessors None Design Test Plan B C 9 10 None A Documentati on D 10 B Coding Risk Analysis E F 24 10 B A Test Lab G 35 C Tech Editing H 40 D Marketing I 15 A Integration J 4 G, H, E User Evaluation K 5 I, F, J 10/7/2020 39

• Once you have this list, the next step is to build a precedence network showing activities as nodes and with lines connecting each activity to its predecessors. • For each activity, add a number indicating its duration (typically, this is in calendar days). 10/7/2020 40

Precedence Network 10/7/2020 41

Precedence Network (Cont. ) • • • The “start” and “end” boxes The earliest start date The latest start date The earliest end date The latest end date The critical path – is any sequence of activities where, if any activity is delayed, the entire project is delayed – There is always at least one critical path. 10/7/2020 42

• slack time: difference between the earliest start date and latest start date • the critical path has zero slack time • when activity durations are uncertain: – replace the exact duration value with a simple equation intended to give an estimated value – A = Likely shortest duration – B = Expected duration – C = Likely longest duration – D = (A + (3 * B) + (2 * C)) / 6. 10/7/2020 43

Scheduling Resources • start identifying the resources needed to perform the various activities once the milestones are scheduled • each activity can be characterized by needing support from one or more roles • each role can be characterized by the number of people needed for that role. • gain a clearer picture of the staffing • resource analysis, balancing, and load leveling really become your primary effort. 10/7/2020 44

Developing A Risk Management Plan • Risk management is critical for project success • Risks are surprisingly easy to plan for, track, and mitigate. 45

Objectives (Benefits of risk management ) • to prevent undesirable situations from occurring • to reduce any negative consequences when something undesirable does occur • Successful of risk management is that you don’t have highly visible problems • the problems are being kept in check precisely because you are actively managing and mitigating them 46

Risk Planning • developing a “house of risk management” • Steps: 1. Identify any significant risks you think you may have on the project 2. list potential ways that the risks can be reduced or eliminated 3. indicate the degree to which the solutions help reduce the risks – black circles=solution is likely to be highly effective – the gray circles=moderately effective solutions 47

house of risk management 48

Risk Planning (Cont. ) 4. construct the roof of the house, which is used to intersect all the options for solutions with each other. any given solution will work well in combination with some of the solutions (Put a plus ) any given solution may be quite incompatible with other solutions. (Put a minus ) when the solutions have relatively little influence on each other (Leave the space empty ) 5. Add values to the side of the house to indicate your estimate of risk exposure most difficult part to quantify 49

Purpose of the House • to help you analyze risk exposure • make better decisions about the actions you will take to reduce your risk. 50

Analyzing Risk • develop a risk exposure scatter plot to help analyze your risks and the impact of mitigating them • How? – the scatter plot has a dollar scale on the y-axis and a probability scale on the x-axis – For each risk on the house, plot it at the appropriate x and y coordinates. 51

Risk Exposure 52

What does plot mean? • the following impact and probabilities result in an $500, 000 risk exposure: – $4, 000 at 12. 5 percent probability – $2, 000 at 25. 0 percent probability – $1, 000 at 80. 0 percent probability • Risk exposure is reduced by reducing the probability of the undesirable event occurring, reducing the cost if it occurs, or both 53

Simple Risk Management Plan • Contains the following items: – top ten risks, in priority order • (ranked by exposure) – potential solutions for reducing risk exposure – contingency actions to be taken in the event that the undesirable event occurs 54

Updating Risk Plan • update risk plan regularly. • When do this: – Revisit your estimates on probabilities and impacts. – Add any new risks. – Remove risks from the top ten list when their exposures fall sufficiently low. – Update the house and scatter diagrams. – Discuss the updated risk information and diagrams with your project personnel. 55

Conclusion • Comprehensive risk management does not need to be: – time-consuming – expensive, or – complicated • Even just a few hours a month may be sufficient to avoid a major project disaster. 56

Developing a Staffing Plan • As you develop plans, you need to think about: – the types of skills you need on the team – any assistance you might need with the various management related activities • Document these decisions in your project plan • As you plan project staffing, you need to consider the required technical skill set. • Consider your ability to find and retain the types of people you are planning to use.

Project Roles • covers the majority of the types of roles you should at least consider having on your team • the resources on the team, in combination with your abilities, must be capable of doing all required work. • Some of the roles described may exist above your management level • several of these roles can be assigned to one person, many of the roles are quite compatible with each other • be careful to avoid losing an oversight role as a result of combining it with a performance role.

Project Senior Manager • monitors the strategic direction of the project to ensure that: – progress is consistent with the overall project plan – goals remain consistent with strategic business or executive goals. • has simultaneous responsibility for multiple projects and is not involved in the day-to-day details or management of the project.

Project Senior Manager(cont. ) • conducts : – Periodic reviews occur at planned regular intervals, such as monthly or quarterly – Event driven reviews occur when major events occur. These include any of the major milestones shown in the project plan, as well as any other predefined triggering events

Project Manager • responsible for all resources on the project. • Focused on just a single project • primary responsibilities include: – tracking the progress of the various groups involved in the project – negotiating commitments and compromises between these groups – resolving any issues that result from disagreements between groups within the project, or between project groups and external groups

Software Manager • responsible for all software resources across the entire project • may be a third, fourth, or higher level manager. • on smaller projects, the software manager may be the first line manager, to whom all project software personnel report • generally he has responsibility for performing, or overseeing, all the activities described in this book.

Configuration Management Manager • responsibility for ensuring that: – software and software-related products are uniquely identified, controlled, and available, – changes to software and software-related products are controlled, – the status and content of software baselines are communicated to those who need such information. • the formality and tool support for configuration management activities can vary significantly between small projects and large projects

Software Quality Assurance Manager • works for the same organization that you work for • His goal is to ensure that you are taking the proper steps to meet your goal. • if you are seeing the long list of software defects and process violations before executive management sees it, Ø the software quality assurance manager most certainly has your best interests in mind.

Software Requirements Manager • manage the software requirements. • may require very little effort. • since requirements drive the entire project, someone needs to be assigned the responsibility to pay attention to (shifting) requirements. • As project manager, you may decide that requirements management is your responsibility and, you will be carrying out the associated responsibilities

Domain Experts • You will need domain experts of two general types: – problem domain experts: understand your customer’s needs – solution domain experts: understand the tools and technologies you’ll be using to implement the system. • it is common on software projects to undertake projects without having sufficient expertise in the problem domain

Domain Consultants • On smaller projects, you should consider expanding team with one or more part-time domain consultants (problem, solution, or both). • These consultants can help transfer knowledge and thereby help your project staff overcome the more difficult obstacles they encounter • The disadvantages to using consultants: – they never seem to be around when you really need them. – You will hearing contradictory advice if you using multiple consultants in overlapped areas of expertise

Mentors • When staffing your project with domain experts, strive to ensure that at least some of them are capable of working as mentors. • This should also be one of the criteria you use for selecting consultants. • Having some mentors on the project will improve the likelihood that junior people will learn quickly.

Technical Leaders • one or more who have both an aptitude for and an interest in performing a few management functions • The role of technical leader can vary significantly among companies • ratio between time spent performing management activities and time spent performing technical activities

Team Leaders • Team leaders head teams where one or more people on the team have more technical expertise than the leader does. • doesn’t create a problem if the team leader has the right set of skills. • technical decisions are made either by individuals on the team or by consensus among multiple team members. • As with the technical leaders, you need to ensure that the team leaders clearly understand the scope of their responsibilities.

Software Specialists • proficient at every lifecycle phase in your project • ensure that you have a combination of senior, intermediate, and junior software specialists. • You need a mix of different levels of specialists to be able to minimize both risks and costs simultaneously. • To avoid having too much of a dichotomy between the senior and junior personnel, be sure to have one or more layers of intermediate expertise.

Administrative Support • Any software project will involve a considerable amount of administrative work. • Without administrative support, you will likely do much of this work, and pass some of it through to your technical personnel. • If at all possible, add one or more administrative support personnel to the project team.

Finding Talent • a lot of software positions remain open longer than desired, and salaries paid are higher than planned

Finding Talent (cont. ) • trying to find “the best” people is a complete waste of time because: – If every organization is trying to hire only the best talent, the majority of them, by definition, will be unsuccessful. – The best tend to want a lot more money than most organizations are willing to pay. – it is almost impossible to identify “the best” in a few halfhour or one-hour interviews – Many organizations have such a large backlog of unfilled positions that they’ll hire anyone with a degree and a pulse

Finding Talent (Cont. ) • With a few above average people on an otherwise average team, you can have a very successful project. • An increasingly popular method for finding software personnel is by paying a sizable “finder’s fee” to existing employees when they recommend a friend who is hired • After you’ve found someone who has expressed an interest in working on your project, you still have the problem of determining whether or not he or she meets your minimum qualifications

Interview process • A mainstay to virtually any attempt at staffing a software project is the interview process: – have an applicant interview with three or more employees. – series of interviews where the applicant meets with technical personnel. – if the applicant is successful at that level, he or she is asked to return for a second series of interviews with management personnel. – you can use person on any project If a person: • Is willing to be flexible in work assignments, • has a history of being able to learn new technology, • has a positive and cooperative attitude

Good Software Engineer • “finding the right talent” is not about finding the perfect software engineer. • sufficiently good engineer is one who meets your minimum technical and educational requirements and who is capable of: • learning—because new technologies and tools are constantly appearing, • changing—because projects and products never seem to unfold the way they are originally envisioned, and • becoming and remaining a member of the team.

Balancing the Team • If everyone is an expert: – they will tend not to listen to each other, – they may tend to forge ahead with their own approach even when that approach is incompatible with those of others on the team. • if everyone is junior: – they will likely work more closely together, – they’ll learn is through trial and error.

Balanced Team Characteristics • characterized by a combination of different: – – – – roles, types of language experience, types of tool experience, types of domain experience, levels of expertise, backgrounds, personalities • A balanced team will help ensure that whatever it is you need at any given moment, someone on the team will be able to provide it.

Finally, • project planning and project staffing occur in parallel Ø as you actually add resources to the project team, be sure to make any appropriate adjustments to the project plans.