Presentation on theme: "Information Technology Project Management – Fifth Edition By Jack T. Marchewka Northern Illinois University Copyright 2015 John Wiley & Sons, Inc.2-1."— Presentation transcript:
Information Technology Project Management – Fifth Edition By Jack T. Marchewka Northern Illinois University Copyright 2015 John Wiley & Sons, Inc.2-1
Project Methodologies and Processes Chapter 2 2-2Copyright 2015 John Wiley & Sons, Inc.
Introduction Project Methodology A strategic-level plan for managing and controlling the project Game plan for implementing project and product lifecycles Recommends phases, processes, tools, and techniques for supporting an IT project Must be flexible and include “best practices” learned from experiences over time. Can be Traditional (e.g., Waterfall) Agile (e.g., XPM, SCRUM) 2-3 Copyright 2015 John Wiley & Sons, Inc.
Project Methodology The step-by-step activities, processes, tools, quality standards, controls, and deliverables that are defined for a project. Provides a systematic way to plan, manage, and execute the work to be completed by prescribing phases, processes, tools, and techniques to be followed. 2-4 Copyright 2015 John Wiley & Sons, Inc.
Advantages of using a methodology Provide the project team with a game plan for implementing the project and product life cycles Focus on the tasks at hand, instead of always worrying about what they are supposed to do next. Provides a common language that allows the project team, project sponsor, and others within the organization to communicate more effectively. Enables management to compare different projects more objectively so they can make better-informed and more objective decisions with respect to which projects get selected and whether funding should continue to support a particular project. 2-5 Copyright 2015 John Wiley & Sons, Inc.
The Project Life Cycle Collection of logical stages or phases that maps the life of a project from its beginning, through its middle, to its end, to define, build, and deliver the product. 2-6 Copyright 2015 John Wiley & Sons, Inc.
Project Phases Phase Exits, Stage Gates, Kill Points Projects should be broken up into phases to make the project more manageable and to reduce risk. Kill points are the phase-end review of key deliverables Allows the organization to evaluate project performance and take immediate action to correct errors or problems or not proceed to the next phase Fast Tracking Starting the next phase of a project before approval is obtained for the current phase Can be used to reduce the project schedule Can be risky and should only be done when the risk is acceptable 2-7 Copyright 2015 John Wiley & Sons, Inc.
Figure 2.1 – A Generic Project Life Cycle 2-8 Copyright 2015 John Wiley & Sons, Inc.
Project Life Cycle – Define and Plan Define Project Goal The project goal should be focused on providing business value to the organization Provides a clear focus and drives the other phases of the project Tells us how we will know if this project is successful given the time, money, and resources invested Alternatives that would allow the organization to meet its goal are identified. The costs and benefits, as well as feasibility and risk, of each alternative are analyzed. A specific alternative is recommended for funding. The project’s goal and the analysis of alternatives that support the goal are summarized in a deliverable called the business case. 2-9 Copyright 2015 John Wiley & Sons, Inc.
Project Life Cycle – Define and Plan Plan Project Project Objectives Include scope, schedule, budget, and quality. Define what work needs to be completed, when it needs to be completed, how much it will cost to complete, and whether the work is acceptable to specific stakeholders. Resources Resources are needed to complete the project work and include such things as people, facilities, and technology. Controls A great deal of managing a project includes ensuring that the project goal and objectives are being met and resources are used efficiently and effectively. Risk, change, and communication among the project stakeholders must be proactively managed throughout the project Copyright 2015 John Wiley & Sons, Inc.
Project Life Cycle – Execute, Close, and Evaluate Execute Project Plan Manage the project scope, schedule, budget, and people to ensure the project achieves its goal Progress must be documented and compared to the baseline plan Project performance must be communicated to all of the stakeholders At the end of this phase, the team implements or delivers a completed product, service, or information system to the organization. Close and Evaluate Project Ensures that all of the work is completed as planned Final project report and presentation to the client Postmortem review Lessons learned and best practices documented and shared 2-11 Copyright 2015 John Wiley & Sons, Inc.
Figure 2.2 – The PMBOK® Guide – The 10 Project Management Knowledge Areas 2-12 Copyright 2015 John Wiley & Sons, Inc.
PMBOK® Guide – The 10 Project Management Knowledge Areas 1. Project integration management 2. Project scope management 3. Project time management 4. Project cost management 5. Project quality management 6. Project human resource management 7. Project communications management 8. Project risk management 9. Project procurement management 10. Project stakeholder management 2-13 Copyright 2015 John Wiley & Sons, Inc.
The 10 Project Management Knowledge Areas Integration Management Focuses on coordinating the project plan’s development, execution, and control of changes. Scope Management Provides assurance that the project’s work is defined accurately and completely and that it is completed as planned. Includes ways to ensure that proper scope change procedures are in place Copyright 2015 John Wiley & Sons, Inc.
The 10 Project Management Knowledge Areas Time Management Important for developing, monitoring, and managing the project’s schedule. It includes identifying the project’s phases and activities and then estimating, sequencing, and assigning resources for each activity to ensure that the project’s scope and objectives are met. Cost Management Cost management assures that the project’s budget is developed and completed as approved Copyright 2015 John Wiley & Sons, Inc.
The 10 Project Management Knowledge Areas Quality Management Focuses on planning, developing, and managing a quality environment that allows the project to meet stakeholder needs or expectations. Human Resources Management? Focuses on creating and developing the project team as well as understanding and responding appropriately to the behavioral side of project management. Communications Management Entails communicating timely and accurate information about the project to the project’s stakeholders Copyright 2015 John Wiley & Sons, Inc.
The 10 Project Management Knowledge Areas Risk Management Concerned with identifying and responding appropriately to risks that can impact the project. Procurement Management Projects often require resources (people, hardware, software, etc.) that are outside the organization. Procurement management makes certain that these resources are acquired properly. Stakeholder Management Focuses on identifying project stakeholders to better understand their expectations or interests, and then developing appropriate strategies for communication and managing potential conflicts Copyright 2015 John Wiley & Sons, Inc.
Figure 2.3 – PMBOK® Project Management Process Groups 2-18 Copyright 2015 John Wiley & Sons, Inc.
The Five PMBOK® Project Management Process Groups A process is “a set of interrelated actions and activities performed to achieve a pre-specified product, result, or service”. In other words, a process is something you do to achieve a result. Processes are an integral component of projects They support all of the activities necessary to plan, create, and manage all of the projects activities Project management processes are different from the PLC phases because they are actions or tasks to initiate, plan, execute, monitor and control, and close a project as well as interact with the project management knowledge areas. PMBOK outlines five process groups The groups overlap within and between the phases of the project as the output of one process group within a phase becomes the input for a process group in the next phase 2-19 Copyright 2015 John Wiley & Sons, Inc.
The Five PMBOK® Project Management Process Groups 1. Initiating processes Defining and authorizing a project or project phase 2. Planning processes Devising and maintaining a workable scheme to ensure that the project addresses the organization’s needs 3. Executing processes Coordinating people and resources to carry out the various plans and produce the products, services or results of the project or phase 4. Monitoring and controlling processes Regularly measuring and monitoring progress to ensure that the project objectives are met 5. Closing processes Formalizing acceptance of the project or phase, closing out contracts, documenting lessons learned 2-20 Copyright 2015 John Wiley & Sons, Inc.
PRINCE2® PRojects IN Controlled Environments 2-21 Copyright 2015 John Wiley & Sons, Inc. Nonproprietary PM methodology developed for government projects in the UK Now used worldwide by 20,000 public and private organization Follows the PLC and provides stakeholders with a common language and approach to managing projects of all sizes and types Key features of PRINCE2 Focus on business justification Defined organization structure for the project management team Product-based planning approach Emphasis on dividing the project into manageable and controllable stages Flexibility that can be applied at a level appropriate to the project.
PRINCE2® 2-22 Copyright 2015 John Wiley & Sons, Inc. Aim of PRINCE2®? Ensure that projects are well-thought out in the beginning, well-managed throughout, and organized until the end. Role of the Project Board A Project Board is created and is accountable and responsible for managing, monitoring, and controlling the project activities to ensure that the project achieves the value envisioned in the business case. It also makes important decisions such as change requests and whether the project should continue. The Project Board is accountable for the project’s success or failure.
PRINCE2® 2-23 Copyright 2015 John Wiley & Sons, Inc. The Project Board may have up to eight people and includes three important roles: a customer, a senior user, and a senior supplier The customer can be a customer, client, or executive sponsor who represents the business interests of the organization. The senior user represents the interests of the users or stakeholders who will use the project’s product in order to bring the expected value or benefits to the organization. The senior supplier represents the suppliers or specialists who provide the skills or resources needed to deliver the project’s product.
PRINCE2® – The Seven Processes 2-24 Copyright 2015 John Wiley & Sons, Inc.
The PRINCE2® – Seven (7) Processes 1. Start Project This is a relatively short process that is focused on developing a project brief or document that provides business justification for the project. 2. Initiate Project Develop the project brief into a more detailed business case, which is a key document that lays a foundation for all important project decisions. 3. Direct Project The Project Board’s overall activities are defined so that it can direct the project successfully throughout each stage up through the project’s closure Copyright 2015 John Wiley & Sons, Inc.
The PRINCE2® – Seven (7) Processes 4. Control Stage During this process, the project manager’s day-to-day activities are defined as well as how the project tasks will be controlled and monitored. 5. Manage Product Delivery This process ensures that the work packages are developed, delivered, and approved as planned Copyright 2015 John Wiley & Sons, Inc.
The PRINCE2® – Seven (7) Processes 6. Manage Stage Boundaries This includes the information or reporting mechanisms the project manager will give to the Project Board in order to review the status of the project and to determine whether continued business justification for the project exists. 7. Close Project This ensures that the project is completed in a controlled manner if the project work is completed as planned or if it is no longer viable. More specifically, activities are defined for the acceptance of the project, as well as for the project manager to archive documents and release project resources Copyright 2015 John Wiley & Sons, Inc.
The PRINCE2® – Themes (guidelines to aid project goal achievement) 1. Business Case Although the business case is an important PRINCE2® process, its importance is also underscored as a theme that asks the questions, “Why should this project be funded?” and “Why should this project continue to be funded?” It is a key document that not only justifies the initiation of a project, but also ensures that the project can deliver its intended value. 2. Organization The organization theme attempts to answer the question, “Who is involved with the project?” Under this theme, roles, responsibilities, and accountabilities are defined Copyright 2015 John Wiley & Sons, Inc.
The PRINCE2® – Themes (guidelines to aid project goal achievement) 3. Risk All projects entail elements of risk, and the risk theme attempts to manage uncertainty by answering the question, “What if....?” The approach to managing risk under PRINCE2® includes identifying, assessing, and managing risk systematically and proactively. 4. Quality The quality theme attempts to ensure that the project is not only completed on time and within budget, but that it also is completed within standards so that the product fits its intended use or purpose 2-29 Copyright 2015 John Wiley & Sons, Inc.
The PRINCE2® – Themes (guidelines to aid project goal achievement) 5. Planning The planning theme provides clear communication by attempting to answer the questions, “Who does what?” and “When will it get done?” Plans also provide control for the delivery of the project’s product and to determine whether the cost, time, quality, risk, work performance targets are achievable by providing a reference point to measure progress against. 6. Change Often changes are required to the project’s plans and target objectives. Requests for changes can come from any of the project stakeholders, so a systematic way to document, manage, and decide whether proposed changes are necessary is warranted. Subsequently, the change theme attempts to manage and control changes to the project as they occur. 2-30
The PRINCE2® – Themes (guidelines to aid project goal achievement) 7. Progress Metrics provide a means to measure a project’s achievement and forecast whether the project’s progress is going according to the approved plan. The progress theme attempts to answer the questions, “Where is the project now?” and “Where will it end up?” 2-31
The PRINCE2® – Principles (Universal guidance for all projects) 1. Business Case Driven The business case is a key document that is developed at the beginning of the project and must be continually justified throughout. Therefore, it is a key driver for starting the project and for continued funding of the project. 2. Product Focus Projects are not just a series of activities or tasks, but rather are undertaken to produce a product. PRINCE2® projects emphasize the design and delivery of a quality product Copyright 2015 John Wiley & Sons, Inc.
The PRINCE2® – Principles (Universal guidance for all projects) 3. Lessons Learned PRINCE2® is based on proven best practices. Therefore, documented experiences in terms of lessons learned are an important component for the PRINCE2® methodology that are sought throughout the life of the project. 4. Manage the Stage At each stage of the project, the Project Board reviews the project’s progress in comparison to the business case. Each stage is planned, monitored, and controlled Copyright 2015 John Wiley & Sons, Inc.
The PRINCE2® – Principles (Universal guidance for all projects) 5. Adapt to the Project The PRINCE2® methodology can be tailored to projects large or small. The methodology can be scaled to the size of the project and should be flexible in terms of the risks and environment unique to the project. 6. Manage by Exception Tolerances are defined and used to empower project stakeholders by allowing them to make decisions without having to ask for approval from the next higher level of authority Copyright 2015 John Wiley & Sons, Inc.
The PRINCE2® – Principles (Universal guidance for all projects) 7. Accountability PRINCE2® projects should have clear roles and responsibilities. Stakeholders need to know their role as well as everyone else’s. The Project Board includes executive sponsorship that defines the project’s objectives and ensures that the project remains viable. Internal or external suppliers provide resources, skills, or the knowledge to deliver the project’s products, while users represent those stakeholders who will benefit from the delivery of the final product Copyright 2015 John Wiley & Sons, Inc.
PMBOK vs PRINCE2 PRINCE2 and PMBOK are not conflicting or competitive or mutually exclusive. PMBOK’s strength is in teaching the knowledge base of the project management profession PRINCE2’s strength is in setting out a standard approach to running a project. Both PRINCE2 and PMBOK fall short of doing both of these to the same degree. In this sense they are complementary and should and can be used as such; PRINCE2 as a supplement to the body of knowledge \ PMBOK as a knowledge base upon which to implement PRINCE2 There should be a continuous tailoring of your approach based on the size, type and complexity of the project, and any existing organizational project management methodology. Copyright 2010 John Wiley & Sons, Inc.36
PRINCE2 vs PMBOK Copyright 2010 John Wiley & Sons, Inc.37 PRINCE2`PMBOK A process based project management methodology A knowledge based approach to project management A series of management processes defining what must be done, when and how it must be done and by whom over the life of a project Describes core practices and a wider range of techniques that can be applied to manage a project Prescriptive, but tailorableDescriptive Defines the roles of everyone involved in a project Focuses on the project manager's role
Figure 2.5 The Systems Development Life Cycle 2-38 Copyright 2015 John Wiley & Sons, Inc.
Systems Development Life Cycle (SDLC) Although projects follow a project life cycle, information systems development follows a product life cycle. The most common product life cycle in IT is the systems development life cycle, which represents the sequential phases or stages an information system follows throughout its useful life. The SDLC establishes a logical order or sequence in which the system development activities occur and indicates whether to proceed from one system development activity to the next Planning The planning stage involves identifying and responding to a problem or opportunity and incorporates the project management and system development processes and activities. A formal planning process ensures that the goal, scope, budget, schedule, technology, and system development processes, methods, and tools are in place. 39
Systems Development Life Cycle (SDLC) Analysis The analysis phase attempts to delve into the problem or opportunity more fully. For example, the project team may document the current system to develop an "as is" model to understand the system currently in place., Systems analysts will meet with various stakeholders (users, managers, customers, etc.) to learn more about the problem or opportunity. This work is done to identify and document any problems or bottlenecks associated with the current system. The "as is" analysis is followed by a requirements analysis where the specific needs and requirements for the new system are identified and documented. Requirements can be developed through a number of means—interviewing, joint applications development (JAD), conducting surveys, observing work processes, and reading company reports. Using modeling techniques, the current system, user requirements, and logical design of the future system called the "to be" system are represented and documented 40
Systems Development Life Cycle (SDLC) Design The project team uses the requirements and "to be" logical models as input for designing the architecture to support the new information system. This architecture includes designing the network, hardware configuration, databases, user interface, and application programs. Implementation Includes the development or construction of the system, testing, and installation. In addition, training, support, and documentation must be in place. Maintenance and Support Once the system has been implemented, it is said to be in production and becomes a legacy system Changes to the system, in the form of maintenance and enhancements, are often requested to fix any discovered errors (i.e., bugs) within the system, to add any features that were not incorporated into the original design, or to adjust to a changing business environment. 41
Implementing the SDLC Defines all of the subphases and deliverables associated with the Execute and Control Project Management Life Cycle phase. Structured Approach to Systems Development Waterfall Method Iterative Development Rapid Applications Development (RAD) Prototyping Spiral Development Extreme Programming 2-42 Copyright 2015 John Wiley & Sons, Inc.
Figure 2.7 – The Waterfall Model 2-43 Copyright 2015 John Wiley & Sons, Inc.
Waterfall Method A structured approach to systems development has been around since the 1960s and 1970s, when large mainframe applications were developed. The waterfall model illustrated was developed as a simple and disciplined method that follows the SDLC closely in a very sequential and structured way. The idea of a waterfall is a metaphor for a cascading of activities from one phase to the next where one phase is completed before the next phase is started. 44
Waterfall Method The waterfall model stresses a sequential and logical flow of software development activities. Design activities or tasks begin only after the requirements are defined completely. The building or coding activities will not start until the design phase is complete. Although there is some iteration where the developers can go back to a previous stage, it is not always easy or desirable. One characteristic of the waterfall model is that a great deal of time and effort is spent in the early phases getting the requirements and design right because it is more expensive to fix a bug or add a missing requirement in the later phases of the project. 45
Waterfall Method - Disadvantages Critics of the structured approach to systems development argue that it takes too long to develop systems and that this approach does not embrace the idea that changing requirements are inevitable. Inexperienced developers often have the false belief that if they ask the users what they want, they will be rewarded with a set of clear, accurate, and complete requirements. In truth, most users do not know or are unable to articulate their needs early on in the project. And if they do, those requirements will most likely change later on. 46
Waterfall Method - Advantages An advantage of the waterfall model is that it allows us to plan each phase in detail so that the project schedule and budget can be computed by summing the time and cost estimates for all the tasks defined in each phase. Provides a solid structure that can minimize wasted effort, the Waterfall model may work well when the project team is inexperienced or less technically competent. This approach is still used today, especially for large government systems and by companies that develop shrink wrap or commercial software packages. A structured approach is suitable when developing large, more complex systems where one assumes, or at least hopes, that the requirements defined in the early phases do not change very much over the remainder of the project. 47
Waterfall Method - Disadvantages Users tend to be involved at three main points during a Waterfall project: 1) when they are needed to define the requirements (i.e., features and functionality) of the software, 2) when users ask for changes to the requirements, and 3) at the end of the project when the software is delivered. Many times this has resulted in strained relationships between users and developers. Users may not have articulated everything they want, and developers become resistant to making any changes later on. 48
Waterfall Method - Disadvantages Adding new requirements or changing software that has already been written adds to the schedule and cost of the project. As a result, a new system may be delivered that does not meet the users’ needs. Another issue is that the potential value of the project can only be attained at the end of the project when the system with all its defined requirements is delivered. For many projects, this could be months or years. 49
Iterative Systems Development Critics of the structured approach to systems development argue that it takes too long to develop systems and that it does not embrace the idea that changing requirements are inevitable. Inexperienced developers often have the false belief that if they ask the users what they want, they will be rewarded with a set of clear, accurate, and complete requirements. In truth, most users do not know or are unable to articulate their needs early on in the project. If they do, those requirements will most likely change later on. The main idea behind iterative systems development is shortening the SDLC and embracing the idea that requirements are difficult to define and will change. 50
Iterative Systems Development Rapid applications development (RAD ) was proposed by James Martin in the early 1990s as a less formal way to expedite the SDLC. RAD attempts to compress the analysis, design, build, and test activities of the SDLC into a series of short iterations or development cycles. For example, a small team of users and developers would work closely together to develop a set of system requirements during a workshop. Using tools such as computer- aided software engineering (e. g., CASE) or visual development environments (e. g.,.NET), the developers would then work with the users to develop a functional or usable version of the system that might include only 25 per- cent of the total requirements. The development cycle would continue with a second usable version that would include the next 25 percent of the requirements. Subsequent iterations would continue until all of the requirements are included in the system. 51
Iterative Systems Development Prototyping, similar to RAD, is an iterative approach to systems development where the user and developer work closely together to develop a partially or fully functional system as soon as possible. Often, however, a prototype may be developed to discover or refine system requirement specifications that can be used as a model for developing a real system. A team may develop a nonfunctional user interface on a personal computer as a model to define the look, feel, and features of a large, multi-user system. 53
Iterative Systems Development 54
Iterative Systems Development Spiral development approach first proposed by Barry Boehm (1988), breaks up a software project into a number of mini- projects that address one or more major risks until all the risks have been addressed. A risk, could be a poorly understood requirement or a potential technical problem or system performance issue. The basic idea is to begin development of a system on a small scale where risks can be identified. Once identified, the development team then develops a plan for addressing these risks and evaluates various alternatives. Next, deliverables for the iteration are identified, developed, and verified before planning and committing to the next iteration. As a result, the completion of each iteration brings the project closer to a fully functional system. 55
Spiral Development 56
Iterative Systems Development Agile systems development methods are becoming an increasingly popular approach to systems development and include various methodologies such as SCRUM, dynamic systems development method (DSDM), and adaptive software development (ASD). One of the most commonly known agile methodologies is eXtreme programming (XP), which was introduced by Kent Beck in the mid-1990s. Under XP, the system is transferred to the users in a series of versions called releases. 57
Iterative Systems Development A release may be developed using several iterations that are developed and tested within a few weeks or months. Each release is a working system that includes only one or several functions that are part of the full system specifications. XP includes a number of activities where the user requirements are first documented as a user story. The user stories are then documented using an object-oriented model called a class diagram. A set of acceptance tests is then developed for each user story. Releases that pass the acceptance tests are then considered complete. 58
Iterative Systems Development Small teams of developers often work in a common room where workstations are positioned in the middle and a workspace for each team member is provided around the perimeter. XP often incorporates team programming, where two programmers work together on the same workstation. Developers often are prohibited from working more than 40 hours a week in order to avoid burnout and the mistakes that often occur because of fatigue 59
The term Agile today is an umbrella term that includes a number of approaches, methods, or ways to develop products or systems. Agile approaches focus on speed and flexibility rather than a rigid development structure. Agile software development has become popular to describe new approaches that focus on close collaboration between programming teams and business experts Visit for informationwww.agilealliance.org Agile Software Development 60
Agile Software Development 61
The Agile Manifesto 2-62 Copyright 2015 John Wiley & Sons, Inc.
Agile System Development 63
SCRUM breaks a software development into a series of iterations or sprints. Each sprint lasts at most 30 days. During each sprint, a set of features are incrementally added to the product under development and a potential release of software is created. The requirements for the product to be developed are held in a product backlog. At the start of a sprint, a sprint planning meeting is held. During the meeting, a set of requirements from the backlog are picked for implementation in the next sprint. The development team decides which requirements they can commit to developing during the next sprint. At the end of a sprint, a sprint retrospective meeting is held to discuss which elements of the process could be improved. Further sprints are then performed until the product backlog of requirements is empty. SCRUM Software Development 64
SCRUM Software Development 65
The Relationship Between the PLC & SDLC The project life cycle (PLC) focuses on the phases, processes, tools, knowledge and skills for managing a project The system development life cycle (SDLC) focuses on creating and implementing the project’s product—the information system. The SDLC is really part of the PLC because many of the development activities occur during the execution phase of the PLC. The last two phases of the PLC, close project and evaluate project, occur after the implementation of the system 66
Figure 2.6 – The Project Life Cycle (PLC) and the Systems Development Life Cycle (SDLC) 2-67 Copyright 2015 John Wiley & Sons, Inc.
Extreme Project Management (XPM) A new approach & philosophy to project management that is becoming increasingly popular Characterizes many of today’s projects that exemplify speed, uncertainty, changing requirements, and high risks Traditional project management often takes an orderly approach while, XPM embraces the fact that projects are often chaotic and unpredictable XPM focuses on flexibility, adaptability, and innovation XPM takes a more holistic view of planning and managing projects Expects requirement changes so planning is an iterative process Enables people to discover best solutions and self-correct themselves as needed 68
Agile Systems Development Themes Four Themes – Customer, Product, Project Team and Performance An Agile team should include business people and technical people who are motivated, self-organizing, and mutually accountable. A team should be given the support and resources it needs and then trusted to get the job done. People who work long hours may burn out, get tired, become less motivated, and tend to make more mistakes. Therefore, the team should be able to work at a pace that is constant and sustainable. The team should have the authority to make adjustments when needed Copyright 2015 John Wiley & Sons, Inc.
Learning Cycle Learning cycles are a useful tool that can be used throughout the project life cycle regardless whether the project team follows Waterfall or Agile. More specifically, they provide a way to resolve ambiguous situations through the repeated pattern of thinking through a problem. A team learning cycle has four phases 2-70 Copyright 2015 John Wiley & Sons, Inc.
Figure 2.10 – A Learning Cycle 2-71 Copyright 2015 John Wiley & Sons, Inc.
Understand and frame the problem At the beginning of a project, the team members’ understanding may be quite general, or they may feel that they really do not understand the challenge assigned to them. Unfortunately, few people are willing to admit that they do not have all the answers or that their understanding of the team’s challenge is limited. On the other hand, other members of the team may approach the project with a high degree of certainty—that is, they may act as though they know what the solution is and, therefore, the team just needs to work out the details of how to go about implementing the solution Copyright 2015 John Wiley & Sons, Inc.
Understand and frame the problem Opinions are often accepted without question and can result in erroneous assumptions that lead the project team in the wrong direction or keep the team from getting at the real problem. Moreover, there is often pressure for the team to take immediate action so that the project can be completed on time and within budget. Example: A plan sponsor tells the project team that the company has too much inventory on hand and the cost is becoming exorbitant. He suggests that an information system will solve his problems. Team members can accept the plan sponsor’s solution or question it and look for alternative solutions which may provide a better result Copyright 2015 John Wiley & Sons, Inc.
Team Learning Cycles over the Project Life Cycle Each cycle provides the opportunity to challenge framing assumptions, create new understanding & find radical solutions 2-74 Copyright 2015 John Wiley & Sons, Inc. An entire project can be viewed as a series of learning cycles.
Purpose of Lessons Learned An entire project can be viewed as a series of learning cycles. Understand & Frame: An initial team meeting can examine the original problem or challenge assigned to the team. Plan: During that meeting, the team can develop an initial action plan. Act: Between meetings, the members of the team can then carry out their assigned tasks for testing assumptions or gathering information. Reflect & Learn: At the next meeting, the team can reflect on what it has learned, document the lessons learned, and then start the beginning of a new cycle. Each cycle should be used to challenge the framing of the problem and create new opportunities for learning Copyright 2015 John Wiley & Sons, Inc.
Purpose of Lessons Learned For example, the team may find out that the high inventory levels are due to an obsolete product or one no longer in style. No information system will help reduce such inventory By not questioning the plan sponsor, the wrong course of action would have been taken and no real reduction in inventory would have occurred despite the investment of time and money Copyright 2015 John Wiley & Sons, Inc.
What we know (Facts) What we think we know (Assumptions) What we don’t know (Questions to be Answered) Company has too much inventory on hand It may be an efficiency problem Why are inventory levels so high? Cost of maintaining current inventory is becoming prohibitive Management believes a new information system will improve efficiency and therefore lower inventory levels What are the current levels of inventory? Inventory turnover needs to be increased What is the desired level of inventory? An Example of a Team Learning Record 2-77 Copyright 2015 John Wiley & Sons, Inc.
Who ?Does What ?By When? Shedelle and SteveInterview sales team to understand past, current, and future trends for the company’s product. Tuesday MyraProvide a detailed count of the current physical inventory on hand. Thursday CoreanResearch potential inventory management system commercial packages Thursday SteveResearch average inventory levels for the industry Wednesday An Example of an Action Plan 2-78 Copyright 2015 John Wiley & Sons, Inc.
Assessing Team Learning Copyright 2010 John Wiley & Sons, Inc.79 Teams do not always begin and end learning cycles at each meeting Some learning cycles can take more than one meeting and some can be accomplished in a shorter time if face-to-face meetings are not needed, thus … Three dimensions can be used to assess team learning Speed – the number of learning cycles completed The opportunity to learn can be increased if a team can complete more cycles in a given amount of time
Assessing Team Learning Copyright 2010 John Wiley & Sons, Inc.80 Depth – the number of learning cycles does not guarantee learning; it must be accompanied by a deepening of understanding How well the team can dig beneath the surface in order to get at the root of the problem Breadth – the impact the project has on the organization Also, does the learning that has taken place within the team stay within the team or is it shared and used throughout the organization The “inventory problem” could turn out to cross several functional or departmental boundaries
Assessing Team Learning 2-81 Copyright 2015 John Wiley & Sons, Inc.