1 Agile Project Management Jan Pool NioCAD University of Stellenbosch 16 April 2008
2 Introduction Objective: Introduce a general Agile Project Management framework. Target Audience: Product, program and project managers. R&D executives. Product development teams. Disclaimer: APM is not the best suited approach for all projects. Remember No Silver Bullets Frederick P. Brooks.
3 Sources Primary source: Agile Project Management Creating Innovative Products: Jim Highsmith ISBN-10: Cost about $40 at Amazon. Secondary sources: Project Management Body Of Knowledge, 3 rd Ed. (PMBOK): Project Management Institute ISBN-10: X Cost about $30 at Amazon. Personal experience.
4 Product Development Environment Lots of new products on the market. Software, consumer electronics, vehicles, clothing, furniture, pharmaceuticals, consumer food products, etc. New products appear frequently. Organisations need to constantly innovate to stay competitive. New or improved product offerings. Markets may change quickly. Organisations must keep pace with change. Cost of product development is decreasing. People s attitude towards work is changing. A landscape of opportunity, uncertainty and risk.
5 Product Development Environment Linear thinking, prescriptive processes and enforced practices struggle in the new environment. The classic Plan-Do PM methodology cannot keep pace and needs to be adapted. Evolutionary lesson If the environment change, your strategy must change as well. A mindset change is required.
6 Exploratory Process An exploratory process is more suitable. Focus change from anticipation (define, design, build) to adaptation (envision, explore, adapt). Keys to reliable innovation: Continuous innovation. Current requirements. Product adaptability. Future requirements. Reduced delivery schedule. Market window and better ROI. People and process adaptability. Product and business change. Reliable results. Growth and profitability. Agile Project Management is one such methodology.
7 Agile Principles Agile Manifesto Individuals and interactions over processes and tools. Working [products] over comprehensive documentation. Customer collaboration over contract negotiation. Responding to change over following a plan. While there is value in the items on the right, we value the items in the left more. Adapted from by J. Highsmith. Software replaced with products.
9 APM Framework People are more important than processes, but processes are still important. Processes do not need to be static and prescriptive. Process improvement does not have to mean rigid standardisation and certification. Process must be coupled with business objectives. Repeated manufacturing -> Prescriptive. Reliable innovation -> Flexible. Follow agile values and principles and derived practices.
10 APM Framework Qualities Support an envision, explore adapt culture. Support self-organising, self-disciplined teams. Promote reliability and consistency to the extent possible given the level of project uncertainty. Be flexible and easy to adapt. Support visibility into the process. Incorporate learning. Incorporate practices and support each phase. Provide management checkpoints for review. Verbatim from APM pg. 80.
11 APM Framework - Phases Phase: Envision Product vision and scope. Project community and team collaboration. Phase: Speculate Feature analysis. Feature based iteration, milestone and release plans. Phase: Explore Deliver features in short time-boxed iterations. Phase: Adapt Review results, team performance and current needs. Adaptive action. Phase: Close Conclude project and share knowledge outside project team. Celebrate. Compare with this with classic PM model: Initiate, Plan, Manage, Control.
12 APM Framework Phase Diagram Envision Speculate Explore Adapt Close
13 Envision Phase Objectives: Defining product vision and objectives. Vision bounds exploration. Scope and constraints. Participants. Development approach. Market and feasibility studies as starting point.
14 Envision Phase - Practices Product vision: Product vision box and elevator statement. Product architecture and guiding principles. Project scope: Project data sheet. Project community: Get the right people. Participant identification. Customer team-developer team interface. Approach: Process and practice tailoring.
15 Envision Phase Practice 1 Practice: Product vision box and elevator test statement. Help product team to create a concise shared vision. Whole product team should participate. Vision box: Product name. Key selling points. Detailed features. Operating requirements. Graphics. Elevator test statement: Sell product in less than two minutes. For (target customer) Who (statement of need or opportunity) The (product name) is a (product category) That (key benefit, compelling reason to buy) Unlike (primary competitive alternative) Our product (statement of primary differentiation)
16 Envision Phase Practice 2 Practice: Product architecture. Internal plumbing of the project. Platform, components, interfaces. Use Feature Breakdown Structure (FBS) to provide a high-level architectural view. Architecture and team structure should coevolve. Define a set of guiding principles.
17 Envision Phase Practice 3 Practice: Project data sheet. Single page summary of scope, schedule and resources. Client or customers. Project manager. Product manager. Project objective statement. Trade-off matrix. Exploration factor. Delay cost. Key features. Client benefit. Performance and quality attributes. Key architectural components. Issues/risks.
18 Envision Phase Practice 4 Practice: Get the right people. Appropriate technical capability. Self-discipline. Process is less important than people.
19 Envision Phase Practice 5 Practice: Participant identification. Identify all participants and their roles. Customers Provide requirements. Project team Develop product. Stakeholders Contribute constraints. Critical Critical to success. Essential Can delay project. Nonessential Interested parties. List of participants can include: Executive sponsor, project manager, product manager, lead engineer, management, customer team, project team, suppliers, government.
20 Envision Phase Practice 6 Practice: Customer team-developer team interface. Define the collaboration interface between the customer team and the developer team. Information flow and channels. Accountability and responsibility. Distinguish between product and project manager. Face-to-face interactions are more valuable than documentation.
21 Envision Phase Practice 7 Practice: Process and practice tailoring. Tailor a process and practices framework that defines the team s approach. Team must agree on an approach and follow it. Start with organisation s standard approach. What process and practices to use? What additional practices to use? Which ones should be modified? What level of formality is required? Process and practices might evolve during project.
22 Speculate Phase Objectives: Determine product features and constraints. Create release, milestone and iteration plans. Employ short time-boxed iterations. Feature based development. Product managers control features. Developers control design and implementation. Plans are speculative and will change.
24 Speculate Phase Practice 8 Practice: Product feature list. Create a feature list, starting with the vision. A feature is a piece of product that delivers some useful and valuable functionality. Evolutionary process. Organise as a hierarchy. Product, component, group, feature. Product, business subject area, business activity, feature. Prioritise features.
25 Speculate Phase Practice 9 Practice: Feature cards. Record basic feature information, high-level requirements and work estimates. Identify features, do not define. Discuss features in detail with customer teams. Items that can be on a feature card: Feature identifier and name. Feature description. Feature type. Estimated work effort. Requirements uncertainty. Feature dependencies. Acceptance tests. Use the back of cards to record technical activities.
26 Speculate Phase Practice 10 Practice: Performance requirements cards. Record the key operation and performance requirements. Items that can be on a performance card: Performance identification and name. Performance description. Difficulty in achieving. Acceptance tests.
27 Speculate Phase Practice 11 Practice: Release, milestone and iteration plan. These plans present a roadmap of how the team will implement the product vision. Base plans on Feature Breakdown Structures (FBS) instead of Work Breakdown Structures (WBS). Three levels of plans: Releases, milestones and iterations. Plans should focus on: Delivering value to customers. Reducing risks.
28 Speculate Phase Practice 11 Iteration 0: Use in larger projects to allow more time for planning. Iteration 1-N: Decided on iteration, milestone and release periods. Iterations should have themes to focus the team. Assign features to iterations. Incorporate schedule and resource constraints. Focus on highest value or risky features first. Larger projects can use component level planning.
29 Speculate Phase Practice 11 How much to plan? Complete plan. Two iteration plan: next and everything after. Iteration-by-iteration. In all cases, the next iteration should always be planned in more detail by the team. Determine first feasible deployment date. Plan and prepare for deployment. Use continuous integration early in project life.
30 Speculate Phase Practice 11 Estimation. Use standard techniques. Estimate by feature, not activity. How do you estimate the unknown? Use progressive estimation. Scope evolution. Scope change is inevitable in exploration projects. Manage scope creep. All parties must be aware of scope creep implications. Risk analysis and management should be part of plan. Adapt plans to address risks.
31 Explore Phase Objectives: Deliver high-value customer features. Utilise low-cost change technical practices. Develop an adaptive, collaborative project community. Project manger s duties: Help team to articulate and understand goals and constraints. Help team to interact effectively. Facilitate decision making process. Develop team members. Ensure appropriate feedback is gathered and incorporated. Track progress and deal with reality when things get off track.
32 Explore Phase - Practices Deliver on vision and objectives: Workload management. Technical practices: Low-cost change. Project community: Coaching and team development. Daily team integration meetings. Participatory decision making. Daily integration with the customer team.
33 Explore Phase Practice 12 Practice: Workload management. Team manages day-to-day activities. Team members should be self-disciplined and accountable. Project manager should monitor progress and provide guidance. Avoid micro-management! This requires a person with sufficient technical knowledge.
34 Explore Phase Practice 13 Practice: Low-cost change. Reduce the cost of iterative development. Keep the cost of change and experimentation at a minimum. Technical debt must be met. Minimise it. Simple design. Frequent integration. Ruthless testing. Opportunistic refactoring.
35 Explore Phase Practice 14 Practice: Coaching and team development. Unleash the team s capabilities by helping each team member to continuously improve. Get the right people. Focus on delivering results. Move from individuals to a team. Trust, respect and privacy. Interaction and equal contribution. Attach issues not persons. Develop individuals capabilities. Provide team with adequate resources. Customers also needs coaching. Manage team rhythm.
36 Explore Phase Practice 15 Practice: Daily team integration meetings. Coordinate team member activity daily. Raise issues, but do not discuss solutions. PM should address. Short meetings attended by all team members. Three questions: What did you do yesterday? What are you planning to do today? What impediments do you face? Team should determine if the daily meetings are valuable.
37 Explore Phase Practice 16 Practice: Participatory decision making. Provide a framework to frame, make and analyse decisions. Effective decision making is a hallmark of effective teams. Frame issues. Impact of decisions? Who should provide input or be involved in discussion? Who will make the decision? Decision criteria? Decision communication: to whom and how? Who will review the decision?
38 Explore Phase Practice 16 Making the decision. Collaborate - win-win outcomes. Allow discussion to diverge first to spread views, but steer towards convergence. Set deadlines for decisions. Once consensus has been reached and a decisions was made, everyone should be committed to implementing it. Review decisions. Learn not blame. Share experience in team and organisation. Self-organisation vs. decisions by leaders. Multiple scenarios and delayed decision making. Toyota s set-based concurrent engineering (SBCE).
39 Explore Phase Practice 17 Practice: Daily integration with the customer team. Ensures the development team stays in touch with customer needs. Typically interact with one person: Product Manager. Discuss requirements, risks, tradeoffs, etc. Do not wait for iteration reviews to speak to customers. Might be a difficult practice to follow strictly.
40 Adapt Phase Feedback: Progress. Technical risks. Requirements evolution. Market related risks: Still competitive? Evaluate: Functionality. Quality. Team performance. Project status.
41 Adapt Phase Questions to ask: Are customers getting value for money? Is the project progressing satisfactorily? Is the project team adapting effectively to changes imposed by management, customers or technology? Adaptive action, not corrective action.
42 Adapt Phase Practice 18 Practice: Product, Project, and Team Review and Adaptive Action. The objectives are: To reflect, learn and adapt. Allow the team to change pace for a while.
43 Adapt Phase Practice 18 Customer focus groups. Demonstrate completed functionality to customer team. Sessions: Facilitated. Small customer group. Review product, not documentation. Focus on changes, not detailed requirements. Wider customer audience, more view points. Form of acceptance test, wider than system. Record change requests. Build customer-development team relationship. Changes are reviewed by development team after session. Feedback to customers only later.
44 Adapt Phase Practice 18 Technical review. Happens continuously during iteration. Scheduled reviews: Facilitated. Small group of competent developers. Review product, selected documentation and statistics. Look at technical issues, design and architecture.
45 Adapt Phase Practice 18 Team performance evaluation. Questions: What went well? What didn t go so well? How do we improve the next iteration? What don t we understand? Team self-assessment. Performance. Behaviour. Evaluate processes and practices.
46 Adapt Phase Practice 18 Scope and value status. Measure features completed per iteration. What is the financial value of the features delivered? Schedule status. Determine the expected time to project completion. Determine shortest, probable and latest completion dates. Constant variance over time means risks and uncertainty is not sufficiently managed.
47 Adapt Phase Practice 18 Cost and resource status. Use organisation s accounting system if not too heavyweight. Determine the expected cost to complete project. Quality status. Use existing quality measures. Proportion of code tested. What is the team s assessment?
48 Adapt Phase Practice 18 Project team information. Share key project information with the team. Visual. Prominent. Concentrate on vision, scope and issues/risks. Adaptive action. Minor tweaks. Update iteration and delivery plans. Technical, resource and schedule adjustments. Management focus: Delivering value. Reduce risks.
49 Close Practice 19 Practice: Close Celebration! Show appreciation to the team. Closure: Indicates project completion. Cleanup open items. Organisational knowledge transfer. Project retrospective.
50 Final Comments APM is a good approach for exploration projects, such as new product development. APM can be applied to general product development, not just software. Be pragmatic, adapt processes and practices to project and organisation s needs. Try APM on smaller projects first.
Agile Project Management Jim Highsmith Chapter 5 An Agile Project Management Model We improve effectiveness and reliability through situationally specific strategies, processes, and practices. One of the
Integrating Scrum with the Process Framework at Yahoo! Europe Karl Scotland Yahoo! Europe email@example.com Alexandre Boutin Yahoo! International firstname.lastname@example.org Abstract Large enterprise
Scrum Is Not Just for Software A real-life application of Scrum outside IT. Robbie Mac Iver 2/9/2009. Agile methods like Scrum can be applied to any project effort to deliver improved results in ever evolving
AGILE FOUNDATION CERTIFICATE SAMPLE FOUNDATION QUESTIONS WITH ANSWERS This document is a set of sample questions, in the style of the Agile Foundation Certificate Examination, which is a 60 question, 1
Introductory Certificate The APM Project Fundamentals Qualification. Examination paper Candidate Number Date Location Examination Paper Sample Paper v1.4 General Notes Time allowed 1 hour. Answer all 60
Agile-Waterfall Hybrid Jessica LaGoy, MS, PMP About Jess BS Applied Physics, WPI / MS Cybersecurity, UMUC PMP, ITIL, Data Scientist, Tableau, Alteryx Project Experience Data and technology Construction
Rally Software Development Corporation Whitepaper Mastering the Iteration: An Agile White Paper Dean Leffingwell Abstract: The heartbeat of Agile development is the iteration the ability of the team to
Agile Software Development 7 Steps to Successful Projects 2012 Kynetix Technology Group INTRODUCTION Many organisations adopt an Agile approach to software development and later wonder why applications
The Basics of Scrum An introduction to the framework Introduction Scrum, the most widely practiced Agile process, has been successfully used in software development for the last 20 years. While Scrum has
Agile Project Management Jim Highsmith Chapter 1 The Agile Revolution Ultimate customer value is delivered at the point-of-sale, not the point-of-plan The key opportunity, uncertainty, and risk resides
Agile Project Management By Mark C. Layton Agile project management focuses on continuous improvement, scope flexibility, team input, and delivering essential quality products. Agile project management
Agile and PRINCE2 And how they integrate enterprise.bcs.org 02 Agile and PRINCE2 And how they integrate Introduction Within the world of method frameworks it is very easy to become polarised on one specific
D25-2 Agile and Scrum Introduction How to Use this Download This download is an overview of a discussion Intertech has with clients on Agile/Scrum This download has an overview of Agile, an overview of
Scaling Scrum Colin Bird & Rachel Davies Scrum Gathering London 2007 Scrum on a Slide Does Scrum Scale? Ok, so Scrum is great for a small team but what happens when you have to work on a big project? Large
04_Highsmith.qxd 3/1/04 5:47 PM Page 77 Chapter 4 An Agile Project Management Model Principles and Practices Hi, Maya, it s Herman. Hi, dude, how s your project going? asked Maya. Pretty well. Things are
Introduction to Agile Scrum by Julia M. Lobur Penn State Harrisburg CMPSC 487W Fall 2015 Introduction to Scrum Learning Goals Relationship of Scrum to other Agile methods Scrum Framework Scrum Roles Scrum
Project Management: PMBOK and more MIEIC, Laboratório de Gestão de Projectos Ademar Aguiar FEUP, Universidade do Porto http://www.fe.up.pt/~aaguiar/ email@example.com FEUP Ademar Aguiar MIEIC/LGPR,
Delivering Successful Projects, Tom Moriarty, MDR Consulting This paper outlines the critical requirements of success in managing projects of all types from the definition of a business need to the delivery
Rolling Wave Planning: Manage Projects Without Going Under Rolling Wave Planning: Manage Projects Without Going Under W. Charles Slaven MBA PMP CSSBB CPA (inactive) Director, Lean Deployment and Continuous
WHY DO I NEED A PROGRAM MANAGEMENT OFFICE (AND HOW DO I GET ONE)? Due to the often complex and risky nature of projects, many organizations experience pressure for consistency in strategy, communication,
THE UNITED REPUBLIC OF TANZANIA PRESIDENT S OFFICE PUBLIC SERVICE MANAGEMENT ICT Project Management A Step-by-step Guidebook for Managing ICT Projects and Risks Version 1.0 Date Release 04 Jan 2010 Contact
Organisational Change Management The only thing that is constant is change in your business, your market, your competitors, and your technology. Remaining competitive and responsive to your customers and
Becoming Agile: a getting started guide for Agile project management in Marketing, Customer Service, HR and other business teams. Agile for Business www.agilefluent.com Summary The success of Agile project
SATORI CONSULTING LEAN AGILE POCKET GUIDE Software Product Development Methodology Reference Guide PURPOSE This pocket guide serves as a reference to a family of lean agile software development methodologies
Agile Software Development Use case for Agile Software Development Methodology in an Oil and Gas Exploration environment. White Paper Introduction No matter what business you are in, there are critical
Foreword Introduction Part One The Evolving State of ESPM xxxi xxxiii 1 Chapter 1 The Changing Landscape of Software Development What Is a Software Development Project? Examples of Two Software Development
What Does a Business Analyst Do on an Agile Project? By Kent J. McDonald Senior Instructor, B2T Training As the use of agile approaches increases, business analysts struggle to determine how their role
HOW STRATEGIC ROADMAPPING ADDS VALUE Irene J. Petrick, Ph.D. June 2010 In the past several years, I have actually heard several mid- to senior-level executives challenge their teams to drive for disruptive
1 www.stephenbarkar.se Lean vs. Agile similarities and differences 2014-08-29 Purpose with the material 2 This material describes the basics of Agile and Lean and the similarities and differences between
6. Software Lifecycle Models A software lifecycle model is a standardised format for planning organising, and running a new development project. Hundreds of different kinds of models are known and used.
The Agile Manifesto is based on 12 principles: Customer satisfaction by rapid delivery of a useful product solution Welcome changing requirements, even late in development Working products are delivered
Jukka Mannila KEY PERFORFORMANCE INDICATORS IN AGILE SOFTWARE DEVELOPMENT Information Technology 2013 KEY PERFORFORMANCE INDICATORS IN AGILE SOFTWARE DEVELOPMENT Mannila, Jukka Satakunnan ammattikorkeakoulu,
Human Resources Values for Working Together and Professional Behaviours A message from the Vice-Chancellor The new Human Resources Strategy, Working Together: A Strategy for Success, in tandem with the
Agile Systems Engineering: What is it and What Have We Learned? March 2012 Dr. Suzette S. Johnson Agile Engineering Northrop Grumman Suzette.Johnson@ngc.com Getting To Know You! Dr. Suzette Johnson Northrop
What is Agile: Agile is a way of developing software and other soft products focused on flexibility and adapting to changing user or customer requirements to maximise value. In many circumstances the end
Scrum Guidelines v.2 2011 W W W. S C R U M D E S K. C O M WHY Agile Ceremonies Agile project is developed in repeatable ceremonies that give rhythm to delivery. Product Strategy Once per year Release Planning
Change Manager Master Level Competency Model The Change Manager Master competency model sets an independent industry benchmark for SENIOR level change management practitioners. The model was launched in
Job Description Senior Accountant Name Reports to Start date Permanent staff Business Services Manager TBA YES A Senior Accountant is a highly productive and functioning member of the team, managing work
A Viable Systems Engineering Approach Presented by: Dick Carlson (firstname.lastname@example.org) Philip Matuzic (email@example.com) i i Introduction This presentation ti addresses systems engineering
Process Methodology for Wegmans Deli Kiosk Version 1.0 Prepared by DELI-cious Developers Rochester Institute of Technology September 15, 2013 1 Table of Contents 1. Process... 3 1.1 Choice... 3 1.2 Description...
Business Intelligence Project Management 101 Managing BI Projects within the PMI Process Groups Too many times, Business Intelligence (BI) and Data Warehousing project managers are ill-equipped to handle
SEMS - Software Engineering M anagement System for Small and Medium Software Product Businesses Goals, Means & Experiences 20.1.2004 Jarno Vähäniitty firstname.lastname@example.org http://www.soberit.hut.fi/
PMP vs. Scrum Master Compatible or Incompatible? Presented by: Karen Little, PMP, CSM, CBAP, ITIL, MCP, MBA Copyright 2007 by Karen Little 1 Agenda Introductions Background on Agile and SCRUM Methodologies
Agile Software Development in the Large Jutta Eckstein 1 Large Large in... Scope Time People Money Risks We concentrate on Large Teams Large is relative 1, 2, 10, 100, 2000 People 2 Principles behind Agile
Jan Marek Jan.Marek@ca. com CA Technologies Session S601 Introducing Agile development methodologies to mainframe development teams Agenda Introduce Agile software development methodologies Scrum overview
Changing Roles and Responsibilities from Traditional project management to Agile project management Vishvadeep Tripathi School of computer science and IT Devi Ahilya University Indore, India email@example.com
Agile Beyond The Team 1 Dilbert Agile 2 What Does Your Organization Value? Projects over Teams? Do new teams spools up for new projects? On-Time/On-Budget Delivery over Zero Maintenance Products Deliver
MODULE 10 CHANGE MANAGEMENT AND COMMUNICATION PART OF A MODULAR TRAINING RESOURCE Commonwealth of Australia 2015. With the exception of the Commonwealth Coat of Arms and where otherwise noted all material
Transitioning from Waterfall to Agile Course AG01; 3 Days, Instructor-led Course Description Identify the challenges you will face when implementing an Agile approach to software development and then plan
Agile for Project and Programme Managers Author Melanie Franklin Director Agile Change Management Limited Introduction I am involved in a mixture of assignments for different organisations across Europe
Project Management and Scrum A Side by Side Comparison by Anne Loeser, October 2006 For decades, software development projects have followed the classic waterfall method in which software development initiatives
Agile Software Development in the Large GI-Vortrag Braunschweig Jutta Eckstein Nicolai Josuttis What Does Large Mean? Large in... scope time people money risks We focus on Large Teams which implies everything
PMI Virtual Library 2010 Carole Wittemann Business Intelligence Project Management 101: Managing BI Projects Within the PMI Process Group By Carole Wittemann, PMP Abstract Too many times, business intelligence
APM-10 Agile project management Content analogy elements of traditional project management elements of agile project management conclusions Karol Frühauf, INFOGEM AG CH-5401 Baden Karol.Fruehauf@infogem.ch
Role profile Basic information Job title Department Location Reports to (Job Title) Matrix manager if applicable (Job Title) Direct reports (Number or Not applicable) Overall people management responsibility
This page was left intentionally blank. Workforce Planning Model Steps What This Step Accomplishes 1. Define the Scope Determines our focus could be long or short term could be a specific business unit
DSDM Case Study An Agile Approach to Software Systems Development for the Highways Agency Government agencies are constantly striving to develop software systems that support business objectives, deliver
Agile Service Transition PATRICK BOLGER HORNBILL SERVICE MANAGEMENT MATT HOEY GRANT THORNTON UK LLP March 2014 The need for speed Technology, and how we use it, constantly evolves. In recent years, Cloud,
IMQS TECHNOLOGY AGILE METHODOLOGY OVERVIEW Agile software development refers to a group of software development methodologies that promotes development iterations, open collaboration, and process adaptability
Laboratório de Desenvolvimento de Software FEUP/MIEIC, 2015/16 Ademar Aguiar Nuno Flores Rui Maranhão Hugo Ferreira Luís Teixeira url: moodle http://www.facebook.com/notes/facebook-engineering/visualizing-friendships/469716398919
Agile QA s Revolutionary Impact on Project Management Introduction & Agenda Rachele Maurer Agile Coach, Platinum Edge Inc. PMP, CSM, PMI-ACP Agenda A quick overview of agile Current QA practices QA using
Article by Peter Mihailidis, Rad Miletich and Adel Khreich: Peter Mihailidis is an Associate Director with bluevisions, a project and program management consultancy based in Milsons Point in Sydney. Peter
LEGAL PROJECT MANAGEMENT Cost management of litigation is becoming a focus of legislators in both Australia and the UK, in an attempt to streamline litigation and ensure costs are proportionate. The Civil
Versions 2.0 Version Date Remarks 1.0 12/4/2012 Initial version 2.0 3/8/2008 REVISION HISTORY Updated knowledge areas Added questions examples Updated suggested readings section Page 2 of 15 Version 2.0
CHANGE MANAGEMENT PLAN WORKBOOK AND TEMPLATE TABLE OF CONTENTS STEP 1 IDENTIFY THE CHANGE... 5 1.1 TYPE OF CHANGE... 5 1.2 REASON FOR THE CHANGE... 5 1.3 SCOPE THE CHANGE... 6 1.4 WHERE ARE YOU NOW?...
14. CAMPAIGN DEVELOPMENT AND MANAGEMENT 14.1. What is a communication campaign? A communication campaign is defined as a connected series of operations designed to bring about a particular result (Kendall,
Program Management Professional (PgMP) Examination Content Outline Project Management Institute Program Management Professional (PgMP ) Examination Content Outline April 2011 Published by: Project Management
About this research note: Technology Insight notes describe emerging technologies, tools, or processes as well as analyze the tactical and strategic impact they will have on the enterprise. Project Management:
Change and project management www.first.com What gets measured, gets d! -Change leader Change and Project Management Change and project management Prince 2, PMI and PCI When projects fail in an organisation,
Demonstrate and apply knowledge of project management in mechanical engineering 22918 version 2 Page 1 of 5 Level 6 Credits 15 Purpose This unit standard is intended primarily for use in diploma courses