I'm incredibly pleased to bring you this interview with Kevin Archbold, a 25-year veteran in project management and a 13-year consultant and teacher of the specialty. This opens the door to people who have excellent skills to better managing their projects and getting better communication going. This one is dense, but work through it carefully because it's a life-changing skill and Archbold is a master at this topic.
You might also be interested in his GiveGetWin deal, "Real-Time Live-Fire Project Management Training With Kevin Archbold" where you'll bring two sentences describing a project you want to the 5-person class, and leave with a project charter filled out.
Better Project Planning Means Less Project Failure by Kevin Archbold, as told to Sebastian Marshall
My background is project management. Most people have a career in a technical field first and then move into project management, but I went directly into PM after University in England. I found it was a good fit for me and stuck with it ever since.
I've got a CompSci degree, but no one's ever paid me to program anything. I started in the telecommunications industry, and then moved through many other industries: 10 years around Detroit, working on a lot of automotive and time at a nuclear power plant. I've worked on internet startups and biotech in Seattle, spent time with the City Government in Seattle, and have been in Tucson for seven years now -- doing mining-related projects and astronomy related projects… a whole gamut of things. I do not provide technical expertise; I bring fundamental project management.
Most people are interested in why projects fail and how to not have that happen to them.
Very often, the root cause of project failure is that stakeholder expectations haven't been well-managed, or even well understood. Projects will fail when key people are expecting different things from the project. Sometimes that comes out in the middle of the project… or sometimes at the end, when it's delivered and the project team feels good about what they delivered, but people feel it didn't meet their expectations, and regard it as a failure.
These unclear and conflicting expectations manifest in different: projects that fail to get started or take a very long time to get started because can't come to an agreement about what the project is. Some projects do get started but then people disagree before it gets really rolling. Sometimes people have a hard time defining the scope and knowing what they're supposed to be doing or not doing.
Sometimes it happens later in planning, with the project almost fleshed out and then a key person says it needs to be put on hold. Maybe the worst is when the disagreements happen towards the end of execution and the team finds that key stakeholders are disappointed.
Sometimes people you never contacted who are going to be impacted come out of the woodwork and are mad because their feedback wasn't incorporated, but it can be challenging when you're well underway with these sometimes angry stakeholders.
Organizations often have a lot of problems at the end of projects. They often don't have a very clear definition of the end of a project, and so the project goes on forever or longer than anticipated because they didn't have a good understanding of what the end conditions look like. So they can never wrap this thing up, they go over budget… because of this lack of clarity of the full scope of what the project is going to do.
The term stakeholder is used slightly different by different people. A good best practice definition is anyone who is involved, impacted, or perceives themselves as being impacted by a project.
This can be a pretty long list of stakeholders for most projects: sometimes they can be grouped together as a group of stakeholders, but you should list them all out and think about what their needs are. The piece most people miss is who is impacted.
Whoever is leading a project might realize six people are heavily involved and realize two people are going to be significantly impacted, but they forget there's another 10 people who expect benefits from the project, or even are resistant to the project happening.
Imagine you're opening a new office in a new location and that's the project. You yourself would be a stakeholder. Anybody involved in the logistics in the organization would be a stakeholder: whoever looks after phone. The lease and facilities people. Anyone involved in legal. The staff who are going to be going into the new office would be stakeholders. Let's say you're moving into an office park environment -- the neighbors would be stakeholders of this project, they're going to be impacted by you moving into the office.
Just because you identify someone as a stakeholder doesn't mean you're necessarily going to spend a lot of time with them, but you still want to identify them and make a proactive decision to include them or not. So maybe you won't involve your neighbors in having a big say in the project, but you should still identify that. Then maybe you reach out to them and explain what you're doing, or maybe not.
If we stretch the concept a bit further, even the utilities companies, anyone providing services to the office park, these are stakeholders. Our existing customers in this geographical region are stakeholders; hopefully we can service them better now. "Future customers" might be stakeholders, and we might not even know who they are!
The company's senior management would be stakeholders. All the staff who are going to work at the office, obviously, and the leaseholder (assuming we're leasing the space). The salesperson, perhaps, who is leasing the space. The legal people from the business park would be stakeholders.
Let's look at it again from another angle. Let's say we have a project at a startup.
You're a stakeholder on your own project. You're going to help define and document the process. There's probably someone who "owns" this part of the company and they'd be a stakeholder. If it's a small company, probably every person at the company will be impacted; we could list everyone out and think about how they'll be impacted.
We'll have 2-3 people who are going to work with us, brainstorm, and document the project with us. They'll be impacted in a different way -- in their functional role, but we're also going to be consuming their time to work on this project. Presumably the goal of this project is to improve the efficiency of the company, so our customers are stakeholders. They benefit from our efficiency here.
We could stretch this out to say, if there's investors (or wherever the funding is coming from), those people are going to be impacted in a different way. Without getting into the specifics, if there's vendors involved and we could be purchasing or changing who we purchase from as part of this process…. let's say we're thinking of buying from a new vendor. Our existing vendor would be a stakeholder, and the pool we could buy from are stakeholders, and the final vendor we choose is a stakeholder. If we really stretch it, your competitors could be stakeholders -- if you bring in more business and are more successful, they might benchmark against you and try to copy your process.
These are all things that could influence how you think about the process very early on. Imagine you got halfway through the project and realize your competitors could just easily copy what you did and you'd have no advantage. Or imagine your investors would get worried about the cost of you switching, and if you'd talked to them upfront they would be less worried. Maybe key customers are getting unsettled.
The point is, we want to get all these potential stakeholders on the table upfront and have an intelligent conversation about them (and possibiy with them).
We want to identify everyone, maybe not talk to everyone, but definitely not fail to think of someone and fail to talk to them because of it.
An example from the radio recently -- there was a project to build a radio tower, and there were some local protests. That's not unusual, but the project manager had already reached out to the local city council, they had gone out to visit the immediate neighbors for where the tower was going up and had talked to them, had talked to local utility companies, and they had started construction… but then people came out of the woodwork and started protesting. But it turned out that the people who were protesting weren't in the jurisdiction, but were in the neighboring jurisdiction. It wasn't going to affect them as much as the neighbors right there, but it was going to -- perhaps -- affect their view of the mountains.
No one has talked to them, and so they get alarmed, and start causing a ruckus. This group was outside the jurisdiction, they weren't an obvious group to talk to, and they experienced difficulties there. The project manager thought they did a good job of covering everyone, but this group they missed caused problems.
There's many things you can do to set and manage stakeholder expectations. And remember, you might well be the "project manager" on anything you're responsible for having happen, even if what it says on your business card isn't "Project Manager." If you're tasked to get something done, you're a project manager.
The most important thing is to get all the stakeholders on the same page at the very beginning and have a clear shared understanding of what the project could be. Before we launch or begin executing, we bring everybody together and get everyone on the same page of what the project is.
That's probably the #1 mistake organizations and individuals make. They want to jump off and get started, but all the key stakeholders don't even have an understanding of what the project is.
One example, a very real one: I got involved with a fairly large team working on an IT infrastructure project for bringing together IT, government, and the trucking industry. It was about regulations and regulation enforcement in the trucking industry. They'd been meeting quite some time before I joined, and when I came in and listened to what was happening, it was clear they were getting absolutely nowhere.
It became quite apparent that the reason they were getting nowhere is because they weren't in agreement about what the team should even be doing. There were two camps that had different ideas of what the team should accomplish, and they had no decisionmaking process to keep moving forwards.
My advice was to create a project charter. And it was fairly painful, and they wound up needing to split the team into two -- half the team thought the charter was a good fit, but the other half saw it as not quite right -- so they needed to break into another team, and created a second project.
We were able to clarity what everyone needed to do, put a decisionmaking process into place, and then what became two different teams were both able to move forwards with clarity on what they needed to do.
A more generic but everyday example: When a boss comes to you and says, "here's a little project I want you to take on," the first thing I recommend you do is write a project charter. Then go back to the boss and say, "this is my understanding of what you asked me to do." You get clarification from the boss on what they want it to look like. You can clarify the scope and raise any potential issues early, that your boss has perhaps not considered yet but which could shape the project significantly. You can tell from the boss's "this is just a little project, it shouldn't take much time" attitude that it perhaps hasn't been thought through very well.
So, define it. Understand the parameters of what you're doing. As a result of your clarification, the boss could look to understand it in new ways. You want to come to a shared understanding before you launch the project.
For all projects, you should be writing some version of a project charter.
It's been my observation that most organizations have something, at least for customer-facing projects. Usually this is very focused on scope, what we're going to do for customers, and the main deliverable. But often, many subtle points are missing. Key points that I would advocate putting in the project charter so you don't run into roadblocks or deadlock later.
We introduced this with the flavor of the stakeholder expectations -- stakeholders popping up halfway through, getting everyone involved, and sometimes the project manager not understanding why it's being done.
That sounds fairly obvious, that the project manager should understand the bigger picture of why things are being done, but often it's not the case. Often the person running the project doesn't understand why it's important at this time! All these questions are helped by creating a project charter.
A good charter creates a nice summary of the project, so when people join later, it's a very succinct way of sharing good concrete information about the project with individuals.
The project charter is short -- 1-2 pages -- document that allows us to have that initial discussion. Before we launch into detailed planning, we make sure we brought everyone together and have them on the same page of what the project needs to be.
This first document is like setting the first tile in the kitchen. If it's slightly off, it can have a huge impact on the whole floor. So it is with the project charter -- if we can set it right, it'll make things easy. If we put the first tile down haphazardly, we'll have problems we need to fix later.
Challenges can be minimized -- obviously the project charter doesn't solve everything, but it's a very important step to deal with stakeholder expectations.
There have been different charters you come across, of different lengths and complexities. I have a template I've used for many years now, and it seems to work well. I didn't create the concept of a project charter, but I did make my own version that works to clarify all the key points you need to think through to minimize problems later, ensure you get the project started on the best footing, and do it in a way that's simple for everyone to understand. If you have the right information, it doesn't take a long time.
I've been using the tool I created since 2003, for 10 years. It's worked very well for ten years or more. It's saved my bacon and that of the people I work with many times.
When people hear about this, they often recognize immediately it would benefit them, and their eyes light up when it if they haven't before. It's the #1 thing that people take away from project management classes, it's the #1 most downloaded template on my website.
Sometimes there's pushback to this concept.
Typically most people recognize if they had this, it'd make their life easier. But sometimes there's a pushback, when they start to fill it in, it takes more time than they expected.
The reality is, filling in a 2-page document doesn't take much time to type. If it takes time, it means you're needing to think through and ask questions to different people. If it's taking time, it means you're getting conflicting information or have missing information. That's the point, that's why you write a project charter.To make sure you can get everyone to agree. If you can't get people to agree on a 2-page document, then how are you going to get them to agree to the project?
NOTE: THE REST OF THE DISCUSSION WILL BE AIDED BY DOWNLOADING KEVIN'S TEMPLATE PROJECT CHARTER AT THIS LINK:
Here's a link to the project charter, it's relatively self-explanatory but I'll share some best practices. Definitely go download a copy right now and look at it as we continue, to best learn this skill.
First -- the names on the lefthand side aren't important. When you prefer to use the word "Goals" or "Mission" or "Objectives"… that's not what's important. The information that's contained in the document is what's important, don't get hung up on the use of these terms. You can and should customize the sections to make it familiar to the people in your organization, but that's what's important about the project charter.
Here's a walkthrough --
The Mission Statement: What the project is. It's a brief sentence or two at most about what is the project. Opening a new store in Taipei, installing a new computer system, building a new building.
Objectives: Why is it important to be doing this now. It's a high level business justification. Why is it important to the organization to get it done? "Because we want to expand our service area", "because we want to make more money", "because we want to improve efficiency", "to cut costs", "to establish new strategic relationships" -- these are big picture purposes behind the project, and these are often missing. People get started with projects without understanding this section. A concrete example -- I was talking to a project manager who was refurbishing a building, but he didn't understand why he was kitting out the building, who was going to move in, and what the project was for. How can you make good decisions if you don't know what the project is for?
(And it's surprisingly common for key people to not know these details.)
Deliverables: What is the project actually going to produce? Usually there's 1-2 important deliverables that are obvious to everybody. Say you're putting a new process in place; the process is an obvious deliverable. But secondary deliverables like support, updating training deliverables, ensuring the staff get trained, update policy/procedure manuals… these kinds of things should also be considered deliverables, and often get missed. The classic example is the new IT system -- obviously you the IT system is the deliverable, but you need it documented, you need to know how you're going to do tech support and keep operating the system, you need everyone trained and using the system, and you need to update the helpdesk / tech support people.
Stakeholders: We already talked a lot about this. Get all the key stakeholders identified.
Roles and Responsibilities: We're not looking for details here, we're just looking who is representing marketing, who is representing engineering, who is providing IT experience, who is providing project management expertise.
High-Level Work Breakdown: What are the major phases of the project going to be? Feasibility, concept ability, test rollout. Or are we going to jump straight into design, or into implementation? Do we need to do research first? What are the major pieces as you see them? A flavor for how the project is going to be performed.
Assumptions: "Assumptions" is a very important section. Various different stakeholders will make various different assumptions about what they believe this project is going to be. They assume it's going to be X, Y, or Z… here's where we can clarify the scope of the project by putting in what we've heard others mention, and what we think our assumptions are. We assume we can use Joe or Mary to help make the project happen, or that the project is just for our home office, or that we're going to use our standard set of tools. People can challenge these assumptions, and that's good -- you want them challenged now, not later.
Communications: How is the team going to be communicating? The project is getting underway now with the creation of this document now. Are you going to be meeting weekly, or daily? Conference calls? What is the main communication channel going to be?
Risks: This is all about uncertainty. What do you, or other people, think could go wrong on the project? If you listen to people early, they'll give you a list of reasons why the project will be an abysmal failure. You could brush them off, or you could think those through -- often these are real risks. We're not talking about challenging parts of the project to do; we're concerned instead that a piece of equipment could fail, a key person might leave the organization or go off the project, maybe a new government regulation could come out or change mid-project, the individual representing the customer or client company might change or leave their organization. Some of these will come from you, some will come from stakeholders. This part says, "Be aware that we're going to start working on this project, but here's things to be aware of could go wrong." It sets expectations for what could go wrong. It gives people an opportunity to say "Here's what we could do differently" even very early on to manage risks. We can do a more detailed risk analysis later, but this lets people begin to raise potential issues and awareness of potential issues.
Documentation: Here's the first project document for the project, where are you going to keep them? A server? In a physical drawer on a desk? Where will the documents reside, and where will people get the latest version from?
Boundaries: This is an interesting one. This is what's not in the project. It's a little counterintuitive, because there's an infinite number of things not in the project… but remember, this document is about clarifying stakeholder expectations. This is where you can head off misunderstandings about people who might think the project is about something more than it is. What would people think is in the project, but shouldn't be? Maybe this project is just about design, and you won't do implementation in this phase. Maybe this project won't affect any existing staff, and will just apply to new staff in a new location. Maybe this project won't include training, and a different part of the organization will do the training on this part of the project. This is where you head off misunderstandings about what people think would be included, but which you won't be doing as part of the project.
Decision Making Process: Different projects work differently, and so do different project managers. Is this a project where decisions will be made by consensus? Will we be taking votes? Will the project manager make PM decisions, and there's a technical lead making the technical decisions? How is the team working on this project going to be making decisions? The reality is, at some point you'll need to make decisions, and it's very difficult to come up with a decisionmaking process at the same time you're trying to make the decision. People will want to set up the decisionmaking process to "win" and "not lose" if you're trying to make a project decision and people disagree. You want to clarify how to make important decisions before you need to do so, and that makes it clear how it's going to be.
Signatures: You want to get signatures from main stakeholders, so you can show them this document later. They'll forget that they've seen it potentially, and that's a very visual reminder. If someone has to sign something, they'll actually read it and not blow it off. This forces them to actually read it and be on the same page with this document. By requesting that people sign it, it encourages them to read it fairly carefully. Sometimes you'll get situations where a key stakeholder says, "I didn't know this was a potential risk and the project would need to be put on hold!" And you can reply, "Well, hang on a second. Here's the project charter, here's where that's written down as a risk, and here's your signature at the bottom." It removes misunderstandings.
Getting signatures is a double-edged sword. Getting 20 signatures would probably take forever. Get the key stakeholders to sign this, but you don't need to get every last person to sign off on it.
"How would this change your thinking and operating in general?"
How does this change things? You'll avoid some of the problems we talked about earlier. You'll have a better understanding of what the project is, you'll have fewer false starts, you'll clarify what the understanding of what the project is, and you'll move through the planning stages that come next more quickly. You've gotten a good start at avoiding the stakeholder problems, and you reap the benefits of having everyone on the same page.
To get better at doing project charters, you just have to start writing them. As you read or study something like this, you'll have a conceptual understanding and think it makes sense. But as you put pen to paper, that's where you realize what you need to do.
You need to start writing these to get good at it. Get feedback from other people on how to do it better, but just get started and get feedback.
After the charter is done, schedule some time to revisit the various sections and check-in. It'll go more smoothly because people are on the same page. There's many more tools to address these sections in more detail, and that's what project management education is all about. You can learn how to think and act on these things. Getting the project charter right gives you an advantage right out of the gate.
There are some fantastic free resources on Archbold's website related to project management and project planning.
Kevin is offering a class of "Real-Time Live-Fire Project Management Training" where you come with a brief description of an important upcoming project, and leave with a project charter filled out and the key issues analyzed from many angles. There are five spots available; you can find the class at GiveGetWin.
I've been thinking of evaluating opportunities lately from the perspective of threats.
There's a downside to it, which is that focusing on the negative can mean a lowering of personal affect, morale, whatever. You tend to get more of what you focus on.
However, evaluating "what are the threats in the way of this succeeding?" seems like a pretty good way to check into ideas that are already on their ways towards correct execution. What could happen, with yourself, your team, competition, or other external stakeholders that could derail your success?
If you identify for threats, you can prepare against them. A cashflow crunch is easier to solve far in the future by securing some lines of credit during good times. If a key client or contract might be paid late, get that credit. If a single client accounts for more than half of your revenue, start diversifying even if it slows down your revenue growth. If a single sector is all you deal in, look if you can pick up a couple side-streams of revenue, especially covering most of your overhead.
Don't obsess over threats, and don't start thinking of them until you're well on your way -- by far the biggest risk is that your project never gets ignited and gets off the ground, and the you or your partners just don't hustle enough. But once things are going, do a once-over on threats. It could be the difference between success and failure. An ounce of prevention and all...
It is important to understand that as a human being, we like to get along with the people around us and that we work with. It is also important to realize that as a developer, it is not our job to please them at the expense of the project. This is a tougher pill to swallow than you might expect, especially when working with volunteers who can pick pu and leave whenever they want. However, sometimes an asset that is created is just not good enough to be included in the project, or is high quality but not in the style you need it to be, and you need to just have the guts to go to your employee/volunteer/contractor and say "I'm sorry, I know you put a lot of work into this asset, but it just isn't high enough quality to go into the project."
I don't suggest being this blunt as a rule, I am merely stating it this way to make my meaning clear. I'm not even going to try and explain some of the good ways of communicating a no - a different topic for a different day. What I =am= trying to convey to you today is that saying no is sometimes the right choice, and you will find that the people working with you and relying on you as a decision maker will actually be happier with you giving a justified no than if you attempt to be their own personal yes man.