Well, this lesson constitutes the start of, in many ways, what people would think of as really the
meat of the project management challenge. And that is taking a lot of ideas and a lot of
creativity and a lot of hopes and dreams and converting them into something that can actually be realized.
In fact, in many ways, the challenge that you're going to face in project
management is being the expert in your organization and doing precisely what it is
we're going to be talking about now, and that is operationalizing these ideas.
Because up until now, even creating scope and creating the genesis of what we're attempting to
do with this project, a service project, a new product development project, it doesn't matter.
The idea is a good one and it's powerful because it triggers what's going to happen after that.
But what's missing is some ability to take and create a rational pathway
from the idea to its natural fruition. In other words, making it happen.
Your ability to be the one person in your organization or the one person in your department
who can make these things happen is going to create an enormous amount of career value for
you because you're going to have a mindset, a discipline base and a thought process that's going
to allow you to convert, to create, to proceed. And that's what this section is about. We're
going to be talking about creating the project network now, as we mentioned.
And what does that really consist of? Well, the first thing I want to do is reintroduce our old friend.
If you remember our lesson two on scope management.
I went to some length explaining the idea of the work breakdown structure. And if you remember what I was
doing there was trying to give us an overview of the value that a work breakdown structure has for us.
The WBS is our means to take that project and deconstruct it further
down, further down, further down, until we finally get to an activity level.
And those activities are what we're going to be focusing on and what we're
going to be pushing, creating, developing, because all of those jointly and collectively, then
ultimately work backwards up the hierarchy, this pyramid to the project itself.
So the work breakdown structure, I mentioned just how critical
that is to the organizational development of the project.
But what we're going to do in this lesson is talk about it in a little more
detail and then see what do we do with this information. So how do we proceed from
the WBS into an actual activity network, which is where we start creating the means to succeed?
So recall that a WBS is this hierarchical decomposition of
the work project, deliverables maybe sub deliverables, and then the
activities or the tasks at the bottom of the pyramid.
So that's what we want to do with it. The steps that we're going to
use are we're going to define the overall project objective, what it is we're doing.
We want to determine these various work elements as part of this process.
And the way I like to explain it to my students is we want to break the project into manageable
elements, pieces into those manageable pieces. The example I gave of trying to get from New York City, from Battery
park to Brooklyn without any help, any guidance, any means of knowing where to go, is a daunting one.
So what we do by painting those goal posts along the way, what we do
by creating these manageable pieces is we give the project team a visible means to
succeed in this activity that they're going to undertake the creation of the overall project.
Remember the work package? Sometimes I'm going to refer to it as the task.
Either one works.
The work packages are the lowest element that we're going to talk about in this hierarchy.
And so in doing that, recall that the organization wbs we have these different
levels, the project level, the deliverable, maybe sub deliverables, and then work packages.
And that's the way we're going to go.
Remember also that work packages require clearly defined ownership.
Who's responsible for this?
I want you to think about lesson two, where I talked about the scope management
process. And one of those activities in there was to create a responsibility assignment matrix.
And it had on the Y axis coming down, it had all the different elements of the work package across the top.
It had all the key project team members, and it was
trying to match up the activities with the team members.
Who's responsible? Who owns each of those activities?
Every activity must have a clearly defined ownership, one
person responsible, clearly defined start and end dates.
Those end dates imply this is when this will start, this is when it will end, this is what it will
create. What I say here is representative of physical accomplishments is another way of saying the start and end of that
activity means that at the end point we have completed that activity. Whatever it is that we determine, it should be.
Third, results that can be compared with our expectations. Remember, we have a plan.
This is what we're developing is a plan, an set of expectations for what each
of these activities is intended to be, what it's intended to create or to do.
And we have to have a means by which we can compare the expected with the actual.
Don't forget all Activities have a budget. There's a budget
number associated with that. How does that number come about?
Well, it depends.
Let's say, for example, that we have three people assigned to an activity, and if we know their hourly rate,
we can say, all right, that activity we're going to show how we do this later. But that activity, let's
say, is going to take 10 hours, and I have three people assigned to it at certain hourly rates.
I simply take their hourly rates, multiply them by 10 hours.
Is there some overhead charge I have to include? That may be the case in your organization. Only you know that.
Are there other physical characteristics? Do we need physical materials or some other materials that we can assign to that activity?
All of those things together, come up with our specific budget item for that activity.
For most of you, the largest single cost item for assigning cost for activities is going to
be the cost of your resources. The person or people that are responsible for getting it done.
How you cost them out is going to vary depending upon the organization you're in.
In some of your companies, the accountant or some other financial person will
handle this for you because they know all of the overhead charges.
So it's usually some percentage of their rate. For example, maybe 40% of
their actual hourly rate has to be added on top for overhead.
All these combined create the final cost
for that resource to accomplish that activity.
So the measurable specific budget in terms of dollars, average hours to
completion, or some other measurable unit, some means by which we can
assign a specific target value to that activity. Let's take an example.
I'm not going to spend a whole lot of time with this because we did an example in lesson two, but I
just want to sort of set the stage. Let's imagine a very simple case where a friend of yours is getting married.
Absolute panic. So this friend assigns you the task of actually organizing a wedding because you got
married yourself a couple years ago. So you have a little bit of a frame of reference.
So you start thinking, I have to plan this wedding. How am I going to do that? Well, remember, this is our challenge.
Here's the goal.
Here's the piece of paper that's blank.
How do I start filling it in? How do I decide what has to be done?
So perhaps I talk to friends, the expert opinion.
Perhaps I remember my historical example with my own wedding. Perhaps I have other people that I
can talk to to start gathering up the different list of tasks, things I have to do.
And suppose I start doing that, and I commit that to paper so I have A goal.
And I start trying to rationalize that goal with activities. So maybe the
wedding project is my first number. That's the 1.0 on my hierarchy.
Underneath that maybe decide on a date marriage license. You have to get that.
Bridal arrangements. Okay, underneath bridal arrangements. Notice now I have some specific activities. So maybe those first ones.
1.1 were deliverables.
1.3 is bridal arrangements. But that's not sufficient, is it? So I have to drill down further and say, well, what about the bridal arrangements?
Okay, well, select attendance, order the dresses. The dresses have to be fit. You have to do all these sorts
of things. And then we get to the ceremony, the rent the church florist, create print programs, hire a photographer.
You can see these are all examples of me breaking down the
project into these bite sized chunks that I've been referring to all
along. The deliverables come down ultimately into activities or tasks.
And so here we are looking at a variety of the different tasks that are going
to be necessary if I am going to pull off this wedding for my friend.
And so I have ultimately taken a project and I've started subdividing it into the various components.
And I've broken it down further. Remember the term I used earlier? I said it's a deconstruction.
A work breakdown structure is a deconstruction of the project down further and further
until I get to a point where I can assign specific measurable tasks.
That's all I'm attempting to do. So let's assume this is just an example
to show and illustrate the ideas of again, a work breakdown structure goal practical.
What I have to do.
Let's take that one step further. So let's assume that we've gotten to the point where we're capable either
on our own or through consultation with experts or other members of our project team or other historical documents.
We're at the point where we feel pretty comfortable now about all of these different activities.
But the next step is this.
What do I do with those activities? How do I now apply them into
a project? How do I make them into a project? How do I get
something out of them jointly so that they ultimately equal the project?
Well, what we're talking about here is the idea of developing activity networks.
Now, activity networks is a fundamental component of a project and it's of developing the project plan. And so we're going
to spend a fair amount of time explaining how do we develop an activity network. What is some of the key
terminology that we have to be familiar with? When we talk about activity networks, what do they do for us?
What are the rules in developing an activity network? The good news is there's some very clearly defined rules. So we're not
trying to blunder in the dark here. We have some means and some rules by which we can start developing this network.
Activity networks essentially are quite simple, quite straightforward. They're a schematic.
So it's a display of all the logical relationships of project activities. Now, the. There's a lot of elements in that definition, so I
want to go through these and pick them apart one at a time. First of all, schematic means that it is a display.
It's a graphic or it's a figure.
It's a display of what the project flowchart is going to look like.
The second point, logical relationships, is also one we're going to delve into here
in a few minutes, because logical relationships define the nature of an activity network.
What I mean by that is, would it make sense, going back to my example of the wedding,
would it make sense to rent the hall before the bride has even said yes to the groom?
Well, clearly no.
Would it make sense to order the band before we've done some of the preliminary things up front as well? Does it
make sense to do these things out of order? Should I order a band and have them on hold for three weeks
until such time as I can get this done while I'm paying their salary the whole time? Well, of course not.
I may book them, but I need them down here at the later end of the process. What I'm
referring to here is this idea of logic. What order should activities follow in what should be done first,
what should be done after that? Can some things be done at the same time to save us time?
All of these questions factor into the decision about how I create logical
relationships among all these activities that I've identified through my work breakdown structure.
I love this idea. The goal of the activity network is to create a set of visual network
paths. Now, there's a lot of words in there that are a little bit fuzzy right now. Don't
worry about that because we're going to come back and we're going to hit each one of these.
But when we say it's to create visual network paths, that idea again says that what
I want you to be thinking about is, what is this schematic? What is this drawing?
What is this figure of all these activities laid out in relationship to each other?
What is it going to resemble?
That's where the network logic comes into play. And that's what we're going to be talking about now. How.
How do I take a bunch of activities and put them into a logical relationship to each other?
Okay, what we're going to do is we're going to be creating
this set of visual network paths by sequencing all these activities.
What has to happen first, second, third, et cetera. That's the sequence we have to pay attention to.
Networks take the results of our work. Breakdown structure. And I like the way
this is referred to. It says they show their temporal relationships to each other.
That's a very fancy way of saying a simple thing.
Some of these happen first and some happen later.
And I have to recognize some things happen before other things have to happen.
I use an example in my classes with my undergraduates. And I say, imagine you're going home for the first time
since you went away to college. You've been gone for two and a half months, and you're home on fall break,
and your mother says, after the hugs, and you look thinner and these other things like that, your mother says to
you, you know, by the way, you never cleaned your room and I asked you to clean your room.
I would appreciate if you'd go in now and clean your room.
So. So you finally agree just to keep peace in the household. You finally agree that you want to go in and clean your room.
You don't want to, but you're going to.
You start looking at all the things. You look at the dishes that are piled up. You look at the crumpled bed sheets that are
laying all over the place. You look at all this stuff because mom, true to her word, simply closed the door when you walked out.
Everything was left as it was the day you left for college.
So first of all, the smell is probably a little bad.
Everything is a mess.
But just going into cleaning the room suggests you have to do certain things in a certain order. That's
that temporal relationship part we're talking about. You can't wash sheets till you strip them off the bed.
You can't vacuum the floor till you pick up the old clothes.
You can't shine the surfaces of your desk till you remove the old dishes.
That's what we're talking about. Anytime we talk about temporal relationships or this
idea of network logic, what has to happen before other things can happen.
Remember, networks are a work in progress. Now, what I mean by this is a very important point. I'm
going to hammer this later on in this lesson, but let's address it right out of the starting gate.
Every time I've been asked to develop a network for any project that I've been involved in.
I recognize that it is an iterative process. The first thing I lay out, where I say, well, this can happen,
and then this, then this, then this. Someone else will look at it and say, well, no, because if you do
this, then basically what we need is many eyes looking at that network, many opinions, and we need to recognize that
that first thing we lay out is probably wrong or at least is going to need a lot of modification.
That's the idea of a work in progress.
So remember that when you develop a network, the first time you do it, put it in
pencil, because you're going to be erasing a lot and you're going to be changing and altering
and modifying. As other people offer advice on the order, none of us are experts on this.
None of us are going to get it right the first time. Your network will be a work in progress as you're
developing it. So recognize that. Don't feel frustrated if you don't get it right the first, second, or even third time.
It's evolving, and that's the idea. It may require many iterations until
you get the logic in the correct order in the correct sequence.
Why do we have network diagrams? Network diagrams are a wonderful thing. You can see it right here.
I sort of illustrated it all on this one slide to show you not only what's good about
them, but just giving you an example of one of these sort of temporally sequenced kind of things.
Notice we have some things happening first, and then they lead into other things which lead into other things.
Networks allow us to understand the interdependence among all those activities. Some of them
are critical that they happen early so that other things can happen afterwards.
Networks facilitate communication because they make us aware of not only who is depending upon my work, but
who I depend upon. So that person has to finish their activity before I can start mine.
And when I'm done, that will lead on to somebody else's. So we're going to talk to each other to
make sure we're on the same page. When do you expect to finish? When do I get this from you?
That kind of information?
I'm going to show you later.
That network development also helps us determine project completion.
You see, this is the beauty of this. Up until this point, we can have all the best
guesses in the world. We can have top management saying, you have to be done by September 1st.
We can say all these different things. But you know what?
Until I create A network, a logical network, one that
works until it's all laid out and it fits.
I can't tell you how long that project's going to take.
Nobody can.
Your boss can order it done until he's blue in the face, but that's not going to change
the basic parameters of when that project is going to get done, depending upon how it's laid out.
So project completion date is not determined by the boss.
Project completion date is determined by the project network.
Project networks help me schedule resources.
I may not need a programmer or a tester until later in the project. Well,
when do I need them? Because their boss wants to schedule that person's availability.
Just saying I'm not sure, I'll let you know is a bad idea.
Because if you say that, you're setting yourself up for not having that person available when you need them.
But the fact is, until you lay out the network, you don't know, you can't.
And so it's not until the network is all laid out and I can look at this network and say, aha,
this is the point in time at which I'm going to need this individual, that now I can contact that person's
boss and say, I need Carol working on these dates, so I need to book her for this point in time.
That helps defray a lot of the ambiguity in when resources will be available because I planned for them.
We're going to see in our next lesson what I call here, critical activities. At this point in time, all
I want you to think about is some activities are going to define how long the project takes overall.
The way I lay out my network paths are going to. One of those
paths is going to determine how long this project is going to be.
The other ones, not so much. They're going to have a little bit of give what we call slack time in them.
But one of those paths will be very important. In fact, the term we use is critical.
So we're going to use all this network that we create to, to identify the critical path. The critical
path tells us all the activities that absolutely gotta be done when they say they're gonna be done.
Networks show start and finish dates along with the idea of determining project completion.
If I set out my network correctly, I'm gonna know when each of
those activities is expected to start, when it is expected to complete.
And so overall, there's no ambiguity, no possibility of surprise in the system. Just because
I was a little tentative in terms of knowing when these activities were supposed to
happen. That will not occur if I lay out a good, logical network.