I'd like to welcome
everybody who has actually come to campus to view this and everybody who's viewing it virtually. Thank you very much for
taking time out of your busy schedule today to participate in this wonderful event. As Tom mentioned, this is a special Master Lecture Series
presentation, in partnership with the Orange County Chapter of the Project Management Institute. It is definitely my pleasure
to introduce our speaker today, Greta Blash. Greta is a certified
project manager, holds an Agile certification in
business analyst certification from the Project Management Institute. She has extensive
experience as an executive and consulting IT professional. Her areas of experience
include program management, project management,
Agile Scrum development with emphasis in the areas
of system implementations and conversions, and maybe she can explain what this is, (laughs) customer
relationship management, data warehousing and
business intelligence. Greta has taught project
management certification courses worldwide, and has
served as a vice president of education and programs for
PMI Southern Nevada chapter. She is currently, and since 2012, served as the academic outreach liaison for PMI Region Seven. Her topic today is on
effective project management and is titled "The Basics
of Good Project Management." So I'll turn it over to
you, Greta, and have fun. (applause) - Thank you so much for
having me here today. I'm looking forward to
being able to do this presentation, and
especially because it's a joint effort between the
Orange County PMI chapter, as well as California Southern University. As we talk about the agenda, obviously, when you talk about the basics of good project management, we
probably need to go back and first identify what is a project, and then what is project management, and how it applies a life skill as opposed to those of us that are
professional project managers. I'm really not sure what
that really means, actually, being a professional project manager. Depending on what we're
doing, what type of projects, as he alluded, I've done a lotta different types of projects. In fact, one of the things that I just did was I installed a phone system. Why? Because I had to have it as part of a call center implementation that was part of a CRM project. So depending on what has to be done, you use the skills, the basic
skills of project management, to manage those efforts. We'll talk about the phases of a project. Those of you that are
actually PMI certified or project managers will
realize I'm not using the formal project
management terminology here. I'm talking about this as
being that something people can do in their everyday life. So we have a starting part of a project. We have a planning, where we figure out what we need to do and
how we're gonna do it. Then we actually do the work. We perform the work. At some point in time,
we have to finish it. Now, unfortunately,
most of us don't finish projects the way that we talk about being able to do. So we'll spend a little
bit of time on that. One of the other areas
that I wanna talk about, because project management is not just a technical skill, but project management also has a lot to do with
some of the competencies as an individual, as
a leader, as a person. So one of the things that we all learn is that even if we can put together a Microsoft Project schedule, we may not be successful in being
able to do the project. There's some additional
skills that we need to have in order to do this. So we'll talk about some
of those competencies and the fact that PMI has actually added an entire appendix to our book that we use to be able to talk about
these various skills. The last thing that I
hope to be able to get to today is talking about the code of ethics that the Project Management Institute has asked us all to sign, which is basic. Basic types of things
that we say we will do. Some of 'em are mandatory type of actions, some of 'em are just kinda think about this and do what ya can, aspirational is the word
that PMI actually uses. We'll talk about that
and how those can apply to everyday life, not
just as a project manager. Let's talk about what is a project. By definition, a project has a beginning and an end. It also creates something that is unique, whether it's a result or
a product or a service or a document, it's unique. But if I have a project
that I'm building a house, and I'm a house builder, why is it unique? Because we all know every house is a little different. If I put in, like I did
with the CRM project, the CRM project, for
one particular company, is very different from another. The people they're trying to work with, the tools they have, all
the things that are there. The project needs to be
able to say we are gonna start on a certain time. We have a target date, a milestone, something that we wanna
get this finished by. That may change,
depending on what goes on, because things happen, and we know that. As a project manager, we have to recognize when those things happen, we have to figure out what does that mean and how we're gonna go about making those changes. A project can involve a single or multiple individuals. Single is not a good idea, but sometimes, and in the last one,
I found myself, when I was assigning a resource to a project, sometimes it was me,
sometimes it was myself and sometimes it was I. There was nobody else there at the time to be able to do this,
and I wanted to play a few different roles, so I did that. We really need to have
multiple individuals. How much time those different individuals are involved in this depends on what their role is, what
the project is and what we're gonna need to do. We can also have people from different organizational units. They could be all within one organization, one family, one community, or they could be scattered over a
bunch of different areas. Obviously, the more that grows, the more difficult you may have in trying to manage that project. We can also have multiple organizations from, multiple units from
different organizations, especially when we get
into contracted work where we end up having people from different companies or organizations working together. Even though we're in Orange County, we spent the last few years in Las Vegas. We were there while they
were building CityCenter. Now, if any of you have been over there or have heard about it,
it was a major effort with a lotta different hotels and casinos and restaurants and retail, et cetera. There were over 200 project managers on that particular task from 200 different companies. Talk about trying to manage
just project managers, much less manage the work effort. Huge effort there. But that's a case where a project can go from a very simple thing, and we always use the basic example of planning a Christmas party or planning the Thanksgiving meal to cleaning the garage to building
a new room on the house. Those are all projects. They're just things that
we do, not necessarily part of the business. If we look at everything that has to be accomplished, that we have to say, "Okay, we're gonna start this now, and we hope to have it
finished by a certain time," we're gonna use some
basic project management skills as we go through that. We can consider that a project. When we talk about projects
and project management, and I talk about PMI, PMI
is a global organization that supports project managers worldwide. We have what's called "A Guide to the Project Management Body of Knowledge." We all call it the PMBOK Guide. This is a guide that helps us understand best practices of ways
to do project management. It's a guide. It was written by a number of volunteers. I started to say a lot, it is a lot. It continually is updated as new ideas come about,
as new people come up with new ideas, best
practices to be able to use. It identifies best
practices, skills, tools and techniques, not vendor specific, but more generic type of things. As a project manager,
our role is to understand kind of what those tools
and techniques bring to the table and whether they're gonna be applicable to what we're trying to do. The other part of it is it provides a common terminology among project managers. I'm not gonna necessarily
use a lot of that terminology today, but we have things like a risk register and a
project charter and all these different things that,
as project managers, when we talk about these
tools and techniques and types of documents, we have an idea of what we're talking about. We have a common base of communication. This is absolutely no
different from what happens when you are in accounting or HR or marketing. We use terminology that
is specific, and people that are in those functional organizations or within those disciplines know what that terminology means, and they can talk back and forth. The key is, on this, we
have a lot of information. This book has gone from probably about less than a quarter of
an inch to now where it's a couple of inches thick. In fact, when we did the latest release, I did a presentation
and I had copies of all the older versions cause I've been working with it that long, and I brought 'em and showed so we started
here and we keep growing because we keep adding
more and more to that. But the key becomes that is not what we must do. That is recommended good
practices, and the first thing that a project
manager and the team need to do is figure out how much is appropriate for this
particular project. So part of what I'm gonna
do today is talk about some of the concepts that
you need to think through and say, "Do I just
need to think about this or should I actually do it? If I do it, how much do I need to do?" When we create a document, do we have a one-page document or do we have three three-ring binders full of information? You do what is appropriate for the task that you're doing. So what is project management itself? Project management is
addressing the needs, concerns of stakeholder expectations. Let me go back and explain
what a stakeholder is, from our standpoint. A stakeholder is anybody, anybody who cares about what we're doing, who may be impacted by
the work we're doing. It could be the people
that could impact us. For instance, I have a project. I wanna go redo my lawn and my whole landscaping in the front yard. Do I have stakeholders? Of course. I have neighbors, I have a group of people within the community that say, "You can do this and you can do this." We have a problem in Southern
California with water. I'm not going to plant
a whole bunch of grass if I have to be able to water it. And in fact, in Vegas, there is no longer grass. We don't have the water, and therefore, the stakeholder is the water association. Do I need to know about
who those people are? Yes. Do I need to know what their concerns are? Do I need to know when to involve them? Absolutely. Those are the types of
things that we talk about when we're talking about stakeholders and their concerns. It's not just me and my project team, but it's the people that
are gonna be impacted by what I'm doing, as well as the people that I will impact as I'm working on this. Noise, cleaning up, all the things that are going to impact the rest of the community. We talk about constraints on a project. Regardless what project you're doing, you have constraints. You either have money or you have time. In some projects, we have to figure out what is the most important constraint. Is it that I have to get
this done on a certain date? Or I have to do it within
a certain amount of cost? Those are different constraints. There could also be some quality that says I have to be able to have a quality level. For instance, I've doing
my landscaping again. I have to be able to know how much water I'm going to have to use for that project. That's a constraint. Therefore, I have to see
how I'm going to water. I'm gonna have to see what kind of plants I'm gonna grow. All of these type of
things become constraints. It's interesting cause
most people talk about the constraint of cost and money being the most important. Unfortunately, when I was
working in the casinos in Vegas, I never, ever even saw a budget, much less had a concern about the cost. Everything was schedule. You must get it done on a certain date because of certain things
that were happening. If I needed more people,
if I needed more equipment, so be it. What it cost, I never
saw, and they didn't care. The constraint was get it done. What you have to understand
when you start out is which one of those
are your constraints. Which is the most important? Which is the second most? Because you're gonna have to make trade-offs as you go through. So what we do with the projects, then, is we understand what do we need to do and who do we need to use in order to help get this accomplished. We also have this thing
of, we have projects, but we have work that's going on within an organization. We usually refer to that
as being an operation. It's the day-by-day work that's done. Whether it's in a business where you're registering students,
whether you're presenting courses, those are all operations. They continually happen. Now let's take presenting a course. If we decide we want a brand new course, we usually initiate a project to do that. We figure out when do
I need to have it done, who needs to be involved in it. When we talk about the two of these, they both are performed by people. They both are still constrained
by limited resources. They, obviously, are planned, executed and controlled
as we go through this. So we talk about project management. As I alluded to before, there's basically four different phases or four different chunks of work that need to be done. We need to start out, and the key on the starting out is figuring
out why are we doing this project, who is
the one that is asking for this and what do we expect to be able to get out of it? Sometimes this doesn't happen. Sometimes we're not told, which, obviously, means that we could go down a different path if we're
not understanding why. Once we figure out why
we're doing the project, now we have to be more specific as to what do we need to do, who needs to be involved, when do those individuals or resources, as we call 'em, which could be equipment, money, people, when do those people or those resources need to be involved, and how are we gonna do this? Some of that planning is going to be at a very high level, and as we get closer and get more in
tune with what's happening, we'll get more into, oops, I didn't know I had to do that or oops, as I'm digging up my garden to put in my plants, all of a sudden I'm hitting something. Ended up being a great big concrete piece that who know why it was there, when it got there, but obviously, we had to get rid of it. So part of that was a
work-around that we had to do. We have to be able to
build in the flexibility to say that we're there. Once we get it finished,
we need to celebrate. We need to say, "Hey, we did it. Good work." We need that feedback,
that positive reinforcement because sometimes that work we're doing, it's hard. It's a lot of hours, it's a lotta people, it a lotta time. We opened a casino down in Mississippi for the Indian tribe. By the time we were assigned to do it, we had seven months to
do the entire thing. We worked seven days a
week, 18 hours a day. We actually finished all the IT stuff a month before opening because we had to have it in place to train people with. My staff was sitting there going, "Okay, so now what do we do? We have a month before opening." I said, "You sit back and you watch. At the time when that actually opens, we're gonna celebrate because we did it." Part of it is being able to recognize the accomplishments. Let's go back to the starting phase. I use the term why. I think most project managers will realize this is probably the area we spend the least amount of time on, and it's also the area,
though, that bites us later on because if we don't understand why we're doing this project, we may not understand,
really, what we need to accomplish. By definition, with PMI, what we say is that we need to officially
authorize the project. We end up developing what's
called a project charter. It is a way that we authorize the project, we authorize the project
manager to spend the money. I have seen it very, very seldomly done, even though I force it now because I wanna promote this and tell
everybody, "Guess what, guys? We're starting this project. Be aware of it. You're a stakeholder. Either you can join us
and give us feedback and participate in this, or you may have some concerns. Voice them now." That's what we need, but we need to understand that. In most organizations, there is something that happened prior to this project starting. There may have had to be a business case, which could be very detailed as to the return on investment, the objectives, how this fits in with the strategic plan. Go back and talk about if I'm going to add a new course to the curriculum. I'm gonna, obviously, have to have some preliminary discussions and approval before this gets started. I wanna be able to get information from that process and figure out what was the thinking, especially who were the people that were
really excited about this and who were the people that kind of were fighting it because those are gonna be stakeholders
I'm gonna have to work with. So I wanna see how we got to the point where we've been given approval to do this project. Let's go back to my landscaping. Do I have to have certain approvals? Obviously, if I'm gonna
dig and put some things in, I'd have to have approvals. Do I have the money for it? Where is it gonna come from? How's it gonna be done
versus something else? These are all projects. We don't formally think of 'em that way, but when we do work, when we do and try to produce something or a result, it is a project, and we need to understand why did we choose this one? Was it a compliance issue that came down and there was, all of
a sudden, everybody had to stop doing what they were because we had a new regulation we had to meet? In that case, does it make sense to go try and get a copy of the
regulation and read it? Absolutely. Figure out why we're doing this, what does it mean, what
impact's it going to have. At this point in the starting phase, usually about the only person that's on the project is the project manager and maybe a few experts that understand the work we're doing. Obviously, if I'm planning my garden or my landscaping, I'm
not an expert in this. I need to go at least to maybe the nursery and talk about what kind of plants I need, what kind of work, those type of things. So those are what we will end up having as we start to build our team. They're not there every day shoveling and doing work, but
they're part of the team, they're giving me the information. I, as the project manager,
don't know everything. I am not expected to know everything, and unless this is a project of one, which doesn't really
work real well, (laughs) I'm not the person that has
all that detailed knowledge. I have a team that I'm working with. That's where this whole starting phase says who do you need to work on this. Especially if you have to pay somebody, whether you have to lease equipment or rent equipment or get people, you need to have the approval
to be able to do that. So we always say it identifies and formally authorizes the
project, and it authorizes the project manager to spend resources, resources meaning money. Should I start a project without having people know that
I'm doing this project? Probably not a good idea,
unless it's something that we don't really wanna get out there yet. We work with a lot of
Department of Defense and Department of Energy projects in this part of the country, where we do have certain projects like that. They're classified projects, so we do not let everybody know what we're doing. Sometimes that's not a
good situation, either. So we have this thing
called a project charter. There's a lot of examples of this. First of all, we always say when you
do a project charter, you need to do it immediately. You need to write this within the first week, minimum, of when the project starts. Otherwise, you're gonna get
into way too much detail because all you're really trying to say is why am I doing this project. What will make it successful? Do I have certain requirements that have to be met, especially
if it's a compliance. I know already there's certain things I have to do, so put those in here to start out with. If it has a constraint of a schedule, put the schedule dates in there. If it has a constraint on money, put the money in there, even though we're gonna have to figure out the disconnect between
what needs to be done and how much time we have to do it and how much money we have to get that work done, but we can at least go through there. The other thing is does it need to be approved when we get finished? If so, who approves it, what do they have to be approving, so that we know that when we do this, it just isn't hanging out there. Part of the problem with these projects that never get closed, they never receive final approval. Therefore, they are kind
of there, but they're not. The key here is stating right up front who's gonna approve this and what are they gonna use, at a very,
very, very high level, to say, "Yes, you did what
we wanted to have done." We say that we know who
the project manager is, what their responsibility, what their authority level is. This is a whole area that I'm not gonna really talk about here because it's more involved, if you're in an organization, as to who kinda has the power and control of things. If I'm in an organization,
like in finance, and I'm doing a finance project, the people that are within finance have a very, very strong control over what's being done. Part of that is being able to see, do I have the ability
to change the budget? Do they have the ability? Do I have to get approval from them? Those are the types of things that, depending on what kind of project and what kind of organization, it then makes a huge difference. The other thing is who's the sponsor? Who's the one that actually has approved the funding of this? Who is the group, and it could be a group, not just an individual, but who is that person that is going to be responsible for paying for this? In a number of projects
I've done in the past, the reason why we actually
wrote this project charter was to make sure that the individual or the department who was
paying for this project knew they were paying for this project because it had been approved six months ahead of time as part
of the strategic plan, and they kinda forgot that, oh, I have committed to this. So part of this was to actually get that sponsoring organization, and it's really supposed
to come from them, supposed to be written
by them, but we know good and well, most of
us as project managers, we write it, we let them distribute it. But we wanna make sure
that people understand what we're gonna be doing, who's gonna be involved, kind of at a very high level, which is why we say write it within the first couple a days or first week. Once again, we know when we do any sort of writings or
any sort of documents for executive, shorter is better, right? One page. If you can't put this basic information on a one-page document, you've gotten into too much detail. This is not the place to go into a huge dissertation
about what the project is and everything about it. High level, introduce the project, focus on the most important things as we go through that. When we get into the planning phase, this is where we start to identify in more detail. This starts almost immediately. It's why we wanna get that charter out of the way to be able to say, "This is the objectives, this is the milestones, high level." Now we can drop down into the more detail. What needs to be done? Who needs to be involved? When will things be done? Then all these assumptions
and constraints. An assumption is basically
saying, "I assume that the following is gonna be there. Therefore, I can do my work." When I worked for IBM, I was told for every assumption, there's is a corresponding constraint. So if I assume that I'm going to have key individuals to work on my project, that's an assumption, and I've done all the planning based on that assumption. But then at the point in time, I also have a constraint because if those key individuals are not available, what impact's it gonna have on my project? It may be delayed, I may
have to cut a portion of it out, things like that. An assumption is what we're basing all of these requirements and all of our planning on. The constraint is what do we know that could go wrong that could cause us to have a problem when we get in here. Then the last thing is determining how we're gonna do this. The how could be how long it's gonna take, what different roles the
different individuals are gonna play, and
there's a lotta techniques that we can use for this
entire planning phase. I put the Cheshire Cat up there because this is still my most favorite quote. When you get into planning, as Alice said, "Which road do I take?" The Cheshire Cat says,
"Where do you wanna go?" "I don't know," said Alice. "Then it really doesn't matter." That's, unfortunately, what happens when we don't plan things. We have no idea what we're gonna end up with, we have no
idea what we're doing. Granted, when we're planning something, we don't necessarily wanna spend months planning something that's only gonna be a two-month effort. So you do the planning in proportion to the amount of time you have, the complexity of the project. We have some ways where what we'll also talk about is that we do some high-level planning to start out with, and then as we get closer in, we'll do more detail planning as we go. I don't know everything when I start, and I don't need to, but I at least need to know what roads I'm going to take. That's the key. Just as an aside, I think
everybody should go back and read "Alice in Wonderland." You will be surprised how many quotes are in that book that we use every day, and especially that are
applicable to business, just as an aside. It's just fascinating
to read it as an adult. So we talk about requirements. We talk about what. Somebody said, "Well,
what's the difference between a requirement
and a specification?" There really isn't anything,
it's just a term we use. Most often today, we
use this in what we call facilitated sessions. A facilitated session is where we get additional people
involved, we get everybody in the room together so
they can talk to each other, so they can discuss. The picture we have here
actually was a session we did at PMI a few weeks ago as part of one of our group efforts. We were facilitating
different outreach type of requirements and how we might do 'em. You're building on information
from everybody involved. You're facilitating it only to make sure that the information is
captured, that it stays on track, we keep going through there. It says that this requirement
should be specific and detailed enough to allow verification and validation. Here I'm dropping into
the words verification and validation. Verification is making sure
we're doing the right thing. Validation is approving. It's making sure that
what you ask me to do, I've done, and the verification, I've done it correctly, but the validation is I approve it and we can move on. When we get into these
requirements, we get into a lot of different
things that obviously could take much more time
than we have available. So we may need to be
able to prioritize this. I put this cartoon in here. I've had it in most of my slides for a number of years because I think it kind of says, if we don't
talk about these requirements, if we don't discuss 'em, everybody has a different idea of what's
gonna be produced, what's gonna be the result, and we need to be able to have this so that we can all discuss and make sure we're saying the right thing,
we're saying the same thing, we're all agreeing on it. We have this thing called a work breakdown structure. It's kind of everything you need to do. I'm gonna digress just a second. I mentioned this earlier. One of the areas of PMI
talks about teaching project management as a life skill, and teaching it to young kids, elementary. The Northern Italy chapter
actually has put together a program on project management where they basically do this by means of Post-its. They have a project for the kids to do, they give 'em all Post-its
and they say, "Write down the different things that need to be done, and then go stick 'em up on the wall." Then they turn around and draw a tree where they can kind of
see the different types of groupings that need
to be done, and everybody goes up and moves their
Post-its onto the right branch of the tree. I actually did this with
my graduate students. I do it when I'm working
with a team of customers who've never worked on a project before because they have the ability
to say, "These are the things we think need to be done, and this is how they group." But it's a physical activity, and, obviously, I don't
recognize the new term, but this is part of a
new way of learning, too, being able to do this. But we work off of this to be able to understand
what needs to be done. We actually use this cause we were trying, both my husband and I
being project managers, decided we'd better teach our daughters. We did this for both of their weddings. We have the Post-its that were on the wall for the different areas
that had to be done on the wedding. It was kind of an overkill in some areas, but it did point out
a lotta things that we had left out. Part of it is being able
to understand what's there. Once we start to understand
what we're trying to do, now we have to figure out who is going to be there. Talked previously a little
bit about stakeholders, talked the project team. As we said, stakeholders are anybody who could be impacted by the project or could impact the project. We need to understand those people. We need to understand
where they're coming from. Why they would be involved in the project, what interests they might have, what influence they could have on us. Are there interdependencies between those various stakeholders that, well, if this one says this,
this one automatically is gonna say the opposite. Or if I can sell the concept to one, they can help me sell
it to the second one, and what kind of potential impact. Once again, working with
some of the DOD type of projects that I have
or my students have in the past, one of my students said, "You know who my biggest stakeholder and the one that causes
me the most problems? That's lobbyists because if I'm working
on a government project, there are lobbyists back in the background that could affect what
we're gonna be doing. They could stop it,
they could increase it. I don't even know who they are. I don't know what they're doing." They're those blind stakeholders that we have to understand they're out there. How am I going to figure
out what they're doing? I'm still not sure how we do that, but at least recognizing that they exist is one of the key. The project team, as we talk about it, are the people who are actually gonna help us do the work. I said, this could be the fact that I have a supporting expert. I have the nursery down the street that I can go ask questions of. I actually have people
that I can contract out to, and we call those the sellers. They're selling their services to us. I could have business partners. In this case, you have a partnership here between the university
and the PMI chapter. That means on this project,
this effort, that had a beginning and an end,
which'll be after today, these are different people
that are on the team. They have to be able to communicate. They have to have different roles. The customer and who represents them, because, obviously,
most cases, we can't go to every customer or everybody who's gonna be involved in this, we
have certain representatives who represent those
customers as we go through. They're all part of the team. They may be part of a core team that works directly on this or they
may be an extended team where we continue to move out and get certain people involved
when, and if, needed. Very definitely in today's world, it varies on the culture, the scope and the location of these members. Erica is working virtually from here. Doesn't stop anything. She's in New Mexico, we're
in Southern California. That is today's world. We have to understand
that we will have people on our team in different locations. We could have full-time people that are all co-located in one location. It used to be this was the preferred way. We're realizing that it is not happening, not available, not able to happen anymore, so we have to be able to move in to either part-time teams, where we bring people
in when they're needed, or we actually go into a virtual world, where we have the team
virtually connected. Virtual teams have little or none of the face to face, the actual people being able to talk to each other. They're enabled through technology. We all know kind of some
of the drawbacks to that, not being able to figure out what people are really saying when
they're writing an email because of the wording they use or there's no emotion
in it, unless somebody forgets to turn off the
cap locks, then you think they're screaming, and they're not. But those are the things that can really add to a team. They can also cause a lotta challenges. The positive is you're able to pick up on expertise from people all over. You're not constrained to what you have in that local area. I could even say that in my case, go back to my landscaping thing, I have a virtual team,
it's called the Internet. I can go out there and
get advice from experts that don't even know
they're part of the team that I'm working on, unless I actually communicate directly with them. Those employees that are working remotely, and more and more this is happening, different shifts, different
hours, different days. Sometimes a challenge. Obviously, if you're
working with a team member who's over on the other side of the world, we have hour differences,
but you could look at it as positive because
when I was working in that situation, we would work all day. We would do testing, we'd
figure out what it needed, what was working, what wasn't. We sent a message at the end of the day. They would work while we were sleeping. We would have a meeting first thing in the morning to say this is what we did, this is what we were able to do. So we, in effect, were able to work a 24-hour shift by
having different members of the team working. Did we have to have some meetings early in the morning and late a night? Absolutely. But the benefit outweighed
those basic constraints that we came up with. The other thing is just the whole cost of getting everybody together. It is huge. That's one of the reasons why so much of the training that we're doing now is going into a virtual, online world because people don't have the luxury or the ability, cost-wise,
to be able to go to a location to take a course anymore. It just makes it unable to be done. Some of the challenges, though. Obviously, misunderstanding, especially when we have words that
are used that people don't understand. We talk about a communication model where there's noise
between what somebody says and what somebody hears. Being able to feel isolated. There are certain
individuals who cannot work in this type of a role. As a project manager, we
need to recognize this. They need that face-to-face contact, they need the people connection. If you put 'em out by themselves, pretty soon you'll see them leave. They'll go to another organization or another job where
they can be connected. The technology has a cost to it. Obviously, if we have
one project who wants to have a virtual team, and the rest of the projects are all being done in a co-located manner, we probably can't do that because
the cost of technology, as you all have seen here, is very, very high. You trade off the benefits of the cost and you look at what
additional information can you provide, how
can you connect people through this technology at that point. I mentioned briefly the
time zone differences. You also have a lot of personal skills that are gonna have to come into play, especially when you start talking about how you're gonna communicate and how you're gonna
resolve any sorta conflict. Especially, even understanding
if there is a conflict because if you don't
see two people together that walk by each other and will not look each other in the eye,
because they're in remote locations, but they will
never speak to each other in however way we have
to speak, you may not even know there's a conflict there. So that's another challenge
that we have to look at. Let's go one step further, virtual teams that are within a
particular geographic area, as opposed to globally spread. We end up having a lotta
cultural diversity, which, in Southern
California, is not as great a thing to handle because of
all the multicultural areas and people that we have in
this part of the country. That isn't the same if
you go back into certain other parts of the United States. They do not have the extra cultures, the multicultural environment. People that are in the
Midwest, and sometimes in the Southeast, they've been there for five and six generations. They do things their way. It's a very difficult
culture to work into. We could have a lotta different industries that we don't have, especially here in Southern California, that
we're working with in some of these other countries. Different languages. I actually taught a class
a number of years ago for Dow Chemical, and I was teaching in Holland. I'm speaking in English,
and then I give 'em an exercise to do. I walk from table to table. I'm listening to these
people and I walk by and they're talking French. Then I walk around, I
come back, now they're talking Dutch. Then I'd come back a little bit later and they may be talking German. I'm going, "Okay, hold on, guys. How do you know what
language you're speaking in?" Well, we all know all of
these languages enough to be able to communicate, and whoever starts speaking chooses the language they're more comfortable
with, and the rest of us understand that. Unfortunately, I don't
think that's the way in the United States. I think we force everybody to use English, even if it is not their first language. As a result, we have the problem. When I was over there, I spoke Spanish. I didn't speak any of these other ones. There was one guy who spoke Italian, so we kinda could communicate cause it was close enough. But I felt very inadequate
when I'm working with these people understanding, you know all these various
languages enough to be able to communicate and understand. If, for instance, something came up and the person that's speaking German got kind of far off and was using words that the rest didn't understand, they would tell him to switch back, and English became the common language. But still, when they're doing an exercise, when they're working like that, the different language makes a difference. So part of what we have to do when we're working in this virtual,
and especially global, this is even more important to look at the effective communication cause that communication has to be timely, it has to be clear. How do we know if it's clear? We need the feedback to be able to say, "Did you understand what I just said?" Because a lotta times,
what we think we've said, obviously doesn't happen. We also need to be able to have this mutual trust of each other. We need to be able to work together, and yet interdependently so that we can get the task accomplished. So once we identify
what we're trying to do and who's gonna help us do it, then we have to start figuring out when. Unfortunately, I think this
is all that people think project management is, is a Microsoft Project schedule, and it's not, it is not at all. You can do a schedule without
using a software tool. In fact, those third-graders, after they took a picture of their tree, then they asked 'em to
take the Post-its off and go to a different wall and put them in the order in which
they needed to be done. Guess what? That was their schedule. They were able, without saying anything about dependencies or
any sorta relationships or anything else, I need to do this before I can do something else. They knew that. We all know that. You don't plant bulbs until you've dug up the ground and put some good dirt in. Well, you can, but you might not have anything grow. So part of that, you have to understand. Yes, a lotta times we
do use a scheduling tool to help us do this because it allows us, when we make a little change, to be able to figure out what the impact of that is. So what happens if it rains? It actually does rain
in Southern California. There's certain things that get delayed as a result. Did we put anything into
our schedule to say, "Okay, if it rains on next Tuesday, what am I gonna do?" Next Tuesday we might have
an idea it might rain, even though it doesn't mean it will, but next month, is it
gonna rain next month? Don't know. Is it gonna snow in Las Vegas? It did a week ago. It did a couple a years ago to the point where it closed down the airport. Do they now start putting things into their project to say,
during the wintertime, it might snow, and if it does, it's a major stoppage. So what we have to identify is what do we need to do to be able to figure out taking what we have to do, who's gonna do it. We have to figure out now when. When does the task need to be done? When are the resources gonna be available to do that? The one thing we always laugh about is the fact that if something
has to be inspected, that's probably gonna throw
your project schedule off more than anything else because you have to be completed with what
they're gonna inspect before they come to inspect it. If they don't come when
you've schedule 'em to come, who knows when that inspection's going to get done. Go back to CityCenter. They're taking apart
one of those buildings brick by brick, or wall by wall, because it wasn't inspected
at the right time, and the inspection wasn't correct. They can't implode the building, but they have to take it down because the inspection was not
done at the proper time and they continued to work. Once again, we have to understand when things have to be done. We have a couple a methods we talk about, critical (sound cuts out),
critical (sound cuts out). You've all heard about the critical path. It's the longest path, it's the path. These are the things that have to be done, and if anything's delayed, your whole project's gonna get delayed. We try to make sure we manage that path. There's also this thing
called critical chain. If you're not familiar
with it, I highly recommend that you read "The Goal," g-o-a-l, by Goldratt. He talks about this as being a, it's a theory of
constraints, but he writes it as a novel, as a story. You can visualize what has to be done, but the idea is that there's certain critical resources, and
if they are not available and if they're not working and not there when they need to be done,
they impact the whole thing. He talks about what you need to do to be able to keep the project moving. Do we have critical
resources on our projects? Absolutely. We have somebody that
has to come do something, and if they're not here, this thing could have a problem. I think, in some cases, I'm
one of those critical resources because if I hadn't been
here on time this morning, this might have had a problem. Could I do it virtually
over my phone as we're driving up the freeway? Probably not the same quality. Part of what we have to
look at is do we need to put some buffers in. Fancy word to say, we
need some wiggle room, we need some things put in there so that we make sure. I come early to make
sure I'm here on time. Don't wanna get into that portion. So once we've figured out what, actually I have to figure out the why, then the what, the who, the when, we start to talk about
how we're gonna do this. There's a number of different approaches that we talk about. Then there's a lotta
detail that we can choose. I don't wanna go into a whole lot on this, but just, there's terminology
and there's concepts here that we probably need to understand. There's what we call
phase-to-phase relationships where we have certain
things that have to be done, and until we are completely sure of that, we don't go to the next step. Obviously, you don't
start building a house until you have blueprints and you have certain blueprints approved. How much? Do I go into where my
closet is on that blueprint, if I'm building a house? Probably. Do I understand how the closet's gonna be laid out, where are the rungs? No, I'm not gonna get to that point yet, but I do have to have
certain things that must be completed in order for me to go to the next step. That's what the
sequential's talking about. When I get into the
overlapping, it may be that I say, "Okay, we have
the blueprint for this portion of the house,
but we don't have the upstairs blueprint yet." We know the basic, we know where the load-bearing walls have to be, so we can put those
in, but we're not gonna do the rest. So we start to overlap
some of these in order to shorten the length of that schedule. We have a new one that we talk about when we talk about adaptive life cycles. This is usually applied to Agile. I don't wanna spend a
whole lotta time on Agile, but I do wanna talk a little bit about it because in our world today, everything has to be shortened. Everything has to be
smaller, has to be faster, we've gotta get this out. The problem is when we
do something like this, if we wait, let's go back
to the course itself. If we wait until the
course is totally developed before we start doing
the marketing for it, we're gonna have some problems because we're gonna have it out there, and then we have the marketing for it. It could also be that what we do is, let's say it's a
three-session program. What we may wanna do is say, "Let's get the first session, and
then we can determine what worked, what didn't work, and then we can reprioritize
what the second session is because maybe what we learned is that what we thought originally was gonna be part of the second
session is really not as important as a few other things." So we basically chunk the work into smaller groups and say, "This is what needs to go first. We'll try it, we'll see what
works, we'll prioritize that. When we get to the next one, we kinda know what we're gonna do, but we figure out that, well, maybe we
reprioritize a little bit, we change some things or the way we did it so it works better." These are what we call iterations. We usually have a fixed time that says we will do what we can
in this amount of time or within this amount of money. Then we'll, when we get to that point, we'll decide what do I do next. So rather than re-landscaping my entire house, I may say, "Okay, I'm gonna concentrate on the front yard." I have this amount of
time, I have this amount of money. I'll do what I can, and then I'll decide in the next iteration, do
I do more in the front yard or do I move to the backyard? Where's my priority? So I'm able to change and adapt. This especially has to
be done if you're working in any sorta marketing effort because the world changes. So as we said, we take this information, we reprioritize it, we figure out how much we can do within that period of time, and then we incorporate some things that are probably some of the best practices for project management. That is what they call
a retrospective review. At the end of each one
of these time periods, the whole team sits back and says, "What did we do right that we need to continue doing? What could we do better? Let's immediately implement
it on the next time, not wait till the entire
project, that takes a couple a years, to be able to make that, but to be able to go through and do that." So once we've done the planning, now we can start performing, wrong. Once we've started the planning, then we can start to
perform cause we're always going to overlap. Actually, I went, go back here a second because I had another
couple a words in here and I realize I don't
have the slides for 'em. That has to do with rolling wave and progressive elaboration. They're really fancy ways
to say, "How am I going to figure out what I'm gonna do?" I mentioned this, that I don't always know exactly what I need to
do at the beginning. So what I do is I put almost
like a timeline together, and I say, "Okay, I think," and I'm gonna continue to use my gardening exercise. You can tell where I've
been the last month or so. It's spring, I actually
have my first daffodil this morning, so spring
is officially here. We'll lay out this and say,
"This is where I'm gonna start, the front yard. Then I think I'm gonna go to the back, then I think I'm gonna
come back to the front, et cetera." So I have that line out there. I know that there's certain things that I do on the front yard that are going to also be done on the
back because I'm doing kinda the same thing. So I will put information at a little bit less detail for the backyard. What I do third, maybe I know what it is, and maybe I don't even know. Maybe it's just a placeholder to say, okay, that's phase three. I don't know what I'm gonna do. I'll figure out when I get there. That's rolling wave. Rolling wave says you concentrate on what you're doing now. You kind of know what's gonna come next. You may have an idea of the out time. You don't try to figure out everything right now because things change, regardless which methodology you're using. Progressive elaboration,
rather than going across, goes down. So I'm now doing my front yard. I know that's what I'm doing. I need the very detail go into exactly what needs to be done. When I get to the backyard, I will do the same. I will drill down, terminology we use in business intelligence, but I will get more and more detail when I
get to that point in time. So when I'm doing the planning, regardless what kinda project you're doing, you need to figure out what do you know, what do you think you know, kinda what's out there and
a vision of the future, but don't waste the time trying to drill these other two down at this point in time cause I don't know enough. Concentrate on what
you're doing right now, allow yourself the ability
to make that modification. So that's why, when we talk about moving from planning into performing or doing, we actually don't
completely finish planning and then move on to actually
starting to perform. We start the planning,
we start the activities that need to be done, and then we look at how that, as we're doing the work, how does that apply back to what I said was going to be done. Go back to my Cheshire Cat. If I don't know where I'm going, then I guess I don't need to figure out, I can go anyplace. I also don't know
whether I've accomplished anything, either. So part of what we do
in the performing phase is we look at what we
said we were gonna do, and we look at what we've
actually accomplished. When it rains, we look
at it and say, "Shoot, I was supposed to be
here by this Saturday. I'm not." So what do I have to do? I have to make some minor adjustments. If I had enough wiggle room in there to say, "Okay, what I was
gonna do next Saturday, I could either do next Saturday
or the following Saturday, that's fine." Based on resources, do
I need to contact them? What do I need to do? So what I'm looking at
is what I thought I was gonna get accomplished and what I've actually been able to do and what adjustments I need to make. Sometimes we have to be a little hard nosed. We have to say, "That was not in the original plan." That's a project manager's job. In my case, I have a subproject manager who's the one that tells me, "That wasn't what you originally wanted to do. That's a change request. You have to get it approved." Cause he's a project manager, too, and we talk this type of
language at home, unfortunately. But it's a case of saying,
"This is what you said you were gonna do. Don't change your mind midstream without figuring out what impact it has on what you said you were gonna do." Once again, go back to
that Agile approach. Agile approach says I only need to be able to concentrate on a short period of time, like two weeks, and
therefore, if I do that, I know that during that time, this is what I'm gonna work on. When I get to the end of
that, I will reprioritize now what I'm gonna do
in the next set of time. That way I allow change to happen, but not when I'm midstream
in doing something. Granted, this can happen. It may have to. When we get that piece of concrete that was not in the schedule, I had to do something about it. We had to look at it and
say, "Okay, what impact is this gonna have on us? How much time's it gonna take away from what we had planned? Do we need to go get some other piece of equipment to get this
thing out of the dirt?" Those are all the types
of things that you do when you manage change. We talked about very
strong management of change to be able to work through this, but the key during this
time is communicate. Communicate with everybody. Communicate with the people on the team. Communicate with the sponsor. Communicate with the stakeholders. If I'm working with things, I'm talking, I'm communicating. Communicating can be
written, can be verbal, can be different ways, depending on what I need to do. One of the tools we use, and this is a little detailed, but
we need to figure out, when we put this plan
together, we will never, ever do it exactly the way we said we were gonna do. It just is impossible, even if you've done this type of project 20, 30 times. Think about a pilot taking off. A pilot takes off. He's done it millions of times. He has a checklist to tell him what to do. He also keeps track of when things are not exactly the way they're supposed to be. But he also understands that there's some wiggle room between
what it's supposed to be and what is still allowed. Obviously, with the crash that we had a couple a days ago up in Santa Monica, there was a case where the pilot understood the problem was farther than the allowable variance,
and he started saying, "I have a problem. I need to go down. I need to go back." So part of that is understanding where I thought I was
gonna be, where I am, and is that within that wiggle room or do I need to correct
something to get it back on track, or am I seeing a problem that's starting to occur, and therefore, I'm gonna have to put some
preventative things in to make sure this doesn't
continue to occur. That's part of what we're doing in here. Once again, we talked about
those change requests. When I'm on a project
within an organization, there's always gonna
be change that's gonna have to happen. We talk about there being
three types of changes. One is a corrective action. That's where I need to fix something that I'm doing today that's not really being done correctly. It may be I have the wrong
resource, it may be that I need to reschedule some things. That's a corrective action. A preventative action
is being able to make a change so that things
don't continue to go south, so that they get better
as we're working through. Preventative measures
that we can put in place to make sure we stay on course. The last one is, obviously,
there's a problem. We need to fix it. That fix may take time,
may take resources, may take money. Whatever is happening, we
need to be able to fix that. If we're not monitoring what we're doing, we may not realize that
we have defects out there. We have just gone through and seen a lot of situations where
companies are in really bad trouble right now because
they weren't on top of things that were happening
or they knew about it and didn't communicate about it, and therefore, being able
to fix those defects, because they waited so long to do it, it made a huge impact
just to the company itself and the brand. One of the things that we talk about, as far as a project
manager, two key things. One is we should be preventative and proactive. Preventative in trying
to make sure we prevent problems from occurring, either because we put things in place, we've
put time in our schedule so there's some slippage
there in case we need it, but we also need to be proactive. We have to be looking
for things and trying to stay on top of it,
rather than sitting back and saying, "Okay, well,
the project's going fine. I'll wait and see if
somebody comes into my office and tells me there's a problem. Then I'll figure out what to do." It doesn't work. We've got to be able to
stay on top of things and see that something is happening. Obviously, I fly a lot when I'm doing a lot of my teaching. Because I fly a lot, I
realize certain things happen. I know when a flight is
going to be cancelled before anybody ever says it because I'm proactive as far as listening to what's being said. I was traveling with a team member a few months ago, and I said to them, I said, "Look, we're gonna have a problem. I can tell. You call the rental car company and get us a rental car. I will call the hotel and
get a hotel, just in case." We were ahead of
everybody because of that, because I was able to be proactive. I also knew that on the rental car, I could cancel it and no cost. The hotel we waited a
little bit longer cause we knew we would incur
a cancellation cost. When we talk about one of the other pieces that I mentioned, the
effective communication, I guess the most important thing to say is that first of all, you need to be as concise as possible, especially in communications
that are telling people what to do, what you expect
to have done, et cetera, so it's right there. Ya need to put it in the right format, whether it needs to be verbal or written. If it's within a contract,
it's usually specified how things have to be communicated. Making sure it's done at the right time, not waiting until later on and saying, "Oh, I shoulda told ya
that, but you know what, I was busy and things were going on." Making sure it's the right impact. Let's not scream wolf when it doesn't need to be. If you start doing that screaming wolf, what's gonna end up happening is after you've done
that two or three times, nobody's gonna listen to you anymore. So you need to understand how important this communication is,
who it needs to go to, et cetera, as we go through that. Then the appropriate context, depending on who we're communicating to. Obviously, most of us in
business have been told, "Do not send anything out
to the general public. Let somebody from public
relations or whatever determine how it's going to be worded, who's gonna say it, not you." Once again, that's the appropriate contact we need to have. Because communication is so important, this is probably the one plan that I do on a real project within a business. What I'm understanding here is two things, who do I have to communicate to and what communications am I going to deliver to those people? How am I gonna deliver it,
what method I'm gonna use, the amount of detail because, obviously, if I do a status report, the status I give to one
individual may be very different from the amount of detail that I give to a higher manager. What is the time frame? How often do I deliver this information? We all get these emails that are blasted out
to us, telling us about meetings or whatever. Sometimes they are way too frequent, and to the point where we get so many, we start to ignore 'em. So we have to, once again, look at when we send it out, how often we send it out. Who are the people that are gonna provide the information to you so you can communicate it out? What information do they need to provide? When do they need to provide it to you so you have time to
compile it to put it out? I put this constraint
in here before things that were happening right now within the government
because it's very important to understand what are
the rules and regulations regarding communications. What can you say, how do you say it, where is it kept, what are
all those various things that you need to know? Every organization, and greater, within the type of
business, have regulations regarding communications now. As a project manager, we
all need to be familiar with those. Also, we talked about timing of people that are coming into inspect. If you have to have approval of a document before it can be sent out, ya need to figure out
how long it's gonna take to get that approval because if you say, "I'm
gonna get the information on Thursday, send it out on Friday," and I'm going to assume that three people are going to be able to sign off on this so I can get it out by end of day Friday, and one of those people are out of town, what do I do? So I need to be able to figure out what is the workflow, what is the steps that have to be done to
get that thing approved before I put it out. So I have the work, it's progressing. We're gonna assume, at this point in time, we did what we said we were gonna do, at least for the first phase. So we're gonna celebrate, but before we celebrate,
there's a few things. Remember the old cartoon
that nothing is done until the paperwork is done? That's what we're talking about here. We need to be able to say, what did we do? What worked? What didn't work? Taking all of the documents, all the information that we need to, putting it away. Why? Because we hope that when
we do the next project, we can find it. I'm a hoard on paper. I'm a hoard on things that I've done. I probably have a copy
of every presentation and every course I've ever taught because there are times when I'm looking for that one picture or that one sentence that was on something
that I want to reuse. That's what we're talking about here. Taking what you've done
and putting it aside so that you can learn
from it, or other people can learn from it. Also, we talk about if we have people that are working on a project, it's really important
for us to give feedback back to their management
as to how they did, what their involvement was, doing recommendations, even as much as LinkedIn. How important is it if somebody is looking to potentially hire a person, they go to LinkedIn, they look
at the recommendations that that person has received. That's exactly what we're talking about. Doing an assessment, an appraisal of whoever's been doing that, to be able to give them some information that they can use future. They did a really great job. Maybe they didn't do as great a job, but you can always find
something positive. If you can't say something nice, figure out how to say something nice. You have to do that. Then we celebrate the project's success. We have a time. Granted, more and more organizations are cutting the budget for that. There's ways to celebrate without spending a lotta money. Part of this, also, is to be able to, as I say, validate. I need to have what I
said in the beginning I was going to do. Need to make sure that
actually has been completed and approved, and I'm
gonna do a comparison between what I said I was gonna do versus what I have. Some of these are some of the deliverables. I wanna keep track of things
that were not approved because I wanna be able
to go back and say, "Why were they not approved? What do I need to do to not
have that happen again?" As I'm going through
this validation process, I'm trying to make sure
that everything we said we were going to do has been done and accepted. There's also this last
piece that has to do with what we call administrative closure. That's the paperwork. I know we all hate it, and I know we all try not to do it, but it is so critical for us to be able to take the time to put this together, both
for our own standpoint of understanding what we
did, but also to be able to say, if we wanna do this again in the future, and maybe it's not do this exact thing, but it's something similar,
what can we learn from it? Being able to put that all together. Now that the project's finished, we need to sit back and look at ourselves as a project manager. What are the types of competencies that we need to have,
as a project manager? First of all, if we are
truly a project manager and managing a team and an effort, we probably need to have some idea of what we should be doing. Even if it's just at that
high level of understanding why, what, who, when, how, and then actually monitoring what's going on. But we also need to be able to perform. We need to be able to
figure out how we're going to accomplish what we're doing. Once again, unless you're
a project of one person, you are talking about
working with other people. You're talking about
being able to motivate those people, to be able to communicate with those people as to
what needs to be done, effectively, so they know
exactly what you want done, as opposed to a picture
of here's what I want and here's what you think, being able to go through there. There's also some behaviors
that are really critical, and they are becoming more critical in today's world. That has to do with some of the attitudes we have towards each other, as a team, between our stakeholders and ourselves, some core personality characteristics that we need to be able to realize. When we're managing or leading, it's very different than doing everything on my own when I'm only trying to tell myself what to do. I have a almost
two-year-old granddaughter. Watching how she's learning and how she's picking up
characteristics from the people she comes into contact are shaping her personality. She is exposed to a
lotta different people. As a result, you can see she
has a very broad spectrum of how she communicates
with different people and how she reacts to situation. The other thing is, as a project manager, we know this project
has those constraints, or at least, we should have figure out what those constraints were, and we need to be able to figure
out how we're gonna get from the why are we doing this and what are we doing, to actually accomplishing it, and yet staying within those constraints. As we said, when we start looking at the constraints of cost and time, maybe we have to make
some trade-offs there, and those are things that we have to know. When I was working on
a casino in Mississippi after Hurricane Katrina, the executives decided we will reopen one year to the day of Hurricane Katrina. I'm looking at what needed to be done, going, "There is no way we can get all of this accomplished." This was a major casino. So I started saying,
"Okay, so what are some of the things that I
might be able to delay, and how am I going to put together a story to sell this?" One of the things that, if you remember, Hurricane Katrina hit at
the end of the summer. If you look at a retail
operation, especially a casino, the end of the summer,
they're doing a sale to get rid of all their merchandise before they bring in their Thanksgiving, Christmas stuff, right? So I thought, hmm, why don't I delay that opening of that retail from August until at least October? That I don't have to concentrate on it right now, and I can put it in here. So I knew, even though I had a constraint, when the CEO said, "We will open one day to the day that the hurricane hit," he didn't say what was going to open. So I used that as my opening to say, "Okay, so can you tell me, do we need all 13
restaurants open on that day? Or can I open just the
buffet and the steakhouse and the coffee shop?" Then maybe open the next one a month or so later so I can do this rolling wave, progressive elaboration things, without using those terms for him. But the idea of being able to look at the constraint and
figuring out what do I do to work within that constraint. What PMI has done is they have started to move from that technical,
these are the things that the project manager must do, put together a charter and a schedule and a scope and all of these variances, and start to look at these things called interpersonal skills. They're also known as soft skills. They are competencies (sound cuts out) help project managers
and leaders and people in those type a situations
be able to better handle some of the ways that we need to work. Some of 'em have to do with
emotional intelligence. I'm not gonna go into this here, but this is an area that every
(sound cuts out) should have at least a basic understanding of what emotional intelligence
means and how to apply it when you're working with a group, and especially as a leader of that group. The group facilitation. We mentioned that earlier. This is an area where learning how to be a facilitator,
learning how to get people to interact and communicate and put ideas together, huge skill that needs to be done. It could be looked upon as
a technical skill, I don't. I look at it as more of a way to get things accomplished. The last one talks about the balance of ethical, interpersonal and conceptual skills that you need to use as you look at things that are occurring, and how are you going to react to it. Obviously, you can look at it and say, "Well, if I ignore it,
it's gonna go away." No. What's the impact? What do I need to do, ethically, as well as for the better of the entire group? In the PMBOK that I mentioned earlier, there's an entire appendix now that has to do with
these different skills, skills on leadership, skills on team building,
how do you build teams, how do you motivate teams, how do you communicate, what are the different
ways of communicating, delivering the right
message to the right person at the right time. How do you influence people without being a dictator, but still being able to get the job accomplished? How do you make decisions? Are they gonna be group decisions? Are they going to be,
okay, I have a majority that rules, or am I gonna have a plurality and let people that have
different things go? Understanding political and cultural awareness. Depending on the project you're in, depending on the organization, depending on where you live, this is all something that we need
to be able to understand. Understanding a little
bit about negotiation, give and take. That win-win situation
versus a win-lose situation. I read recently where
they said something about on a team, don't do a competition because when you do a competition, somebody loses. As a result, do something
so everybody wins, as opposed to this person winning and this person losing. Sometimes we kind of do
that without thinking. We need to look at that. How do I build trust? What are the different ways? How am I looked upon as a project manager? Am I looked upon somebody who's an expert in project
management or an expert in CRM? I obviously wasn't an expert in putting in a phone system, but by the time I had to do that, I had another skill that I had because of my other work, I had the expertise associated with me to say, "We can handle this." How do we handle conflict management? Huge term, huge concept and something that we can talk about at later time. How do we coach, how do
we mentor other people? Because regardless, even
when I was trying to teach my daughters, I was helping 'em do their wedding, but I was
also trying to coach 'em and mentor them and trying to break down what needed to be done. Reduce the stress level, as to different areas, as we went into that. Kinda one last thing I wanna talk about. PMI has this code of ethics, which is a code of conduct that
is meant to be applied to all project managers who either (sound cuts out) who have a certification, who volunteer with PMI. It's mainly to be able
to make sure that if an organization has a project manager, that they can understand
they follow certain rules. It also helps us as individuals look at that ethical decision. When should I do something,
when should I not, especially conflict of interest. Then being able to look
at it profession-wide. Project management is a profession. There's a lotta people. The PMP, which is the project
management certification, is 30 years old this year. There are thousands of
people that are certified. There's thousands of project managers. There's also a need for even more in the future. We know we don't have that. But we need to understand
how we should act. Our code of ethics basically
has four aspects to it. It has the aspect that
you must be responsible. You must take on the responsibility to do what you say you're gonna do. You need to respect the people that you're working with, your team members, your
stakeholders, everybody. You have to have that respect for them. You need to be fair. You can't take and have some people do things that you don't have others, making that fairness. And last, being honest, telling the truth, not lying, not covering
up as we go through. So as we say, we have both aspirational and mandatory standards. The mandatory are things that we must do, like we must not cheat, we must not lie. If we have a contract, we have to meet the needs of the contract, you don't have the conflict of interest,
things like that. In fact, well, most of us have to sign an additional conflict
of interest statement every time we do anything, which is fine. I found this quote by
Roy Disney and I thought it was really critical
or really appropriate. "It's not hard to make decisions once you know what your values are." That's basically what this is. It's being able to understand where you should be going, and therefore,
where do you wanna go. I'm gonna skip this because of time. Just one last kind of plug. PMI has a academic program that they present. That's part of why I'm
here, because that's what I represent is the outreach to the academic community. We have a number of different things that we are doing, as far as material, et cetera. But trying to work with
both the practitioners that are becoming project
managers, students, especially people that are, like, MBAs that will become a
project manager when they get a job, whether they
hold that title or not, because they will have
work that has to be done. Anyway, I hope that
I've at least been able to expose some of the
concepts of project management to you and be able to have you understand some of the basic good practices that we have, that we try to do. I thank you. (applause) - Greta, thank you so much. We'll take some questions now. I'll start with some questions from our virtual attendees, and give our in-person audience here a chance to gather their thoughts. The first question comes from someone who's interested in the field and had a question about the best path to take, best career path. The question's if project management requires both project management skills and knowledge, in addition to knowledge of the particular field, whether it's manufacturing or logistics or IT or whatever it might be, what typically is the path? The project managers that are out there, do they normally develop
the project management skills first, and then add
the substantive skills? Or does it tend to be vice-versa where there are people in
the field that then add project management expertise on top of their expertise in manufacturing or IT or whatever the case may be. - Well, I'm looking at some of the people that are project managers saying, "Okay, I hope I say this right." Let me tell you where I came from. I started out working on a project. I started out as a programmer years ago, became an analyst, designer, and then moved into more of a team leader type of thing. In my thing is, I think you either have a direction that you want to
go that incorporates people and teamwork to get things accomplished, as opposed to being that person that sits and is kind of a loner by themselves. As a result, somebody
who's a technical person, who just is really happy
sitting in a corner doing code or laying concrete or whatever, may not have the desire to
become a project manager, whereas if they get to
the point where they want to start maybe moving up and managing the team, that's where it kind of goes. There are certain skills, there are certain bents. We see a lotta project managers who know the tasks, but they don't
have the people skills. It has to be a mix of the two. - Great. This question gets into
some of the softer skills you were alluding to towards the end of your presentation. This learner outlines
a particular situation. As a project manager, what do you do in a situation where you have, say, an eager team member who
want to take responsibility for an area where he or she doesn't really have the appropriate skills, and the project manager
might prefer to bring on someone who is a little more experienced in this area? Is the project manager's
responsibility solely to make the call that
gets the project done most efficiently, or in that scenario, might there be some room
for softer considerations, like the morale of that eager team member or helping that team member
build additional skills? - I look at it and say, very
seldom was I actually able to determine who was gonna be on my team. I usually walk into a contract situation, especially where the team is there, and I have to work with those people. Some of 'em being overly
qualified, and therefore, thinking they could do
this stuff by themselves. So I let them teach me. If they think they're over, if they think they really know what they're doing, they're eager, hey, participate with me. On the other hand, can I map or match them up with somebody that doesn't have those
skills or, for instance, let's say they have the technical skills in an area, but they
may not have some of the soft skills that are
needed, by pairing them up with somebody that they can work together to kind of rub off on each other. But I think the key is when
we work with team members, we have to get the job
done, yes, but we also have to make sure that
the team that is working on here actually can accomplish it. Very seldom do we have the ability to choose who that team member is, as well as being able to release a team member. That's the sticky part, is at point, what point in time. I've had to do that in
a couple of situations, where I've had to figure out how to move that person off the project, while still allowing them to save face. So a lotta times, it's a
matter of finding another project that I can say is more critical, here ya go, type of thing. But I think the project
manager, depends on, once again, that organizational structure I didn't talk about, that depends a lot on how much responsibility and authority the project manager has for that team. - Another question about
the field, more broadly. How do business leaders
today, in your opinion, value kind of formal
project management skills? In other words, are
they increasingly likely to hire or engage a
trained project manager, or are they, as opposed to being apt to just make the assignment to someone in the relevant department? Does that make any sense? - Yeah, it makes a lotta sense. I think a lot of it has to do, once again, with the organization structure working in because in a functional organization, we talk about the fact that, most often, the projects are done within
that functional organization. They're managed by the functional manager, not really a PM. They're staffed by the
people within that function. They don't really, a lotta
times, have those skills. Also, there's a cost associated, and we see that a lotta times. I think one of the reasons why, unless you have an organization that does a lot of projects, you
will not necessarily see a full-time project manager or project managers in that organization. They will be brought in to be able to help manage that project, and when the project is completed, they're let go, which is what you expect. It's a start and an end,
which is personally why I like being a project manager. I don't like the day-to-day operation. I like the idea of I have a project, I have something I have to do, I get it done. I think that's something that some of us feel the same way. - Any questions from our audience? Just one second. - I just wanted to ask,
what is the best possible way of answering the question on what are your weaknesses? I'm the project manager,
I go in for an interview. I may be having a lot of weaknesses, which, of course, I have, but
how should I best possible answer this question on what exactly are my weakness? Because right now, I'm
there to sell myself and not tell them my weaknesses, right? But if I am asked this question, how do I handle this? - I'm probably not the right person to answer that because
I would be struggling with the same thing. Part of it, when I talked about why, the more research I can do on why they might be hiring me, what kind of organization it is, what kinda skills they would expect, and therefore, being able to figure out
that these are the things they expect, and I know I can do those. Maybe something that's not that critical. One of my weak skills
is I'm a procrastinator. I know that, but I get things done. But I also realize that's
really not the best way to do things because the more we wait till the last minute, that
whole student syndrome idea, and we get under stress,
we don't do as good a job as we might. That's probably a question (laughs) that other people here
could help answer even more. But you're right, you're
trying to sell 'em your positives, and the
only thing might be to say, "Okay, let me think. If these are my positives,"
so that I restate them, then let me see if I can
figure out something, as I'm restating my positives, to be able to state what my weakness is. That would be the thinking process I might go through. - Hi, Greta, thank you so
much for the presentation. I took several pages of notes. (laughing) My question to you is you mentioned that there's a greater need
for project managers. What do you think is fueling that need? - Just the fact that I
think there are projects that need to be organized to be done. I think what happens is because of things that have to be done,
especially in a very tight time frame, that whole idea of being able to get somebody who
knows how to organize it and get it accomplished, as opposed to, and it goes back to the previous question about can we just use
somebody that's there. If they have knowledge
of what has to be done, probably those skills of
managing, keeping things on track, could be
supplemented by somebody else. A lotta times, they are, through kind of a project management assistant or some sort of coordinator type of
person to do some of that hard skills, the hard
tasks that need to be done. But I think a lot of
it is just a matter of everything is done in a
shorter time frame now. We have those constraints
of time and cost. So therefore, being able to have somebody that can organize it and make sure that they stay on top of it, and not just expect everything to happen. I think that's part of where, I guess, the organizations, and I
look to you, too, to say, do you kind of agree with that, as to why we have projects? - Over here. I got a follow-up question. Just a follow-up question
on what Amber just asked. Do you see a greater
acceptance within industry of the value of bringing
in a project manager? - Oh, absolutely. I think that, once again, most organizations realize
that when they take upon a project, even that phone system, being able to have somebody that could stay on top of it, they're
looking at how much money they're putting out. They wanna make sure that it gets done and that it doesn't get out of budget and out of control. Once again, the types of things. In my case, I tend to be able to see that, well, in
order to do this project, you need to do these other pieces of it, so it's what we call a program, but that's neither here nor there. But the idea that, yeah,
having a project manager to not have to worry about that day-to-day operation. They're assigned, they're
put in charge of this, and you can assume that it's
gonna get completed then. - I have a question that's kind of along the lines of the time constraints. If you're dealing with a project that has a strict time constraint
and one of the tasks, maybe a task along the
critical path, for example, is, you feel is running behind, do you have any tips for a project manager to try and light a fire, so to speak, to make sure that that task completes on time so your project's not delayed? - There's two activities
that we use in that case. We call it schedule compression. We talk about the idea that sometimes being proactive and preventative. If I know that's gonna be happening, which I should, I should be able to see ahead of time we're gonna
have a problem here, I can either maybe start it
a little bit ahead a time. I run some risk that
we're gonna have to do some rework, but maybe I can get pieces of it done ahead of time. That's one thing. The other thing is what we call crashing. That's where we throw more people onto it. Obviously, at some point in time, you reach this case where ya have too many people, and the communication and everything that needs to be done starts to go south, but those are some of the things. I think, in my mind, though, it's being able to understand there is a potential that this is gonna happen so I have time to think out
the different alternatives that I need to do, rather than waiting until all of a sudden I see, oh, my god, not gonna make that. Working backwards from that time of when it's there, like
I said, when I opened the casino, I ended up actually telling my team, "I know what the date of the opening is, but
that's not your date. Your date is a month
before," and actually, in some cases, even
earlier, because we had people that need to train on the system, we need to have people that could do this. I worked those different dates. I knew I had wiggle room in there, and that's the other thing. I always have. That's my official term is wiggle room. I always put those type a buffers in there so that I can handle. But staying on top of it,
realizing it may happen. I'd rather be able to be proactive and try and figure out that it may happen or what might I have to do. Perfect example, you're driving up here. You have a time, you're
supposed to be here at a certain time. Do I listen to the radio to listen to the traffic? Yes, so I know if there's
a potential problem, coming early. There's all sorts a things you can do to be able to be that proactive. That just has to be
kind of in your nature. - Greta, thank you for a
wonderful presentation. You brought to bear so many points that are so important
for project management. I like the comment that you made about how project management is so much more than the schedule, and you really need to look at all the phases. Then on top of that, talking about the softer skills. My question for you is, looking at all of the softer skills
that are so important, and having worked with so many different types of project managers,
what would you say are really the most important soft skills that a strong project
manager really needs to have? - I think the first is
being able to communicate and the other is being
able to work with a team, being able to understand the team members, being able to encourage
them, motivate them, et cetera, as we go through. But I think you have to
be able to communicate. To me, communicate is by walking around, not sitting in my office. I never, ever was in my office. Once we ended up getting the cell phones, they could still get me all the time, but I need to be able to
communicate with people, I need to understand what they're saying, what they're doing, where they're feeling, things like that, understanding that. Then being able to figure out you're behind schedule. What do we need to do
to get, to motivate you to get this done? Do we need to add more people? Do we need to figure
out what's going wrong? What do we have to do? So I would say those are the two main ones that I would see. You agree? - I think we can squeeze in two more. - Oh, dear. - Can the students
benefit from joining PMI? (laughter) - He's a PMI member. And since we're doing a joint.
- Is that a hardball question? (laughter) - I'll mention, PMI has a couple a different memberships. One is for those of us in the profession. It also has a student membership. The student membership
for a full-time student is very, very reasonable. Through that, not only
do you have attendance and capability to be part of these groups, be mentored, being able to volunteer and work with experienced
project managers, the PMBOK Guide that you
saw up there, is free in an online version to anybody that's a member of PMI, which means if you're in a project management class, it probably makes sense for you to download it free of charge, rather than paying the whatever,
80, $100 that it costs. There's another website that PMI just acquired. It's called projectmanagement.com. It is a fantastic resource. If you're not a member, a lotta free information out there. If you're a member of PMI,
even a student member, you have access to
webinars, you have access to templates, you have access to thousands of things that can help you. As a student, if I have to put together a project, (laughs)
there's a lotta resources out there that are available to me. One of the things that
we look at is the ability to get students a little bit more involved because students are our future project managers. When we were in Las Vegas, our students were our volunteers for
all of our organizations. As a result, they were seen by the people in the chapter. Almost every one of 'em got a job after graduation because of that contact that they had made, the
references that they were able to receive
for that volunteer work that they did. We push very hard as far as being able to be involved. It's a great group of people. We just spent four days on a cruise, which, unfortunately,
is not my favorite way to do presentations, and
the pictures came back with me hanging onto the podium, as we were rocking back and forth, but being able to work with other people, other key people that have gone through similar situations, it's a great networking opportunity for students, as well as
for people who are looking, as we say, in transition, between jobs. - I just have a quick question. That is basically when you're working on a project and you're
working with your team, what incentives or motivational tools do you utilize? - Well, one of the
things that I used to do, and I don't know if
it's still appropriate, but whenever I had my staff meetings once a week, I would always have some sort of little candy bar, whether it was a PayDay or a Million
Dollar bar or something, and I would recognize somebody who did something well, or somebody who had made a mistake, but admitted to it so that we could make an adjustment to it. Just that little recognition. Obviously, there's other things that we can do to motivate, but
there's a whole theory of motivational that we study because you have to understand where a person is to be able to understand
what motivates 'em. For instance, if I were to say to Robin, for instance, "Guess what? You can work from home virtually." But she's the type a person that doesn't feel comfortable unless
she's in an environment with other people. That motivation, which
I thought woulda been a motivation and a benefit, a reward, ends up being a penalty because that's not where she is. We have to understand where people are, what motivates 'em. Sometimes a $25 gift card motivates people, and sometimes that's not what they need. This goes back to that
emotional intelligence. I need to understand my people. I need to understand where they are, what's important to them, the sympathy, the emotion
that I have to have in order to, I guess,
not as much motivate 'em as to make sure I don't demotivate 'em. If you notice on the slide, those of us that are project managers
as part of our certification have to have so many hours
of continuing education. We have the PDU numbers
that you would have to have to record this, just like you have your students as a project manager, certified project manager,
so the event number is up there and the date
and the number of PDUs. - On behalf of the entire
institute, I'd like to thank both our partners at the Project Management Institute and Greta for a fantastic and
informative presentation. Thank you so much. (applause)
It's long and has really good basics.
Upvotes but no comments.... How was the video everyone?