ISM 5316 Week 3 Learning Objectives You should be able to: Define and list issues and steps in Project Integration List and describe the components of a Project Plan Explain the purposes of a Project Plan Develop and document a Project Plan Describe Project Plan inputs, outputs, and issues Describe the purpose and components of a Change Control System Explain the critical need for top management commitment in development and execution of a Project Plan Project Integration Develop a project plan Execute the plan Coordinate changes Integrate all project processes within organizational context with other projects with on-going operations interface management: communication! Purpose of the Project Plan Guides project execution Guides project control Documents assumptions Documents decisions Facilitates stakeholder communication Serves as baseline for progress measurement Produce quality work results Project Plan Inputs Uses outputs from other planning processes Cost, Uses schedule, WBS, etc. historical data from past projects estimated Uses vs. actual time, cost, risk, etc. organizational policies (formal, informal) quality, personnel, financial Constraints: factors that limit options Assumptions: involve uncertainty, risk Project Planning Outputs Project Plan: • formal, approved document • expected to change over time Charter Milestones Approach Cost Scope WBS Staff Risks estimates Performance measures Open issues Supporting details technical documentation, etc. Main Elements In a Project Plan Introduction/Overview Project Organization Managerial Process Technical Process Work packages, schedule, budget The Plan should be: Dynamic, flexible, subject to change Tailored to fit the project’s needs Overview Meaningful, distinct name Brief description: needs met and goals Sponsor PM, key team members: contact info. Deliverables Supporting documents (reference materials) history, List summaries of scope, schedule, cost, etc. of definitions and acronyms - glossary Project Organization Organization chart(s) lines of authority and communication Boundaries and interfaces Responsibilities Process model for project functions Management & Technical Processes Management’s assumptions, objectives priorities, constraints Controls: monitoring change Risk management management Staffing Technical processes and methods Work to be Done Work packages (logical units of work) WBS: work breakdown structure Key deliverables formal specifications, if relevant Schedule summary and detailed Budget summary Supporting and detailed information Stakeholder Analysis Help understand and meet stakeholder needs Separate document sensitive Each - intended only for project team stakeholder: Name, organization, role, facts Level of interest Level of influence Suggestions for managing relationship Planning Issues Those who do the work should plan the work Project managers should lead by example importance of the Plan and planning follow-through using the Plan Organizational link policies and procedures between planning and execution Management leadership, Product skills negotiation, communication knowledge provided through staff acquisition Tools for Project Planning Work authorization system right people do right work at right time written approval to begin specific activity Regular status review meetings exchange project information motivation to progress verbal vs. written better motivation PMIS: Project Management Information System integration of project information Overall Change Control Identify, evaluate, and manage change Ensure that changes are beneficial Must monitor status to identify change Take corrective actions anything done to bring expected performance in line with the project plan Notify stakeholders Minimize changes that occur Change Control Process Outputs: Inputs: project plan updates corrective action documentation of lessons learned project plan performance reports change requests Change control process Change Control System Formal, documented procedures Define steps by which documents may be changed Documentation Tracking Approval Automatic CCB: approval categories Change Control Board formal approval Change Request Form (database) Unique number, name Description of change Business justification Business impact assessment Technical impact assessment Status Scheduled integration, if needed Dates of status changes Responsible staff Change Request Process 1. Log request 2. Business assessment Determine affected user areas 3. Technical assessment Determine affected technical areas 4. Determine appropriate approval level 5. Notify requesters of decision 6. Advise affected external groups 7. Pass change to technical team 8. Alter deliverables Software Configuration Management Configuration named baseline set of software components Change: new feature defect resolution performance enhancement Change request vs. defect report Software Change Order (SCO) Title Description Metrics: type of change Resolution: responsible person Assessment: inspection, demo, or test Disposition: proposed, accepted, rejected archived, in-progress, closed SCO Component Title Description Examples Description Originator, Date, ID Text details Metrics Type of change Resolution Responsible person Software Component Assessment Method for assessing change completion Inspection Analysis Demonstration Test Disposition Status of change Proposed Accepted Rejected Archived In progress In assessment Closed Originator suggested, CCB approved New feature Defect resolution Performance enhancement Managing Project Changes View Project Management as continuous Plan communication and negotiation for change Formal change control system (CCS), board (CCB) Configuration management Prioritize changes Written and oral performance reports PMIS Software Project Changes Minimize changes by: complete requirements definition user involvement short project duration Spiral approach: iterative refinement Top Management Commitment Reflects overall organization commitment Get needed resources Get timely approval Cross-organization cooperation Mentoring and coaching on leadership Commitment to Information Technology Need for Project Management standards