If you want something done right...better hope you’re in the right kind of organization. All projects are about teamwork—but how your team works depends a lot on the type of organization you’re in. In this chapter, you’ll learn about the different types of organizations around—and which type you should look for the next time you need a new job.
Now that she’s working on getting her PMP certification, Kate’s learning a whole load of new skills. And she’s even started to look for a new job—one where she does more than write down what other people say all day...
Kate is a project expediter right now.
Kate may have the job title of “project manager,” but even though that’s what’s printed on her business cards, that’s not really her job. Kate’s job is to document what’s happening on a project, but she doesn’t have the authority to make decisions on it. The PMBOK Guide calls this role a project expediter. She may work on projects, but she’s certainly not managing anything.
Kate’s got three major options when looking at the kinds of organizations she can work for. Functional organizations are set up to give authority to functional managers, projectized organizations give it to the PM, and matrix organizations share responsibility and authority between the two.
Good point.
Sometimes companies will use multiple organization types to get different kinds of projects done. Those organizations are called composite organizations.
Kate: Hi, Ben. I’m excited to be here. It’s such a relief to be hired as a project manager, and not just a project expediter anymore.
Ben: We’re excited too, since you’ll be taking care of our main software development project. It’s in maintenance mode right now.
Kate: Sounds great. How do we handle that here?
Ben: Well, we’re constantly getting business reports from the field, and when people think of new ideas, we just add them to the project.
Kate: Umm...so how do you know when you’re done?
Ben: We’re never really done; we try to release new versions as often as possible.
Kate’s spent a lot of time studying for the PMP exam, and the first thing she learned was that a project is temporary. When she sees ongoing work that doesn’t really have a start or a finish, it’s not a project at all. Ben asked Kate to do operational work, which has no beginning and no end. Since there’s no way for Kate to know when she’s done, it will be harder for her to be successful at her job. And that makes her nervous!
Anyone who will be affected by the outcome of your project is a stakeholder. It’s usually pretty easy to come up with the first few people on the list of affected people. The sponsor who’s paying for the project, the team who’s building it, and the people in management who gave the project the green light are all good examples. But it can get a little tricky as your project gets going. You might start with that core group of people and find that the number keeps growing as time goes on. It’s your job as a project manager to find all of the stakeholders who are influential in your project and keep them updated on where your project is going. Making sure that their expectations are managed can be the difference between your project succeeding and failing.
Not all of the people you’re working with are rooting for your project to succeed. Sometimes, the people you’re working with think that your project might bring negative consequences for them. Ben’s worried that bringing any kind of planning into his company will slow down his team. Kate’s going to have to manage his expectations and work with him to set goals that make sense to him if she’s going to bring him around to supporting her work. You need to know what’s motivating all of your project stakeholders if you’re going to understand the influence they’ll have over your project.
One of the first things you’ll do when you start a project is figure out who your stakeholders are and write down their goals and expectations in a stakeholder register. That’s part of the Identify Stakeholders process that you’ll learn more about in Chapter 13 of this book. Even though you do that work up front, you’ll find that new stakeholders are always popping up, and you’ll need to make changes to your stakeholder register to include them as you learn about them.
You’ll learn more about how the Identify Stakeholders process helps you understand their goals and expectations in Chapter 13.
Take a minute to think about all of the stakeholders who’ve ever had something to do with the projects you’ve worked on in the past. Making sure that they are all informed and helping your project to succeed is the point of Project Stakeholder Management, one of the 10 knowledge areas that are covered in the PMBOK Guide. Let’s take a look at some of the kinds of stakeholders that will impact your project.
Project Stakeholder Management is covered in depth in Chapter 13 of this book.
The sponsor is the person who pays for the project. Without the sponsor’s help, there’s no way the project can be a success.
Usually, you build a product or service so that someone can buy or use it. You have to make sure your project meets the customer’s needs if you want to call it successful.
You might license software or contract consultants to help you build your product. The companies you work with to help you deliver it are stakeholders in your project’s success too.
You might not think about it at first, but there are many ways that groups outside your team can be affected by your project. Your sales team, your internal support teams, all kinds of groups inside your company will have a stake in your project’s success
Your company might contract a company to provide training or other materials that affect your project. They’re important stakeholders of your project too.
If you’re building an accounting software package, you’re going to need accounting expertise to understand what you’re building. Functional managers provide the subject matter expertise to make things run smoothly on your project.
When you think about it, most of the roles we just talked about have a place on your project team too. When you think about your team, it’s easy to focus on the PM and the project staff. But your team can be comprised of roles from many different stakeholder organizations. Think about all of the stakeholder organizations that might help you deliver the product of your project by actually assigning people to your project team.
Human Resource Management is covered in depth in Chapter 9 of this book.
Let’s figure out how things are working in Kate’s new organization... and start to think about how we can improve things.
When Kate thinks about solutions, she’s going to have to deal with the project’s constraints. Every project, regardless of what is being produced or who is doing the work, is affected by the constraints of time, scope, cost, quality, resources, and risk. These constraints have a special relationship with one another, because doing something to deal with one of the constraints always has an effect on the others.
Any time your project changes, you’ll need to know how that change affects all of the constraints.
For Kate’s project to succeed, she needs to think about the project constraints. If she doesn’t manage these six constraints at the same time, she’ll find that her project is either late, over budget, or unacceptable to her customers.
A stakeholder is anyone who is affected either positively or negatively by your project.
Even the best project managers can’t control everything that affects their projects. The way your company is set up, the way people are managed, the processes your team needs to follow to do their jobs... they all can have a big impact on how you manage your project. On the exam, all of those things are called Enterpise Environmental Factors.
Kate: This will really come in handy. There’s an organization chart that describes all of the teams and people that will rely on our project. Wow. There’s also a whole process for escalating issues that come up.
Ben: I wanted to make sure we didn’t re-invent the wheel when we drew up the plans for our development project.
Kate: This will make my life a lot easier. One question though: I don’t see any guidelines for project acceptance. How do we know if a project is a success?
Ben: Usually our sales team takes the new features out in the field and they let us know what the response is. If our customers like what we’ve done, the project is a success. If not, well... you get the picture.
Kate: Umm... that sounds a little hard to manage.
It’s a lot harder for a project to be successful if the team doesn’t have a clear goal in mind. Kate’s project needs to follow all of the company governance guidelines, but she also needs to write down the goal her team is shooting for. That way, it will be clear that the project has met its goals when it completes. Most projects aim to finish within the constraints we talked about in the last chapter (time, cost, resources, quality, risk, and scope). It helps to write down concrete goals for those constraints as acceptance criteria up front. That way there are no surprises when the project ends.