Five Common Mistakes of Project Managers - Part 1

Video Activity

In this lesson, Subject Matter Expert (SME) Kelly Handerhan begins a discussion of the Top 5 Mistakes that Project Managers make. Learn from them, and you can move forward successfully. In discussing the first big mistake that Project Managers make, Handerhan emphasizes that Project Management is not just managing tasks or just producing work. Ther...

Join over 3 million cybersecurity professionals advancing their career
Sign up with

Already have an account? Sign In »

2 hours 27 minutes
Video Description

In this lesson, Subject Matter Expert (SME) Kelly Handerhan begins a discussion of the Top 5 Mistakes that Project Managers make. Learn from them, and you can move forward successfully. In discussing the first big mistake that Project Managers make, Handerhan emphasizes that Project Management is not just managing tasks or just producing work. There are several other components of a project that must be taken into consideration: - Stakeholders - Value and benefits - Risk management - Scope You will learn the importance of understanding who your stakeholders are, how to communicate your project's value and benefits, how to manage risks through a "risk register", and how to use a "scope statement". Handerhan explains how Project Managers need to use formalized documents (many are available as free templates) to organize the project and how important it is to know - exactly what the scope of work is - what deliverables need to be produced - that sign-offs need to be obtained in writing Lesson 4 of this Module concludes the discussion of the Top 5 Mistakes Project Managers make.

Video Transcription
all right, let's talk about some common mistakes that project managers make, and we all make mistakes. Absolutely. It's more important that we learn from them and that we move forward successfully. So the number one mistake and I see this all the time. Project managers think
that project management is just getting work accomplished,
managing tasks. And again, this goes back to the idea of our we just producing a product, or are we truly managing Ah, project? So what we need to make sure is that, yeah, we've got to produce work. We've got to conduct tasks, absolutely. But there's so much more to project management.
First of all, we have to acknowledge that we have stakeholders
and we want to be very clear on the definition of stakeholders because stakeholders aren't just our sponsors and our customers. A stakeholder is anyone that is affected by the work or the outcome of a project
positive or negative, because if we have someone even that anticipates or even that you know, we've all heard that phrase perception is reality. Even if I have someone who perceives the project will negatively affect them,
then I need to be aware of that stakeholder and I need to have an active strategy. Ah, lot of times and organizations whose main focus is not project management, and we're in more of a functional environment. If I'm managing a project within that organization, I have to go. Let's say I need developers, application developers.
I have to go to their manager and say,
I know you've got work to do also, but I need three of your programmers,
That's that Manager feels like my project is negatively affecting them.
I tell my staff that we're creating new software, toe handle, incident response, and all they can think of is we just learned the last system and now you're gonna change it again. So I need to identify the fact that I have stakeholders
that are excited that are beyond, you know, behind the project that they want to succeed.
But I also have stakeholders that don't in finding an effective way to identify their stakeholders and developing a manage strategy. A management strategy is essential to being successful
value and benefits. Am I delivering the value that I've promised?
And the answer is, I don't know until I do some of the work and evaluate the work versus my expectations. Here's where I am. Here's where I thought I would be,
you know, on Day one those two are exactly the same, right? But as we move forward, our project where I thought I would be is gonna vary from where I am. How can I get back on track and make sure that I'm meeting the goals of the project? One of the things that you'll notice that I'll continue to talk about throughout this course
is I will talk about meeting
customer expectations.
You will not hear me say, exceeding customer expectations. And sometimes that throws people for a loop. My job is not to exceed a customer's expectations. My job is to meet them
Now I know that goes against what we've heard, perhaps, and customer service training or you know what we've heard in the business always exceed the customers expectation. The problem with that is,
if I give the customer Maur than they've asked for more than we've agreed upon that I'm doing extra work at a loss to me and my organization. That's one more piece that I may have to fix as warranty. We're just just think about software development. Ah, customer asks for a database system that's gonna house
medical information
that needs to perform. Encryption service is authentication. Service is on an unknown, and they give me a list of requirements and I decide, Well, you know, there's one additional security feature that I'm gonna tack on. We can do this relatively cheaply. I'm gonna implement biometric authentication for them. You know,
that's more than they asked for.
It's also expensive. It's another moving piece that may not operate in their environment and understand that things always come to trade off anything extra I provide. There's a drawback to it.
I'm gonna meet the customer's expectations. All right now deliver the value to which you have committed support. The customer helped them meet their requirements. Make sure you understand those requirements and that the requirements inherently have value to the customer and you'll be successful
Risk management.
We could talk and talk and talk about risk management, and essentially, you could, uh, consider a risk to be the unknown.
Some unknown element that will affect my project and often in project management terms.
We look at a risk is being neutral. You have positive risks and you have negative risks. Most of the time we look at risk is having kind of a negative connotation, right? You know, I've never said there's a big risk I might win the lottery. We don't think in talking about those terms, but the idea is
really it's that element of uncertainty that makes it a risk.
Certainly we have negative risks from the I T world. Anytime we implement a system, could be security. Vulnerability there could be compromised. There could be functionality, problems, whatever those air risks. But we've also gotta think about positive risks as well. We have to think about opportunities. Maybe
bringing in a System Tau one organization, ah, might open us up to more potential work down the line. Maybe the system performs better than expected, saving us money, whatever that might be. So the ideas with risk management. We've got to maximize our opportunities and minimize our threats. Now,
if I talk in terms of eliminating risks, is that really possible? Now you can eliminate risks, risks don't go away. What we can do is we can mitigate those risks in such a manner that they're within our acceptable level of tolerance, and that's our goal and risk management everywhere.
I teach a ton of information technology security classes.
Every one of those classes revolves around risk management. What are my assets? What are they worth? What are threats and vulnerabilities, and what am I going to do about him? Same idea within a project. I have activities, each of those activities air designed to bring value. How much value?
What are the things that could threaten or prevent me from delivering that value? And what am I gonna do about it? Sometimes we use contingency funds. We took a little money away just in case.
But often we have more active mitigation strategies, and we will create a document called the Risk Register. And another thing you'll hear me not necessarily matching, You know, word for word on the slide, but you'll hear me suggest certain documents that will help you effectively address some of these issues.
A risk registers a very important document that many organizations have
can be just as basic as an Excel spreadsheet. But having a risk register where you identify risks, you prioritize them based on probability and impact. You try to determine from there a quantitative value, meaning a numeric value ideally a dollar value.
You assign an owner to those risks,
and then you determine a mitigation strategy. You might also look for triggers. You know, you might also have that in your document that essentially, if this happens, then the risk is likely to occur. But whatever four match your risk register takes on, that's an essential piece of risk management.
And, of course, the question wins the best time to deal with risks.
It's not. While they're happening right, we've got to be proactive. Scope, scope, scope, scope, scope, scope. So very important
scope. If you want to define it, it's the total of work and deliver Bols to be produced as a result of the project.
Or, you can say to meet the project requirements. Whatever
it's one I'm producing. It's the work that I'm doing.
I can't have a good, clean, clear scope unless I have clean requirements, unless I have well defined requirements. Unless I have an agreement between the customer and my organization, what those requirements are, and we understand
many of us have years and years and years of experience working with customers,
um, one of the questions I always love when I'm conducting an interview. I love to ask people, Is the customer always right?
And just think about that question. How would you answer that in a job interview? Is the customer always right? Well, in my opinion, and that's where there's questions. I don't know that there's a definite right indefinite wrong, too. But for me no, the customer is not always right. Sometimes the customer thinks they need one thing when they actually need another. So it's my job as a project manager
or, you know, someone who collects requirements.
Toe. Listen to that customer in more than just the words they say. But to be able to salute or elicit information what are you really trying to accomplish? Best example of that cloud moving to the cloud Gotta move to the cloud Cloud Cloud Cloud Why? Because
the cloud right, That's what I'm hearing all the time. Got to get to the cloud. Why? What are you really trying to accomplish? Well, I want to make it easier to distribute work among you know, the two departments in my organization, while the cloud may help with that but they're also other ways that may be more cost effective for you,
maybe provide a greater level security.
The bottom line is, sometimes a customer comes to you with the need that's not clearly articulated or doesn't really match the requirements that they give you. It's our job to make sure we spell things out clearly and precisely. Another document that's gonna help me with that is a scope statement,
a well written scope statement.
And I'll tell you, if you'll go out to the Internet and Google Project management documents there, several different organizations out there that put out free templates. PM I dot or if you're a member of P M I dot or gives you access to numerous templates for these documents, let me tell you, put your process is in place.
Have your formalized documents.
Look at your requirements, documenting those getting sign off from the sponsor from the customer. Make sure before we pick up the first hammer and nail that we know exactly what the work is that we're gonna do and the deliver balls to be produced
and the way I make sure that I know what you're thinking. And you know what I'm thinking
is we put it down in writing and we get sign off.
Does that guarantee? No, Nothing guarantees anything, but that puts me a step closer.
Up Next
Practical Project Management

In the Practical Project Management course, Subject Matter Expert (SME) Kelly Handerhan discusses the importance of effective Project Management in the enterprise.

Instructed By