1 Information Technology Project Management – Fifth Edition By Jack T. MarchewkaNorthern Illinois UniversityCopyright 2015 John Wiley & Sons, Inc.
2 Project Methodologies and Processes Chapter 2Copyright 2015 John Wiley & Sons, Inc.
3 Introduction Can be Project Methodology A strategic-level plan for managing and controlling the projectGame plan for implementing project and product lifecyclesRecommends phases, processes, tools, and techniques for supporting an IT projectMust be flexible and include “best practices” learned from experiences over time.Can beTraditional (e.g., Waterfall)Agile (e.g., XPM, SCRUM)Copyright 2015 John Wiley & Sons, Inc.
4 Project MethodologyThe 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.Copyright 2015 John Wiley & Sons, Inc.
5 Advantages of using a methodology Provide the project team with a game plan for implementing the project and product life cyclesFocus 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.Copyright 2015 John Wiley & Sons, Inc.
6 The Project Life Cycle Collection of logical stages or phases that maps the life of a projectfrom its beginning, through its middle, to its end,to define, build, and deliver the product.Copyright 2015 John Wiley & Sons, Inc.
7 Project Phases Phase Exits, Stage Gates, Kill Points Fast Tracking 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 deliverablesAllows the organization to evaluate project performance and take immediate action to correct errors or problems or not proceed to the next phaseFast TrackingStarting the next phase of a project before approval is obtained for the current phaseCan be used to reduce the project scheduleCan be risky and should only be done when the risk is acceptableCopyright 2015 John Wiley & Sons, Inc.
8 Figure 2.1 – A Generic Project Life Cycle Copyright 2015 John Wiley & Sons, Inc.
9 Project Life Cycle – Define and Plan Define Project GoalThe project goal should be focused on providing business value to the organizationProvides a clear focus and drives the other phases of the projectTells us how we will know if this project is successful given the time, money, and resources investedAlternatives 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.Copyright 2015 John Wiley & Sons, Inc.
10 Project Life Cycle – Define and Plan Plan ProjectProject ObjectivesInclude 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.ResourcesResources are needed to complete the project work and include such things as people, facilities, and technology.ControlsA 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.
11 Project Life Cycle – Execute, Close, and Evaluate Execute Project PlanManage the project scope, schedule, budget, and people to ensure the project achieves its goalProgress must be documented and compared to the baseline planProject performance must be communicated to all of the stakeholdersAt the end of this phase, the team implements or delivers a completed product, service, or information system to the organization.Close and Evaluate ProjectEnsures that all of the work is completed as plannedFinal project report and presentation to the clientPostmortem reviewLessons learned and best practices documented and sharedCopyright 2015 John Wiley & Sons, Inc.
12 Figure 2.2 – The PMBOK® Guide – The 10 Project Management Knowledge Areas Copyright 2015 John Wiley & Sons, Inc.
13 PMBOK® Guide – The 10 Project Management Knowledge Areas Project integration managementProject scope managementProject time managementProject cost managementProject quality managementProject human resource managementProject communications managementProject risk managementProject procurement managementProject stakeholder managementCopyright 2015 John Wiley & Sons, Inc.
14 The 10 Project Management Knowledge Areas Integration ManagementFocuses on coordinating the project plan’s development, execution, and control of changes.Scope ManagementProvides 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.
15 The 10 Project Management Knowledge Areas Time ManagementImportant 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 ManagementCost management assures that the project’s budget is developed and completed as approved.Copyright 2015 John Wiley & Sons, Inc.
16 The 10 Project Management Knowledge Areas Quality ManagementFocuses 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 ManagementEntails communicating timely and accurate information about the project to the project’s stakeholders.Copyright 2015 John Wiley & Sons, Inc.
17 The 10 Project Management Knowledge Areas Risk ManagementConcerned with identifying and responding appropriately to risks that can impact the project.Procurement ManagementProjects often require resources (people, hardware, software, etc.) that are outside the organization. Procurement management makes certain that these resources are acquired properly.Stakeholder ManagementFocuses 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.
18 Figure 2.3 – PMBOK® Project Management Process Groups Copyright 2015 John Wiley & Sons, Inc.
19 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 projectsThey support all of the activities necessary to plan, create, and manage all of the projects activitiesProject 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 groupsThe 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 phaseCopyright 2015 John Wiley & Sons, Inc.
20 The Five PMBOK® Project Management Process Groups Initiating processesDefining and authorizing a project or project phasePlanning processesDevising and maintaining a workable scheme to ensure that the project addresses the organization’s needsExecuting processesCoordinating people and resources to carry out the various plans and produce the products, services or results of the project or phaseMonitoring and controlling processesRegularly measuring and monitoring progress to ensure that the project objectives are metClosing processesFormalizing acceptance of the project or phase, closing out contracts, documenting lessons learnedCopyright 2015 John Wiley & Sons, Inc.
21 PRINCE2® PRojects IN Controlled Environments Nonproprietary PM methodology developed for government projects in the UKNow used worldwide by 20,000 public and private organizationFollows the PLC and provides stakeholders with a common language and approach to managing projects of all sizes and typesKey features of PRINCE2Focus on business justificationDefined organization structure for the project management teamProduct-based planning approachEmphasis on dividing the project into manageable and controllable stagesFlexibility that can be applied at a level appropriate to the project.Copyright 2015 John Wiley & Sons, Inc.
22 PRINCE2® Aim of PRINCE2®? Role of the Project Board Ensure that projects are well-thought out in the beginning, well-managed throughout, and organized until the end.Role of the Project BoardA 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.Copyright 2015 John Wiley & Sons, Inc.
23 PRINCE2®The Project Board may have up to eight people and includes three important roles: a customer, a senior user, and a senior supplierThe 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.Copyright 2015 John Wiley & Sons, Inc.
24 PRINCE2® – The Seven Processes Copyright 2015 John Wiley & Sons, Inc.
25 The PRINCE2® – Seven (7) Processes Start ProjectThis is a relatively short process that is focused on developing a project brief or document that provides business justification for the project.Initiate ProjectDevelop the project brief into a more detailed business case, which is a key document that lays a foundation for all important project decisions.Direct ProjectThe 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.
26 The PRINCE2® – Seven (7) Processes Control StageDuring this process, the project manager’s day-to-day activities are defined as well as how the project tasks will be controlled and monitored.Manage Product DeliveryThis process ensures that the work packages are developed, delivered, and approved as planned.Copyright 2015 John Wiley & Sons, Inc.
27 The PRINCE2® – Seven (7) Processes Manage Stage BoundariesThis 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.Close ProjectThis 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.
28 The PRINCE2® – Themes (guidelines to aid project goal achievement) Business CaseAlthough 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.OrganizationThe 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.
29 The PRINCE2® – Themes (guidelines to aid project goal achievement) RiskAll 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.QualityThe 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 purposeCopyright 2015 John Wiley & Sons, Inc.
30 The PRINCE2® – Themes (guidelines to aid project goal achievement) PlanningThe 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.ChangeOften 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.
31 The PRINCE2® – Themes (guidelines to aid project goal achievement) ProgressMetrics 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?”
32 The PRINCE2® – Principles (Universal guidance for all projects) Business Case DrivenThe 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.Product FocusProjects 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.
33 The PRINCE2® – Principles (Universal guidance for all projects) Lessons LearnedPRINCE2® 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.Manage the StageAt 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.
34 The PRINCE2® – Principles (Universal guidance for all projects) Adapt to the ProjectThe 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.Manage by ExceptionTolerances 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.
35 The PRINCE2® – Principles (Universal guidance for all projects) AccountabilityPRINCE2® 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.
36 PMBOK vs PRINCE2PRINCE2 and PMBOK are not conflicting or competitive or mutually exclusive. PMBOK’s strength is in teaching the knowledge base of the project management professionPRINCE2’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 PRINCE2There 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.
37 PRINCE2 vs PMBOK PRINCE2` PMBOK A process based project management methodologyA knowledge based approach to project managementA series of management processes defining what must be done, when and how it must be done and by whom over the life of a projectDescribes core practices and a wider range of techniques that can be applied to manage a projectPrescriptive, but tailorableDescriptiveDefines the roles of everyone involved in a projectFocuses on the project manager's roleCopyright 2010 John Wiley & Sons, Inc.
38 Figure 2.5 The Systems Development Life Cycle Copyright 2015 John Wiley & Sons, Inc.
39 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 nextPlanningThe 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.
40 Systems Development Life Cycle (SDLC) AnalysisThe 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
41 Systems Development Life Cycle (SDLC) DesignThe 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.ImplementationIncludes the development or construction of the system, testing, and installation.In addition, training, support, and documentation must be in place.Maintenance and SupportOnce the system has been implemented, it is said to be in production and becomes a legacy systemChanges 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.
42 Implementing the SDLCDefines all of the subphases and deliverables associated with the Execute and Control Project Management Life Cycle phase.Structured Approach to Systems DevelopmentWaterfall MethodIterative DevelopmentRapid Applications Development (RAD)PrototypingSpiral DevelopmentExtreme ProgrammingCopyright 2015 John Wiley & Sons, Inc.
43 Figure 2.7 – The Waterfall Model Copyright 2015 John Wiley & Sons, Inc.
44 Waterfall MethodA 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.
45 Waterfall MethodThe 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.
46 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.
47 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.
48 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.
49 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.
50 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.
51 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.
53 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.
55 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.
57 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.
58 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.
59 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
60 Agile Software Development 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 expertsVisit for information
64 SCRUM Software Development 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.
66 The Relationship Between the PLC & SDLC The project life cycle (PLC) focuses on the phases, processes, tools, knowledge and skills for managing a projectThe 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
67 Figure 2.6 – The Project Life Cycle (PLC) and the Systems Development Life Cycle (SDLC) Copyright 2015 John Wiley & Sons, Inc.
68 Extreme Project Management (XPM) A new approach & philosophy to project management that is becoming increasingly popularCharacterizes many of today’s projects that exemplify speed, uncertainty, changing requirements, and high risksTraditional project management often takes an orderly approach while, XPM embraces the fact that projects are often chaotic and unpredictableXPM focuses on flexibility, adaptability, and innovationXPM takes a more holistic view of planning and managing projectsExpects requirement changes so planning is an iterative processEnables people to discover best solutions and self-correct themselves as needed
69 Agile Systems Development Themes Four Themes – Customer, Product, Project Team and PerformanceAn 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.
70 Learning CycleLearning 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 phasesCopyright 2015 John Wiley & Sons, Inc.
71 Figure 2.10 – A Learning Cycle Copyright 2015 John Wiley & Sons, Inc.
72 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.
73 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.
74 Team Learning Cycles over the Project Life Cycle An entire project can be viewed as a series of learning cycles.Each cycle provides the opportunity tochallenge framing assumptions, create new understanding & find radical solutionsCopyright 2015 John Wiley & Sons, Inc.
75 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.
76 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 inventoryBy 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.
77 An Example of a Team Learning Record 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 handIt may be an efficiency problemWhy are inventory levels so high?Cost of maintaining current inventory is becoming prohibitiveManagement believes a new information system will improve efficiency and therefore lower inventory levelsWhat are the current levels of inventory?Inventory turnover needs to be increasedWhat is the desired level of inventory?Copyright 2015 John Wiley & Sons, Inc.
78 An Example of an Action Plan Who?Does What?By When?Shedelle and SteveInterview sales team to understand past, current, and future trends for the company’s product.TuesdayMyraProvide a detailed count of the current physical inventory on hand.ThursdayCoreanResearch potential inventory management system commercial packagesSteveResearch average inventory levels for the industryWednesdayCopyright 2015 John Wiley & Sons, Inc.
79 Assessing Team Learning Teams do not always begin and end learning cycles at each meetingSome 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 learningSpeed – the number of learning cycles completedThe opportunity to learn can be increased if a team can complete more cycles in a given amount of timeCopyright 2010 John Wiley & Sons, Inc.
80 Assessing Team Learning Depth – the number of learning cycles does not guarantee learning; it must be accompanied by a deepening of understandingHow well the team can dig beneath the surface in order to get at the root of the problemBreadth – the impact the project has on the organizationAlso, does the learning that has taken place within the team stay within the team or is it shared and used throughout the organizationThe “inventory problem” could turn out to cross several functional or departmental boundariesCopyright 2010 John Wiley & Sons, Inc.
81 Assessing Team Learning Copyright 2015 John Wiley & Sons, Inc.