We encounter projects in our everyday lives—in business and at home. Think about projects for a minute: at work you might be building or contributing to a deliverable (like a report, a website, a tool or product, or even a building), and at home you might be making a meal, planning a vacation, or even working on upgrades to your home. These—and many other examples—are true projects that have a defined start and end date, a goal, a scope, and resources. And, they all require some level of management.
In business, which is where we’ll focus in this chapter, projects are typically unique operations that are conducted to meet specific goals. Examples of projects might be the development of software to increase employee productivity, the construction of a building to house community events, or the design of a website to decrease call volume to a business. The list could go on and on. All of these types of projects require a team of people who are responsible for different aspects of the delivery. For instance, you’d likely see a designer, developer, and copywriter working on website design projects. In many instances, a project manager is staffed to these projects to ensure that the team delivers the project on time, under budget, and meeting its stated goals.
So, then, what is project management? It’s not a tool or a person, it’s a practice. Project management is a critical practice that applies knowledge of process, skills, tools, deliverables, and techniques to project activities to ensure a solid path to project success by meeting goals and requirements.
So, then, what is project management? It’s not a tool or a person, it’s a practice.
No matter where they work—construction, consulting agencies, marketing teams, manufacturing, HR teams, software developers, and event planners—or the types of projects they manage, project managers are the men and women on the front lines of projects, defending their teams, clients, and projects from miscommunication, missed deadlines, scope creep, and any other failures. They champion the well-being of the people involved in their projects and look to make or facilitate strategic decisions that uphold the goals of their projects. That’s a hefty job description, and it requires a fine balance of managing the administrative details of a project and its people. While PMs are often lumped in the “behind the scenes” aspect of project, to be highly effective, they need to be a part of the bigger strategic project conversations.
PMs are not robots. They are not on your team to just take notes and make sure you’re recording your time properly. Yes, they do work in spreadsheets and follow-up on deadlines at a sometimes-annoying rate. But the PM role is important on your team for several reasons.
There are so many intangible tasks and qualities of project managers that it’s not uncommon for people to not fully understand just what a PM does, and if they need one or not. Here’s the thing: You always need a PM, no matter what. That PM might be called a producer, account manager, designer, or even developer.
As mentioned, the role and even the title may differ slightly from place to place, but the basics of what a PM will do for a team are fairly consistent (though some may be less formal than others). The role of the project manager encompasses many activities including:
That is a lot to include in one job description—one that does not actually hold any operational or management responsibility for the team working on the projects. Often, you will find PMs in a tough position of trying to make things happen, but without the authority to truly push an issue. In order for that to happen, the PM has to gain the trust and respect of their teams and have the endorsement of senior management.
Project management speak can get technical, but it all comes back to terms that keep projects on track. Here’s a list of things you might hear come from the mouth of a project manager (in alphabetical order):
Agile methodologies are based on the mindset that self-organizing software development teams can deliver value through iteration and collaboration. The Agile Manifesto for Software Development was formally developed in 2001 by 17 practitioners and is based on a core set of values of delivering value and collaborating with customers. The principles are:
When PMs or teams make assumptions, they have to communicate them, because project assumptions can affect scope, goals, deliverables, and outcomes. In fact, assumptions can set the context for how a project is defined and even executed. You’ll see project managers bringing up assumptions and turning them into larger conversations, scope line items, milestones, deliverables, and anything else to ensure that the team is operating on concrete facts.
Projects change often and it’s the PM’s job to make sure that everyone—clients, team, and any other related parties—is aware of the change and its impacts. As the scope or business requirements change during the project, it is very likely that the effort, associated cost, and deadline may no longer be valid. In this case, the PM will draft a change order or change request document to formalize the change and its associated impacts.
This can mean a couple things. PMs working in a consulting space like an advertising agency or building company work with clients to build or deliver a product. The PMs need to take those clients into account when crafting process, presenting work, and gaining approvals. At the same time, those clients might have clients or customers they are trying to please when building a product. Often, in the digital space, you’ll hear those people referred to as “users,” and a lot of work is done to ensure that a product is built to please these people.
Constraints are limitations that are outside the control of the project team and need to be managed to. An example of this might be a scope or budget, or a timeline. There is only so much you can do within those things, so they set a constraint on the work product. Project managers are hyper aware of these constraints, because it’s their job to keep projects within timeline and budget.
The critical path is the sequence of stages determining the minimum time needed for an operation, especially when analyzed on a computer for a large organization. It’s a formal, step-by-step project management technique for process planning that defines critical and non-critical tasks with the goal of preventing scheduling or timeline problems and process bottlenecks.
A deliverable is any tangible outcome that is produced by the project—either produced along the way to gain consensus, or delivered at the end as the final work product. Examples of deliverables include visual designs, documents, plans, code, prototypes, blue prints, proofs, buildings, apps, websites, products, etc.
In project management, a dependency refers to a task that cannot happen without its predecessor being completed. This is an important detail for PMs to consider when planning projects. Planning tools like TeamGantt make it very easy to point out and track dependencies.
A gantt chart is a chart in which a series of horizontal lines shows the amount of work done or production completed in certain periods of time in relation to the amount planned for those periods. TeamGantt produces beautiful gantt charts to help you keep track of your project tasks, dependencies, resources, and even communications. Check it out now!
A project goal or objective is a documented statement of the intent and outcome of the project. Goals are used to help make decisions when at crossroads, or points of indecision (or even scope creep) of projects, because the goals determine project success.
Project managers are constantly hunting for project issues so they can knock them down before they become bigger problems. Issues typically impede the progress of the project and cannot always be resolved by the project manager or project team without outside consultation. A common example of a marketing project issue is when content is absent or delivered late. When that happens, it holds up progress and often requires the deadline to be moved.
A milestone is an action or event marking a significant change or stage in the production or development of a project. By its project management definition, a milestone has a duration of zero and no effort, because there is no work associated with it. It’s essentially a point in the project plan that signifies important work has been completed, and the project will transition to a new phase.
There are several ways to manage projects, as methodologies and processes have been formalized and taught for several years—waterfall and agile methods included. It’s good to know how methods were created, and decide for yourself how they can be adapted in the work you’re doing today. So, if you’re looking to learn, see our chapter about project management methodologies, including:
When working on several projects that are connected in some way (goals, product, client, etc.), it’s often referred to as a program. The program itself is not a project with deliverables. It provides overall management to ensure that all projects included have a central point of communication that provides consistency and alignment for the proper timing, pacing, and approval of all interconnected projects.
Program managers are often not only responsible for projects, but also for larger strategic initiatives and sometimes teams of project managers. When it comes to programs—or sets of projects—they help articulate the goals and objectives of those connected projects and how their outcomes will impact the business overall. Knowing these goals helps the program manager focus on the strategy of each project's implementation and how to get them done with the appropriate resources and team members.
This was mentioned at the beginning of this chapter. Projects are unique operations that are conducted to meet specific goals. Examples of projects might be the development of software to increase employee productivity, the construction of a building to house community events, or the design of a website to decrease call volume to a business.
Also mentioned earlier in this chapter, project managers are the men and women on the front lines of projects, defending their teams, clients, and projects from miscommunication, missed deadlines, scope creep, and any other failures. They champion the well-being of the people involved in their projects and look to make or facilitate strategic decisions that uphold the goals of their projects. That’s a hefty job description, and it requires a fine balance of managing the administrative details of a project and its people. While PMs are often lumped in the “behind the scenes” aspect of project, to be highly effective, they need to be a part of the bigger strategic project conversations.
In order to organize projects, PMs will organize series of tasks or deliverables into phases. On a website redesign project, logical phases might be definition, design, development, and deployment.
PMs create project plans to chart the course for how a project will be completed. Good project plans show overall process in phases, deliverables, and tasks along with corresponding detail on who is responsible, the dates when the work will start and finish, and any relevant notes for each task. The project plan is a form of communication and arguably one of the most important deliverables on a project, as it provides detail on what should be happening at any point during the course of a project. You can find plenty of sample plans and templates on the TeamGantt website.
The project team includes the people who are responsible for conducting tasks and completing deliverables on a project. Project teams vary by industry and project type, and companies recruit the proper team members with expertise to conduct the work.
Requirements are critical to getting a project done right. Requirements are often included in a detailed scope of work and define how the product should act, appear, and function within the stated goals.
This is a term that is by far the least human of all PM terms. Resources are the people who do the work on projects. A better term here would be “staff” or “team” but for some reason, we revert back to this. You’ll see or hear about “resourcing plans,” which are created to ensure that staff are properly assigned to projects and not being over- or under-utilized. A simple way to sort this out is by using the resourcing functionality in TeamGantt, which allows you to assign people to tasks and estimate the time needed to complete tasks.
Issues cause risk! When PMs talk about risk, they are thinking about potential issues or events that cause things to go wrong along with the probability the event will occur and how it will impact the project overall. A good way to keep a team tuned in to potential risks is by including a risk register (or a list of risks, issues, and a mitigation plan) in a regular status report.
A scope describes, in detail, what will and will not be included in a project. It defines what the project will deliver and what it will not deliver. When in a consulting organization (like an advertising agency), this will take shape in a formalized document. When working for an internal team, it might take shape in a brief, or even in a less formalized format like an email.
When working on large projects, you might hear the ultimate decision maker or funder referred to as the project sponsor. This person has ultimate authority over the project and will be involved to make funding decisions, resolve issues and scope changes, approve deliverables, and provides overall strategic direction. At the same time, the sponsor is often held responsible for championing a project within an organization, ensuring that all are on board.
Stakeholders are the people who have an actual stake in the outcome of the project. They can be internal to the project (think marketing, IT, and other departments), but also external to the project (suppliers, investors, partners, etc.). PMs work with stakeholder groups to make sure they are aware of project developments and are a part of the decision making process when necessary.
Waterfall is certainly among the most widely-known and practiced PM methodologies. The key ingredient in running a waterfall project is to complete a task and hand it down for it to be used, or built on, in a following task or phase. This requires a fair amount of planning and requirements gathering before work begins. Without that initial step, steps can be missed, incomplete, or even out of line. Further, any alteration to project requirements can cause a change in scope.
There is no single way to run all projects. You’ll find that most organizations spend a lot of time making mistakes and adjusting their process in order to get it just right, only to find that when they thought it was “just right” it needed to be tweaked again. Factors like changing business needs and goals, new or different staff and expertise, evolving or new technology are often among reasons why processes have to change. But what’s most important is that an organization or team have a basic framework for how projects operate. As you research project management processes, you will find that most models identify three basic phases (with varying names, tasks, and deliverables) to organize activities:
Typically, an organization will perform some level of research to determine the validity of a project. This could take the form of market research, user research, competitive analyses, among many other activities. These are the critical steps in the project that help to define goals and requirements for what needs to be designed or built. This is also when a project team can come together to define how they will work together, and what their execution plan will be, taking all outside factors into consideration.
Once the project is planned, it’s time to execute. The execution can play out in several different ways, using different processes like waterfall, agile, or variants therein. Essentially what you will find in this phase is time for collaboration, creation, review, and iteration. Teams will partner with stakeholder groups to present work, accept feedback, and complete deliverables that are mutually agreed upon, leading up to a final deliverable. This happens to be the phase that is riddled with change, delays, and sometimes even dispute. For that reason, it happens to be the phase where the PM is most active.
After a project has launched, it’s time to make sure it’s tracking well against its goals. In an agile project, a minimum viable product (or MVP) will be launched to gain early feedback to iterate. On waterfall projects, the feature-complete product will be launched and tested. In either case, test results will reveal what is and is not working for users and stakeholders. Teams will take test results and alter—or build on—the product to create something that is closer to those goals. This is natural for agile projects, but not so much for waterfall projects, which would require a new or “Phase 2” project to be added on.
There is no right or wrong way to roll out a process. What’s most important is that the process matches the values and talent of the organization. It will become quite evident if the process is not a right fit for a team, because people will be unhappy and work will not get done without issues. The best thing you can do when it comes to process is sit down with your team to discuss what will work best and why. Document decisions, roll out a process, and be open to discussing it and changing it when needed. Keep the 3 steps above in the back of your mind for an overall framework to operate by, and do what feels right for your project and your team.
There are so many intangible tasks and qualities of project managers that it’s not uncommon for people to not fully understand their worth. The benefits of any role seem to come down to perception, but a bulk of a PM’s work is “behind the scenes,” so how can you demonstrate the benefits? First, it starts with the individual. Each and every PM should know their role and their worth and follow-through on being a good PM for their teams. Second, it comes down to the organization. A PM will not thrive in an organization that does not value the role and see the benefits of it. And, lastly, the benefit of having a PM on a team is realized by the people who work with them. If they are not bought in, the PM will have a hard time helping.
Some people see the benefits of having a PM on a team, and others don’t. And that is okay—sometimes just having someone on a smaller team to handle logistics and communications is enough. That’s right, you don’t always need a PM, but you do need someone who will handle PM tasks. If simply stating that managing tasks and communications can provide more time to team members to collaborate and create isn’t enough to sell you on the value of PM, read on for more direct benefits.
Having a PM on your team means that you’ve got a person dedicated to making sure that work is done on time and at the right time. That person is also looking to make sure that the team’s practices are running smoothly, and if they are not, they will be corrected through discussion. This is the kind of thing that makes teams happier, because they can focus on working hard and producing successful products.
Everyone—clients and teams—walks away from projects that are done on time and within budget with a smile on their faces. They’re also happy when they’re communicating well. Guess who helps to make all of that happen?
Teams with project managers benefit from the fact that someone is paying attention to how, when, and why something should happen. Great PMs utilize tools like project plans and RACI matrices to help suss out the details. When you have a dedicated PM, there is time to organize and use the right tools to help a team.
When you’re trying to work on a task and manage it along with everyone and everything else, it can be tough. That means that you don’t have the time to focus on your work product, or developing strategies or methodologies to do it better. When a PM is involved, that stress is peeled away and the team gets to collaborate and grow by trying new approaches to deliverables. There’s something to be said for letting experts focus solely on their craft (even when that expert is a PM).
Great PMs know that projects change, and they are always on the lookout for it. And when that change becomes a real factor, they immediately find ways to adapt the project’s path. Having a PM on your team means that you’ll always know when a risk, issue, or change is on the horizon, and you’ll be able to plan for them.
When your team is focused on their craft, the quality of work goes up because they have all the time they need (well, within scope) to do that job. And, a good PM will always have quality of work on their minds as they help to deliver work to stakeholders. It’s common for a PM to contribute to internal reviews, proofread content, and make sure that work is flawless before it goes out the door.
This one is important for business owners. When you remove the burden of PM from your team and place it on one person, you free up their time to take on more projects and produce more work. Sounds like a win-win.
There are surely many more benefits to project management, like the hard facts and details you get out of typical PM reports and deliverables: transparency on budget and timeline, accountability for tasks, and so on. Those tend to be the things people think about when they hear “project management,” and they are absolutely great benefits. But as you see, those benefits create other benefits that affect not only the bottom line, but the people and the process.
In order to be a great project manager, you have to educate yourself and stay current with what is happening in your industry. New articles, books, courses, blogs, newsletters, templates and resources are made available to PMs and PM enthusiasts every day. But how do you keep up with it all? It’s not easy to wade through it all and know what will work best for you, and we get that. That’s why, over the past few years, TeamGantt has produced a lot of great content to help you be a better project manager. Check out these resources:
Educating yourself on project management is the first step in defining what your organization needs in terms of the role, process, and everything else wrapped up in PM. The best job you can do is take this information and adapt it to your situation. One way to ensure you’re headed in the right direction is to ask yourself these questions:
There are tons of questions you could ask, but give these a shot. Or, even better, talk to a project manager who can help you to determine the right path for your organization.
Learn how easy project planning can be with TeamGantt. Create your first gantt chart for free.