1. Introduction to Project Management
Project Life Cycles
Welcome to Introduction to Project Management: Project Life Cycles. This is Lecture c.
Lecture c
This material (Comp 19 Unit 2) was developed by Johns Hopkins University, funded by the Department of Health and Human Services, Office of the National Coordinator for Health Information Technology under Award Number IU24OC This material was updated in 2016 by Johns Hopkins University under Award Number 90WT0005.
This work is licensed under the Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License. To view a copy of this license, visit
Health IT Workforce Curriculum Version 4.0

2. Project Life Cycles Learning Objectives—Lecture c
Identify process groups and knowledge areas in project management.
Differentiate linear, iterative, adaptive, and agile project life cycles.
Relate life cycle phases to reviews, milestones, and deliverables.
Compare various organizational structures as contexts for managing projects.
The Objectives for Project Life Cycles are to:
Identify process groups and knowledge areas in project management.
Differentiate linear, iterative, adaptive, and agile project life cycles.
Relate life cycle phases to reviews, milestones, and deliverables.
Compare various organizational structures as contexts for managing projects.
This lecture will continue focusing on the second objective before proceeding to the third objective.

3. Example of an Adaptive Life Cycle Model
Our example of an adaptive life cycle model will help to illustrate the differences between models, so notice the contrast with the linear and iterative models. With adaptive models, even the planning should be considered initial planning at the start of the project. The planning should be sufficient for your team to develop and deliver an initial capability. Parallel to your development effort, you will typically have ongoing discussions with the customer and the user community, so that together you learn more about what is desired in the system. As users work with the first delivered release, you will learn even more information. All this additional information contributes to the revised planning sessions that will define later releases. Again, the key characteristic is that you can only develop an initial plan for an initial delivery. The later planning will be keyed to what you learn from the user and customer communities and other stakeholders.
You can think of it as trying to hit a moving target in the sense that you need the active participation of customers and users so your team can get the feedback to continually adapt the product appropriately. It’s not a criticism when we say that users or customers don’t always know what they want at the beginning of the project. It’s unrealistic to expect that everyone will know precisely what they want in a totally new system. This model provides a really engaging way for your development team and the stakeholders to work together to define the system that really makes sense for the community and provides real value to the business.
Healthcare IT is a relatively young field. It has only been around for about 10 years, so many institutions do not actually have a concrete understanding of what they want out of their Health Care IT system. With the adaptive model, you can show your stakeholders and end users a prototype, use their feedback to change it a little bit, and then send it back for review. This process not only helps your users to understand what they will ultimately want in your project, but helps you to understand and define the requirements as you go along.

4. Agile Life Cycle Models
Project Characteristics Requirements Changes Risks Feasibility of Resulting System Complexity of Project Stakeholder Engagement
When to Consider Adaptive Models Minimal, intentionally no attempt to try define them completely at the start Key to evolving the system with tight High; continually engage risk issues Uncertain; excellent models when feasibility is in question Can be significant Entirely different relationship; developers and customers work as a team to evolve and enhance system
Our fourth and final family of life-cycle models is called agile. Although we are showing agile life-cycle models using the same set of project characteristics as the others, we are doing so to compare and contrast them with these other models. With agile, there’s a fundamental shift from the previous three life cycle models. Agile represents really an entirely different philosophy, a fundamental break from the other models. While the table on this slide states that the requirements are only minimally developed, what’s different here is that there is no attempt to define them at the start. This model reflects the reality of health IT systems development, which is a very dynamic process between systems, IT and practitioners.
Prototyping is very helpful in agile life-cycle modules because your final requirements are not known at the beginning. You may start out with vague requirements like, “I want you to go from system A, get some information from system B, and bring it back.” And once you’ve built that system and show it to your stakeholders, they can say OK, now we want to change it using information from system C, and bring that in to get a more complete view of what we want to do. Once you’ve done that they may say, “OK that’s great, but now we want the system to do X before the final step.” And so a prototype is very useful for helping the stakeholders envision the final end product even while it’s being built.

5. Agile Projects Are Distinctive
Use “Just-in-time” Planning
Plan only enough to define next feature of value to customer
View Changes as Desirable
Not viewed as a problem that causes adjustments to plans
Changes tell you what the customer wants
Adopt Goal of Delivering Business Value to Customers
Customers work collaboratively with project team
Define System as Testable Features
Have customers identify and prioritize desired system features
System features define the scope
Note that agile projects represent a strong departure from the other three families of life-cycle models. They challenge many of the assumptions of traditional development, such as that planning is critical at the beginning of the project. The assumption is that if you have stable, known requirements with no changes, and you’re able to do all the planning in the beginning, that’s a much more comfortable existence and it makes it much easier to estimate costs and schedule, and proceed with the activities of the project. Agile challenges all of that. Instead, you use just-in-time planning, which plans only enough to discover the next feature or value to a customer. Instead of thinking that change is undesirable, agile views it as desirable. It’s not a problem; rather, changes tell you what the customer wants. So the goal of agile is, really, delivering business value to the customers and users. It involves your development team, your project team working collaboratively with customers and with users to define those testable features that bring value to what they do. It’s very important to recognize the major differences between agile projects and the other projects that we’ve talked about. Agile is also, as used here, an encompassing concept for a lot of named methodologies, such as extreme programming, and scrum, so there are many variations in some of these principles that we’re talking about, and we’re considering them all under the umbrella of agile projects. Again, they can be much more realistic for health IT project development these days, and they represent the reality of systems development and providing useful IT systems for users and customers.
In healthcare information systems, there are always wonderful ideas that your stakeholders are going to suggest for making the system better. Using an agile life-cycle allows you to bring those suggestions or functionality back to the programmers so they can, over time, include additional functionality to your Health Care program.

6. Key Characteristics in Defining a Life Cycle for Your Project (1 of 3)
Project Goal:
How clearly and completely defined are the goal and requirements?
Is there consensus among stakeholders on the goal?
Project Outcomes:
How feasible is it to achieve the desired outcomes based upon the novelty and complexity of the desired system, the state of technology, the availability of resources, or other factors?
In terms of key characteristics for defining a life cycle for your project, we want to step back now for a moment. We’ve analyzed four families of project life cycle models and recall that our original concept was that health IT projects are unique. And as a project manager, one of your responsibilities will be to come up with a project life cycle that makes sense for your specific project. We want to deal more critically with those key characteristics in your project and how they will really help guide you to select a project life cycle that makes sense. These questions may help you to determine the general family of model that you should be considering: linear, iterative, adaptive, or agile. Even though the linear sequential model may be desirable from traditional viewpoints, it’s really only appropriate for a small percentage of health IT projects. So the first two project characteristics to look at are considerations of the project goal and the outcomes that you desire from the project. With respect to that goal, how clearly and completely defined are they? And is there a lot of consensus among stakeholders? Regarding the project outcomes, what degree of novelty exists? How complex or novel or unprecedented is this desired system with respect to the state of technology, availability of resources, and other factors?
In healthcare IT you will hear the expression, “on the bleeding edge.” That means that the project is very complex, and it’s using state-of-the-art hardware, software, or processes. Most people do not want to be on the bleeding edge. They want to be one step back from that. So whenever you’re looking at your IT projects, be sure to understand whether you’re developing a bleeding edge technology, or if you’re in a safer zone.

7. Key Characteristics in Defining a Life Cycle for Your Project (2 of 3)
Project Stakeholders
How many different stakeholder entities are there?
What are the levels of commitment from senior management, internal and external customers, and those who are paying for the project?
How much engagement and time commitment can you expect from each stakeholder, especially people who will be using the resulting system?
An important set of characteristics revolve around the stakeholders in the project. In fact, one of the earliest empirical studies of factors affecting software project success identified stakeholder complexity as one of the key determinants affecting the productivity of development teams. As a result, it’s time well spent for you to understand your stakeholders – not only how many you have, but what are their different roles and expectations? How will each one influence your project? These are really key characteristics. One that’s often overlooked is your reliance, as a project manager, on the engagement and participation of your stakeholder in determining the success of your project. For example, you might want to obtain their feedback on early releases or otherwise engage them in the project and throughout the project. It is important to know if that kind of engagement is a realistic expectation. These characteristics can be critical in terms of the success of the system and project.
Stakeholder identification is key. In a healthcare IT project, you need to identify everyone who might have a part of that system. You will need to gather together people from all strata of the work force—from the greeters at the front door of the hospital all the way up to the administrators at the highest levels. Their amount of engagement will also be key. The people on the front lines -- the nurses and doctors that are going to be using your system -- generally do not have a lot of time to view the product because of their responsibilities to their patients. You need to make sure that you allow plenty of time for multiple people on each stratum to review the system, because they may bring back wonderful suggestions and changes that you might want to incorporate in your system.

8. Key Characteristics in Defining a Life Cycle for Your Project (3 of 3)
Expected Change:
Is the goal likely to change during the project?
How much change in project scope or other desired outcomes is anticipated during the project?
Uncertainty:
What uncertainties exist in the availability of resources, such as expected sources, amount, and timing of funding?
What is the level of uncertainty in the surrounding economic and social environment that could affect project success?
Are there uncertainties among organizational entities whose existence or stability is critical to project success?
The final set of characteristics that will help you define a life cycle for your project deal with the expected change and the uncertainty. It should be clear that expected change and degree of uncertainty are key drivers in your determination of the best life-cycle model for your project. As a project manager, you are charged with analyzing the specific characteristics of your unique projects, and using these characteristics and questions as a guide. But you really want to pay attention to change and uncertainty. Again, notwithstanding all that we have learned about agile models and the viewpoint of the agile community in terms of change and uncertainty, it is important to understand how much change you can expect and what kind of uncertainties exist, and to define a life cycle model that reflects a realistic view of how both of these exist in your project, in the technology, and in the organizational entities.
No one really likes change. Many times in Health Care IT you’ll hear, “I don’t know why we’re changing it, we’ve been doing it this way for 100 years, and it’s always worked.” Unfortunately in Health Care IT, change is a constant. So helping people work through those changes is part of your job. You are going to have to be reassuring on some days and forceful on other days, and there will be some days that you will have to be all those things for one person. Understanding change and how it affects people on a day to day basis is very important.

9. Life Cycle Phases: Opportunities for Management Review
Regardless of your project life cycle, every phase completion provides an opportunity:
To assess performance during the phase
To review deliverable results, such as designs, documents, code, test results
To determine if the phase has achieved its objectives
To revisit the project management plan and ensure it is appropriate for succeeding phases
We are ready to look at life cycle phases, and present these as valuable opportunities for you as a project manager. We’ve seen four families of lifecycles, and your project will have its own unique life cycle. Regardless of the specific life cycle, we’ll be talking about the elements that make it up as being phases, so your life cycle is composed of phases. And each phase represents an opportunity for you to exercise important management and leadership responsibilities. One particular opportunity is performance assessment. As the project manager, you need to take charge and assess the performance during each phase. Ask yourself: What happened, what was planned, what were the objectives of the phase, and were they achieved? What about deliverable results? Deliverable results really define a phase, and each one is pointed for a particular outcome or result. What are those tangible, deliverable results? Whether they’re designs, documents, processes, or prototypes, it’s an opportunity to determine if the phase has achieved its objectives. It’s also an opportunity for you to lift your head up from the day to day operation of the project to ask, “how does the project now stand with regard to our project management plan? Is that plan still appropriate for succeeding phases?” It’s a chance for you to regroup and ask, “does it still make sense for us to proceed in the same way to succeeding phases as we had planned, or do we really need to think about revisiting the plan?”
The end of a phase is good opportunity to take a breath, review what has been accomplished, look at what needs to be done, and reassess where you are, not only in your project plan, but also against other objectives that the institution may be pursuing. At this point, you can take a deep breath and reassure your management that you are headed in the right direction, and then begin work on the next phase.

10. Linking Life Cycles to Processes
Each life cycle phase will use processes from all five process groups:+
Initiating: processes to start the phase, confirm scope definition and adequacy of resources
Planning: plan the activities of the phase, schedule the work to meet deadlines
Executing: lead the team and coordinate their work to produce deliverables
Monitoring and Controlling: assess progress compared to plans, take corrective actions as needed
Closing: ensure completion of tasks and deliverables, prepare for phase-ending review and readiness for succeeding phases
We began this unit talking about project management elements, such as processes and knowledge areas, and then we transitioned to processes as raw materials useful to you when you’re building your life cycle model and throughout the life cycle. Now we want to turn back on that with respect to phases, and really point out that each life cycle phase will use processes from all five process groups. Not only does a project provide an opportunity for you to use all five process groups, but so does each individual life cycle phase.
If you consider each phase as a self contained entity, you can, for example, use processes from the initiating process group to help you start a phase, confirm the scope definition, and confirm the adequacy of resources. Within a phase you can call on processes from the planning process group to help you plan. Certainly part of every phase involves execution. And there are processes in the executing process group that you can call upon to coordinate the work of the team. There’s a process group for monitoring and controlling, and you’ll certainly want to call on that process group to assess the progress during a phase, compare it to the plans, and take corrective actions as part of your controlling activity. During the phase you will want to invoke processes from the closing process group to finalize the processes, ensure the completion of all the tasks and deliverables associated with that phase, prepare for the phases ending review, and ensure the success of succeeding phases.
At the beginning and the end of each phase, you should look at your project team and think about the next phase that you’re going into. Do you have the right mix of people? Do you need additional resources? How are you going to plan for the next phase? How are you going to mitigate the risks that are coming with the new phase? How are you going to monitor the process, and how are you going to communicate that process to upper management? Ultimately, how are you going to make sure that all of the tasks are completed?

11. Examples of Deliverables and Management Reviews in a Project Life Cycle
We want to show some examples of deliverables and management reviews associated with phases. Recall we said that each life cycle phase gives you an opportunity to consider that phase’s deliverables and introduce management reviews. This diagram is highlighting the reviews and deliverables that might be associated with a linear or sequential life-cycle model. It’s trying to show the key role played by the completion of each phase, and considering it a unit for defining your management reviews, and your review of deliverables from that phase. While this example uses the linear model, you can certainly associate this with any of the four families of models. The key idea is that this is a great opportunity for you as a project manager to review the activities of each phase. The particular names given here are just meant to suggest that they’re related to the activities performed during the phase. But you can certainly make up your own names for the reviews, or simply call them management and status reviews. Again, some of the deliverables just reflect logical activities being performed during the particular phase, such as the result of the implementation phase would certainly involve code for the system as well as a test plan, so that the test plan would be an important deliverable from the implementation phase that you could review. And this would help ensure that your team is ready for the testing phase that follows.
Each phase presents you with an opportunity to review what you’ve done, even if you do not ultimately use the information or use the product that has resulted from that phase. You have learned necessary requirements from your overall project that you can carry forward in the next design. If a product at this point in time does not meet the needs, then at least you’ve explored that part of the requirements and decided that those are not useful parts to move the project forward.

12. Phase Completion as a Milestone
Has the phase has achieved its objectives?
Yes, this represents a milestone of progress
Compare the actual completion compared to the plan to determine if changes to the plan are warranted
Confirm readiness to proceed to the next phase in the life cycle
No, adjustments are needed
Assess the gap between actual and planned results
Reflect on the experiences during the phase for any indication of broader project issues or concerns
Plan activities necessary to achieve phase objectives
Estimate resources required
Evaluate impact on other phases and overall project timeline
Completing a phase really serves as a milestone. A key question for you as a project manager is, are we making progress? And certainly you’ll have this question asked of you by senior management and customers. What constitutes progress in your project? And often, completion of a phase indicates possible progress, but it does not necessarily constitute real progress. So, has the phase achieved its objectives? If it has, you can view it as a milestone of real progress. Compare the outcomes of the phase to the plan to determine if changes to the plan are warranted. But certainly, by achieving its objectives, a phase can signal its readiness to proceed to the next phase in whatever life cycle you’re using for the project. If the phase has not achieved its objectives, then this represents an opportunity for you to assess the gap between the actual results and the planned results. How serious is the gap, and how extensive is it? Are there indications that there are other issues, broader project issues or concerns that you really need to consider? Perhaps this individual phase is an indication of something more fundamental going on that you really need to attend to. The adjustments may involve planning other activities that are necessary to close this gap, so you will be able to achieve those phase objectives. If you are planning additional activities, you need to understand how the resources will be provided for these activities, and how they will impact your resource estimates, the other phases, and the overall project timeline? Does the fact that the objectives were not achieved mean that your schedule is now at risk? Phase completion is an important opportunity for you to consider what constitutes progress in your project, and to ensure that all the objectives of the phase are achieved, and that you have also paid attention to any indications about issues that need to be considered with regard to the whole project.

13. Project Life Cycles Summary—Lecture c
This lecture continued our discussion of the four project lifecycles, reviewing adaptive and agile life cycles in depth.
The lecture presented agile life cycles as much more dynamic processes than the other three life cycle models, so they are particularly well suited for IT projects.
We also examined how applying the five process groups to a life cycle can help manage each phase of that life cycle.
This concludes Lecture c of Project Life Cycles. In summary, this lecture continued our discussion of the four project lifecycles, reviewing adaptive and agile life cycles in depth. The lecture presented agile life cycles as much more dynamic processes than the other three life cycle models, so they are particularly well suited for IT projects. We also examined how applying the five process groups to a life cycle can help manage each phase of that life cycle.

14. Project Life Cycles References – Lecture c
Highsmith, JA. (2009) Agile Project Management: creating innovative products. 2nd ed; Boston: Pearson Education.
Houston S, Bove LA. (2010) Project Management for Healthcare Informatics. New York: Springer Science + Business Media, LLC.
Kerzner H. (2009) Project Management: a Systems Approach to Planning, Scheduling, and Controlling. 10th ed. Hoboken, NJ.:Wiley.
Project Management Institute, A Guide to the Project Management Body of Knowledge. 4th ed (2008).Newtown Square, PA: PMI.
Whitten N. Neal (2007).Whitten's Let's Talk! More No-nonsense Advice for Project Success. Vienna, VA.:Management Concepts Inc.
Wysocki, RK .(2009).Effective Project Management: traditional, agile, extreme. 5th Edition. New York: Wiley.
No audio.
Images
Slide 3: Example of a Life Cycle Model: Courtesy of: Theron Feist
Slide 11: Examples of Deliverables and Management Reviews in a Project Life Cycle. Courtesy of: Theron Feist
Health IT Workforce Curriculum Version 4.0

15. Introduction to Project Management Project Life Cycles Lecture c
This material (Comp 19 Unit 2) was developed by Johns Hopkins University, funded by the Department of Health and Human Services, Office of the National Coordinator for Health Information Technology under Award Number IU24OC This material was updated in 2016 by Johns Hopkins University under Award Number 90WT0005.
No audio.
Health IT Workforce Curriculum Version 4.0