Schedule Validation

[Nancy]

What is the methodology for validating the schedule data in MS Project once
a master schedule has been created?

 

[JulieS]

Hi Nancy,

Could you explain more precisely what you mean by "validating the schedule
data"? What is it you are trying to accomplish or show?

Julie

 

[JackD]

There are an number of ways.
Here is what I would typically do.
Some of it I do as we go along so I do not perform any formal schedule
validation, but a schedule review is quite important and should not be
skipped.


First you want to validate that there are no major technical issues.

You can search to find all tasks without predecessors or without successors.
These are commonly called dangling tasks. For a working critical path
schedule there should be few of these. Ideally just one at the start and one
at the finish, but the world is not an ideal place so at least know which
tasks are dangling and understand why.

You also want to make sure that tasks all have some sort of valid duration.
Project puts a question mark after the duration of all added tasks and that
stays until the duration has been adjusted. Check to see that there are no
remaining question marks.

Next review the logic and durations with the people that are going to do the
work. It should be clear and correct. Walk through task by task for the main
schedule activities (starting with the critical path).

Next, check resource loading to be sure that all tasks have resources
assigned (if you are using resources in your schedule) and that no one is
tremendously overloaded. In my opinion brief overloading and underloading is
acceptable and there is no need to make every resource evenly loaded. It is
just an estimate at this time.

You might also want to check to make sure that the work described in the
schedule includes all of the work necessary to complete the project.

When you are all done save a baseline.

 

[Nancy]

Julie,

Thanks for your quick response. JackD's response pretty much covered what
I was looking for. However, would appreciate anything you could add.

While developing the schedule, each functional expert (software, logistics,
engineering, etc.) provided a schedule for their respective activities
required to develop a given capability. Unfortunately, a cross-functional
evaluation was not conducted to determine what impact their individual
schedule would have on another functional area. Then all the individual
schedules were integrated into a master schedule. I know there are
disconnects, which is driving my need to validate the schedule.

I'm inclined to focus on activities that are on or near the critical path
and to make sure we have links to the critical assets required to support
test activities. However, I hoping someone can tell me if there are other
areas I need to focus on.

Thanks again,

Nancy

 

[Nancy]

Jack,

Thanks for your quick response. That helps alot.

In developing the schedule, each functional expert (software, logistics,
engineering, etc.) provided a schedule for their respective activities
required to develop a given capability. Unfortunately, a cross-functional
evaluation was not conducted to determine what impact their individual
schedule would have on another functional area. Then all the individual
schedules were integrated into a master schedule. I know there are
disconnects, which is driving my need to validate the schedule.

I'm inclined to focus on activities that are on or near the critical path
and to make sure we have all the interdependencies and links to the critical
assets required to support test activities. However, I hoping someone can
tell me if there are other areas I need to focus on.

Thanks again,

Nancy

 

[Steve House [MVP]]

One problem I see with this approach is in the manner in which your schedule
is being determined. You have functional experts, the resources, telling
the project manager when they're going to work on their activities - you
said they "provide a schedule of their respective activities." This, to my
thinking is getting it backwards and relegating the project manager to the
role of a project documentor at best. To validate the schedule, you need to
insure it is aligned with the functional and strategic needs of the
organization as a whole, expressed through the plan as developed by the
project manager, approved by senior management, and then communicated to the
resources. You consult with the functional experts as you develop the plan,
most certainly, but the final plan is yours. The final decisions and the
authority to determine what is done, who will do it, and the timeframe for
when it must be done must lie with the project manager, NOT the functional
experts. This means, in a nutshell, the functional experts don't tell you
what they want to do when. Instead it's you, the one charged with the
responsibility of insuring the strategic goals of the organization are met -
in other words, the boss in the context of the project - who should be
telling tell THEM what THEY need to do in order to bring the project in
successfully. Oh, you phrase it tactfully and all that but the bottom line
is that the Project Manager has to take charge and instruct (okay, "advise")
the resources what they are supposed to be doing and when they're supposed
to be doing it and insure that there are processes in place, perhaps, to
correct situations where the required plan is not being followed (like they
get poor job performance reports and no raises).

Just my 2 cents ....

 

[JackD]

One problem I see with this approach is in the manner in which your schedule
is being determined. You have functional experts, the resources, telling
the project manager when they're going to work on their activities - you
said they "provide a schedule of their respective activities." This, to my
thinking is getting it backwards and relegating the project manager to the
role of a project documentor at best. To validate the schedule, you need to
insure it is aligned with the functional and strategic needs of the
organization as a whole, expressed through the plan as developed by the
project manager, approved by senior management, and then communicated to the
resources. You consult with the functional experts as you develop the plan,
most certainly, but the final plan is yours. The final decisions and the
authority to determine what is done, who will do it, and the timeframe for
when it must be done must lie with the project manager, NOT the functional
experts.

Where I am, responsibility for meeting the deliverables in the plan belongs
to the functional experts. They need to commit to the plan. They need to
believe the plan is workable. You can push from the top down, but only so
hard before people stop listening and start laughing.

This means, in a nutshell, the functional experts don't tell you
what they want to do when. Instead it's you, the one charged with the
responsibility of insuring the strategic goals of the organization are met -
in other words, the boss in the context of the project - who should be
telling tell THEM what THEY need to do in order to bring the project in
successfully. Oh, you phrase it tactfully and all that but the bottom line
is that the Project Manager has to take charge and instruct (okay, "advise")
the resources what they are supposed to be doing and when they're supposed
to be doing it and insure that there are processes in place, perhaps, to
correct situations where the required plan is not being followed (like they
get poor job performance reports and no raises).

Steve, there are many ways to run a project. I think you might consider
phrasing this in terms which are less absolute.

-Jack

 

[Steve House [MVP]]

You are absolutely correct that the functional experts should be intimately
involved in planning the project, no question about that, and I'm the last
one to advocate an authoritarian management style. But the only reason to
HAVE a project manager is to coordinate and channel the activities of a
disparate group of resources. If that wasn't needed and a project consisted
of a group of workers all just doing their own thing, all you'd have to do
is post a list of the organization''s goals in the employee lounge and let
everyone pick and choose what they want to work on or even if it was going
to be worked on.

Joe Schmoe may wish to twiddle his widgets during the first week in May and
considers that the most important thing on his plate. But the strategic
goals of the organization, completely unknown to Joe, say we'll be dropping
widgets completely from the product line in August and so any widget
twiddling between now and then is a waste of resources. Meanwhile, the new
product that replaces the widgets - cheese fids - is being developed and
Joe's talents are really needed on twiddling the fids that first week in
May. It's the project manager's job to insure he spend the first week in
May twiddling the fids and not the widgets (and he is doing it the first
week of May and not the last week of April or the second week of May).

"Managment" is the function of organizing and directing other people's
efforts in order to achieve specific objectives. I suggest that the Project
Manager, in coordination with the senior management s/he reports to, has the
ultimate responsibility for insuring that the right work is being done by
the right people at the right time and at the right cost to achieve the
organization's objectives. Otherwise s/he's not a manager at all but is
simply a clerk documenting what other people have decided to do.
--
Steve House [MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs

 

[Nancy]

Thanks Steve and JackD for your responses.

You've both highlighted some of the many challenges a project manager faces
in developing and managing master program schedules. Unfortunately, I was
handed this one and am attempting to validate what I have.

The optimum way that this should have been developed was to have the project
manager provide the strategic goals to the organization, including any
critical event-driven milestones that had to be met. Each functional
manager would then develop an initial schedule to meet the end
milestone/goal(s). Cross-functional support should be used in the
development of the initial schedule so that correct predecessor/successor
task links are included. Those individual schedules would then be
integrated together and a cross-functional review of the draft schedule
would be conducted to provide a "logic" check of the events. This would
include an assessment of the timespan of events that are on or near the
critical path, verifying predecessor/successor task links, ensuring resource
loading for critical activities, and assessing links to critical test assets
and deliverables (integration labs, test equipment, technical manuals,
training, etc.) to determine whether the schedule is sound enough to meet
strategic goals. The organization should also have a policy that any event
that runs for over a specific number of days (e.g. 60) has to be
automatically re-evaluated.

Once this assessment is completed, a summary level schedule would be
presented to senior management for their approval. Upon receipt of
approval, the project manager would be held accountable for the execution of
the schedule. How the PM holds the functional managers accountable is
organization dependent.

Having said that, the schedule I inherited was not developed this way, I
searching for suggestions for validating what I have. If we ultimately
determine through this validation that the schedule is incorrect, it could
adversely affect our program budget. Any recommendations on how to do this?

Thanks again, Nancy

 

[Steve House [MVP]]

Sounds like you're well aware of how a program SHOULD be designed and have
the problem of selling that to more senior managment that's more used to
seat-of-the-pants methods - not an enviable position. <smile>

Validation, in your case, seems like a process of taking what you have and
seeing if it's close enough to what it should be to be workable. I think an
approach to investigate would be to take the information you have on the
task breakdown, duration estimates and linkages, and resource availability
and create a new schedule as it should have been done. Meanwhile, enter the
schedule for those same tasks that you have been given into one of the
interim plan slots. Now you can easily customize views in the Gantt chart
to display the schedule as you developed it and the schedule as you
inherited it on the same view and go from there to compare the two.

 

[JackD]

You are absolutely correct that the functional experts should be intimately
involved in planning the project, no question about that, and I'm the last
one to advocate an authoritarian management style. But the only reason to
HAVE a project manager is to coordinate and channel the activities of a
disparate group of resources.

Actually, the part you are missing is that the project managers where I work
do not have resources who report to them.
Functional managers do. A project manager manages managers (sometimes termed
first-line managers). Sometimes they manage the manager's manager's
managers.

If that wasn't needed and a project consisted
of a group of workers all just doing their own thing, all you'd have to do
is post a list of the organization''s goals in the employee lounge and let
everyone pick and choose what they want to work on or even if it was going
to be worked on.

Strawman. If a project consisted of a pie eating contest...

Joe Schmoe may wish to twiddle his widgets during the first week in May and
considers that the most important thing on his plate. But the strategic
goals of the organization, completely unknown to Joe, say we'll be dropping
widgets completely from the product line in August and so any widget
twiddling between now and then is a waste of resources. Meanwhile, the new
product that replaces the widgets - cheese fids - is being developed and
Joe's talents are really needed on twiddling the fids that first week in
May. It's the project manager's job to insure he spend the first week in
May twiddling the fids and not the widgets (and he is doing it the first
week of May and not the last week of April or the second week of May).

No, the project manager probably doesn't even know Joe. He might know his
boss. It is highly unlikely that in a team of a few hundred people that the
project manager knows Joe. He might not even know Jack.

"Managment" is the function of organizing and directing other people's
efforts in order to achieve specific objectives. I suggest that the Project
Manager, in coordination with the senior management s/he reports to, has the
ultimate responsibility for insuring that the right work is being done by
the right people at the right time and at the right cost to achieve the
organization's objectives.

Sure, but they don't direct Joe's work. They might not even know what Joe
does or how he does it. They are incapable of planning or understanding the
details and it would be foolish for them to try.

Otherwise s/he's not a manager at all but is
simply a clerk documenting what other people have decided to do.

Steve,
There are a number of project management models. They are all valid in
different circumstances.
Just because the model described doesn't match your conception of what
project management is doesn't mean it is wrong.

-Jack

 

[JackD]

You situation is not so uncommon. If it were me I'd do the following:

1) meet with the functional experts and go over their sections of the
project. See if it makes sense and they can explain it. Then focus on any
dependencies they have with other groups. Document these. Put them in the
schedule.
2) Next, confirm that the person on the other side of the dependency agrees
with it in both scope and timeframe. Connect everything up and see what
results.
3) At this point it is worth getting together as a group to "scrub" the
schedule. Go over the basic assumptions to set the stage then start with the
critical path. First make sure everyone agrees that is the critical path.
Work to see if things can be sequenced to make things fit better or where
more resources could reduce the duration of the tasks. Don't stop until you
have agreement that the schedule is realistic.
4) If you're schedule is longer than desired do a little exploratory work to
determine how it could be reduced. Are there ways to shorten the schedule?
Are there trade-offs between scope or quality which would make sense?

It may turn out that you have a schedule problem. Certainly it is unpleasant
to report that fact, but it is more important to tell the truth.
And better to tell it now than after you have been working with it for a
while. This is your opportunity to state that you have been given a poorly
constructed and inaccurate schedule.

 

[Nancy]

Thanks again, Steve and Jack I really appreciate your recommendations on
this matter.

Because of the magnitude of tasks in the schedule and the urgency to get to
the "real answer" ASAP, it's more cost-effective to add the appropriate
detail to the current schedule than to create another one for comparison.
My original plan was in line with what Jack recommended. I just wanted to
make sure that I hadn't omitted some steps in my validation plan.

It doesn't really sound like there's a standard roadmap for validation. The
key appears to be open communications, documenting assumptions and
agreements made during the validation process and making sure the resulting
schedule supports strategic goals. I have absolutely no problem delivering
bad news if some major disconnect is found. I've already voiced my
reservations about the accuracy of the current schedule.

Thanks again for your valuable input. Our validation meeting is guaranteed
to be very interesting, challenging, and hopefully, very productive.

Nancy

 

[Steve House [MVP]]

I'd venture to say in most cases the PM won't have resources permanently
reporting to him. They may not even be temporarily transfered to be under
his control for the duration of the project, although they may be. He very
well may not even have the resource's managers, or anyone for that matter,
reporting to him. Some organizational specialists talk about "position
power" versus "political power." When someone exercises position power,
they are the boss and have the authority to directly mandate something be
done in a certain way. When one exercises political power OTOH, one
influences the outcome without having the direct position authority to
mandate it. But lack of direct position authority still doesn't mean that
the PM isn't the one that should be making the decisions about how the
resources are deployed. It only goes to the techniques he must use to get
those decisions implemented. It may well be that the pm "advises" senior
managment as to what the resources need to do and then the senior management
is the one with the authority to actually direct them to do it via the chain
of command. Buit in terms of what the resources end up doing, the end
result is the same regardless of whether the chain of command is one of the
direct exercise of authority or the result is achieved by the indirect
application of political influence.

You said

Sure, but they don't direct Joe's work. They might not even know what Joe
does or how he does it. They are incapable of planning or understanding
the
details and it would be foolish for them to try.

and you are absolutely correct. That is why I tell my students the most
important traits of a project manager include the ability to formulate
meaningful questions, the ability to seek out experts (including the
resources on the project) who have the answers, and the good sense to
actually listen to the answers they receive. But that doesn't negate the
fact that Harry Truman's sign "The buck stops here" should also be on their
desks. They shouldn't relinguish control to others who may have their own
agendas that run counter to the project's objectives. Seek out the best
advice one can find, but always be the one to decide whether to take it or
not.

My point is I can't imagine a PM being able to do the job without taking a
proactive approach to the structure of the work. The methods that one uses
to influence the outcome might take many different forms depending on the
nature of the organization. But the one thing that will be common to all
(successful) projects is the PM's understanding that he is tasked to be the
composer of the symphony and the conductor of the orchestra performing it
and not merely a sound engineer recording the performance.
--
Steve House [MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs