Software Project ManagementIntro to Project Management

Presentation ByNISHA R.S.Lecturer,Dept. of MCA

Lecture #1

Course ObjectivesUnderstand the fundamental principles of Software Project management & will also have a good knowledge of responsibilities of project manager and how to handle these. Be familiar with the different methods and techniques used for project management. By the end of this course student will have good knowledge of the issues and challenges faced while doing the Software project Management and will also be able to understand why majority of the software projects fails and how that failure probability can be reduced effectively. Will be able to do the Project Scheduling, tracking, Risk analysis, Quality management and Project Cost estimation using different techniques

Lecture #1

Unit I Introduction

Lecture #1

Project DefinitionIn the broadest sense, a project is a specific, finite task to be accomplished. Any activity that results in a deliverable or a product. Projects always begin with a problem. The project is to provide the solution to this problem. When the project is finished it must be evaluated to determine whether it satisfies the objectives and goals.

Lecture #1

What is Management?Management can be defined as all activities and tasks undertaken by one or more persons for the purpose of planning and controlling the activities of others in order to achieve objectives or complete an activity that could not be achieved by others acting independently.Management functions can be categorized asPlanningOrganizingStaffingDirectingControlling

Lecture #1

Management FunctionsPlanning Predetermining a course of action for accomplishing organizational ObjectivesOrganizing Arranging the relationships among work units for accomplishment of objectives and the granting of responsibility and authority to obtain those objectivesStaffing Selecting and training people for positions in the organizationDirecting Creating an atmosphere that will assist and motivate people to achieve desired end resultsControlling Establishing, measuring, and evaluating performance of activities toward planned objectives

Lecture #1

What is Project Management The application of knowledge, skills, tools and techniques to project activities in order to meet project requirements

Lecture #1

What is Project ManagementProject management is a system ofmanagement procedures,practices,technologies,skills, andexperiencethat are necessary to successfully manage a project.

Lecture #1

Software Project ManagementConcerned with activities involved in ensuring that software is delivered:on timeon schedulein accordance with the requirements of the organization developing and procuring the software

Lecture #1

Project StakeholdersStakeholders are the people involved in or affected by the project activesStakeholders includeThe project sponsor and project teamSupport staffCustomersUsersSuppliersOpponents to the project

Lecture #1

Project CharacteristicsOne clear objectiveA well defined set of end resultsGoal orientedEnd product or service must result FiniteFixed timeline, start date, end date, milestone dates LimitedBudget, Resources, Time Life CycleRecognizable sequence of phases

Lecture #1

Lecture #1

Product Life CyclesProducts also have life cyclesThe Systems Development Life Cycle (SDLC) is a framework for describing the phases involved in developing and maintaining information systemsTypical SDLC phases include planning, analysis, design, implementation, and support

Lecture #1

Steps in SDLCConcept ExplorationSystem explorationRequirementsDesignImplementationInstallationOperations and supportMaintenance Retirement

Lecture #1

Process & Process ModelSoftware Processthe set of activities, methods, and practices that are used in the production and evolution of softwareSoftware Process Modelone specific embodiment of a software process architecture

Lecture #1

Why Modeling?To provide a common understandingTo locate any inconsistencies, redundancies and omissionsTo reflect the development goals and provide early evaluationTo assist development team to understand any special situation

Lecture #1

Sample SDLC ModelsWaterfall model: has well-defined, linear stages of systems development and supportSpiral model: shows that software is developed using an iterative or spiral approach rather than a linear approachIncremental release model: provides for progressive development of operational softwareRAD model: used to produce systems quickly without sacrificing qualityPrototyping model: used for developing prototypes to clarify user requirements

Lecture #1

Waterfall ModelRequirementAnalysisSystemDesignCodingTestingMaintenance

Lecture #1

Waterfall Model (contd)classicalone-shot approacheffective controllimited scope of iterationlong cycle timenot suitable for system of high uncertainty

Lecture #1

V ModelRequirements AnalysisSystem DesignProgram DesignCodingUnit andIntegration TestingSystem TestingMaintenanceUser Acceptance Testing

Lecture #1

V Model (contd)Additional validation process introducedRelate testing to analysis and design Loop back in case of discrepancy

Lecture #1

Spiral Model (adapted from Boehm 1987)

Lecture #1

Spiral Model (contd)Evolutionary approachIterative development combined with risk management Risk analysis results in go, no-go decision

Lecture #1

Spiral Model (contd)Four major activitiesPlanningRisk analysisEngineeringCustomer evaluation

Lecture #1

Prototyping ModelGoalsmeet users requirements in early stagereduce risk and uncertainty

Lecture #1

Classification of PrototypeThrow-awayAfter users agree the requirements of the system, the prototype will be discarded.EvolutionaryModifications are based on the existing prototype.IncrementalFunctions will be arranged and built accordingly.

Lecture #1

Prototyping ModelBuild prototypeUsersatisfactionYESNOUser feedback

Lecture #1

Benefits of PrototypingLearning by doingImproved communicationImproved user involvementClarification of partially-known requirements

Lecture #1

Prototyping SequencesRequirements gatheringQuick designPrototype constructionCustomer evaluationRefinementLoop back to quick design for fine tuningProduct engineering

Lecture #1

Benefits of PrototypingDemonstration of the consistency and completeness of a specificationReduced need for documentationReduced maintenance costsFeature constraintProduction of expected results

Lecture #1

Drawbacks of PrototypingUsers sometimes misunderstand the role of the prototypeLack of project standards possibleLack of controlAdditional expenseClose proximity of developers

Lecture #1

Forms of PrototypesMock-upsSimulated interactionPartial working model

Lecture #1

Incremental ModelBreak system into small componentsImplement and deliver small components in sequenceEvery delivered component provides extra functionality to user

Lecture #1

Incremental Model (contd)Requirements AnalysisArrange requirements in incrementsValidate incrementDesign and develop incrementIntegrate incrementYESNOSystemOK?

Lecture #1

Iterative ModelDeliver full system in the beginningEnhance functionality in new releases

Lecture #1

Iterative Model (contd)Develop system version nValidate system version nYESNODesign system version nSystemcomplete n = n+1

Lecture #1

Why Have Project Phases and Management Reviews?A project should successfully pass through each of the project phases in order to continue on to the nextManagement reviews (also called phase exits or kill points) should occur after each phase to evaluate the projects progress, likely success, and continued compatibility with organizational goals

Lecture #1

Distinguishing Project Life Cycles and Product Life CyclesThe project life cycle applies to all projects, regardless of the products being producedProduct life cycle models vary considerably based on the nature of the productMost large IT products are developed as a series of projectsProject management is done in all of the product life cycle phases

Lecture #1

Capability Maturity ModelThe CMM is a process model based on software best-practices effective in large-scale, multi-person projects.The CMM has been used to assess the maturity levels of organization areas as diverse as software engineering, system engineering, project management, risk management, system acquisition, information technology (IT) or personnel management, against a scale of five key processes, namely: Initial, Repeatable, Defined, Managed and Optimized.

Lecture #1

Level 1 - Initial

At maturity level 1, processes are usually ad hoc, and the organization usually does not provide a stable environment. Success in these organizations depends on the competence and heroics of the people in the organization, and not on the use of proven processes

Lecture #1

Level 2 - Repeatable

At maturity level 2, software development successes are repeatable. The processes may not repeat for all the projects in the organization. The organization may use some basic project management to track cost and schedule.

Lecture #1

Level 3 - Defined

The organizations set of standard processes, which are the basis for level 3, are established and improved over time. These standard processes are used to establish consistency across the organization. Projects establish their defined processes by applying the organizations set of standard processes, tailored, if necessary, within similarly standardized guidelines.

Lecture #1

Level 4 - Quantitatively Managed Using precise measurements, management can effectively control the software development effort. In particular, management can identify ways to adjust and adapt the process to particular projects without measurable losses of quality or deviations from specifications

Lecture #1

Level 5 - Optimizing

Maturity level 5 focuses on continually improving process performance through both incremental and innovative technological improvements. Quantitative process-improvement objectives for the organization are established, continually revised to reflect changing business objectives, and used as criteria in managing process improvement.

Lecture #1

International Organization for Standardization(ISO)12 Engineering ActivitiesSystems requirement analysisSystem architectural designSoftware requirement analysisSoftware architectural designSoftware detailed designSoftware coding and testingSoftware IntegrationSoftware qualification testingSystem integrationSystem qualification testingSoftware installationSoftware acceptance test

Lecture #1

Unit II

Domain Processes

Lecture #1

Scope Planning and the Scope StatementA scope statement is a document used to develop and confirm a common understanding of the project scope. It should includea project justificationa brief description of the projects productsa summary of all project deliverablesa statement of what determines project success

Lecture #1

Scope Planning and the Work Breakdown StructureAfter completing scope planning, the next step is to further define the work by breaking it into manageable piecesGood scope definitionhelps improve the accuracy of time, cost, and resource estimatesdefines a baseline for performance measurement and project controlaids in communicating clear work responsibilities

Lecture #1

The Work Breakdown StructureA work breakdown structure (WBS) is an outcome-oriented analysis of the work involved in a project that defines the total scope of the projectIt is a foundation document in project management because it provides the basis for planning and managing project schedules, costs, and changes

Lecture #1

WBSWBS was initially developed by the U.S. defense establishment, and it is described in Military Standard (MIL-STD) 881B (25 Mar 93) as follows: "A work breakdown structure is a product-oriented family tree composed of hardware, software, services, data and facilities .... [it] displays and defines the product(s) to be developed and/or produced and relates the elements of work to be accomplished to each other and to the end product(s)."

Lecture #1

Sample Intranet WBS Organized by Product

Lecture #1

Sample Intranet WBS Organized by Phase

Lecture #1

Intranet WBS in Tabular Form1.0 Concept1.1 Evaluate current systems1.2 Define Requirements1.2.1 Define user requirements1.2.2 Define content requirements1.2.3 Define system requirements1.2.4 Define server owner requirements1.3 Define specific functionality1.4 Define risks and risk management approach1.5 Develop project plan1.6 Brief web development team2.0 Web Site Design3.0 Web Site Development4.0 Roll Out5.0 Support

Lecture #1

Approaches to Developing WBSsUsing guidelines: Some organizations, like the DOD, provide guidelines for preparing WBSsThe analogy approach: It often helps to review WBSs of similar projectsThe top-down approach: Start with the largest items of the project and keep breaking them downThe bottoms-up approach: Start with the detailed tasks and roll them up

Lecture #1

Basic Principles for Creating WBSs*1. A unit of work should appear at only one place in the WBS.2. The work content of a WBS item is the sum of the WBS items below it.3. A WBS item is the responsibility of only one individual, even though many people may be working on it.4. The WBS must be consistent with the way in which work is actually going to be performed; it should serve the project team first and other purposes only if practical.5. Project team members should be involved in developing the WBS to ensure consistency and buy-in.6. Each WBS item must be documented to ensure accurate understanding of the scope of work included and not included in that item.7. The WBS must be a flexible tool to accommodate inevitable changes while properly maintaining control of the work content in the project according to the scope statement. *Cleland, David I. Project Management: Strategic Design and Implementation, 1994

Lecture #1

Scope Verification and Scope Change ControlIt is very difficult to create a good scope statement and WBS for a projectIt is even more difficult to verify project scope and minimize scope changesMany IT projects suffer from scope creep and poor scope verification

Lecture #1

Factors Causing IT Project Problems**Johnson, Jim, "CHAOS: The Dollar Drain of IT Project Failures," Application Development Trends, January 1995, www.stadishgroup.com/chaos.html

Lecture #1

Factor

Rank

Lack of user input

1

Incomplete requirements and specifications

2

Changing requirements and specifications

3

Lack of executive support

4

Technology incompetence

5

Lack of resources

6

Unrealistic expectations

7

Unclear objectives

8

Unrealistic time frames

9

New Technology

10

Suggestions for Improving User InputInsist that all projects have a sponsor from the user organizationHave users on the project teamHave regular meetingsDeliver something to project users and sponsor on a regular basisCo-locate users with the developers

Lecture #1

Suggestions for Reducing Incomplete and Changing RequirementsDevelop and follow a requirements management processEmploy techniques such as prototyping, use case modeling, and Joint Application Design to thoroughly understand user requirementsPut all requirements in writing and currentCreate a requirements management databaseProvide adequate testingUse a process for reviewing requested changes from a systems perspectiveEmphasize completion dates

Lecture #1

Unit III

Software Development

Lecture #1

Software Size and Reuse Estimating

Lecture #1

Software Size and Reuse Estimating

Lecture #1

Predicting the size of a software system becomes progressively easier as the project advancesAt no other time are the estimates so important than at the beginning of a project

Lecture #1

Product Development Life CycleEstimating size and effort will occur many times during the life cycleAfter requirements, after analysis, after design, and so on...

Lecture #1

Learning ObjectivesExplain why the sizing of software is an important estimating techniqueDescribe how Work Breakdown Structure can be used to estimate software sizeList, explain and describe several models used to estimate sizeSummarize the advantages and disadvantages of the modelsExplain the impact of reused software components upon the size estimate

Lecture #1

Problems with EstimatingProblem is not well understoodLittle or no historical dataNo standardsManagement uses estimates as performance goalsDevelopers are optimisticCustomer demands quick estimatesetc...

Lecture #1

Risks of EstimatingIf incomplete or incorrect estimate:disappointing the customerpossibly losing future businesstoo optimistic fixed-price contract result in the contractor losing money and losing face

Lecture #1

How to tackle size-related risksProduce a WBS, decomposed to the lowest level possible smaller is easier to estimateReview assumptions with all stakeholdersResearch past organizational experiences and historical dataStay in close communication with other developers, common languageUpdate estimatesUse many size estimating methodsEducate staff in estimation methods

Lecture #1

Getting StartedSizing is the prediction of product deliverables needed to fulfill requirementsEstimation is the prediction of effort needed to produce the deliverablesWBS is a description of the work to be performed, broken down into key elementsWBS is our TOC, a hierarchical list of the work activities required to complete a projectChoose a method and stick with itCompare actual data to planned estimatesEverything should be counted, any observable physical piece of software

Lecture #1

Size measuresLines of Code (LOC)Function PointsFeature PointsObject PointsModel BlitzWideband Delphi

Lecture #1

Lines of CodeVery difficult to know how many LOC will be produced before they are written or even designedLOC measure has become infamousStill the most used metricAverage programmer productivity rate remains despite of new languagesFunctionality and quality are the real concerns, not the LOC

Lecture #1

Lines of Code 2WBS should be decomposed to the lowest level possibleEstimating using expert opinions, asking experts who have developed similar systemsEstimating using Bottom-Up summing, asking developers to estimate the size of each decomposed levelAsk for an optimistic (200), pessimistic (400) and realistic size (250) estimate (200+400+(4*250)) / 6 = 266 LOCWhat exactly is a line of code? Standards and rules needed

Lecture #1

Lines of Code 3Translate the number of LOC to assembly language line in order to make comparisons between programming languagese.g. convert 50,000 LOC system written in C to Java Assembler level for C = 2.5, Java = 6 50,000 * 2.5 = 125,000 if written in assembler 125,000 / 6 = 20,833 LOC if written in Java

Lecture #1

Advantages of LOCWidely used and acceptedAllows for comparison between diverse development groupsDirectly relates to the end productEasily measured upon project completionMeasure from the developers point of viewContinuous improvement

Lecture #1

Disadvantages of LOCDifficult to estimate early in the life cycleSource instructions variate with language, design, programmer etc.No industry standars for counting LOCFixed costs are not included with codingProgrammers may be rewarded for large LOC countsDistinguish between generated code and hand-crafted codeCan not be used for normalizing if languages are differentOnly existing products and expert opinions can be used to predict a LOC count

Lecture #1

Function PointsIdea: software is better measured in terms of the number and complexity of the functions that it performsFunction points measure categories of end-user business functions

Lecture #1

Function Point Process StepsCount number of functions in each category (outputs, inputs, interfaces etc..)Apply complexity weighting factors (simple, medium, complex)Apply environmental factorsCalculate complexity adjustment factorCompute adjusted function pointsConvert to Lines of Code (optional)

Lecture #1

Advantages of Function Point AnalysisCan be applied early in the life cycleIndependent of language and technologyProvide a reliable relationship to effortCan be used as a productivity goalUsers understand betterProvide a mechanism to track and monitor scopeEnvironmental factors are considered

Lecture #1

Disadvantages of Function Point AnalysisRequires subjective evaluationsResults depend on technology used to implement the analysisMany effort and cost models depend on LOC, must be convertedBest after the creation of a design specificationNot good to non-MIS applications

Lecture #1

Feature PointsExtension of the function point methodDesigned to deal with different kinds of applications, like embedded or real-time systemsA feature point is a new category of function point that represent complex algorithms

Lecture #1

Areas where Feature Points are used RTS such as missile defense systemsSystem softwareEmbedded Systems like radar navigation packagesCAD & CAM

Lecture #1

Feature Point Process StepsCount number of feature points in each categoryCount feature points (algorithms)Weigh Complexity (avg for feature points, simple/avg/complex for algorithms)Evaluate environmental factorsCalculate complexity adjustment factorAdjust feature pointsConvert to LOC (optional)

Lecture #1

Advantages of Feature Point AnalysisSame as in function point analysisAdditional advantage for algorithmically intensive systems

Lecture #1

Disadvantages of Feature Point AnalysisPrimary disadvantage:subjective classification of algorithmic complexity

Lecture #1

Object PointsMethod developed for object-oriented technologyCounting object points to determine software sizeConducted at a more macro level than function pointsAssigns one object point to each unique class or objectOtherwise similar to function and feature points

Lecture #1

Model BlitzEstimating gets better with each passing phaseConcept of blitz modelling is counting number of process (object classes) * number of programs per class * avg program size = Estimated size (LOC)A historical database is essentialFunction-strong systems and data-strong systems are calculated separately

Lecture #1

Contd20 object classes implemented to 5 procedural programs & on an avg 75 LOC per procedural prgNo. of Process X no. of programs per class X Avg Prg Size = Estimated Size20 X 5 X 75 = ?7500 LOC

Lecture #1

Advantages of Model BlitzEasy to use with structured methods and with object-oriented classesAccuracy increases with historical dataContinuous improvement activities used for estimation techniques

Lecture #1

Disadvantages of Model BlitzRequires use of design methodologyEstimation can not begin until design is completeRequires historical dataDoes not evaluate environmental factors

Lecture #1

Wideband DelphiPopular and simple technique to estimate size and effortGroup consensus approachUses experience of several people to reach an estimate

Lecture #1

Wideband Delphi stepsPresent experts with the problem and a response formGroup discussionCollect opinions anonymouslyFeed back a summary of resultsAnother group discussionIterate until consensus

Lecture #1

Advantages of Wideband DelphiEasy and inexpensiveExpertise of several peopleParticipants become better educated about the software and projectDoes not require historical dataUsed for high-level and detailed estimationResults more accurate than in LOC

Lecture #1

Disadvantages of Wideband DelphiDifficult to repeat with different group of expertsPossible to reach consensus on an incorrect estimate, people may not be skeptical enoughCan develop a false sense of confidenceMay fail to reach a consensusExperts may be biased in the same subjective direction

Lecture #1

Effects of Reuse on Software SizeMany softwares are derived from previous programsResult in savings of cost and time, increased qualityCan also cost more, take longer time and yield lower qualityFirst step in code reuse is to separate new code from modified and reused code

Lecture #1

Effects of Reuse continuesIf the unit has changed, it is modifiedIf more than 50% of the unit is changed, it is considered to be newReused code will be converted to equivalent new codeConversion factor reflects the amount of effort saved by reuseReuse factors come from experience (e.g. 30% for reused, 60% for modified)Can also be done on more accurate level

Lecture #1

Unit IV

Scheduling Activities

Lecture #1

Project management resource activities.

Project management resource activities.

Project management resource activities.

Inference management is the process of managing all the different interfaces with other people and groups related to the product and the project, it includes identifying, documenting, scheduling, communicating, and monitoring these interfaces throughout the course of project.

Lecture #1

Kinds of interfaces:

Personal Organizational System

Lecture #1

PERSONALIt deals with all conflicts involving people in or related to the project. ORGANIZATIONALIt deals with conflicts due to varying organizational goals and the different management styles of the project and resource supplying organizations. SYSTEM It deals with the product, facility, or other non people interfaces developed by the project.

Lecture #1

Organizational structure:

"An organization is a system that exchanges materials, personnel, manpower, and energy with the environment

Lecture #1

TYPES OF ORGANIZATIONS:

Functional organizations Matrix organizations

Projectized organizations Combination of all the above

Lecture #1

FUNCTIONAL ORGANIZATIONSThe functional organization is a standard old-fashioned organization. It is the style in which people are divided into their functional specialties and report to a functional area manager.

Lecture #1

MATRIX ORGANIZATIONS In the matrix organizations there is a balance of power established between the functional and project managers. The project worker in a matrix organization has a multiple command system of accountability and responsibility.

Lecture #1

PROJECTIZED ORGANISATIONS:

In projectized organizations the project manger has total authority and acts like a mini-CEO. All personnel assigned to the project report to project manager.

Lecture #1

Software development dependencies "Dependencies are any relationship connections between activities in a project that may impact their scheduling".

Lecture #1

External vs Internal Dependencies Resource vs Activity Dependencies

Lecture #1

DEPENDENCY RELATIONSHIPS: Finish-to-start(FS) Start-to-start(SS) Finish-to-finish(FF) Start-to-finish(SF)

Lecture #1

Scheduling fundamentals:

The three most common forms of presenting a project schedule are: Table. Gantt chart. Network diagram.

Lecture #1

Critical Path Method (CPM)CPM is a project network analysis technique used to predict total project durationA critical path for a project is the series of activities that determines the earliest time by which the project can be completedThe critical path is the longest path through the network diagram and has the least amount of slack or float

Lecture #1

Finding the Critical PathFirst develop a good project network diagramAdd the durations for all activities on each path through the project network diagramThe longest path is the critical path

Lecture #1

Simple Example of Determining the Critical PathConsider the following project network diagram. Assume all times are in days.a. How many paths are on this network diagram? b. How long is each path? c. Which is the critical path? d. What is the shortest amount of time needed to complete this project?

Lecture #1

Determining the Critical Path for Project X

Lecture #1

More on the Critical PathIf one of more activities on the critical path takes longer than planned, the whole project schedule will slip unless corrective action is takenMisconceptions:The critical path is not the one with all the critical activities; it only accounts for timeThere can be more than one critical path if the lengths of two or more paths are the sameThe critical path can change as the project progresses

Lecture #1

Using Critical Path Analysis to Make Schedule Trade-offsKnowing the critical path helps you make schedule trade-offsFree slack or free float is the amount of time an activity can be delayed without delaying the early start of any immediately following activitiesTotal slack or total float is the amount of time an activity may be delayed from its early start without delaying the planned project finish date

Lecture #1

Techniques for Shortening a Project ScheduleShortening durations of critical tasks for adding more resources or changing their scopeCrashing tasks by obtaining the greatest amount of schedule compression for the least incremental costFast tracking tasks by doing them in parallel or overlapping them

Lecture #1

Importance of Updating Critical Path DataIt is important to update project schedule informationThe critical path may change as you enter actual start and finish datesIf you know the project completion date will slip, negotiate with the project sponsor

Lecture #1

Critical Chain SchedulingTechnique that addresses the challenge of meeting or beating project finish dates and an application of the Theory of Constraints (TOC)Developed by Eliyahu Goldratt in his books The Goal and Critical ChainCritical chain scheduling is a method of scheduling that takes limited resources into account when creating a project schedule and includes buffers to protect the project completion dateCritical chain scheduling assumes resources do not multitask because it often delays task completions and increases total durations

Lecture #1

Multitasking Example

Lecture #1

Buffers and Critical ChainA buffer is additional time to complete a taskMurphys Law states that if something can go wrong, it will, and Parkinsons Law states that work expands to fill the time allowed. In traditional estimates, people often add a buffer and use it if its needed or notCritical chain schedule removes buffers from individual tasks and instead createsA project buffer, which is additional time added before the projects due dateFeeding buffers, which are addition time added before tasks on the critical path

Lecture #1

Program Evaluation and Review Technique (PERT)PERT is a network analysis technique used to estimate project duration when there is a high degree of uncertainty about the individual activity duration estimatesPERT uses probabilistic time estimates based on using optimistic, most likely, and pessimistic estimates of activity durations

Lecture #1

PERT Formula and ExamplePERT weighted average formula: optimistic time + 4X most likely time + pessimistic time6Example:PERT weighted average = 8 workdays + 4 X 10 workdays + 24 workdays = 12 days6where 8 = optimistic time, 10 = most likely time, and 24 = pessimistic time

Lecture #1

Controlling Changes to the Project SchedulePerform reality checks on schedulesAllow for contingenciesDont plan for everyone to work at 100% capacity all the timeHold progress meetings with stakeholders and be clear and honest in communicating schedule issues

Lecture #1

Working with People IssuesStrong leadership helps projects succeed more than good PERT chartsProject managers should useempowermentincentivesdisciplinenegotiation

Lecture #1

Using Software to Assist in Time ManagementSoftware for facilitating communications helps people exchange schedule-related informationDecision support models help analyze trade-offs that can be madeProject management software can help in various time management areas

Lecture #1

Words of Caution on Using Project Management SoftwareMany people misuse project management software because they dont understand important concepts and have not had good trainingYou must enter dependencies to have dates adjust automatically and to determine the critical pathYou must enter actual schedule information to compare planned and actual progress

Lecture #1

Lecture #1

Lecture #1

Lecture #1

Lecture #1

Unit VQuality Assurance

Lecture #1

Integrated Change ControlIntegrated change control involves identifying, evaluating, and managing changes throughout the project life cycle (Note: 1996 PMBOK called this process overall change control)Three main objectives of change control:Influence the factors that create changes to ensure they are agreed uponDetermine that a change has occurredManage actual changes when and as they occur

Lecture #1

Integrated Change ControlIntegrated change control requiresMaintaining the integrity of the performance measurement baselineEnsuring that changes to the product scope are reflected in the definition of the project scopeCoordinating changes across the knowledge areas

Lecture #1

Integrated Change Control -- CoordinationCoordinating changes Across the Entire Project

Lecture #1

Change Control on Information Technology ProjectsFormer view: The project team should strive to do exactly what was planned on time and within budgetProblem: Stakeholders rarely agreed up-front on the project scope, and time and cost estimates were inaccurateModern view: Project management is a process of constant communication and negotiationSolution: Changes are often beneficial, and the project team should plan for them

Lecture #1

Integrated Change Control -- Process

Lecture #1

Integrated Change Control Process

Lecture #1

Change Control SystemA formal, documented process that describes when and how official project documents and work may be changedDescribes who is authorized to make changes and how to make themOften includes a change control board (CCB), configuration management, and a process for communicating changes

Lecture #1

Change Control Boards (CCBs)A formal group of people responsible for approving or rejecting changes on a projectProvides guidelines for preparing change requests, evaluates them, and manages the implementation of approved changesIncludes stakeholders from the entire organization

Lecture #1

Making Timely ChangesSome CCBs only meet occasionally, so it may take too long for changes to occurSome organizations have policies in place for time-sensitive changes48 hour policy allowed project team members to make decisions, then they had 48 hours reverse the decision pending senior management approvalDelegate changes to the lowest level possible, but keep everyone informed of changes

Lecture #1

Configuration ManagementEnsures that the products and their descriptions are correct and completeConcentrates on the management of technology by identifying and controlling the functional and physical design characteristics of products Configuration management specialists identify and document configuration requirements, control changes, record and report changes, and audit the products to verify conformance to requirements

Lecture #1

Suggestions for Managing Integrated Change ControlView project management as a process of constant communications and negotiationsPlan for changeEstablish a formal change control system, including a Change Control Board (CCB)Use good configuration managementDefine procedures for making timely decisions on smaller changesUse written and oral performance reports to help identify and manage changeUse project management and other software to help manage and communicate changes

Lecture #1

Reduced maintenance costs in the sense that users are less likely to ask for changes after the system goes into its operation. However, when asked for changes, the system is difficult to maintain because the software is usually not well structured.