Project Management Toolkit For Communities


The tools and techniques explored in this toolkit are used in the strategic planning process developed by the True Colors Fund to address LGBTQ youth homelessness in communities across the United States. This work is informed by the federal strategic plan introduced by the U. S. Interagency Council on Homelessness (USICH), which seeks to end youth homelessness by:

  • Focusing on prevention.
  • Focusing on early identification and intervention.
  • Creating community-wide coordinated entry systems that connect youth to services based on their needs and circumstances.

In addition to stable housing, this framework is designed to support youth in achieving the following key goals: forging connections to positive social networks like family and community; completing educational activities and/or maintaining employment; and gaining the social and emotional competencies needed to thrive.

From 2014 to 2016, the True Colors Fund partnered with five federal partners (the U.S. Departments of Housing and Urban Development, Education, Health & Human Services, and Justice, along with the United States Interagency Council on Homelessness) to launch the LGBTQ Youth Homelessness Prevention Initiative. Throughout the process, the True Colors Fund provided technical assistance to stakeholders in two pilot communities – Houston, TX and Hamilton County, OH – as they identified successful strategies for preventing and ending LGBTQ youth homelessness and developed strategic plans to address the issue. Following completion of the pilot, the True Colors Fund began replicating this model to launch True Colors Community Initiatives in additional communities across the United States.

This material has been produced with a grant provided by the PMI Educational Foundation. The Project Management Institute logo and the PMI Educational Foundation logo are Marks of Project Management Institute, Inc. All other trademarks, service marks, trade names, trade dress, product names and logos appearing herein are the property of their respective owners.

This publication contains material from A Guide to the Project Management Body of Knowledge (PMBOK® Guide) – Fifth Edition, which is copyrighted material of and owned by, Project Management Institute Inc. (PMI), Copyright 2013. This publication has been developed and reproduced with the permission of PMI. Unauthorized reproduction of this material is strictly prohibited.

The PMI Educational Foundation (PMIEF) is a 501(c)(3) supporting organization of Project Management Institute (PMI), the world’s leading not-for-profit professional membership association for the project, program, and portfolio management profession. Founded in 1990, PMIEF develops, implements, and delivers innovative initiatives to leverage project management for social good globally. These include grants, scholarships, and awards as well as educational resources that strengthen project management knowledge of teachers, youth, and nonprofit organizations. PMIEF’s vision that “all people worldwide have a better tomorrow by applying project management skills in their daily lives” comes to the life through the generosity of individual and corporate donors as well as the PMI community. For additional information, visit


A True Colors Community Initiative begins with a needs-assessment conducted by the community coalition to identify what’s working, what’s not working, what’s missing, and what could be changed to address youth homelessness. Using the information learned from the assessment, the True Colors Fund then works with the coalition over a period of six months to develop a comprehensive plan to address the issue.

The technical assistance provided during the planning process includes:

  • Best practices around creating inclusive and affirming spaces for LGBTQ young people.
  • Youth collaboration philosophies to ensure young people with lived experience play an active role in creating solutions.
  • Project management practices to help local communities stay focused and organized as they develop and implement their plans.

The planning process culminates with the development of a strategic plan containing a portfolio of projects that is customized to suit the community’s specific needs. Past portfolios have included projects such as creating a 24-hour drop-in center, launching a program to increase affordable housing options, and hosting a convening to educate community leaders about the needs of LGBTQ youth.

It is important to understand that a community’s work does not culminate with the creation of a strategic plan; rather, the plan enables the work to begin. Only through effective implementation – achieved by adhering to project management best practices – will a community begin to see measurable change.

While this toolkit provides best practices, it’s important to note that there’s more than just one way to manage a project. The methods outlined should be tailored to meet the unique needs of your project and your community.

In order to directly apply the principles explored in this toolkit, we will refer to an example project commonly included in a community’s portfolio – an educational convening.

Foundation Concepts.

Project Management Terminology

First things first. A project is a temporary endeavor that produces something new. In this context, temporary means that it has a beginning, middle, and end. It is not determined by the length of time it takes for a project be completed. Some projects last many weeks while others last many years. Everyone working on a project – the project team – should be able to pinpoint the exact date the project began and the exact date the project is completed.

The output of this completed project should be something new and unique. It can be large-scale and permanent, like a renovated community center; or smaller and more immediate, like a presentation for a convening. Most importantly, this unique result should fulfill a specific set of requirements.

A project is not to be confused with operations. Unlike a project, operational activities are ongoing. They do not produce unique results, since the outputs are usually repetitive. For example, ordering routine supplies would be considered operations, while launching a new system to better manage supplies would be considered a project.

Project management is the application of knowledge, skills, tools, and techniques to ensure that a project’s activities satisfy its requirements. The person who is ultimately responsible for the day-to-day functions of moving the project forward, correcting course as needed, and successfully meeting requirements is the project manager.

The project team is the group of people with specific skills or expertise who are responsible for executing the project work.

The project sponsor ensures top-level buy-in, helps secure large-scale project resources (including human resources and funding), provides strategic direction, and authorizes a project to begin. The project sponsor can also cancel a project. It is important to note that while the term “sponsor” is often synonymous with “donor” in the nonprofit sector, it’s not necessarily the case in this context.

It is up to the project sponsor to determine the level of authority granted to the project manager. Ideally, the project sponsor should provide guidance without micromanaging and the project manager should have the autonomy to make day-to-day decisions. It is up to the community coalition to determine which stakeholders are most appropriate for which project roles. For instance, a committee chair might be a skilled facilitator, but lacks the experience necessary to manage a complex project.

An effective project manager:

  • Creates a collaborative team environment.
  • Delegates firmly and thoughtfully, setting team members up for success by giving them tasks that play to their strengths while challenging them to grow.
  • Anticipates needs of the project, the team, and other stakeholders.
  • Makes informed decisions.
  • Remains optimistic while learning from past mistakes.
  • Anticipates problems and focuses on solutions (prepares for a Plan B).
  • Manages conflict through effective negotiation techniques.
  • Offers timely and relevant feedback.
  • Exhibits integrity and cultural competence.
  • Motivates the team and drives action.

Process Groups

Oftentimes, a project’s end goal is clear, but the path is a little murky, which is why it helps to break down the project into process groups. The five essential process groups of project management include initiating, planning, executing, monitoring & controlling, and closing. Together, they make up the Project Life Cycle.

Initiate: This begins in the strategic planning process, when the community coalition conducts a needs assessment and engages in project proposal and selection. Questions to be considered during the initiate process include: What is missing within the community? What is the community trying to accomplish? How do the proposed projects align with the community’s strategic goals? What is the community not trying to do? Answers to these questions are documented in a Project Charter. The project team also begins identifying individuals and groups who will impact the project, as well as those who will be impacted by it, in a Stakeholder Register. (These two tools will be explored in detail  later in this section.)

Plan: During this process, the project team creates detailed plans based on the high-level points outlined in the project charter, including project scope, schedule, budget, communications, quality control, human resources, outsourcing, and risk. Risks are identified and logged in a Risk Register. Project work is dissected into a Work Breakdown Structure (WBS) and WBS Dictionary before it is assigned to team members and scheduled using a Network Schedule Diagram and/or Gantt Chart. (These terms will be further explored in the sections that follow.)

Execute: This is the process in which the project team carries out the work. It’s also when most of the budget will be spent and most of the deliverables produced.

Monitor & Control: Rather than occurring at a single point, Monitor & Control is an ongoing process throughout the course of a project’s life cycle. It is the process group that ensures a project remains on time, on budget, and most importantly, that it meets all requirements. Tools and techniques used during Monitor & Control include quality control tests, cost and schedule variance calculations, team meetings, and status update emails. (These terms will be further explored in the sections that follow.)

Close: This is the process group in which all project activities are finalized, invoices are paid, and the final product is delivered. The project team should also convene for a debrief meeting to discuss what worked, what didn’t work, what was missing, and what could be changed next time. It’s important that the project manager documents lessons learned in a secure place so that everyone’s hard work can referenced for future initiatives. Questions to be answered during this process include: If the project were to be replicated in the future, what should the next project manager know? Is all project documentation archived in a place where the next project manager can easily find it?

Triple Constraints

Three competing factors – scope, time, and cost – are known as a project’s triple constraints. If any one of these factors gets out of line, the other two will be affected. Think of this as an equilateral triangle with one constraint on each side and quality at the center. If any one side were to change in length, the other two sides would be forced to compensate – changing the quality of the shape. An effective project manager is mindful of how changes to one constraint can result in short- and long-term consequences for the others – and ultimately, the project as a whole.

Example: Missing a deadline to print invitations for your convening could lead to higher production costs, which means less money is available for something else – like that charcuterie spread (yum). All of these factors would negatively impact the project’s quality.

Project Management Methodologies

There are many different approaches to project management, each with its own pros and cons depending on the specific needs of the project and the project team. A methodology is broadly defined as the processes, responsibilities, and workflows needed to achieve an objective. Two of the most commonly used project management methodologies include Waterfall and Agile.

Waterfall Methodology, often referred to as “traditional project management,” is ideal for projects with fixed requirements, where each step progresses in a logical order and culminates at a single point. That is, you know exactly what the end product should look like. When using the Waterfall approach, the cost of change increases as time passes, and last-minute changes can seriously impact quality.

Example: There are many logical components of planning a convening that can be managed without a question: setting a date, securing a venue, determining A/V needs, ordering catering, inviting guests, hosting the event, sending thank you notes, etc. Since many of the requirements are known up front, the project would be well suited for Waterfall.

The logistics of hosting an event are fairly easy to anticipate. The type of programming to include, however, is another story…

Agile Methodology is ideal for projects in which the requirements are not clearly defined. It’s no wonder this methodology was born out of the software development world, which is more inclined to iterate products rather than focus on a single fixed-end product. However, Agile can be applied to much more than software – it can be used for just about any project that requires flexibility and/or relies heavily on feedback from external stakeholders. It’s important to note that while Agile is flexible, it does not lack structure – a common misconception. Many of the same tools and technique used in Waterfall still apply in Agile. The approach, however, focuses on cycles of release, testing, and re-release.

Example: If you were tasked with determining the program for the convening without many specifics about what’s expected, an Agile approach might be beneficial. Your project team can develop a rough program outline, request feedback from stakeholders (including prospective attendees), make adjustments, identify potential speakers, request additional feedback from stakeholders, make more adjustments, and so on. This ensures that you’re gaining buy-in throughout the process, increasing the likelihood that your attendees will enjoy the convening.

Each method has its own pros and cons and can be combined as needed. A Hybrid model may contain Agile sprints within a larger Waterfall structure. A Hybrid approach can also integrate more feedback than Waterfall, which can lead to more transparency throughout the project. A Hybrid approach is actually outlined in the above examples: Waterfall is used for the overall logistics of the project, while Agile is used to determine the program.

When choosing methodologies, be sure to consider how it may impact project risk, internal and external communications, and group dynamics.

The Project Charter and The Project Plan

Believe it or not, we are all project managers in our everyday lives. Have you ever followed a recipe to cook a meal? If so, you’ve worked with a project plan!

Just like project plans, recipes contain an estimated timeline (the dish’s prep time and cook time), a list of requirements (ingredients), a scope statement (cooking instructions), and a few outlined risks (bake longer for crispier edges; remove from heat early for al dente). Some recipes even include a budget!

A project charter is a document that formally grants a project manager the authority to apply resources – such as time, labor, or money – to project activities. The charter provides a high-level overview of what’s expected from the project. A project charter is not an exhaustive description of everything involved in executing a project, but rather identifies overall project deliverables, objectives, and stakeholders.

For example, the project charter for the convening might include the following pieces of information:

  • Statement of Need: Why this project, at this time?
    • e.g. In order to establish cross-sector systems to address youth homelessness, stakeholders from each sector first need to get on the same page about the causes and prevalence of the issue.
  • Summary of Work: What are the deliverables?
    • e.g. We will host a live event for up to 200 people along with an online component so attendees can participate remotely.
  • Goals: Think SMART. Each goal should be specific, measurable, achievable, relevant, and timely.
    • e.g. We want 200 people to attend the live convening – with an even distribution of service providers, youth, funders, advocates, and government officials in attendance.
  • Requirements: How will success be determined?
    • e.g. The convening needs to be youth led. There needs to be an outdoor reception for donors. The venue needs to be ADA compliant. The menu needs to be considerate of particular dietary restrictions.
  • Risks: What are some unknown factors that could prevent the project team from meeting its goals? What about unknown factors that could enhance the convening?
    • e.g. Unpredictable weather conditions might complicate hosting an outdoor reception. Collaborating with certain organizations might attract potential funders.
  • Stakeholders: Who will impact the convening? Who will be impacted by the convening?
    • e.g. Service providers, youth experiencing homelessness, funders, government officials, media.
  • Estimated Timeline: How long will it take the project team to launch the convening?
    • e.g. Three months of planning. A one hour reception with a two hour program.
  • Estimated Budget: Considering the requirements and constraints, how much money is needed to host the convening?
    • e.g. Total: $15,000. $1,000 must be used for the opening reception.

Keep in mind that a project isn’t considered a “success” until all stakeholders are satisfied and all requirements are met. So in this case, if the convening is completely led by adults in a venue that is not ADA compliant, with a restrictive menu, it cannot be determined a success – even if it happens on time and on budget.

The Project Plan

Once you receive sign off on the Project Charter, it’s time to begin building the Project Plan, which includes the following components:

  • Stakeholder management plan
  • Requirements management plan
  • Scope management plan
  • Project change management plan
  • Risk management plan
  • Cost management plan
  • Schedule management plan
  • Resource management plan
  • Communications management plan
  • Quality management plan

These topics will be explored in the sections that follow.

Stakeholders and Project Requirements.

Analyzing and Prioritizing Stakeholders

Now that we’ve discussed an overview of project management, it’s time to iron out the details. We’ll start by focusing on the people who are involved in the process – the project’s stakeholders. These folks can be internal, such as other members of a coalition, or external, like members of the state’s office on youth homelessness. They can be individuals, such as key personnel within the mayor’s office; groups of people, like youth currently experiencing homelessness in the community; or companies, such as to-be-determined contractors or sponsors. Remember the “Five I’s.” A stakeholder is anyone who is or will be:

  • Interested (e.g. Media, residents)
  • Involved (e.g. Project team, project sponsor)
  • Invested (e.g. Funders,  technical assistance providers)
  • Influencing (e.g. Elected officials, organizations with opposing views)
  • Impacted (e.g. Youth experiencing homelessness, service providers)

Once stakeholders have been identified, it’s important to determine the level at which each needs to be engaged. A Stakeholder Analysis Chart will help the project team make that determination.

Stakeholder Analysis Activity

  1. Create a chart that is divided into four quadrants (see diagram), with “Level of Power” and “Level of Interest” on each axis.
  2. Write each stakeholder on its own sticky note and, using your best judgement, plot them all on the chart based on their levels of power and interest regarding this particular project.

The quadrant in which each stakeholder falls will determine whether you need to keep them satisfied, manage them closely, monitor them, or keep them informed.

Note: This exercise should be conducted privately and only members of the project team should be present. No one likes to hear that they’ve been determined to have a low level of power or interest! For that reason, all outputs from this process should be kept strictly confidential.

Identifying and Analyzing Requirements

Each stakeholder brings a specific set of requirements to the project. However, it’s not always possible to please everyone at the same time. Therefore, it’s crucial that a project manager takes the time to not only collect requirements, but also determine which are to be considered in the scope of work. This can be accomplished by conducting a Requirements Analysis, which is similar in format to the Stakeholder Analysis.

Requirements Analysis Activity

  1. Create a chart that is divided into four quadrants (see diagram), with “Level of Difficulty” and “Importance” on each axis.
  2. Write each requirement on its own sticky note and, using your best judgement, plot them all on the chart based on their level of difficulty and importance.

The quadrant in which each requirement falls will determine whether it is a “must have” (Go), “should have” (Negotiate), or “nice to have” (No-Go). Requirements that fall into the No-Go quadrant should be addressed in a future project. Requirements that fall into the Negotiate quadrant should be discussed with the stakeholder that proposed them and/or further evaluated to determine whether or not they are to be included in the scope of the project.

Now that you’ve conducted both Stakeholder Analysis and Requirements Analysis, it’s important to explore the relationship between the two – especially since one directly informs the other.

Prioritization Activity

  1. Place the Stakeholder Analysis and Requirements Analysis charts side by side.
  2. Draw lines (or use string) to connect stakeholders to their requirements.

By evaluating these charts in relationship to one another, you’re more equipped to determine the importance of each requirement. The more stakeholders that connect to a requirement, the more essential that requirement is to the success of the project. If you find that stakeholders in the Manage Closely quadrant are linked to requirements in the Negotiate quadrant, you may want to consider moving those requirements to the Go quadrant.

Managing Stakeholders

Now that you have an understanding of the project’s stakeholders and their key requirements, it’s time to log this data into a Stakeholder Register. The document is essentially a spreadsheet that includes information about each stakeholder such as:

  • Name
  • Title
  • Contact information
  • Role within the project
  • Project requirements
  • Communication needs
  • Communication frequency
  • Power Score
  • Influence Score
  • Overall Stakeholder Score

Stakeholder Register Activity

  1. Using information gathered during Stakeholder and Requirements Analysis, populate the provided Stakeholder Register.
  2. Assign Power and Interest Scores to each stakeholder. The Stakeholder Register will automatically assign overall stakeholder scores.
  3. Sort stakeholders by their overall scores, from greatest to least. The higher the score, the more closely the stakeholder will need to be managed.

Stakeholders can be categorized based on their Power and Interest in the project or whether they are internal or external. This document is designed to give the project team an outline of all the project’s primary and secondary players, as well as their impact on the project and how closely they should be managed. This will form the baseline for the communications plan that will be discussed in later topics. Since roles and responsibilities often shift over time, the Stakeholder Register should be treated as a living document that is frequently updated throughout the course of a project. It’s recommended that the document is regularly reviewed at team meetings.

Note: Just like the Stakeholder Analysis, the Stakeholder Register is a confidential document that should only be accessed by the project team. Again, no one likes to hear that they’ve been determined to have a low level of power or interest!

Project Scope.

Writing a Scope Statement

Now that the project charter is complete, stakeholders are identified, and requirements are determined, it’s time to get specific about the work that needs to be happen – and how that work will be accomplished. This information is detailed in a Scope Statement – a written document that should be approved by key stakeholders before any work begins. The Scope Statement is essentially a fleshed-out version of the Statement of Work in the Project Charter, so it’s crucial that the two are in alignment.

A Scope Statement should include the following components:

  • Project purpose: A summary of the “business case” that led to the launch of the project.
    • e.g. “The community’s needs assessment determined that there was an overall lack of knowledge and understanding around the causes and prevalence of LGBTQ youth homelessness. In order to develop solutions to prevent and ultimately end youth homelessness, stakeholders first need to be educated…”
  • Goals and objectives: A summary of key objectives with success criteria (again, think SMART goals) that the project sets out to accomplish. These goals should align with the project purpose.
    • e.g. “Our primary goal is to establish a common understanding around the causes and prevalence of LGBTQ youth homelessness by ensuring all key stakeholders are at the table. This includes youth experiencing homelessness, service providers, government officials, etc…”
  • Acceptance criteria: The criteria used by stakeholders to determine whether the finished product or service has met project requirements. This section also defines the acceptance process, which might include internal testing or evaluations. It provides clarity and manages stakeholder expectations.
    • e.g. “Youth are the experts of their own experiences. Therefore, it’s imperative that the convening is co-lead by members of the local youth action board…”
  • Project deliverables: This section provides a detailed description of the project deliverables, including special features or functionality.
    • e.g. “The live convening will include three educational tracks, including service provision, public policy, and community organizing. Online attendees can access a live video broadcast of sessions taking place in the grand ballroom, and all footage will be archived on the organization’s YouTube account.”
  • Project exclusions: In order to effectively manage stakeholder expectations, it’s just as important to clarify activities that will not be included in the project scope.
    • e.g. “Due to cost restrictions, this project will not include a way for online attendees to interact with presenters at the live convening.”
  • Project constraints: A summary of limitations that may impact project work, including time, cost, and human resources.
    • e.g. “The project team will only be be available to work on planning the convening Monday through Friday between 9:30am ET and 5:30pm ET. However, the team will be available to work the evening of the event, from 5:30pm ET to 10:00pm ET.”
  • Project assumptions: Assumptions are circumstances that are expected to occur throughout the course of the project. While assumptions are often true, they’re also subject change, so it’s important that they aren’t taken for granted.
    • e.g. “It is assumed that there will be no employee turnover during the planning or execution phases of the convening.”

Preventing Scope Creep

Once you receive formal sign-off on your scope statement, team members or other high-level stakeholders might start to come up with new ideas to “enhance” the project.

Here’s an example: While it is understood that there will not be a mechanism for online attendees to interact with presenters who are at the live convening, a coalition committee chair thinks it’d be great to host a “tweet-up,” which would allow folks to ask questions and connect with one another on Twitter. The best part: Twitter is totally free, so it won’t impact the budget! All you need to do is come up with a hashtag. And promote it. And come up with some tweets that can be scheduled to guide the conversation. And it would probably be good to have a moderator during the event – just in case any problems arise. And it’d be really nice to have the tweets projected on the wall so attendees at the live convening can follow the conversation online…

Before you know it, that simple, “free” idea has snowballed into something far more complex – and it’s pulling your team’s time and attention away from other crucial parts of the project.

Scope creep refers to uncontrolled growth or continuous changes in a project’s scope after the project begins – and it’s one of the most common causes of project failure. Like the example outlined above, scope creep often occurs gradually and it’s caused by either a lack of clarity in the scope statement and/or a lack of change control.

A Change Control Agreement is a document that outlines the process in which changes can be made to a project. For instance, certain changes might be up to the discretion of the project manager while others need to be formally submitted to a Change Control Board. The Change Control Board might include the project sponsor, project manager, subject matter experts, and constituents.

If changes are proposed, the Project Manager would complete a Change Form and submit it to the Change Control Board for review. If the change is approved, the Project Manager should update the project plan accordingly. All requests should be tracked in a Change Log, which includes the request’s reference number, a title or description of the change, the person making the request, the person/people approving the request, the date of the request, whether the request is high/low/medium priority, the status of the request, and any relevant comments or notes.

Here’s an example:

No matter how seemingly minor, all changes should be funneled through your Scope Change Control system.

Breaking Down Project Work

Once you receive sign-off on the Scope Statement, it’s time to begin planning project work. This process can seem daunting, especially when you’re working on a complex project with multiple deliverables. That’s where the Work Breakdown Structure (WBS) comes in. The WBS, which resembles an organizational chart, is a visual representation of a project’s deliverables, sub-deliverables, and work packages. Generally speaking, deliverables are nouns while work packages are verbs. Keep in mind, a WBS is not a schedule or a chronological listing of tasks, so it does not include assignments or due dates.

At the top of the WBS is the main primary product (e.g. Convening). The next level below includes high-level deliverables (e.g. Live Event, Online Event, Marketing, and Project Plan). The next level below breaks down those deliverables even further (e.g. Sub-deliverables of the live event might include venue, program, catering, etc.). Deliverables and sub-deliverables are then numbered using decimals to indicate hierarchy. (e.g. Convening 1.0, Live Event 1.1, Venue 1.1.1, etc.).

At the lowest level are Work Packages, which are groups of activities related to the preceding sub-deliverable (e.g. Tour venues, Select venue, Negotiate cost, Secure venue, etc.).

Work Breakdown Structure Activity:

  1. With your team, write the project’s deliverables on sticky notes. Keep in mind that deliverables are almost always nouns.
  2. Organize the sticky notes into a hierarchy that makes the most logical sense. You might find yourself moving stickies around – that’s totally normal! There is no one way to create a WBS. The important thing is that you create a hierarchy that makes the most sense to you and your team.
  3. Once you are satisfied with the hierarchy, code each sticky sequentially as described above.

Once the WBS is complete, it’s time to log the activities from the Work Pages in the Work Breakdown Dictionary, a spreadsheet that contains information such as the WBS # (for reference), activity name, a high-level description of the activity, cost control #, completion criteria, and the person responsible for completing it.

Managing Risk.

Defining Risk

The word “risk” often evokes a sense of danger. However, in relation to project management, a risk is simply an unknown – and that unknown can be positive or negative.

Here are a couple of examples:

  • Negative risk: Unpredictable weather conditions might complicate hosting the outdoor reception for the convening.
  • Positive risk: Collaborating with certain organizations might attract potential funders.

All risks have three components: a cause, an event, and a consequence. The cause is a factor or condition that can result in an event taking place. The event is the moment at which there is an occurrence or a change in circumstances. Finally, the consequence is the impact of the event on the rest of the project.

Here is an example of a risk statement: If it begins to rain on our outdoor reception (cause) our donors will leave (event) and we may not reach our fundraising goal (consequence).

At the beginning of a project, uncertainty is high and the cost of changes is low. However, as time goes on, the cost of changes steadily rises. For this reason, it’s crucial that you identify risks as early as possible – and develop a response plan. For instance, it would likely be cheaper to reserve a tent a week in advance of the reception than to place a rush order the night before.

By monitoring risks throughout the course of the project, you’ll be prepared to respond as quickly and efficiently as possible. For instance, as the reception approaches, you can monitor the weather forecast to determine whether or not the tent is needed – or if you prefer to have one on hand, you can research cancellation and return policies.

It is recommended that you use a Risk Register to record and monitor information on each risk, including:

  • Risk: A description of the risk event.
  • Probability: % of risk event occurring.
  • Impact Score: Level of severity.
  • Overall Risk Score: The average of the probability and impact score
  • Cause: Reason for the risk event.
  • Consequence: Impact of the risk event on the rest of the project.
  • Category: Is it a threat or opportunity?
  • Source: Is the origin external, organizational, with the team, or technical?
  • Risk owner: Person responsible.
  • Response strategy (more on this in a later topic)
  • Trigger event: Moment at which a response is necessary.
  • Residual risk: Risks that remain after responding to the risk.
  • Secondary risk: New risks that arise as a result of responding to the risk.

Risk Register Activity

  1. Identify risks (we’ll explore some techniques in the next topic) and log them in the Risk Register.
  2. Assign Probability and Impact Scores to each risk. The Risk Register will automatically assign Overall Risk Scores.
  3. Sort the spreadsheet by Overall Risk Scores, from greatest to least. The higher the score, the more closely the risk should be managed.

Since risks are unknowns, they’re subject to change – and new risks are constantly arising. For that reason, the Risk Register should be treated as a living document that is frequently updated throughout the course of a project. It’s recommended that the document is regularly reviewed at team meetings.

Risk Identification Methods

There are many ways to identify risk throughout the project life cycle. Common methods include brainstorming, risk breakdown structure, and SWOT analysis, in which you identify the project’s strengths, weaknesses, opportunities, and threats.

Brainstorming Session Activity

There are many ways to facilitate a brainstorming session. The most common methods include structured, unstructured, and anonymous.

  • In a structured brainstorming session, you might solicit one potential risk from each person in the group sequentially and write them on a whiteboard or flip chart. To avoid redundancy, risks should not be repeated. If a participant doesn’t have an idea, they are free to pass. When using this method, everyone in the room contributes to the conversation equally – regardless of their power or influence. However, the process can feel restrictive and some participants may not appreciate being put on the spot.
  • In an unstructured brainstorming session, participants are free to call out ideas as they come up. This method is less restrictive than a structured session and participants are able to build on one another’s ideas. However, the meeting can easily be dominated by participants with outgoing personalities – especially those who are in positions of power.
  • If folks are hesitant to voice their ideas, due to power dynamics or otherwise, you can facilitate an anonymous brainstorming session, in which participants write their ideas on sticky notes. You can then collect the notes and post them for everyone to review, grouping similar ideas together. Since participants are sourcing their ideas independently, this method may result in repetitive ideas – and the process lacks the creative energy of a group brainstorming session.

Keep in mind, you are not restricted to using just one technique. Feel free to combine methods are you see fit.

SWOT Analysis Activity

  • Create a chart that is divided into four quadrants: Strengths, Weaknesses, Opportunities, and Threats
  • With your team, populate each of the quadrants. Keep in mind, strengths and weaknesses are internal while opportunities and threats are external. Often, strengths will inform opportunities while weaknesses inform threats.
  • Log the Opportunities (positive) and Threats (negative) in your Risk Register.

Risk Breakdown Structure (RBS) Activity

  1. Determine your risk categories. Depending on your project, you may decide to group them by deliverable, origin (technical, team, organizational, external), constraint (time, cost, scope), or something entirely different.
  2. Write the risk categories on sticky notes.
  3. With your stakeholders, brainstorm potential risks related to each category. Write the risks on sticky notes. You can use multi-colored sticky notes to color code risks based on their level of impact.
  4. Organize the stickies into a hierarchy (similar to the Work Breakdown Structure).
  5. Once you are satisfied with the hierarchy, code each sticky sequentially according to the hierarchy.
  6. Log the risks in your Risk Register.

Risk Response Strategies

Identifying risks is only the beginning. It’s crucial that you continue to monitor risks on an ongoing basis – and respond when necessary. Depending on the impact of the risk, and whether the risk is positive (an opportunity) or negative (a threat), your response strategy may vary.

There are four options when responding to positive risks (opportunities) and four options when responding to negative risks (threats):

Once a risk occurs, it becomes an issue. All issues should be tracked in an Issue Log, which will serve as a valuable resource in debrief meetings and future projects.

The Issue Log includes information such as:

  • Issue Description
  • Status (e.g. Open, In Progress, Resolved)
  • Source (e.g. External, Organizational, Team, Technical)
  • Category (e.g. Threat, Opportunity)
  • Impact Score (from the Risk Register)
  • Owner (person responsible for response)
  • Response strategy
  • Impact
  • Open Date
  • Close Date
  • Other comments and notes

Working With Vendors.

Determining When To Outsource Work

Now that the project team has conducted a work breakdown structure and identified risks, it’s time to determine which deliverables are to be handled by the team and which, if any, need to be outsourced. One way to make this determination is to use a Project Assessment Model.

Project Assessment Model Activity

  1. Create a chart that is divided into four quadrants (see diagram), with “Team Capacity” and “Clarity of Requirements” on each axis.
  2. Write each deliverable on its own sticky note and, using your best judgement, plot them all on the chart.
  3. The deliverables in the High Complexity quadrant carry the most risk. Outsourcing work for these deliverables should be considered if possible.


You need to create a printed program for the convening. Your team consists of experienced designers who have created printed programs for past events. You know the program will need to include an agenda, speaker bios, and sponsor ads. This deliverable would likely be placed in the Low Complexity Requirement since your team has the knowledge and skills necessary to manage it.

You also need to broadcast the event for your online attendees, but none of your team members have expertise in video production or streaming live content on the Internet. There are many unknown factors at play including equipment, streaming services, and Internet speed. This deliverable would likely land in the High Complexity quadrant and you would need to seek support from an external vendor.

Requests for Proposals

Once you’ve determined which deliverables need to be outsourced, you may decide to begin a Request for Proposals (RFP) process, in which you disseminate a formal request for vendors to submit proposals or quotes. An RFP is a document that clearly defines the needs of your project and/or deliverable.

RFPs include information such as:

  • Introductions: A brief overview of the community coalition, organizations involved, and project team members. It’s also helpful to include information on organizational structure and decision-making bodies.
  • Project Purpose: The strategic goal or specific need that the project will meet in the community.
  • Technical Requirements: These are specific to the product that’s being created. It is helpful to present requirements as a list, rather than written in narrative form, so bidders have a clear understanding of what is expected. You may also include a definitions section to clarify technical terms for folks who are not part of your community coalition.
  • Management Requirements: These are specifics about how the project needs to be implemented, staffed, maintained, and documented.
  • Vendor Qualifications: This might include licenses/certifications, descriptions of similar work, or references from past clients.
  • Budget: Relevant details about one-time costs, recurring costs, nonprofit discounts, tax-exemptions, etc.
  • Contracts and Leases: This may include payment terms (more on that in the next section), warranties, licensing terms, and nondisclosure agreements.
  • Overview of the selection criteria
  • Timeline for selection

It’s helpful to designate a point person on your team to field questions from vendors throughout the RFP process.

Regarding contracts, there are three types you’re likely to encounter during the procurement process:

  1. Fixed-Price Contract: Also known as a lump-sum contract, these are used when there is no uncertainty about the scope and timeline of work. For these contracts to succeed, the vendor carries most of the risk, as they are legally bound to complete the work as stipulated in the contract. For this reason, the scope of work must be carefully outlined so there is no confusion about what is expected of the vendor. Vendors will sometimes add to their fee to cover their risk.
  2. Cost Reimbursable Contract: In these contracts, the buyer covers a percentage of direct and indirect costs associated with the project. Direct costs can include the salaries or billable hours of key personnel and the price of specialized equipment purchased solely for the project. Indirect costs can include overhead or administrative costs. Vendors make a profit through an incentive or bonus fee, which are often associated with activities such as meeting key milestones ahead of schedule or keeping project costs below budget. Cost reimbursable contracts are most appropriate for projects with uncertain risk or scope; however, the buyer assumes more risk.
  3. Time and Materials Contract: These contracts involve setting a fixed price per hour of labor, though the number of hours required may not be entirely clear. The buyer can stipulate a maximum ceiling for billable hours. However, due to the nature of this arrangement, it is possible to reach the maximum budget without the project being complete. In this model, risk is distributed evenly between the buyer and seller. The buyer also covers the cost of any materials purchased for the project.

Vendor Selection

In order to complete the RFP, your team will need to develop criteria for a winning proposal. Most often, this is determined via a points-based evaluation system that’s based on the degree to which the proposal meets specified requirements and the priority of those requirements. For instance, your team might decide that budget, vendor qualifications, and references are included among the selection criteria – however, budget is the most important criteria (as it often is). Therefore, you would want to weight budget higher than the other factors when making your final determination.

The easiest way to manage all of these variables is to create an RFP Scoring Matrix. This spreadsheet usually includes the following columns:

  • Criteria Name
  • Weight (Usually a % out of 100)
  • Vendor Rank (Usually 1-10)
  • Final scores (Usually a formula field that multiplies Weight by Vendor Score)


A comprehensive evaluation system will allow your team to balance internal and external requirements and select a proposal that works best for everyone.

Estimating Time and Cost.

Determining a Good Estimate

Now that you have your Work Breakdown Structure, it’s time to estimate how long it’ll take to complete project activities (which will inform the schedule), and the resources needed to complete those activities (which will inform the budget). Resources include labor, facilities, and materials.

In this section, we’ll explore a number of estimating techniques that can be applied to cost and schedule management. But before we dive in, we first need to clarify what constitutes a “good” estimate.

A good estimate is:

  • Accurate, within an acceptable range.
  • Complete. Even seemingly minor activities will require time and money.
  • Verifiable based on relevant historical data.
  • Determined using a standard approach. (More on this in the next topic.)
  • Considerate of risk, assumptions, and constraints. There should be no surprises if uncertainties eventually come to fruition.
  • Not padded. With that said, some components of the schedule or budget will likely require some defensible contingencies – but they should be applied judiciously. Adding a cushion to everything might seem “safe,” but it will only lead to problems down the line.

Estimation Techniques

There are four different techniques you can use to determine estimates for your project. From least accurate to most accurate, these techniques include analogous, parametric, three-point, and bottom-up. Determining which estimation technique to use will depend on the nature of your project and the information that’s readily available to you:

An analogous (or top-down) estimate involves comparing the current project to past similar projects. Analogous is mainly used when the details of the new project are still fuzzy. It’s the quickest, but also the least accurate estimation method. It also requires accurate documentation from the previous project, which isn’t always available.
e.g. You’re working on launching a new program for Coalition B. In your research, you discover Coalition A launched a similar program last year. You estimate your current project’s schedule and budget based on what it took to launch Coalition A’s project.

A parametric estimate involves calculating the cost and duration of tasks on similar past projects and scaling them. This method is more accurate than analogous. Since it doesn’t factor in customizations or other variables, it’s not always the most accurate.
e.g. If it took your team one hour to create a 15 minute presentation, you can estimate it will take them four hours to complete a 60 minute presentation.

A bottom-up estimate involves gathering cost and scheduling quotes from each team member and adding it all together. This estimation technique is the most accurate and the most time consuming. However, because team members are included, bottom-up estimates build buy-in from the team and often increase trust between team members and the project manager.
e.g  Team Member 1 tells you it’ll take three hours and $150 to write content for your presentation. Team Member 2 tells you it’ll take two hours and $100 to design it. To complete both activities, it’ll take five hours of work and $250.

A three-point estimate is created by taking the pessimistic, optimistic, and ‘most likely’ estimates and averaging them (P+O+M/3). For a more accurate estimate, you can also take the ‘most likely’ estimate and weight it (P+O+4M/3). This is known as a PERT (Program Evaluation and Review Technique) estimate. In order to conduct a PERT estimate, you’ll need historical data in order to accurately weigh the “most likely variable.”

Once you have your estimates, you’re able to develop your budget and schedule baselines. These baselines will be used to measure progress throughout the course of the project. For that reason, it’s important to have the budget and schedule baselines approved before work begins!

Measuring Performance

Estimations are useful not only before project work begins, but throughout the entire project, as they can be used to determine how well a project is performing. Determining the variance between your estimates and actuals will allow you to make necessary adjustments to the project schedule, budget, and workloads.

In order to dive into performance measurement, you’ll need to have an understanding of the following terms (and do some math):

Earned Value Analysis

  • Planned Value (PV) is the budgeted cost of work scheduled to date.
  • Earned Value (EV) is the budgeted cost of work performed to date.
  • Actual Cost (AC) is the money spent on work performed to date.

Earned Value Management

  • Cost Performance Index (CPI) determines whether or not a project is on budget.
    CPI = EV / AC. A CPI score of 1 or greater means the project is on or under budget.
  • Schedule Performance Index (SPI) determines whether or not a project is on budget.
    SPI = EV / PV. An SPI score of 1 or greater means the project is on or ahead of schedule.

Variance Analysis

  • Cost Variance (CV) is the difference between the amount budgeted and the amount spent for work performed. CV = EV – AC
  • Schedule Variance (SV) is the difference between the amount budgeted for work completed vs. the work that was planned. SV = EV – PV

Creating a Schedule.

Scheduling Terminology

Once you’ve determined your project estimates, it’s time to create a schedule. An accurate schedule allows you to effectively lead project team members and manage stakeholder expectations.

Before we create a schedule, let’s first define some key terms and concepts:

  • Also known as a task, an activity is a component of the project that requires a specific amount of time and resources to complete. In a Work Breakdown Structure, related activities are grouped into work packages (at the bottom of the chart).
    • e.g. Draft communications, design program, invite guests.
  • A milestone is a moment on a timeline, often used to mark anchors such as start dates, checkpoints, and due dates. Milestones can sometimes trigger risk responses.
    • e.g. Content reviews, design approvals, application deadlines, the start of a new phase.
  • Lag is the time that must pass between two activities.
    • e.g. After distributing a call for session proposals, the team needs to wait until the proposal window closes before reviewing applications.
  • Lead is when there’s acceleration of a successor activity, causing activities to overlap. It’s the opposite of lag.
    • e.g. Rather than waiting for the session proposal window to close, the team decides to review applications on a rolling basis. By shortening the amount of time required to evaluate sessions, the program can be announced to the public ahead of schedule.

Creating a Schedule Network Diagram

The numbers on the upper left-hand corner of each box represent the day the activity will begin and the number on the upper right-hand corner represents the day the activity will end. The number in the center indicates how long the activity takes to complete (to find this number, subtract the start day from the end day.)

The lines connecting the boxes indicate dependencies – that is, one activity cannot begin until another activity is completed. These relationships fall into four categories:

Finish to Start (FS): Activity A must finish before Activity B can start.

  • e.g. The convening agenda must be finalized before it can be laid out in the program.

Start to Start (SS): Task A must start before Task B can start.

  • e.g. In order to start setting up catering, you first need to start setting up the venue.

Finish to Finish (FF): Task A must finish before Task B can finish.

  • e.g. In order to end the live broadcast, the final speaker needs to finish their presentation.

Start to Finish (SF): Task A must start before Task B can finish.

  • e.g. The convening must begin before registration can close.

Determining The Critical Path

The longest chain of activities in a Schedule Network Diagram is called the critical path. Identifying the critical path is essential, as it represents the shortest overall amount of time required complete a project. If any of the tasks along the critical path take longer than expected, the project end date will be delayed. Knowing the critical path allows you to make informed decisions about resource allocation. For instance, to prevent delays along the critical path, you can opt to complete activities simultaneously that would normally be accomplished sequentially. This technique, known as fast tracking, often involves increased risk. You can also apply additional resources to activities in order to shorten the schedule. This technique, known as crashing, often involves increased cost. Fast tracking and crashing are both forms of schedule compression.

While many projects have only one critical path, some projects have multiple. The critical path is also subject to change as fast tracking, crashing, and other factors can change the schedule.

If the critical path is the longest chain of activities in a Network Schedule Diagram, that means the other paths have some wiggle room along the way, known as float or slack. Float is the amount of time an activity can be delayed without delaying the project end date.

Managing Communications.

Types of Communications

Believe it or not, approximately 90% of a project manager’s time is spent communicating with stakeholders. Therefore, effective communication is critical for project success.

In this context, communications is more than a media strategy. It involves any exchange of information between two stakeholders – either internal or external. This exchange can occur in any direction: upwards to management, downwards to team members, and laterally to peers. It’s also important to note that communication can be voluntary or involuntary – through speaking, writing, gestures, or media.

There are four types of communication: formal written, formal verbal, informal written, and informal verbal.

Here are some examples of each type of communication:

  • Formal written
    e.g. Project plan, donor letter
  • Formal verbal
    e.g. Presentation, status meeting
  • Informal written
    e.g. Instant message, text message, notes
  • Informal verbal
    e.g. Water cooler conversation

The type of communication you use will largely depend on the situation and the stakeholder with whom you’re communicating.

Methods of Communication

All messages are transmitted from a sender to a receiver via a specific medium. The mode of communication you select can sometimes be just as important as the message itself. The three main methods of communication include push, pull, and interactive.

Push Communication involves the one-way distribution of information to specific recipients.  Examples include emails, letters, reports, and advertisements.

Pull Communication involves placing information in a central location and so stakeholders can access it as needed. Examples include shared drive, website, database, intranet, kiosk, online knowledge center, and bulletin board.  

Interactive Communication encompasses any situation where information is mutually shared and processed. Examples include meetings, conference calls, webinars, and workshops.

Throughout the course of your project, you’ll likely use a combination of these methods. Be sure to consider the environment in which you’re working and the stakeholders with whom you are communicating when selecting methods of communication. For example, an online shared-drive is a great way to collaborate on convening plans with your coalition, but not everyone might be comfortable using every platform.

Creating a Communications Plan

Now that we’ve established a common understanding of project communications, it’s time to develop a Communications Plan. This plan is a written document that defines:

    • Messengers
      • e.g. Project manager, project team
    • Recipients/Audience
      • e.g Convening speakers, attendees, project team members, project sponsor, coalition members
    • Channels/Delivery Methods
      • e.g. Email, shared drive, online forum, database
    • Message Content
      • e.g. Status reports, invitations, agreements
    • Frequency
      • e.g. Daily, weekly, monthly
    • Other Notes

A communications plan can be written as a narrative, a matrix, or a combination of the two. Here is an example of a communications plan matrix:

Leading The Project Team.

Understanding Personal Motivations

It’s been said that the “p” in project management stands for “people” as much as “project.” In order to effectively work with – and manage – others, it’s essential that we take the time to understand what motivates them. To do this, let’s explore a theory that may be familiar to those working in social services: Maslow’s Hierarchy of Needs.

According to Maslow’s Hierarchy of Needs, humans are motivated by a series of increasingly complex needs that can be visualized as a pyramid. Each layer of the pyramid is dependent on the layers below.

At the base of the pyramid lies our physiological needs: food, water, shelter, and sleep. These are the basic elements required to sustain life. The next layer above includes our safety needs: security and safety. In this case, security and safety can apply to employment, physical and mental health, bodily safety, and access to resources. These two groups of needs act as primary motivators for all humans. Without them, we cannot begin to engage any of the motivations in the layers above, such as a sense of belonging, relationships, esteem, and, ultimately, self-actualization and fulfillment.

This is an important concept to keep in mind, not only as we execute projects – but also as we design and implement programs and services for youth experiencing homelessness.

Navigating Team Dynamics

Now that we have an understanding of what motivates people on a personal level, it’s time to discuss how they interact with one another in a team environment. There are five stages of team development, which occur chronologically:

  • Forming: This is when the team members first meet, learn one another’s backgrounds and interests, form first impressions, and generally get a feel for what it’ll be like to work together.
  • Storming: Having made first impressions, team members begin vying for attention and approval. Team members will often have different ideas about how to execute their tasks and conflicts will inevitably arise. In most cases, the project manager will need to step in and help smooth things over. This stage ends when the team learns to trust one another and work together for the good of the project.
  • Norming: This is when the team starts to effectively work together. There is mutual respect for what team members bring to the project. Team members feel comfortable seeking advice or assistance from one another. This is the stage in which the project manager will often take a step back, as the team becomes more comfortable making decisions and problem solving together.
  • Performing: At this point, the team is motivated to complete the project and members are fully capable of problem solving, leaning on one another for support, and making decisions as a group. Unfortunately, many teams do not make it to this stage – instead, they remain in Norming. Teams can also revert to Storming if a member breaks away from the group, or Forming if a new person joins the team.
  • Adjourning: As the project is wrapping up, team members begin to move in separate directions. The project manager should ensure there is time for the team to celebrate their successes and perform closing activities – such as a debrief meeting to discuss lessons learned.

It’s inevitable that a project team will experience conflict at some point – particularly during the “storming” stage of the team’s development. The project manager may be called upon to resolve issues, ensuring that the team can move past these situations to successfully execute the project. The project manager has a few options when resolving conflicts:

  • Withdraw/Avoid: This is the most passive approach, in which the project manager withdraws from or avoids a problem. This option works best when the stakes are low and it’s possible to buy time until the project manager is better equipped to address the situation. Withdrawing is usually a temporary solution; in most cases, the issue is likely to continue unless more direct action is taken.
  • Smooth/Accommodate: In this case, the project manager would downplay areas of conflict and highlight commonalities among proposed solutions. However, this style doesn’t necessarily resolve conflict – it’s mostly used to foster teamwork and goodwill.
  • Compromise/Reconcile: This approach involves both sides giving something up for the greater good. It is often used when the matter is time-sensitive and negotiations are at an impasse. Compromise is reached when parties realize that they will lose entirely if they do not agree to work together.
  • Force/Direct: This is a win/lose situation; one party wins at the expense of the others. Using force is often necessary when the stakes are high and decisive action is required.
  • Collaborate/Problem Solve: This is a win/win situation. The project manager should strive to resolve conflicts using this style as much as possible, which prioritizes mutual learning and open communication. Typically, this approach is most successful when there is enough time for parties to work through the problem together. There must also be mutual trust and a willingness to learn from one another.

Managing a Team

The successful completion of an activity is often dependent on more than one person. However, this can sometimes lead to confusion over who is ultimately responsible (“I thought she was doing it.”) This is where a Responsibility Assignment Matrix (RAM) comes into play. A RAM is essentially a tool that is used to track each team member’s degree of responsibility in relation to project activities.

One common type of RAM is a RACI, in which team members receive one of the following designations: Responsible, Accountable, Consult, Inform:

  • Responsible: This person is ultimately responsible for completing the activity. There should be only one person assigned as Responsible.
    • e.g. Nick is responsible for designing an advertisement for the convening.
  • Accountable: This person has final authority for approving the task’s quality.
    • e.g. Joe is responsible for maintaining brand standards for the convening. Therefore, all design will need to be reviewed and approved by him.
  • Consult: This person can provide guidance or expertise before an action is taken.
    • e.g. Selina is responsible to placing ads. She has the specifications.
  • Inform: The person or group of people that should be informed that the activity is completed.
    • e.g. Twiggy is ultimately responsible for promoting the convening. Therefore, she needs to be kept informed about advertising activities.

As a team leader, maintaining a system of accountability is essential for building trust, managing expectations, and limiting confusion among the project team.

Meeting Project Requirements.

Creating a Quality Management Plan

A project cannot be considered a success unless all requirements met – even if the project is completed on time and on budget. For this reason, it’s crucial that you create a Quality Management Plan, which is a narrative that defines quality for the project and outlines how the team will ensure that this level of quality remains consistent for each deliverable.

Here are some elements that should be included in the Quality Management Plan:

  • Definitions of quality in relation to the project and its deliverables.
    • e.g. “The convening must be co-led by young people, which means a Youth Action Board works with adult partners to curate content and facilitate sessions. The Youth Action Board has equal decision making authority throughout the process as adult partners.”
  • Methods used to assess quality during the project lifecycle.
    • e.g. “Authentic youth collaboration will be gauged through surveys and meetings in which youth are able to provide feedback about the planning process.”
  • Schedule for assessing quality during the project lifecycle.
    • e.g. “A survey will be distributed at the midpoint and close of the project. Youth participants will be invited to bi-weekly meetings in which they provide feedback about the process.”
  • People responsible for overseeing quality.
    • e.g. “The Youth Collaboration Director will be responsible for quality assurance and quality control.”

Throughout the duration of the project, you’ll want to perform an ongoing series of activities to ensure that project quality remains uncompromised – especially when there are changes to scope, schedule, or cost. Here are some key considerations to monitor when determining project quality:

  • Functionality: Does the project’s final product function as intended?
  • Performance: How well does this product serve its users?
  • Reliability: Is this performance reliable?
  • Relevance: Do results meet the needs of its users? How easily can these results be adapted as needs change?
  • Timeliness: Are results delivered to users in a timely and efficient manner?
  • Completeness: Do results encompass the full scope of services or products that was promised to its users?
  • Consistency: Do users receive the same results (as adapted to their specific needs)?

You may have come across the terms, quality assurance and quality control, however they mean two different things:

Quality assurance ensures the right process is happening the right way.

e.g. Are surveys and meetings effective ways to gather input from the Youth Action Board? Is the survey comprehensive enough? Is the meeting structure working?

Quality control is focused on inspection of the final product.

e.g. Distributing surveys and analyzing results. Hosting meetings, facilitating conversations, and logging responses. Using a checklist to determine is specifications are met.

Transferring Ownership

Once all requirements have been met, the project can be closed. Closing a project involves:

  • Obtaining final approval of deliverables
  • Identifying work packages that were not completed (these may be rolled into another project)
  • Paying invoices
  • Closing contracts
  • Conducting necessary trainings
  • Releasing the project team
  • Returning physical resources
  • Informing stakeholders
  • Storing project documentation

Since a project is a temporary endeavor that produces something new and unique, it’s also necessary to determine who will assume responsibility for the new end product.

For example, once the convening happens, who owns the video and where will it be hosted? Who will be responsible for maintaining relationships with participants? Who owns the project documentation? Does anyone need to be trained to keep things running?

Answers to these questions are especially relevant for community coalitions, which often do not have a central governing body. For this reason, it’s important to include a summary of transition activities in your project plan. Ideally, this summary should be determined early on in the planning process to avoid complications when it’s time to close the project.

Evaluating a Project

Once a project is complete, it’s time to gather feedback from stakeholders in a formal evaluation process. This process includes:

  • Post-project surveys: Distribute anonymous surveys to key stakeholders to determine whether or not the project met its goals (e.g. send a survey to convening attendees to collect their feedback). Anonymous surveys can also be distributed among team members around process topics such as communications, team dynamics, scheduling, budgeting, and risk management. It’s best to conduct these surveys and review sessions reasonably close to the end of the project, when potential feedback is fresh in people’s minds. Depending on the complexity of the project, it might also be helpful to distribute the surveys first, then highlight any recurring themes in a later review session.
  • A post-implementation review session: Convene the project team for an open and honest discussion about the entire project, from planning to implementation. Ask attendees to discuss what worked, what didn’t work, what was missing, and what could be changed for future projects.
  • A final consolidation report: Once you hold a post-implementation review session and collect data from surveys, the next step is to compile your findings into a final report. This final report might be distributed to stakeholders or stored as a reference point for future projects.

The most important part of the evaluation process is to document lessons learned for future projects!

Project Management for Communities Toolkit

Complete this short form and we'll send you the toolkit via email.
  • This field is for validation purposes and should be left unchanged.