PM paper
daaiv2
AD642-FinalProjectPlanReport-2019Example-Cosangra.docx-edit.pdf
BU MET AD 642 PROJECT PLAN - GROUP 3 TEAM C 1
Table of Contents
1.0 Executive Summary……………………………………………………………………………………..….2
2.0 Introduction……………………………………………………………………………………….…….......3 2.1 Project Charter……………………………………………………………………………………….…...4
2.2 Stakeholder Register………………………………………………………………………………….…..5
2.3 Project Priority Matrix……………………………………………………………………………….…...5
3.0 Scope…………………………………………………………………………………………………………6 3.1 Work Breakdown Structure (WBS)……………………………………………………………………...7 4.0 Sequence and Schedule………………………………………………………………………………….…8 4.1 Network Diagram and Schedule………………………………………………………………….……...9
4.2 Gantt Chart………………………………………………………………………………………………10
4.3 Milestones…………………………………………………………………………………………...…..10
5.0 Budget Estimate………………………………………………………………………………....……..….11
6.0 Project Risks……………….………………………………………………………………….…….......…12 6.1 Risk Identification……………………………………………………………………………………....12
6.2 Risk Response Plan………………………………………………………………………………....…..14
6.3 Benefits Realization and Sustainability…………...……………………………………………..…...…15
7.0 Conclusion…………………………………………………………………………………………..……...16 7.1 Success Measurements…………………………………………………………...………………......…17
7.2 Communications Plan....…………………………………………………………………………...……17
7.3 Lessons Learned and Recommendations……………………………………………………...……...…18
7.3.0 Initiating Process Group…………………………………………………………….…….…18
7.3.1 Planning Process Group……………………………………………………………………..19
7.3.2 Executing Process Group……………………………………………………………..…….19
7.3.3 Monitoring and Controlling Process Group……………………………………………..….20
7.3.4 Closing Process Group…………………………………………………………………...…20
7.3.5 Application of Recommendations…………………………………………………......……21
References……………………………………………………………………………………..………....…….22
Appendix A - Project Charter………………………………………………………………………...…..….24
Appendix B - Stakeholder Register…………………………………………………………………..........…31
Appendix C - Project Priority Matrix……………………………………………………….……...…...…...32
Appendix D - Work Breakdown Structure (WBS)………...…………………………………..………...….33 D.1 - Numeric WBS…………………………………………………………………………………….......33
D.2 - Graphical WBS …………………………………………………………………………………....…34
D.3 - WBS Dictionary……………………………………………………………………………………....34
Appendix E - Network Diagram ………………………………………………………………..………...….47 E.1 - Microsoft Project NetworkDiagram………………………………………………...………………...47
E.2 - Gantt Chart……………………………………………………………………………………….……50
Appendix F - Microsoft Project Schedule…………………………………………………………………....51
Appendix G - Cost Management Plan & Budget……………………………………………………....…....52
Appendix H - Risk Management………………………………………………………………….…..……...57 H.1 - Risk Register………………………………………………………………………………………….57 H.2 - Risk Response Plan……………………………………………………………………………..…….60
H.3 - Risk Heat Map………………………………………………………………………....……...………61
H.4 - Monte Carlo Simulation…………………………………………………………………..……..……62
H.5 - Task Sensitivity Analysis…………………………………………………………….……………….65
H.6 - Risk Breakdown Structure…………………………………………………………….………………66
H.7 - Risk Report Detail………………………………………………………………………...…………..66
Appendix I - Communications Matrix…………………………………………………………….…………80
Appendix J - Application Design/Mockups……….……………...…………………….………….……...…81
Appendix K - Lessons Learned ……………………………...…………………………………….…………82
BU MET AD 642 PROJECT PLAN - GROUP 3 TEAM C 2
1.0 Executive Summary
To help combat the ongoing issue of blood shortages during natural and man-made disasters, our
project management team has developed and introduced a mobile application, with the ultimate
goal being to facilitate an enhanced donor collection program for the American Red Cross. The
team began by establishing the project’s objectives and identifying major stakeholders,
subsequently developing a project charter and work breakdown structure (WBS). The schedule
and budget constraints were then carefully articulated; the estimated cost of the project is
$500,000, and the estimated project start and completion dates are February 4, 2019 and January
27, 2020 respectively. Assumptions, potential risks, and planned responses were identified and
categorized. Finally, the team carefully noted each lesson learned, in order to benefit the project
management community as a whole. The initiating, planning, executing, monitoring and
controlling, and closing process groups will each be touched upon in this essay. Our project
management team intends for the application to increase blood volume donation by 15% in times
of need, and for the application to be accessible and usable by all for an indefinite period of time.
BU MET AD 642 PROJECT PLAN - GROUP 3 TEAM C 3
2.0 Introduction
The American Red Cross, and its volunteer-operated blood drives, saves countless lives every
single day. The organization’s mission is to “...prevent and alleviate human suffering in the face
of emergencies by mobilizing the power of volunteers and the generosity of donors”
(redcross.org, n.d.). While the organization does successfully prevent and alleviate human
suffering in many cases, there are times in which volunteer and donor resources are not utilized
to their utmost potential. Our project management team identified a separation between the need
for donated blood in times of emergency, and actual volumes of blood donated. A single car
accident victim can require as many as 100 pints of blood; at the same time, red blood cells can
only be used within 42 days of collection, so it cannot be stockpiled in advanced preparation of a
disaster (redcross.org, n.d). One can only imagine how this can create a dire shortage of blood if
a sudden disaster occurs and leaves hundreds seriously wounded.
These shortages are exacerbated by the fact that many potential donors are often willing to give
their blood, but cannot or will not attend a blood drive due to time or transportation constraints.
In fact, a recent news article details the recent “polar vortex” and its detrimental effects to blood
supply. The article explains how the current blood system is “vulnerable to disruption,” and that
“natural disasters wreak havoc on the carefully choreographed supply chain” (Thon, 2019). Not
to mention, setting up a blood drive takes significant time and resources for the American Red
Cross, and may not be feasible in urgent times of need. With the intention of bridging this gap,
our team devised the CoSangRA mobile application. The app will facilitate in-home blood
donations by pairing volunteer phlebotomists with donors at the click of a button, similar to a
rideshare or food delivery application.
2.1 Project Charter
BU MET AD 642 PROJECT PLAN - GROUP 3 TEAM C 4
The CoSangRA project management team developed a project charter (Appendix A) to initiate
the CoSangRA Mobile Application project. The purpose of a project charter is to formally
recognize the existence of a project, provide a summary of its objectives and management, and
most importantly get the project green-lighted by the project’s sponsor (Schwalbe, 2017).
Although the contents of a project charter vary from project to project, it typically outlines the
proposed project’s objectives and scope, identifies its key stakeholders and assumptions,
estimates cost and schedule, and defines the authority of the project manager. A critical part of
the charter is the sign-off section, where key project stakeholders sign the document to
acknowledge their agreement on the need for the project (Schwalbe, 2017). In our project’s case,
there were five project managers (James Taylor, Bette Midler, Cecelia Zhang, Yulia Petrenkov,
and Marty Wan) who each took on heightened responsibility during various weeks of the project.
The sponsor that the proposal was written to is Richard Schoenfeld, our class facilitator and the
American Red Cross’ Vice President of Information Technology.
Good scope definition is crucial to project success because it helps improve the accuracy of
schedule and cost estimates, defines a performance measurement baseline, and aids in clear
communication of work responsibilities (Schwalbe, 2017). It is important to note that a project’s
scope statement is different from the project charter, in that it details the project objectives and
deliverables first outlined in the project charter (Schwalbe, 2017). A primitive version of our
scope can be found in our project charter, but is described in further detail in section 3.0 below.
2.2 Stakeholder Register
An important piece of information included in the CoSangRA project charter that we would like
to draw special attention to is the project’s stakeholders. We created a stakeholder register
(Appendix B), which is a document that identifies project stakeholders and details including their
BU MET AD 642 PROJECT PLAN - GROUP 3 TEAM C 5
roles in the project and their major requirements and expectations. Identifying and understanding
a project’s stakeholders helps to increase stakeholder support throughout the project (Schwalbe,
2017). The CoSangRA mobile application’s primary stakeholders include: the project
management team, the project sponsor, the local government, existing and potential blood
donors, the American Red Cross and its executives, and finally phlebotomists and other medical
professionals.
2.3 Project Priority Matrix
In addition to developing a project charter, our team found it helpful to prioritize the constraints
that would surely affect the project. Creating a project priority matrix (Appendix C), as part of
the initiating process group, helped us do so. Once the inception of the CoSangRA application
project idea was discussed, accepted, and documented, the project priority matrix was created in
order to the define and document the priority of each project constraint. Project managers
understand that there are three primary constraints surrounding any project: scope, schedule, and
cost. Risk is another important project constraint, but we discuss it separately in section 6.0 of
this paper. In CoSangRA’s case, scope was considered the biggest constraint. If the app did not
operate as intended or lead to the desired result, there could be serious consequences. Taking
extra time or extra financial resources in order to achieve the necessary scope was permissible.
Consider the project priorities from least to most important:
❖ Cost was least important. Cost is considered a weak constraint, in our case. Although
cost is affirmatively considered a constraint and is objectively important, a $500,000
budget would more than suffice for a project of this magnitude. Additionally, an IT
project such as a mobile application is less likely to face surprise costs than a
construction project or event is.
BU MET AD 642 PROJECT PLAN - GROUP 3 TEAM C 6
❖ Schedule was second most important. Releasing the application before the next disaster
strikes could lead directly to a decreased loss of life. If the app is released late, the
opportunity cost could equal the loss of lives that otherwise could have been saved due to
blood collected through app-facilitated donation.
❖ Scope was most important. The application must be able to effectively function during
times of disaster. Disastrous consequences could include the release of private health
information, unqualified phlebotomists performing blood draws, and willing donors
being unmatched with phlebotomists. Additionally, a lack of proper functionality could
lead to permanent loss of trust in the app, exponentially increasing its chances of failure.
3.0 Project Scope
A crucial piece to the planning process group of a project is defining the project’s scope. As
discussed above in section 2.1, the scope is briefly discussed in the project charter, which was
ultimately used to help develop the project’s official scope statement. The scope statement
develops and confirms a common understanding of the project scope, and is an important tool for
preventing scope creep, which is the uncontrolled expansion to product or project scope without
adjustments to time, cost, and resources (Schwalbe, 2017). As mentioned in section 2.3 of this
paper, project scope is one of the three primary constraints in a project (the other two, schedule
and cost, will be discussed in detail in sections 4.0 and 5.0, respectively).
The scope for the CoSangRA project is the development and deployment of a mobile application
designed to connect Red Cross volunteers to blood donors in times of urgent need. The
application is intended to help the American Red Cross retrieve blood by deploying a notification
to CoSangRA application users/volunteers - both donors and certified phlebotomists, or blood
BU MET AD 642 PROJECT PLAN - GROUP 3 TEAM C 7
collection professionals - regarding the need for a specific blood type within a certain geographic
radius. The application allows medical professionals to apply to volunteer as phlebotomists in
advance, and also allows potential donors to be screened for blood type and overall health in
advance. When there is a low shortage for a certain blood type, the app will notify pre-qualified
donors and phlebotomists in the area. Once one potential blood donor replies to the request with
time availability, the volunteer phlebotomists can confirm the request. The CoSangRA app will
drastically improve and maximize communications between the American Red Cross and blood
donors; our goal being to increase donations by 15% in times of need.
3.1 Work Breakdown Structure (WBS)
Also in the planning process group of a project is the development of the Work Breakdown
Structure (WBS). The WBS is a deliverable-oriented grouping of the work involved in a project,
which defines the total scope of the project. It breaks all required work into deliverables, and
groups them into a logical hierarchy (Schwalbe, 2017). There is no time element to the WBS; it
should focus on the work to be done, rather than how it will be done. A project’s WBS can be
displayed in numeric (outline style) or graphical (family-tree style) form (see Appendix D.1 and
Appendix D.2, respectively). Both styles provide a clear structure of the necessary tasks involved
to develop the CoSangRA application, and exclude time and financial constraints.
The work breakdown structure for CoSangRA consists of six work streams: Project Starting,
Logical Application Designing, Physical Layer Design, Program Unit Testing, System Test and
Implementation.
1. Project Starting - The CoSangra PMO evaluates funding requirements, and defines the
project scope of the new application. Customer engagement is key in establishing the
scope.
BU MET AD 642 PROJECT PLAN - GROUP 3 TEAM C 8
2. Logical Application Designing - Full breakdown of data requirements, designing,
structuring and validating of the operating system.
3. Physical Layer Designing - The procedural definitions are created to prepare for the
test environment of the application.
4. Programming and Unit Testing - Project management development team begins initial
programming and testing internally prior to engaging customer for end-user testing
scenarios.
5. System Test - Front to back testing of the proposed final product conducted by the
project manager and the Red Cross end users of the CoSangra application. The PM
collects the end users feedback and makes final adjustments to product as needed.
6. Implementation - Final software application product is distributed and integrated into
the Red Cross network for field use to begin new blood collection process.
The deliverables at the lowest level of the WBS can each be assigned to and managed by a single
individual, and are called work packages (Schwalbe, 2017. The WBS dictionary (Appendix D.3)
describes each work package mentioned in the WBS. In comparison to the numeric and graphical
WBS, the WBS dictionary paints a more detailed picture as to what is involved in each step of
work package ID. The dictionary presents each element in a fashion which makes each work
package reflect as if to be a scaled-down project in and of itself.
4.0 Sequence and Schedule
Also crucial to the planning process of a project is the development of a project schedule, which
occurs when the elements of duration, sequence, and resource availability are added to the
elements of the WBS (Schwalbe, 2017). Project scheduling is a mechanism to communicate
BU MET AD 642 PROJECT PLAN - GROUP 3 TEAM C 9
what tasks need to be completed and which organizational resources will be allocated to
complete those tasks in what timeframe. The work included in this section includes a network
diagram (Appendix E.1), a gantt chart (Appendix E.2), and an overall project schedule
(Appendix F). We will also discuss project milestones.
4.1 Network Diagram and Schedule
A network diagram is a visual representation of a project’s schedule. It is useful for planning and
tracking the project from beginning to finish. The CoSangRA application will be accomplished
over the course of an estimated 256 days beginning on February 4, 2019 and ending on January
27, 2020. The project is divided into six phases, which will consist of a total of 31 tasks. There
will be six total milestones, each of which is a representation of “Phase Completion.”
Phase 1: Project Starting - Milestone A. Consists of 5 tasks and has a duration of 91 days
(from Feb 4, 2019 to June 10, 2019)
Phase 2: Logical Application Designing - Consists of 10 tasks and has a duration of 98
days (from May 27, 2019 to October 9, 2019)
Phase 3: Physical Layer Designing - Milestone B. Consists of 3 tasks and has a duration
of 110 days (from June 6, 2019 to Nov 8, 2019)
Phase 4: Programming and Unit Testing - Consists of 3 tasks and has a duration of 55
days (from June 6, 2019 to August 8, 2019)
Phase 5: System Testing - Consists of 4 tasks and has a duration of 58 days (from July 7,
2019 to Oct 16, 2019)
Phase 6: Implementation - Milestone C. Consists of 4 tasks and has a duration of 12 days
(from January 10, 2020 to Jan 27, 2020).
BU MET AD 642 PROJECT PLAN - GROUP 3 TEAM C 10
Because multiple tasks will be worked concurrently but are dependent to their specific “Phase
Completion Milestone,” a change in scope would potentially affect that specific milestone
completion date and can cause a shift to the right of the final deadline of Milestone C.
The network diagram (Appendix E) depicts the critical paths for each task. The critical path trails
from ID 2 “Project Start” to Milestone C, and since all task are dependent on one another with
multiple milestones there is very minimal amount of float or slack in our project. Currently, there
are only 35 days of total float, 25 days of free float from Task 4 to Task 10, and 10 days of float
from Task 10 to Task 11. That being said, if there was to be a scope change it could create
approximately 45 to 80 days of float in Phase 2 and Phase 3 due to reliance on the Phase 1
actions.
The MS Project network diagram was later used to create the project schedule (see Appendix F).
A project schedule is a document collecting all the work needed to deliver the project on time.
4.2 Gantt Chart
A Gantt Chart provides a graphical timeline of the project schedule and work streams. Our team
developed one (Appendix E.2) using MS Project. All Critical Tasks are colored in light pink,
Noncritical Tasks in light orange, and Milestones in a blue diamond.
4.3 Milestones
Milestones depict specific areas of completion such as key deliverables, start and end dates to
project phases, and client or stakeholder approvals. The CoSangRA team has identified the
project milestones by phase completion, referenced by date within the gantt chart (Appendix E.2)
and network diagram (Appendix E.2). Milestones are represented in the network diagram by a
diamond shape (Schwalbe, 2017). The project milestones we identified consist of the 6 major
“Phase Completions” and the 7th and final “Milestone C/Project Completion.” All milestones are
BU MET AD 642 PROJECT PLAN - GROUP 3 TEAM C 11
represented in the network diagram where the critical path is identified to achieve project
completion. The beginning, middle, and endpoints of the project are identified as Milestones A,
B, and C, while the others are identified by a number. Milestone A (Phase 1 Completion) is
scheduled for June 10, 2019. Milestone 2 (Phase 2 Completion) is scheduled for Oct 09, 2019.
Milestone B (Phase 3 Completion) is scheduled for Nov 8, 2019. Milestone 4 (Phase 4
Completion) is scheduled for Aug 25, 2019. Milestone 5 (Phase 5 Completion) is scheduled for
Oct 16, 2019. Milestone 6 (Phase 6 Completion) is scheduled for Jan 27, 2020. The Project
completion Milestone C is scheduled for and has a deadline of Jan 27, 2019. We identified these
deliverables based off of the relationships between phases, as well as the need to ensure
completion dates are met within the agreed timeline. The milestones will also allow the team to
complete their respective phases sufficiently and ensure that the application is developed in the
most productive and fail proof manner possible.
5.0 Budget Estimate
Project cost management includes the processes required to ensure that a project team completes
a project within an approved budget (Schwalbe, 2017). Estimating costs involved developing an
approximation of the cost of each resource necessary for project completion. Cost budgeting
involves allocating the overall cost estimate to individual activities over time in order to establish
a baseline for measuring performance (Schwalbe, 2017). The project cost management plan (see
Appendix G) was developed to align with the following activities:
❖ Project scheduling (Appendix F)
❖ Project risk management planning (Appendix J)
BU MET AD 642 PROJECT PLAN - GROUP 3 TEAM C 12
The cost baseline was created by estimating the costs by the 256-day period that the project
would be completed, starting February 4, 2019 and ending January 27, 2020.
The process of budgeting was initiated early in the CoSangRA application project, when the total
budget ($500,000) was established. In this project, the budget estimate (see Appendix G)
increases based on labor cost, since the largest deliverables are rational database designing and
developing program modules. This relies heavily on the efficiency project’s PMs utilizing their
skills in designing and developing.
6.0 Project Risks
The risk management plan is the key platform and procedure for managing risk throughout the
life of a project (Schwalbe, 2017). Anticipated risks were first outlined in our project charter
(Appendix A). After gaining an understanding of the work needed to achieve project objectives,
then building scheduling estimates for those efforts outlined in the WBS, followed by assessing
financial costs for the work based on costing estimates, project tasks had to be decomposed
further in order to populate the risk register for the project and product and develop of risk
response plan (see Appendices H1 - H7).
6.1 - Risk Identification
Risk Register
The development of a risk register (Appendix H.1) involved reviewing each task in the WBS,
including a given task’s characteristics -- duration, relation to the critical path, costs, resource or
other constraints, as well as enterprise environmental factors -- in order to identify threats (see
Appendix H.7). Because the project is pre-launch as well as non-commercial and humanitarian
BU MET AD 642 PROJECT PLAN - GROUP 3 TEAM C 13
nature, the analysis focused on threats, deferring the identification of opportunities to a later
implementation stage.
Threats
Threat characteristics, on the other hand, were derived from the complement of task
characteristics (Appendix H.5). For example, task number nine is on the critical path.
Therefore, achieving the scheduled delivery of project objectives is dependent on task number
nine’s timely execution. As a consequence, task number nine was deemed to be vulnerable to
the inside threat of delays resulting from incomplete requirements.
Risk Breakdown Structure, Decision Trees, Monte Carlo Simulations
Risks were introduced into the risk register, given a risk score, and -- using a risk breakdown
structure -- prioritized (see Appendices H.1 and H.6, respectively). Risk scores were a function
of probable frequency and projected impact calculations. Preliminary responses were listed (see
Appendix H.2). TreePlan, a decision tree decision support tool, was used to support cost-benefit
analysis of the risk response resulting from the severest threat because it was the most expensive
response. Risk triggers, assumptions, root causes, and warning signs were also delineated. To
assess the probable impacts of all the identified risks, the probability of occurrence, and impact
on both costs and duration were projected using Monte Carlo simulation, provided by Intaver
Institute RiskyProject tool (see Appendix H.4), and then plotted on a heat map (see Appendix
H.3). For threat of incomplete requirements, as well as others, the profile was associated with a
valuation of the projected exposure based both on the individual cost of that particular task as
well as those other tasks that are dependent on it. Dependencies defined in the WBS informed
the simulation runs (see Appendix H.7).
BU MET AD 642 PROJECT PLAN - GROUP 3 TEAM C 14
Sensitivity Analysis
Both individual project risks and sources of overall project risk were identified. Dependency
levels were assessed using sensitivity analysis of both duration and cost (see Appendix H.5).
When tasks foundational to the project as a whole were identified, the exposure was based on the
aggregate value of the project (see Appendix H.1). The RiskyProject default algorithms were
used because they seemed in line with our observations:
❖ Combined impact = maximum impact of all categories; for example Cost Impact
is 30%, Schedule Impact is 40%, and Safety Impact is 10%. Total impact is 40%
❖ Combined impact = sum of impacts in each category and then normalized; for
example Total impact will be 70%. However if total impact for at least one risk in
risk register will exceed 100%, all impacts for all risk register will be
proportionally reduced to ensure that on impact is greater than 100%.
The risk register (Appendix H.1) is selective, not exhaustive. Threats identified as the source of
risks in the risk register were were members of one of two categories. One category external
threats, for example the failure of cloud services platform. Substantive threats in this category
tended to be lower in frequency and high impact. The other category was internal threats, which -
- when substantive -- tended toward both high frequency and impact. RiskyProject does not plot
risks that fell below a low priority threshold, which seems like a logical way to present copious
and complex information.
6.2 Risk Management Plan
Risk Strategy
The two primary approaches to risk response for this project are avoidance of controllable risks
and transfer of uncontrollable, external risks. Based on probability analysis of some controllable
BU MET AD 642 PROJECT PLAN - GROUP 3 TEAM C 15
risks, should overruns occur, we have defined risk tolerances and will accept additional risks
within those tolerance ranges (see appendices H.1 - H.4).
Roles and Responsibilities
The primary mechanism for risk management is the periodic management reviews embedded at
the start and end of each phase. The participants on the review committee have primary
responsibility for iterative risk reviews.
Funding
The primary mechanism for funding risk management is the periodic management funding
reviews embedded at the start and end of each phase. The participants on the review committee
have primary responsibility for iterative reviews. Identified shortfalls are to be reported to the
investment sources.
Timing
Risk management reviews are scheduled to occur monthly. Avoidance actions are to be
integrated into the project schedule. Mitigation actions will be scheduled as required.
Risk Categories
During risk identification, risks were grouped into four categories: technology, performance,
legal, and quality, and were presented in a risk breakdown structure (RBS) (see Appendix H.6).
6.3 Benefits Realization and Sustainability
The CoSangRa application is designed to solve an immediate problem described by Thon
(2019): recent record-cold temperatures exposed a key problem underlying our nation’s blood
donation system. It relies exclusively on volunteer donors to provide blood for transfusion. But
bad weather routinely keeps potential donors away — as do good weather and holidays.” Levin
(2015) describes benefits realization as having an “...emphasis on benefits involves identifying
BU MET AD 642 PROJECT PLAN - GROUP 3 TEAM C 16
the benefits a program or project can provide in order to justify it, planning for how the benefits
are to be realized successfully, monitoring and tracking the benefits and preparing a benefit
report on a regular basis, and closing the program or project once all of the benefits have been
attained and can then be transitioned to customers or an ongoing operational unit so they can be
sustained.” The purpose of this project, as previously stated, is to develop and deploy an
application facilitates collection of humanitarian aid in the form of blood donations by
implementing a cloud based application infrastructure supporting distributed blood retrieval.
Managing the risks to the costs and duration of this project, and ensuring this project is
completed on time and on budget, could save many lives. According to recent studies, extreme
weather events are projected to increase in frequency and severity, resulting in a sustainable need
for this blood-gathering platform (European Academies' Science Advisory Council, Leopoldina -
Nationale Akademie der Wissenschaften, 2018)
7.0 Conclusion
So far in this paper, we have discussed the CoSangRA mobile application project charter and
scope, the WBS, the network diagram and schedule, the project budget, and associated risks. The
CoSangRA Project Management Team is proud of the work that we have done, and hopes that
the American Red Cross will face continued success in part from our application, and that the
app will directly result in spared lives for years to come. As an extension to this conclusion, we
will go on to discuss how we will continue to measure project outcome success, how project
communications were conducted successfully, and, lastly, the lessons that the team learned from
the project from each of the five process groups.
BU MET AD 642 PROJECT PLAN - GROUP 3 TEAM C 17
7.1 Success Measurements
Several success metrics were constructed to measure the outcome and effectiveness of the
CoSangRA application project. These are identified in Table 1 (also part J of Appendix A).
Table 1: Success metrics for CoSangRA application
Metrics How Measured?
App downloads Monitor internal tracking
Number of concurrent donors
participating
Analyze system logs
Preference of using this system over
attending traditional blood drives
Post-implementation volunteer surveys
Number of donations retrieved in less
than 8 hours of disaster cessation
Create a report of ratio of victims requiring blood
infusion to number of donations delivered to victims
Less than 10 bugs reported in the first
month of implementation
Error and bug logs
7.2 Communications Plan
In order to monitor and standardize communication throughout the project, our team kept a
running communications matrix (Appendix I). This matrix documents each type of routine
communication, both internal and external to the project team. It describes how frequently the
communication occurred, the owner of the communication, its target audience, and the vehicle
used to distribute the information. According to the class text, monitoring communications
throughout the project life cycle ensures that stakeholder information needs are met. It is a
crucial part of the monitoring and controlling process group, which of course occurs throughout
the project’s duration rather than just towards the end (Schwalbe, 2017). In our project’s case,
BU MET AD 642 PROJECT PLAN - GROUP 3 TEAM C 18
there were eight standard communication events: overall project status meetings, executive and
sponsor updates, a project kickoff meeting, technical design meetings, creative design meetings,
risk management communication, budget/financial updates, application testing information, and
application implementation training and communication. Each served a crucial role in keeping
project stakeholders up to date and in sync, thus ensuring project success.
7.3 Lessons Learned and Recommendations
Lessons learned are provided by all five PMs involved in the project. Table 2 (see Appendix K)
lists the lessons the project team learned over the course of completing the CoSangRA
application project. It is important to document lessons learned throughout the project in order to
conserve useful information and knowledge that can be leveraged for future projects. Project
management offices (PMOs), for example, harbor important historical information related to past
projects that provide guidance for successful project completions. Important to note here is that
every project is different and unique, so there really is no one-size-fits-all blueprint for success as
it relates to historical project information. The point here is that lessons learned play an
important part in project management and CoSangRA’s PMs reserved vital notes and documents
related to the development of the project. These important lessons lay the groundwork for project
recommendations (see Appendix K).
7.3.0 Initiating Process Group
Initiating processes include actions to define and authorize new projects and project phases
(Schwalbe, 2017). In CoSangRA’s case, a kick-off meeting was used during initiation and the
project charter was created. The project charter was agreed upon by all five PMs involved in the
project. Important to note here, however, was its ability to be reviewed by all stakeholders
throughout the development of the CoSangRA application as more detailed planning elements
BU MET AD 642 PROJECT PLAN - GROUP 3 TEAM C 19
like the schedule, milestones, and budget elements became available. This process reflected LL3
in Table 2 (See Appendix K).
Moreover, as the project plan neared completion, the project charter (see Appendix A) was
updated to reflect altered project details that would be reviewed by all stakeholders involved in
the project including the five PMs. Given this instance, the planning process group was invoked
prior to the completion of the initiating process group, and the two worked simultaneously due to
the fact that process groups are not linear (Gomes, Oliveira & Chaves, 2018).
7.3.1 Planning Process Group
The planning process included devising and maintaining a workable scheme to ensure that the
project is meeting its scope, schedule, and cost goals as well as organizational needs. The
planning process group was given the proper amount of time, care, and consideration so that the
project would be done correctly, avoiding costly re-works and delays.
7.3.2 Executing Process Group
Staskiewicz, J. (2015) explains that it is recommended that execution begin with a kick off
meeting with all stakeholders to review the charter, scope, and schedule upon charter sign off.
The PMs developing the CoSangRA application formally accomplished this because the kick-off
meeting is such a critical part of a project. During the meeting, the project’s tone was set, its
vision and background were discussed, common project goals were shared, and stakeholder
relationships were established. The kickoff meeting established the general expectations for an
enhanced understanding of the need for flexible scheduling, as the project team members
operated and communicated in a virtual environment. This was in accordance with LL2, LL4,
LL8, LL9, and LL11 from Table 2 (see Appendix K). A project management team inclusive of
its project sponsor (see Appendix B) formed, and milestone review meetings were scheduled.
BU MET AD 642 PROJECT PLAN - GROUP 3 TEAM C 20
The following was discussed during these meetings:
❖ Per LL5 from Table 2 (see Appendix K), the project charter was reviewed, and its
maintenance consolidated to review each deliverable as it expands on the project charter
sections agreed upon that required status updates. All decisions on potential changes to
several of these updates were thoroughly discussed and agreed upon.
❖ Review and update the project risk register (see Appendix H.1). All decisions on
potential changes to several of these updates were thoroughly discussed and agreed upon.
❖ Project milestones were evaluated and confirmed to be completed. Once it was confirmed
that the milestones were completed successfully, per LL6 from Table 2 (see Appendix
K), discussions were held regarding the next step in the project process.
7.3.3 Monitoring and Controlling Process Group
A Guide to the Project Management Body of Knowledge (PMBOK® Guide) (PMI) documents
basic concepts regarding monitoring and controlling (Hayes Munson, 2012). In CoSangRA’s
case, the project management team focused on translating information gathered via the
monitoring and controlling processes regarding project execution into actionable knowledge.
Therefore, the monitoring and controlling processes were created to measure progress toward
achieving project goals, monitoring deviation from plans, and taking corrective action to match
progress with plans and stakeholder expectations.
7.3.4 Closing Process Group
The closing process includes formalizing acceptance of the project and bringing it to an orderly
end. It will include the completion of all WBS items (see Appendix D). Project files will be
archived, contracts will be closed, lessons learned will be documented and formal acceptance of
BU MET AD 642 PROJECT PLAN - GROUP 3 TEAM C 21
the deliverables will be received. It will also be important to plan for a smooth transition of the
results of the project to the responsible operational groups.
7.3.5 Application of Recommendations
The suggested recommendations are meant to ensure the success of the CoSangRA application
project. As previously mentioned, lessons learned (see Appendix K) play an important part in
project management and CoSangRA’s PMs reserved vital notes and documents related to the
development of the project are to be shared and used to guide future projects. Sharing lessons
learned and recommendations can help others avoid rework, optimize time, and reduce cost
(Gomes, Oliveira & Chaves, 2018).
BU MET AD 642 PROJECT PLAN - GROUP 3 TEAM C 22
References
American Red Cross. (n.d.). About us. Retrieved March 3, 2019 from
https://www.redcross.org/about-us.html.
European Academies' Science Advisory Council, Leopoldina - Nationale Akademie der
Wissenschaften. (2018, March 21). New data confirm increased frequency of extreme
weather events: European national science academies urge further action on climate
change adaptation. ScienceDaily. Retrieved February 28, 2019 from
www.sciencedaily.com/releases/2018/03/180321130859.htm
Gomes, F., Oliveira, M., & Chaves, M. (2018). An analysis of the relationship between
knowledge sharing and the project management process groups. Knowledge and Process
Management, 25(3), 168-179.
Hayes Munson, K. A. (2012). How do you know the status of your project?: Project monitoring
and controlling. Paper presented at PMI® Global Congress 2012—North America,
Vancouver, British Columbia, Canada. Newtown Square, PA: Project Management
Institute.
Levin, G. (2015). Benefits – a necessity to deliver business value and a culture change but how
do we achieve them? Paper presented at PMI® Global Congress 2015—North America,
Orlando, FL. Newtown Square, PA: Project Management Institute.
Project Management Institute. (2008). A guide to the project management body of knowledge
(PMBOK Guide) (6th ed., pp. 10,). Newtown Square, Pa. Project Management Institute,
http://www.pmi.org/learning/thought-leadership pulse (accessed February 28, 2019).
Schwalbe, K. (2017). Introduction to Project Management, Sixth Edition (6th ed.).
BU MET AD 642 PROJECT PLAN - GROUP 3 TEAM C 23
Thon, J. (2019, February 27). We need more than blood drives to solve shortages of platelets.
Retrieved February 28, 2019, from https://www.statnews.com/2019/02/28/blood-
platelets-shortages-new-approache/
BU MET AD 642 PROJECT PLAN - GROUP 3 TEAM C 24
Appendix A - Project Charter
A. General Information
Project Title: Development of the CoSangRA Mobile Application
(colligentes sanguinem ratio – a system to gather blood)
Brief Project
Description:
Situation - During disasters, either natural or man-made, a heightened need for
blood donations is often a detrimental factor in the aftermath. Current blood
donation protocol requires set up, staffing, awareness of, and transportation to a
blood drive. Additionally, donated blood expires, so it is impossible to stock up to
prepare for the next big disaster.
Proposal - The CoSangRA mobile application will connect volunteer American
Red Cross phlebotomists (blood-collection professionals) with willing blood donors
in their own homes. The system will consist of several functional layers including:
❖ A software-based, satellite-linked logistics management substrate and
communications network
❖ Phlebotomist and donor tracking database (including phlebotomist license
confirmation and background check)
❖ Deployment of drones and/or vans to deliver phlebotomy supplies and
retrieve collected blood
❖ High-level security to protect private health information (PHI)
❖ Risk measurement capabilities including predictive analytics
Prepared By: Group 3 Team C
Date: March 1, 2019 Version: 2
B. Project Objectives
The CoSangRA project aims to upgrade the existing blood collection platforms during emergent
situations by supplementing existing blood collection channels with innovative gathering
mechanisms. The intent of the upgrade is to facilitate awareness of need for and the acquisition
of blood during circumstances that prevent or dissuade a sufficient number of donors from being
able to travel to collection points, thus preventing them from donating all together.
1. To determine and validate the features necessary for this application.
2. Complete the application development and system implementation on time, and within
budget.
3. Provide reporting on project requirements using established performance metrics.
BU MET AD 642 PROJECT PLAN - GROUP 3 TEAM C 25
C. Assumptions
1. Disasters will occur and will result in an influx of hospital patients requiring donated blood
in a timely manner.
2. 2. There is a high level of frustration during situations of disaster, when life support
resources, blood in particular, are available but inaccessible to the medical facilities trying
to serve victims.
3. The system implications from developing such an app are technologically feasible, as well
as reasonably within budget.
4. An appropriate budget has been established for a full, successful implementation of this app
and blood collection system.
5. Under certain circumstances, collection systems increase the risk exposure for several
stakeholders in recovery exercises including but not limited to donors, victims, and medical
professionals.
6. Feature testing will successfully identify and assist in resolving bugs.
7. Subject Matter Experts (SMEs), volunteers, and other resources are available throughout the
project’s life.
8. The application is being developed for use within the United States and its territories.
D. Project Scope
The CoSangRA project will serve to develop and implement an application that will facilitate a
blood-gathering system that will incorporate new, improved technologies adapted to traversing
disaster-ravaged terrains in a timely manner, and transmission of both physical and electronic
subject matter expertise. This will be completed by January 27, 2020.
Deliverables:
❖ SME survey to determine desired features, functionalities, and interface needs
❖ Report of final requirements with sign-off from project sponsors
❖ Functional design draft – an outlined design that meets the project requirements
❖ Technical design draft – an outlined technical architecture of the application
❖ The CoSangRA mobile application
❖ An explanation to the American Red Cross of necessary system implementations,
specifically manned or unmanned all-terrain blood and supply transportation technologies
❖ Post deployment reports (feedback and incident reports).
BU MET AD 642 PROJECT PLAN - GROUP 3 TEAM C 26
Specifically excluded from this project is the on-going deployment, management, and application of
the CoSangRA system to various international locations, as well as the ongoing maintenance
necessary to maintain the application and resulting process additions.
E. Project Milestones
Milestone Deliverable Date
Phase #1: Requirements Gathering
Kick-off Meeting with
CoSangRA Project
Sponsor
General requirements, objectives Feb 4, 2019
Develop Approach for
Defining Requirements
The creation of Subject Matter Expert (SME) survey with
questions based feature, functionality, interface, etc.
Mar 22, 2019
Gather System
Requirements
Collect input from SMEs to determine requirements.
Customized survey question based on function and
contributor’s domain of expertise
April 22, 2019
Final Requirements Use kick-off information, analysis, and survey data to
generate final project requirements and get sign-off from
project sponsors
June 10, 2019
Phase #2: Development
Design Technical design document is created which outlines
technical architecture to be created
Oct 9, 2019
Development CoSangRA application architecture complete Nov 8, 2019
Testing Verify testing results meet Project Requirements Aug 25, 2019
Identify Effects on
Current System
Relay to American Red Cross what will be necessary to
support our application’s impact upon implementation
Jan 14, 2020
BU MET AD 642 PROJECT PLAN - GROUP 3 TEAM C 27
Deployment CoSangRA system advertised by the American Red Cross.
Live usage of the application in accordance with blood
collection system developments
Jan 27, 2020
Post-Deployment Gather performance data, feedback reports, and incident
reports; close the project and evaluate lessons learned
Jan 27, 2019
F. Impact Statement
Potential Impact Systems/Units Impacted
New, unfamiliar system may fail to inspire
confidence in donors.
victims, volunteer phlebotomists
Leaves room for technology errors to cause
tangible implementation errors.
IT Department, volunteer donors and
phlebotomists, American Red Cross
May be cost-prohibitive for certain venues. American Red Cross, victims
Successful use relies on willingness of volunteers,
app usability and accessibility.
victims, volunteer phlebotomist
G. Roles and Responsibilities
Executive Sponsor
Name Role
Richard Schoenfeld VP of Information Technology, American Red Cross
Project Managers
BU MET AD 642 PROJECT PLAN - GROUP 3 TEAM C 28
Name Email / Phone Lead Week
James Taylor
Bette Midler
Cecelia Zhang
Yulia Petrenkov
Marty Wan
Project Team Members
Name Email / Phone
As above
Identified Stakeholders
Project Management Team Project Sponsor
Local Government Existing and Potential Donors
BU MET AD 642 PROJECT PLAN - GROUP 3 TEAM C 29
The American Red Cross Medical Professionals & Phlebotomists
H. Resources
Resource Constraints
Project Budget $500,000.00 - This estimate is based on similar projects undertaken.
Timing February 4, 2019 - January 27, 2020
I. Project Risks
Risk Mitigation Strategy
Red Cross implementation difficulties. Outline the effects this application is expected to have on their
service provision and donation volumes.
Cannot prove effective usability until a disaster occurs Perform stress tests to simulate usage during disasters. Reward
participation.
Feature testing may not identify all bugs and issues Create robust and comprehensive testing scripts and an easy to
use process for reporting issues. Reward bug reporters.
Unanticipated or unprecedented adverse crisis
conditions manifest that undermine system
effectiveness
Use modular engineering to facilitate rapid redesign and
component repurposing.
SMEs may not be engaged in the surveys, testing or
results
Encourage participation in testing process and issue reporting.
Reward participation.
J. Success Measurements
Metrics How Measured?
App downloads Monitor internal tracking
Number of concurrent donors
participating
Analyze system logs
Preference of using this system over
attending traditional blood drives
Post-implementation volunteer surveys
BU MET AD 642 PROJECT PLAN - GROUP 3 TEAM C 30
Number of donations retrieved in less
than 8 hours of disaster cessation
Create a report of ratio of victims requiring blood
infusion to number of donations delivered to victims
Less than 10 bugs reported in the first
month of implementation
Error and bug logs
K. Approvals
Stakeholders
Name Signature Date
Executive Sponsor
Name Signature Date
Project Manager
Name Signature Date
BU MET AD 642 PROJECT PLAN - GROUP 3 TEAM C 31
Appendix B - Stakeholder Register
Stakeholders
Position/ Organization Name Threats Opportunities
Project Management
Team
James Taylor
Bette Midler
Cecelia Zhang
Yulia Petrenkov
Marty Wan
Time constraints, lack of
knowledge surrounding app
development
Desire to learn, strong vision,
solid team culture
Project Sponsor Richard Schoenfeld,
VP of IT at the
American Red Cross
High demands for project,
enforced deadlines
Supportive, responds to questions
and concerns immediately
Existing and Potential
Blood Donors
Lack of knowledge surrounding
app/technology usage and
awareness, fear of allowing
phlebotomists in own home
Can provide greater volume of
blood, thus increasing number of
lives saved
Local Government Regulatory constraints,
increased risk of legal issues due
to at-home implications
Can fund, facilitate access, and
mandate participation
The American Red Cross
as an organization & its
Executives
May decline to participate out of
distrust of “foreign” personnel
and technology
Have on-the-ground knowledge
about spectrum of transportation,
communications, non-official
intelligence
Medical Professionals &
Phlebotomists
Lack of volunteer willingness
due to increased effort
requirement
Can provide greater volume of
blood, thus increasing number of
lives saved
BU MET AD 642 PROJECT PLAN - GROUP 3 TEAM C 32
Appendix C – Project Priority Matrix
Project Priority Matrix
Project Priority Matrix
Scope Cost Schedule
Constraint
Enhance
Accept
Constraint Project Specific:
The application must be able to effectively function during times of disaster. Disastrous
consequences could include the release of private health information, unqualified
phlebotomists performing blood draws, and willing donors being unmatched with
phlebotomists. Additionally, a lack of proper functionality could lead to permanent loss of
trust in the app, exponentially increasing its chances of failure.
Enhance Project Specific:
Releasing the application before the next disaster strikes could lead directly to a decreased
loss of life. If the app is released late, the opportunity cost could equal the loss of lives that
otherwise could have been saved due to blood collected through app-facilitated donation.
Accept Project Specific:
Cost is considered a weak constraint, in our case. Although cost is affirmatively considered
a constraint and is objectively important, a $500,000 budget would more than suffice for a
project of this magnitude. Additionally, an IT project such as a mobile application is less
likely to face surprise costs than a construction project or event is.
BU MET AD 642 PROJECT PLAN - GROUP 3 TEAM C 33
Appendix D - Work Breakdown Structure (WBS)
D.1 - Numeric Work Breakdown Structure (WBS)
ID Product Elements
1 CoSangra Application
1.1 Phase 1: Project Starting
1.1.1 Requirements Funding
1.1.2 Problem or Opportunity Defining
1.1.3 System Requirements Documenting
1.1.4 Systems Architecture Validation
1.1.5 Management Reviewing / Phase 2 Funding
1.2 Phase 2: Logical Application Designing
1.2.1 Detailed Data Requirements Identifying
1.2.2 Prototype or User System View Developing
1.2.3 Database Designing
1.2.4 Processes Structuring
1.2.5 Interfaces Designing
1.2.6 All Inputs and Outputs Specifying
1.2.7 Preliminary Test and Conversion Procedures Developing
1.2.8 Logical Design Validating
1.2.9 System Architecture Validating
1.2.10 Management Reviewing / Phase 3 Funding
1.3 Phase 3: Physical Layer Designing
1.3.1 Relational Database Designing
1.3.2 Procedure Definitions Creating
1.3.3 Test Procedure Developing
1.4 Phase 4: Programming and Unit Testing
1.4.1 Program Modules Developing
1.4.2 Test/Conversion Procedures Updating
1.4.3 Management Reviewing / Phase 5 Funding
1.5 Phase 5: System Test
1.5.1 Integrated System Test Plan Finalizing
1.5.2 User Acceptance/Training Test Finalizing
1.5.3 User Acceptance/Training Test Conducting
1.5.4 Management Reviewing / Phase 6 Funding
1.6 Phase 6: Implementation
1.6.1 Software Installing
BU MET AD 642 PROJECT PLAN - GROUP 3 TEAM C 34
1.6.2 Management Reviewing
1.6.3 Effects on Actual Blood Collection Process Identification
1.6.4 Reevaluate Development Costs
D.2 - Graphical Work Breakdown Structure (WBS)
D.3 - WBS Dictionary
WBS Dictionary
1.1 Project Starting
Work Package ID 1.1.1
BU MET AD 642 PROJECT PLAN - GROUP 3 TEAM C 35
Work Package Name Requirements Funding
Work Package Description Submit funding approval request to program management.
Deliverables Funding Proposal/Approval
Duration (Hours) 120
Resource Requirements Project Manager, Program Management Office, Proposal and Contract
Department Managers, IT Architecture Director
Cost $7,260
Dependencies Defined Scope of CoSangRA Project
Work Package ID 1.1.2
Work Package Name Problem or Opportunity Defining
Work Package Description Define opportunities and potential problems of project scope.
Deliverables Finalized Project Scope with customer sign-off
Duration (Hours) 168
Resource Requirements Red Cross End Users (customer), IT Architecture Lead, Project Manager
Cost $10,140
Dependencies Define Scope of CoSangRA Project
Work Package ID 1.1.3
Work Package Name System Requirements Documenting
Work Package Description Documenting customer requirements and system requirements to use
during project development execution.
Deliverables System Requirements
Duration (Hours) 160
Resource Requirements Red Cross End Users (customer), IT Architect Lead, Project Manager, IT
Software Development Team
BU MET AD 642 PROJECT PLAN - GROUP 3 TEAM C 36
Cost $9,660
Dependencies 1.1.1
Work Package ID 1.1.4
Work Package Name Systems Architecture Validation
Work Package Description Validating integration of device software, CoSangra software and user
interface.
Deliverables Architectural Design Map
Duration (Hours) 80
Resource Requirements IT Architect Lead, Project Manager, IT Software Development Team,
CoSangra User Interface Developers
Cost $4,860
Dependencies 1.1.3
Work Package ID 1.1.5
Work Package Name Management Reviewing / Phase 2 Funding
Work Package Description Management review of CoSangra system requirements and architecture
validation and phase 2 funding requests.
Deliverables Project Manager and Program Manager Approval
Duration (Hours) 48
Resource Requirements Project Management Office, Program Management Office, Financial
Planning & Analysis, Business Team
Cost $2,940
Dependencies 1.1.1, 1.1.2, 1.1.3, 1.1.4
1.2 Logical Application Designing
Work Package ID 1.2.1
Work Package Name Detailed Data Requirements Identifying
Work Package Description Identify and consolidate required data from cross-functional IT
CoSangRA teams and have architect validate proposed requirements.
BU MET AD 642 PROJECT PLAN - GROUP 3 TEAM C 37
Deliverables Data Requirements Review
Duration (Hours) 80
Resource Requirements IT Architect Lead, Project Manager, IT Software Development Team,
CoSangRA User Interface Developers
Cost $10,980
Dependencies 1.1
Work Package ID 1.2.2
Work Package Name Prototype or User System View Developing
Work Package Description IT development teams work to develop initial prototype and user system
based on customer’s scope criteria.
Deliverables Application Prototype
Duration (Hours) 200
Resource Requirements IT Architect Lead, Project Manager, IT Software Development Team,
CoSangra User Interface Developers
Cost $16,080
Dependencies 1.2.1
Work Package ID 1.2.3
Work Package Name Database Designing
Work Package Description IT Software team develops database design based on data requirements
and initial application prototype.
Deliverables Initial Database Design
Duration (Hours) 120
Resource Requirements IT Software Development Team, CoSangra User Interface Developers
Cost $9,680
Dependencies 1.2.1, 1.2.2
Work Package ID 1.2.4
BU MET AD 642 PROJECT PLAN - GROUP 3 TEAM C 38
Work Package Name Processes Structuring
Work Package Description Creating a process structure to integrate various CoSangRA project
elements associated with overall application development.
Deliverables Process Map
Duration (Hours) 16
Resource Requirements IT Architect Lead, Project Manager, IT Software Development Team,
CoSangra User Interface Developers
Cost $1,360
Dependencies 1.2.1, 1.2.2. 1.2.3
Work Package ID 1.2.5
Work Package Name Interface Designing
Work Package Description Development of user interface design.
Deliverables User Interface
Duration (Hours) 40
Resource Requirements CoSangRA User Interface Developers, Project Manager
Cost $3,280
Dependencies 1.2.1, 1.2.2
Work Package ID 1.2.6
Work Package Name All Inputs and Outputs Specifying
Work Package Description Identify all required inputs and outputs connecting software to user
interface.
Deliverables Input and Output Matrix
Duration (Hours) 24
Resource Requirements IT Software Development Team, CoSangra User Interface Developers
BU MET AD 642 PROJECT PLAN - GROUP 3 TEAM C 39
Cost $2,000
Dependencies 1.2.1, 1.2.2, 1.2.3, 1.2.5
Work Package ID 1.2.7
Work Package Name Preliminary Test and Conversion Procedures Developing
Work Package Description Development of test procedures in preparation for transitioning
application script into the testing environment.
Deliverables Test and Conversion Procedural Document
Duration (Hours) 24
Resource Requirements IT Architect Lead, Project Manager, IT Software Development Team,
CoSangRA User Interface Developers
Cost $2,000
Dependencies 1.2.1 - 1.2.5
Work Package ID 1.2.8
Work Package Name Logical Design Validating
Work Package Description Review and validation of system logic, ensuring the logic is reliable and
prepared for internal testing.
Deliverables Project Manager and IT validation sign-off
Duration (Hours) 80
Resource Requirements IT Architect Lead, Project Manager, IT Software Development Team,
CoSangRA User Interface Developers
Cost $6,480
Dependencies 1.2.3 - 1.2.7
Work Package ID 1.2.9
Work Package Name System Architecture Validating
Work Package Description Validation of system integration and architecture of database design,
logic, and processing.
Deliverables IT Architect Lead and Project Manager Approval
BU MET AD 642 PROJECT PLAN - GROUP 3 TEAM C 40
Duration (Hours) 56
Resource Requirements IT Architect Lead, Project Manager
Cost $4,560
Dependencies 1.2.3 - 1.2.8
Work Package ID 1.2.10
Work Package Name Management Reviewing / Phase 3 Funding
Work Package Description Management review of phase 2 design and architectural work. Phase 3
funding request provided by project manager.
Deliverables Project Manager and Program Manager Approval
Duration (Hours) 40
Resource Requirements Project Management Office, Program Management Office, Financial
Planning & Analysis, Business Team
Cost $3,280
Dependencies 1.2.9, 1.3
1.3 Physical Layer Designing
Work Package ID 1.3.1
Work Package Name Relational Database Designing
Work Package Description Cross-functional IT integration of database information.
Deliverables Database Integration Matrix
Duration (Hours) 640
Resource Requirements IT Architect Lead, Project Manager, IT Software Development Team,
CoSangRA User Interface Developers
Cost $57,690
Dependencies 1.2.10
Work Package ID 1.3.2
BU MET AD 642 PROJECT PLAN - GROUP 3 TEAM C 41
Work Package Name Procedure Definitions Creating
Work Package Description Creating and defining procedures.
Deliverables Procedure Definitions
Duration (Hours) 200
Resource Requirements Project Manager, CoSangRA User Interface Developers
Cost $18,090
Dependencies 1.2.10
Work Package ID 1.3.3
Work Package Name Test Procedure Developing
Work Package Description Development of test procedure required to begin initial internal testing
program and unit testing.
Deliverables Test Procedure
Duration (Hours) 40
Resource Requirements Project Manager, CoSangRA User Interface Developers
Cost $3,690
Dependencies 1.2.7
1.4 Programming and Unit Testing
Work Package ID 1.4.1
Work Package Name Program Modules Developing
Work Package Description Development of program modules.
Deliverables Module Breakdown
Duration (Hours) 200
BU MET AD 642 PROJECT PLAN - GROUP 3 TEAM C 42
Resource Requirements IT Architect Lead, Project Manager, IT Software Development Team
Cost $20,100
Dependencies 1.4
Work Package ID 1.4.2
Work Package Name Test/Conversion Procedures Updating
Work Package Description Application of test procedures to confirm validity and accuracy.
Deliverables Final Test/Conversion Document
Duration (Hours) 8
Resource Requirements IT Architect Lead, IT Software Development Team
Cost $900
Dependencies 1.3
Work Package ID 1.4.3
Work Package Name Management Reviewing/Phase 5 Funding
Work Package Description Management review of phase 4 test results and deliverables. Phase 5
funding requests.
Deliverables Project Manager and Program Manager Approval
Duration (Hours) 72
Resource Requirements Project Management Office, Program Management Office, Financial
Planning & Analysis, Business Team
Cost $7,300
Dependencies 1.5
1.5 System Test
Work Package ID 1.5.1
Work Package Name Integrated System Test Plan Finalizing
BU MET AD 642 PROJECT PLAN - GROUP 3 TEAM C 43
Work Package Description Finishing the system test plan prior to engaging customer for testing.
Ensuring system integration is functioning as intended.
Deliverables System Test Plan
Duration (Hours) 120
Resource Requirements Project Manager, CoSangRA User Interface Developers, Software
Development Team, IT Architecture Lead
Cost $9,680
Dependencies 1.4.2, 1.4.3
Work Package ID 1.5.2
Work Package Name User Acceptance / Training Test Plan Finalizing
Work Package Description Project Manager and IT Architecture Lead provide training to customer
on how to use application. Work step instructions also provided to all
participants in training.
Deliverables Successful training to customer on usage of application. Work Step
Procedure Guide
Duration (Hours) 144
Resource Requirements Red Cross End Users (customer), Project Manager, CoSangra User
Interface Developers, Software Development Team
Cost $11,600
Dependencies 1.5.1
Work Package ID 1.5.3
Work Package Name User Acceptance/Training Test Conducting
Work Package Description Customer pilots the final product prior to deployment to Red Cross
organization and approval of completed CoSangRA application.
BU MET AD 642 PROJECT PLAN - GROUP 3 TEAM C 44
Deliverables Final questions and feedback from end-user, and last change requests
prior to final product deployment and sign-off.
Duration (Hours) 160
Resource Requirements Red Cross End Users (customer), Project Manager, CoSangRA User
Interface Developers, Software Development Team
Cost $18,530
Dependencies 1.5.2
Work Package ID 1.5.4
Work Package Name Management Reviewing / Phase 6 Funding
Work Package Description Management reviewing end user testing results and feedback prior to
release of final product deployment and installation.
Deliverables Project Manager and Program Manager Approval
Duration (Hours) 40
Resource Requirements Project Manager, Program Manager Approval, Business Team
Cost $3,280
Dependencies 1.5.3
1.6 Implementation
Work Package ID 1.6.1
Work Package Name Software Installing
Work Package Description Installation of software to end users preferred mobile devices.
Deliverables Deployment and installation to customer’s approved devices.
Duration (Hours) 40
Resource Requirements Red Cross End Users (customer), Project Manager, CoSangRA User
Interface Developers
Cost $2,460
BU MET AD 642 PROJECT PLAN - GROUP 3 TEAM C 45
Dependencies 1.5.3, 1.5.4
Work Package ID 1.6.2
Work Package Name Management Reviewing
Work Package Description Management team reviews final installed application.
Deliverables Management Sign-Off of final product
Duration (Hours) 40
Resource Requirements Project Manager, Program Management Office, IT Development
Manager
Cost $2,460
Dependencies 1.5.4, 1.6.1
Work Package ID 1.6.3
Work Package Name Effects on Actual Blood Collection Process Identification
Work Package Description Receive feedback from end users on field application of the final product.
Deliverables Market Feedback Analysis (MFA)
Duration (Hours) 160
Resource Requirements Red Cross End Users (customer), Project Manager, CoSangRA User
Interface Developers
Cost $9,660
Dependencies 1.6.1
Work Package ID 1.6.4
Work Package Name Reevaluate Development Costs
Work Package Description Reevaluation of development costs compared to initial proposed project
estimation to project actuals.
Deliverables CoSangRA Financials Actuals
Duration (Hours) 8
BU MET AD 642 PROJECT PLAN - GROUP 3 TEAM C 46
Resource Requirements Project Management Office, Program Management Office, Financial
Planning & Analysis, Business Team
Cost $758
Dependencies 1.6.2
BU MET AD 642 PROJECT PLAN - GROUP 3 TEAM C 47
Appendix E - Network Diagram
E.1 - Microsoft Project Network Diagram
BU MET AD 642 PROJECT PLAN - GROUP 3 TEAM C 48
BU MET AD 642 PROJECT PLAN - GROUP 3 TEAM C 49
BU MET AD 642 PROJECT PLAN - GROUP 3 TEAM C 50
Appendix E.2 - Gantt Chart
BU MET AD 642 PROJECT PLAN - GROUP 3 TEAM C 51
Appendix F - Microsoft Project Schedule
BU MET AD 642 PROJECT PLAN - GROUP 3 TEAM C 52
Appendix G – Cost Management Plan & Budget
Introduction
This project is developing a new app called CoSangRA, which is a mobile application meant to
connect volunteer American Red Cross phlebotomists (blood-collection professionals) with
willing blood donors in their own homes.
The system will consist of several functional layers including:
❖ A software-based, satellite-linked logistics management substrate and communications network
❖ Phlebotomist and donor tracking database (including Phlebotomist license confirmation and background check)
❖ HIPAA-compliant security to protect private health information (PHI) ❖ Risk measurement capabilities including predictive analytics
Project deliverables include:
❖ SME survey to determine desired features, functionalities, and interface needs. ❖ Report of final requirements with sign-off from project sponsors. ❖ Functional design draft – an outlined design that meets the project requirements. ❖ Technical design draft – an outlined technical architecture of the application. ❖ The CoSangRA web-based app and mobile application. ❖ An explanation to the American Red Cross of necessary system implementations,
specifically manned or unmanned all-terrain blood and supply transportation
technologies.
❖ Post deployment reports (feedback and incident reports)
According to deliverables, there are six main planned items: project starting, logical
application/designing, physical layer designing, programing and unit testing, system test, and
implementation.
Overall the project was budgeted as $500,000.
Cost Management Approach
1. Resource Estimate Approach: The resource estimate approach uses activity-based costing
techniques to determine expenses associated with all work packages and their associated
activities. Therefore, a bottom-up approach to calculate the overall cost is administered.
2. Resource Allocation Approach: The resource estimate approach uses activity-based resource
techniques to determine proper resource allocation strategies. Therefore, the proper resources
are delivered to the right activities at the right time.
3. Resource Leveling Approach: A critical chain approach is utilized in order to balance project
schedule and resource management.
4. Cost Reserve Approach: Cost contingency reserves are set aside to provide a contingency
allowance included in the cost baseline for any additional expenses incurred. Reserves for
similar projects generally amount to 5% - 10% of the overall project budget. CoSangRA
reserves 10% of the project’s total cost for this purpose and the 10% reserves are also based on
several known risks that may occur.
Project Overall Budget
BU MET AD 642 PROJECT PLAN - GROUP 3 TEAM C 53
Project Cost Estimate
Project Name:
CoSanRa
Date: 04-Feb-2019
WBS Categories Internal Labor
$/hour Internal
$ Total
External
Labor
$/hour External
$ Total
Other $
Costs
Labor $
Reserves
Non-Labor $
Reserves
Total Cost
1.1. Project Starting 576 $60 $34,860.00 $34,860.00
1.1.1. Requirements
Funding
120 $60 $7,260 $7,260
1.1.2. Problem or
Opportunity
Defining
168 $60 $10,140 $10,140
1.1.3. System
Requirements
Documenting
160 $60 $9,660 $9,660
1.1.4. Systems
Architecture
Validation
80 $60 $4,860 $4,860
1.1.5. Management
Reviewing / Phase 2
Funding
48 $60 $2,940
$2,940
1.2. Logical
Application
Designing / Phase 2
680 $80 $59,700
$59,700
1.2.1 Detailed Data
Requirements
Identifying
80 $80 $6,480
$4,500
$10,980
1.2.2. Prototype or User
System View
Developing
200 $80 $16,080
$16,080
1.2.3. Database
Designing
120 $80 $9,680
$9,680
1.2.4. Processes
Structuring
16 $80 $1,360
$1,360
1.2.5. Interfaces
Designing
40 $80 $3,280
$3,280
BU MET AD 642 PROJECT PLAN - GROUP 3 TEAM C 54
1.2.6. All Inputs and
Outputs Specifying
24 $80 $2,000
$2,000
1.2.7. Preliminary Test
and Conversion
Procedures
Developing
24 $80 $2,000
$2,000
1.2.8. Logical Design
Validating
80 $80 $6,480
$6,480
1.2.9. Against System
Architecture
Validating
56 $80 $4,560
$4,560
1.2.10 Management
Reviewing /
Phase 3 Funding
40 $80 $3,280
$3,280
1.3. Physical Layer
Designing /
Phase 3
880 $90 $79,470
$79,470
1.3.1. Relational Database
Designing
640 $90 $57,690
$57,690
1.3.2. Procedure
Definitions
Creating
200 $90 $18,090
$18,090
1.3.3 Test Procedure
Developing
40 $90 $3,690
$3,690
1.4. Programming and
Unit Testing
280 $100 $28,300
$28,300
1.4.1. Program Modules
Developing
200 $100 $20,100
$20,100
1.4.2. Test / Conversion
Procedures
Updating
8 $100 $900
$900
BU MET AD 642 PROJECT PLAN - GROUP 3 TEAM C 55
1.4.3. Management
Reviewing / Phase 3
Funding
72 $100 $7,300
$7,300
1.5. System Test /
Phase 5
464 $80 $43,090
$43,090
1.5.1. Integrated System
Test Plan Finalizing
120 $80 $9,680
$9,680
1.5.2. User Acceptance /
Training Test Plan
Finalizing
144 $80 $11,600
$11,600
1.5.3. User Acceptance /
Training Test
Conducting
160 $80 $12,880
$5,650
$18,530
1.5.4. Management
Reviewing /
Phase 3 Funding
40 $80 $3,280
$3,280
1.6. Implementation /
Phase 6
248 $60 $15,338
$15,338
1.6.1. Software Installing 40 $60 $2,460
$2,460
1.6.2. Management
Reviewing
40 $60 $2,460
$2,460
1.6.3. Effects on Actual
Blood Collection
Process
Identification
160 $60 $9,660
$9,660
1.6.4 Reevaluate Dev.
Cost
8 $60 $540
$218
$758
Indirect Costs (Reserves)
$26,000
$26,000
Total-Horizontal
$286,758
Total-Vertical 3,128 $250,390 $10,368 $26,000 $ - $286,758
BU MET AD 642 PROJECT PLAN - GROUP 3 TEAM C 56
Important Assumptions
1. The budget is in U.S. currency.
2. All project managers are on a contract basis and only paid for their work.
3. All project employees are assumed to be working 8-hour days.
4. Reserves estimated at 10% of overall budget to account for both known risks such as
technology, performance, and quality risks (see Appendix H):
Technology
❖ Insufficient patching that creates breach vulnerabilities ❖ Cloud services being unavailable
Performance
❖ Insufficient patching that creates breach vulnerabilities ❖ Cloud services being unavailable ❖ Incomplete requirements
Legal
❖ Insufficient patching that creates breach vulnerabilities ❖ Cloud services being unavailable ❖ Incomplete requirements
Quality
❖ Insufficient patching that creates breach vulnerabilities ❖ Incomplete requirements
Cost Change Processes
Project management team is authorized to change budget under amount of $15,000. Any change
over $15,000 must be approved by project sponsor. The overall change processes are as follow:
1. Seriously consider, develop, and submit the change proposal.
2. Project management team discusses the scale of the proposed change and the necessity of the
change request. The team also considers possible alternatives regarding the change request.
3. Project managers that considered, developed, and submitted the change request participate in a
one-on-one meeting with the project sponsor to thoroughly discuss the reasons and
background of the change request.
4. While the change is approved, the project management team executes the change.
5. Final discussion takes place between project management team to review the change, its impact
on the project, and any additional inquiries regarding the change in order to be on the same
page.
BU MET AD 642 PROJECT PLAN - GROUP 3 TEAM C 57
Appendix H - Risk Management
H.1 - Risk Register
Global Risks
BU MET AD 642 PROJECT PLAN - GROUP 3 TEAM C 58
Risk Information
BU MET AD 642 PROJECT PLAN - GROUP 3 TEAM C 59
Monitoring
BU MET AD 642 PROJECT PLAN - GROUP 3 TEAM C 60
H.2 - Risk Response Plan
BU MET AD 642 PROJECT PLAN - GROUP 3 TEAM C 61
Risk Response Plan Decision Tree Reviewing Cost-Benefits of Risk Response
H.3 - Risk Heat Map
BU MET AD 642 PROJECT PLAN - GROUP 3 TEAM C 62
H.4 - Monte Carlo Simulation
Monte Carlo Simulation - Costs
BU MET AD 642 PROJECT PLAN - GROUP 3 TEAM C 63
Monte Carlo Simulation - Duration
BU MET AD 642 PROJECT PLAN - GROUP 3 TEAM C 64
BU MET AD 642 PROJECT PLAN - GROUP 3 TEAM C 65
H.5 - Task Sensitivity Analysis
Duration
Cost
BU MET AD 642 PROJECT PLAN - GROUP 3 TEAM C 66
H.6 - Risk Breakdown Structure
H.7 - Risk Report Detail
BU MET AD 642 PROJECT PLAN - GROUP 3 TEAM C 67
BU MET AD 642 PROJECT PLAN - GROUP 3 TEAM C 68
BU MET AD 642 PROJECT PLAN - GROUP 3 TEAM C 69
BU MET AD 642 PROJECT PLAN - GROUP 3 TEAM C 70
BU MET AD 642 PROJECT PLAN - GROUP 3 TEAM C 71
BU MET AD 642 PROJECT PLAN - GROUP 3 TEAM C 72
BU MET AD 642 PROJECT PLAN - GROUP 3 TEAM C 73
BU MET AD 642 PROJECT PLAN - GROUP 3 TEAM C 74
BU MET AD 642 PROJECT PLAN - GROUP 3 TEAM C 75
BU MET AD 642 PROJECT PLAN - GROUP 3 TEAM C 76
BU MET AD 642 PROJECT PLAN - GROUP 3 TEAM C 77
BU MET AD 642 PROJECT PLAN - GROUP 3 TEAM C 78
BU MET AD 642 PROJECT PLAN - GROUP 3 TEAM C 79
BU MET AD 642 PROJECT PLAN - GROUP 3 TEAM C 80
Appendix I - Communications Matrix
BU MET AD 642 PROJECT PLAN - GROUP 3 TEAM C 81
Appendix J - Application Design/Mockups
BU MET AD 642 PROJECT PLAN - GROUP 3 TEAM C 82
Appendix K – Lessons Learned
Table 2: Lessons learned creating project plan for CoSangRA application
ID Description
LL1 Utilize Google Docs as a shared document to allow for multiple,
simultaneous, and instant edits from all CoSangRA project
management contributors. E-mail communications and attachments
are still utilized but there is a preference for leveraging shared online
document given its convenience.
LL2 Be flexible with team meeting times and dates to allow for all team
members to meet virtually when convenient to all.
LL3 Continuously update project charter throughout the CoSangRA
mobile application development process.
LL4 Focus on clear and consistent communication throughout the project
process. This means leveraging multiple communication channels
that include phones calls, texts, group messaging, e-mail, virtual
meetings, and shared online document collaboration.
LL5 Maintaining a close relationship with the project’s sponsor was
important to gain perspective, direction, and advice regarding the
project and its development.
LL6 Allocate adequate and appropriate amount of time for working on
project deliverables. Time estimates for creating these tended to be
realistic and we never scrambled toward the end of each week to
submit the final version.
LL7 Team trust was earned and developed through continuous
interactions and opportunities to talk things out, despite challenges
and disagreements regarding work distribution.
BU MET AD 642 PROJECT PLAN - GROUP 3 TEAM C 83
LL8 Weekly meetings ensured we reviewed work and determined
direction or project deliverables as a team.
LL9 A willingness and acceptance of changing the times and dates of the
weekly virtual meetups ensured that a flexible schedule would allow
for all PMs to contribute in the most convenient way possible. This
was especially important given that every PM resided in different
parts of the country.
LL10 Understanding the different backgrounds of every PM involved in
the project ensured that the proper skills were utilized for the right
work packages and project deliverables. Team member interests and
work preferences were also considered. These elements aided in
increasing engagement by all PM and an increased focus on the
quality of work completed.
LL11 Virtual meetings were decided to be the best format for continuous
weekly discussions and assignment of work deliverables and tasks to
all team members.
LL12 Quality contributions by every team member were made to ensure
“getting it right” the first time. Project deliverables were also
reviewed by all team members to confirm quality of work and
increase the deliverables chances of success.
LL13 Thoughtful research and continuous learning of the project process
was valued and prioritized in order to enhance the quality of the
project deliverable.
LL14 Creating, saving, and maintaining notes and historical information
regarding CoSangRA application project and its associated work
activities and deliverables was ensured to reserve a “library” of
relevant project data to be used for presenting the project.
