Project Management Best Practices

This document is intended to provide an overview of phases in project lifecycles. It includes brief
descriptions of phases as well as potential questions to consider at each phase. It does not adhere to a
single project management methodology but draws from multiple. More specific documentation that
elaborates on project management processes and templates will be linked here as created.

Before you begin 1

Starting a project 1

Project documentation 2

Projects in progress 3

Ending a project 4

Before you begin

Before you formally initiate a project, ensure that a project is necessary. A project has a clear
beginning and end as well as clear objectives. A project will solve a problem by providing new or
improved products, services, or processes.

Questions to ask:
● What is the problem you are trying to solve?
● Is this something that has a clear end?
● Do your colleagues and management agree that your problem is “a problem”?
● Would a SWOT analysis be helpful in defining your project?
● Has someone else already solved this problem somewhere else? Can you borrow from
their work?
● Has someone else already attempted to solve the problem at your institution? What was
the result and why was it successful / not successful?

Starting a project
Once you have determined that this problem is best solved by a project, begin the project
planning and pre-work. This is a time to develop documentation that will guide the project -
those who work on it, the tasks it undertakes, and the output it produces. While everyone may
be excited to begin working on the project immediately, spending time to develop
documentation generally will reduce unnecessary work or rework and keep everyone on track in
the longer term. Some projects may lend themselves to a lightweight approach and won’t
require all the documents described here, but it’s useful to be familiar with the full breadth of
available tools.
Pre-project work is the phase in which a problem is identified, defined, and information about
the problem is gathered. This information can include details about the current state of practice
at your institution as well as information from an environmental study. Pre-project work also
includes the identification of stakeholders such as: end-users/customers, managers, project
managers, those doing the work, those funding the work as applicable, and any generally
interested parties.

Questions to ask:
● What resources do you need? (people, money, material, time)
● Who are the right people to solve your problem?
● Do you require a domain or subject matter expert to understand the problem and solve
it?
● What is the priority of this project in relation to other projects and ongoing work?
● Who needs to “buy-in” or approve before you can begin?
● Who are the anticipated users of the product or service?
● Who and what will be impacted by the new product or service?
● Will any users of the service or product need training before the product or service
launches?
● Think about: owners of and a plan for ongoing commitment.

Project documentation
The documentation developed while starting a project can include a project charter (see: ​TRLN
Project Charter Template​) or project plan, a communication plan, schedule, budget, supporting
information in a project management tool, and any other supplemental information. These
documents will provide in-depth information about people (see: ​TRLN Project Roles Definitions
and ​Template​): project team members and their roles, stakeholders and their needs, and
communication expectations. The documents will also define the project’s end result: goals,
functional requirements, deliverables, and what is in or out of scope. Finally, the documents will
address the things that impact projects: budgets, timelines, risks, and change processes.

Hold a kickoff meeting either prior to creating documentation or once documentation has been
finalized. Regardless of timing of the kickoff meeting, ensure that all key individuals sign off on
the project charter/plan so that everyone involved can proceed to the goals with the same
expectations for success. Use the project charter/plan to get buy-in from stakeholders (both
those who control resources for your project and those who will be impacted by your project).

Questions to ask:
● What is the project’s goal and scope? What is (are) the associated deliverable(s)?
● Who is involved in or impacted by the project?
● What are the project limitations and constraints (time, budget, challenges)?
Projects in progress
Now that the project is underway, your well-articulated plan, timeline, and stakeholder
identification will help you to keep the project on track. However, even with excellent planning
and the best intentions, projects will inevitably get messy.

As the project manager, ensure that you perform regular, scheduled assessments with your
team and check-in with the stakeholders. Communication is essential throughout a project’s
lifecycle! It is often beneficial to use prototyping, mockups, and beta testing to gather feedback
at multiple points in the process, which also helps your team to embrace risk taking, failure, and
iteration.

In all of your communications with the team, be honest about the project’s progress, challenges
(aka roadblocks), and remaining work. It is hard to be honest, especially if the project has
encountered problems. Don’t be afraid; be clear about issues. Your team and your stakeholders
respect honesty. You can do it! Enlist the help and support of management when needed if your
team members are not delivering as promised. Conversely, don’t hesitate to celebrate victories,
however small, and acknowledge progress.

Be open to change - in goals, scope, schedule, budget, and stakeholders - but do not let it
manage the project. If a change occurs that impacts the project, make sure to update the
documentation so that you have a record moving forward. Don’t be tempted to over deliver or to
dive down every rabbit hole or tangent. Remember that you can always create new, related, or
follow up projects for things that are worthwhile; but if you continually move the goals for your
current project, you prevent progress.

Questions to ask:
● Re-read your project charter - does it resonate with the work you and the team are
actually doing? Or are you now doing a completely different project?
● Are you following through with your communication plan?
● Is the project still in scope? Is the scope creeping?
● Is the timeline still achievable? Why or why not?
● Where are the roadblocks? Who can address these issues?
● Have you learned anything that indicates a need for changes to your project?
● Are you over-delivering?
● Are you assessing & measuring the right things to ensure success?

Ending a project
Once the new or redefined product, service, or process has been delivered ​and accepted​, the
project is complete. Any ongoing or maintenance work should be considered regular work, not
part of the project. In addition to getting formal approval that the work is complete, the end of the
project is also the time to assess the project as a whole (see: ​TRLN Gathering Feedback matrix​)
to better inform future projects, finalize and archive project documentation and lessons learned,
and celebrate success. If the team is tracking their time, the end of a project presents an
excellent opportunity for consolidating this data. Although it can be challenging for teams to
embrace time tracking, it is the best method for predicting the resources required for similar
projects in the future.

Although not essential, it is beneficial to document the end of project assessment as a report
and archive it with other project documentation. It is not overly time-consuming to produce an
end of project report, and as it is sometimes required for grants it is a good habit to form.
Regardless of how the end of project assessment is conducted, it is important to recognize team
members’ contributions and show appreciation for their efforts. It is also beneficial to officially
inform all project team members that the project is over, their work is complete, and they are
free to focus on other tasks and projects.

Questions to ask:
● Did you meet the project’s goals?
● Did you receive sign-off on the deliverable?
● Have you transitioned any service/support work to those responsible for it?
● What lessons did you learn? How can you use them and your project’s information to
improve a future project?
● Did you thank your team and your stakeholders? Is there an opportunity to thank your
team publicly or announce your results widely?