Hello again and welcome back to our course on Project 2013 Advanced.
In this section we’re going to start to look at Project consolidation and the first
thing I need to do apart from explaining to you what Project consolidation is, is to explain
why we might want to deal with consolidated projects.
So here’s a Project schedule for a very straightforward schedule which is fairly high
level at the moment but it shows the development and implementation of a new website for a
company, Northern Farm Foods.
Now this particular schedule is pretty simple by any standards.
There’s just maybe 12, 15 tasks in that schedule.
They’re arranged into little summary tasks.
So we’re talking about tendering process, contract, and so on, requirement specification,
then analysis and design, then the development of the website, the testing of the website,
and the implementation and go live for that particular website.
Now if you don’t know anything about developing websites, don’t worry about it because the
actual tasks here don’t really matter too much in this situation.
Now that’s a straightforward schedule but what if instead of having about say 15 tasks
or so it had 150?
Or 1,500?
Or 15,000 for that matter?
Once a schedule starts to get very big, then it starts to become very unwieldy.
Now that’s not only from the point of view that the file and all the processing involved
starts to get big and slow but it also means that if you’re working on say a particular
part, let’s suppose you’re responsible for doing the schedule for the testing of
this new website, it may well be that you don’t really need to look too much at all
the other parts of the schedule.
You only need to know when your part is due to start and then you really want to be able
to focus on your part of the schedule.
So there’s a strong case for saying, well why don’t we split this schedule up into
parts so that we can deal with each part separately.
Now although there are some strong arguments for doing that, when you’re dealing with
a very large plan there are some arguments against it as well.
Let’s deal with one of the arguments for this approach first.
Let’s suppose that when we come to do this plan and Northern Farm Foods is a pretty big
company so it’s pretty significant, the websites really a major exercise, then they
want to make sure this runs as slickly and smoothly as possible.
So basically they have really three teams of people working on it.
They have a team that is going to deal with the requirements.
So they’re the people that are going to say, “Right.
This is what the website must be able to do.
This is the sort of graphics, the branding images, and so on that we want on there.”
Then we have another team that do the analysis and design of the website.
So they work out where the data is coming from, how all the pages of the website relate
to each other, all the sort of commercial marketing, shopping cart side of things, and
so on.
And then they actually go ahead and develop the website.
So they create the resources they need, they implement the database, they write the pages
of the website.
So they go ahead and do the development.
The third team is responsible for, say, testing and for going live.
Now each of those teams let’s suppose has a project manager.
So we’ve got somebody on the requirements side who’s going to project manage the requirements
definition.
We have another project manager who’s going to do the analysis and design and development
and another project manager who’s responsible for testing and implementation.
Now one of the big issues we have is that if we have this one schedule like this, it’s
just about impossible for all three of them to work on it at the same time.
Now even though there are some ways in which this can be done to some extent, it does present
its own difficulty, some of which we’re going to look at later on in the course.
But immediately, you can see an advantage of being able to split this whole project
up into three parts and then let each of those three project managers manage their own part
of the schedule.
So let’s suppose that what I did was to just take this schedule and split it into
three parts for those three project managers.
That sounds pretty straightforward.
In fact, it is pretty straightforward.
I’ll show you how to do that in a couple of minute’s time.
But now let’s look at some of the disadvantages of doing that.
Well, one of the most obvious disadvantages is that you no longer have this nice, clean
overview of the whole project.
You may decide, for instance, to call each of those three separate parts a project and
call this whole thing a program, which is absolutely fine.
But you would then not have a good, simple overview of your program.
So one of the things we want to be able to do is to split the schedule up but we want
to split it up in such a way that we can still get a good overview of the whole program or
the whole what we call consolidated project.
Now let’s look at one of the less obvious disadvantages of this approach.
Let’s go into Resource Sheet View.
I’ll use one of the buttons on the status bar and you’ll see that I’ve already setup
some resources.
Now the people involved in this, apart from Northern Farm Foods in a generic sense, are
a company called Bakersfield Associates who are going to do a lot of the marketing related
work.
And then we’ve got a company called People4People who are going to do some of the HR work on
it.
And then we’ve got a mixture of named individuals from Northern Farm Foods who are going to
be involved in various aspects of project management and some of the technical aspects
and I’ll talk about what each of those people does at later on in the course.
Now let’s go back to the Gantt Chart View again.
All the time that I’ve got this view with all of the tasks in it, I can make sure that
I understand how my resources are allocated.
So for instance, if I know that I’m allowed a certain amount of general resource from
the company Northern Farm Foods, then I can make sure that I don’t exceed that amount
of resource at any time.
If I need a particular one of the individuals to work on different aspects of the project,
then I can make sure that person is not overallocated.
Let’s take somebody who’s fairly flexible, perhaps somebody with a lot of the technical
knowledge.
I can make sure that they’re not overallocated because they’re used in both the analysis
and design part of one project, development part of that project, but also that they may
be involved in scripting some of the tests that need to be performed on the website.
So I can make sure that those individuals are not overallocated.
Once I split this project up into parts, there’s a danger that individuals or even generic
resources will be overallocated and I won’t be aware of it.
So the other key requirement if I’m splitting this into a set of separate projects is that
the resourcing of each project is aware of the resource requirements of the other projects.
Now the general approach we take to this is to setup what’s called a resource pool and
the resource pool is shared by all of the projects that make up our consolidated project.
Now to be strictly fair, you can actually set it up in a more complex way than that.
But for the purposes of the exercises on this course, we’re going to think of it that
when you’re dealing with a consolidated project you’re going to have a resource
pool that all of the individual constituent projects use as well and that’s how we make
sure that we keep control of how much of each of the available resources we use.
Now in the balance of this section, I’m just going to show you how to split up a project
like this one and we’re going to deal with issues like the resource pool in later sections
of the course.
But before we even do the split, I’d like to just mention one other thing.
If you are using Project Server or planning to use Project Server, then project consolidation
and what’s known as enterprise resource planning, so using a very, very big pool of
resource to deal with many, many projects and programs is very well handled by Project
Server.
As I said earlier on in the course we don’t cover Project Server on this course, but if
you have Project Server then one of the things you will almost certainly use it for is to
deal with the shared resource issue.
Now in order to do that with Project Server, you need to be using Project Professional.
The features that you need to deal with enterprise resource planning in Project Server require
Professional rather than Standard.
But as we’re not using Project Server on this course, that’s pretty much irrelevant
and the things that we’re going to be doing here, in terms of sharing resources, you can
do using Project Standard or Project Professional.
So Project Standard doesn’t give you a restriction on this approach to sharing resources but
it does restrict you in terms of your use of Project Server.
Now what I’m going to do here is to start to split this project up and to make three
separate smaller projects out of it.
In fact, we’ll ultimately finish up with four projects as you’ll see.
But for the first project, I’m just going to use this Requirements Summary Task.
Now one thing to beware of here and it’s something to be very careful of when you come
to split a project into smaller projects is that there are dependencies here.
So for instance, according to this current schedule, requirements definition here doesn’t
start until the tendering process and contract process are complete.
Now if I pull this into a separate project, then with things as they are at the moment
I’ll lose that dependency.
Now I’m not going to worry about that dependency at this stage.
We’ll look at these dependencies later on and then you’ll see the sort of techniques
you can use so that you don’t lose dependencies unnecessarily in the future.
The other thing to bear in mind is that within the requirements there is a dependency in
that the requirement sign off is dependent on requirements definition.
So you’ve got a link from that task to that task.
Now you won’t lose that dependency because it’s within this overall summary task.
But then you’ve got another dependency, in fact you’ve got two dependencies between
the start of requirements definition and the start of analysis and design, and the start
of graphical resources and branding.
Now we’re also using this approach, going to lose those two dependencies again and we’ll
need to put those two back in place again as well.
Now when we do this, as you’ll see in a moment, Project 2013 gives us a warning about
this and you need to make a conscious decision that you’re going to accept losing those
dependencies using the approach that we’re using here, but we’ll come back to that
in just a moment.
So let’s select those three tasks, copy them to the clipboard.
I’ll just use the keyboard shortcut Ctrl-C. Then we say File, into Backstage View, New
Project, Blank Project, and then all I need to do is to press Paste.
Now when I press Paste, I get this warning which is basically saying that you’re really
trying to paste a dependency that will no longer work.
The first task is dependent on something that isn’t in this project.
Now if you want to continue pasting and take any more error messages, just say Yes and
carry on.
I get another warning.
This is to do with the second task and its successor, as you can see from the wording
there.
That’s the link that goes through to the analysis and design and development tasks.
Click on Yes again and I do actually see that my requirement summary task and its two constituent
subtasks are pasted and I have in fact kept that internal dependency.
But the other two dependencies are lost.
Now what I’m going to do now is to save this project with a name that shows that it
is part of this overall Northern Farm Foods project.
So my original Project File, NFF Proposed Implementation.mpp, I’m saving the requirements
as NFF Requirements.mpp.
These files are all in the scratch folder that I’m using on the course.
So if you’re working along with this or with perhaps a project of your own, these
go into your scratch folder as well I hope.
Click on Save and having saved that project, I’m just going to close it and I’ll use
it again a little bit later on.
So having taken that little summary task requirements and copied it, made a separate project, in
theory what we’re going to do is to replace this little batch of tasks here in the original
project with a new subproject.
So we’re actually going to put in here not a sequence of tasks as such but a link to
a project, a separate project.
But we’re going to do that in a particular way, as I’m going to show you in the next
section.
So please join me for that.