Re: Lag / Lead Time

Of course it doesn't make sense to have it in the plan for any date other than 02 Sept. But the dates that items in a plan will be able to happen are driven by predecessor relationships and resource availability. The ONLY way you can present your plan to the board on 02 Sept is if all the things that go into preparing the presentation are ready by that date. You can't just declare it so and expect all the predecessors to automatically fall into place. The way I see Project most effectively used in the planning process is through a series of iterations ... "If I order the slides from the graphics artists on Tuesday, what date will that let me deliver the presentation? How about Thursday? Could I hold off ordering until the 20th? What about the 22nd?" Each trial gives me a forecast "ready to deliver" date and I keep trying different options and workflow organizations until I get the one that lands "Deliver to Board" on 02 Sept. What's crucial to me is the answer to the question "if I order the slides on the 20th, will that let me be ready in time and if not, what date would that have put it on?" I don't know that yet - I have to plug the data into Project and let it freely calculate the "deliver" date so I can find out if my idea of a plan will work or not. If it doesn't, it's back to the drawing board. You don't HAVE a plan until all the computed dates are meeting their "must hit" dates. The rough draft is not the plan - locking tasks to fixed dates with constraints while trying various interim plans prevents you from seeing if things get better or worse on the next iteration. Similarly, locking tasks down with constraints in the final plan prevents you from seeing how actual performance deviating from planned performance is going to negatively impact your "must hit" dates once you start tracking actual progress. If they're constrained MSO, MFO, or MFNLT, they'll always show as being on time no matter what happens with their predecessors. If Joe comes to me and says the graphics won't be ready until the 25th, I want to see on the Gantt chart that his delay to the 25th means the presentation won't be ready to deliver until 15 Sept! That's why I'm using the computer - to tell me exactly that fact. If the "presentation" task is constrained to 02 Sept, that's the date it shows occuring REGARDLESS of what Joe says will be delivery date for the graphics, hardly an effective early warning system of impending trouble. A deadline (instead of a constraint) of 02 Sept tells me, on the other hand, it has to occur the 2nd but with Joe's delay it can't occur until the 15th, so I better figure out a plan B for getting those graphics - okay, if I send him a helper what will that do to the forecast "ready to deliver" date? - or start rewriting my presentation now so I don't need 'em.

As I've said before, IMHO the project plan is not just a calendar to record the dates that you do know - all you need is a file-o-fax or Outlook to do that. It is more of a tool to help you predict the dates that you DON'T know.
--
Steve House [Project MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs



"Jan De Messemaeker" <jandemes at prom hyphen ade dot be> wrote in message news:%23OhXmgA3HHA.1164@xxxxxxxxxxxxxxxxxxxxxxx
Hi,

Two details here.
Scanning for negative slack is extremely simple (make a filter or simply use the auto filter)
And a project manager is not the top of the world. If you have to present your project to the board of directors on September 2nd f.i., it doesn't make sense to plan that activity on September 7 (nor on August 30, for that matter), whatever the other tasks may say: an appointment is an appointment, you shouldn't pin any other date on it, that is fooling yourself.

--
Jan De Messemaeker
Microsoft Project MVP
http://users.online.be/prom-ade
"Steve House" <sjhouse at hotmail dot com> wrote in message news:eCZmZ3$2HHA.1164@xxxxxxxxxxxxxxxxxxxxxxx
Yes, of course commitment is commitment. But have things unforeseen never caused you to miss a commitment you have made, for instance, ever made payment a day or so late? Project's displayed dates are not, IMHO, intended to document the commitments that have been made. IMHO, the reason to use software instead of just a pencil and paper to-do list is to create a "What If" analytic tool to predict whether the commitments that have been made will actually be achieved and if not, how late (or early, for that matter) they will be. It is first and foremost a forecasting tool and for it to take performance to date and from that forecast when future Task X will be able to take place, you can't prevent the task's free movement by constraining it. To do so is exactly as if you created a "What If" profit optimization model in Excel and somehow managed to constrain it so that it would never go negative to show that some pricing structures would result in a loss. Let's see, we should not exceed a total of 10 ... 5+3=8, 5+4=9, 5+5=10, 5+6=10, 5+7=10, 5+8=10 ... that's exactly what a constraint (in this case a FNLT) does in a project's schedule model and the forecast of achievable project progress one obtains in such as case is just a fallacious as is my arithmetic here. As long as the forecast is acceptable the calculations are correct. But as soon as you get into trouble, and predicting trouble is the only reason to bother with the exercise in the first place, it no longer works. It fails you in what you need it most to do, keeping you out of trouble. Using a MSO or MSNLT or MFNLT to indicate an agreed upon start or delivery date means your plan will never warn you if that commitment is not going to be met, it always will promise on-time performance.

I know you like to use the numerical slack values and look for negative slack but frankly, scanning down a column of numbers to find those slacks that don't look right would drive me nuts. Give me a model showing me where things are predicted to end up if we keep on our present course along with nice red flags if the predicted result are not where it ought to be. But show me what I'm GOING to get unless I change direction instead of what I OUGHT to get. I know where I ought to be, I'm using the software to find out if I'm going to make it or not and if not, to figure out what I can do about it. To do that, it must show me the results that would be obtained for each option I might consider.
--
Steve House [Project MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs


"Jan De Messemaeker" <janremovethis@xxxxxxxxxxx> wrote in message news:e48q9M%232HHA.1204@xxxxxxxxxxxxxxxxxxxxxxx
Hi,

Wow, what a reaction.
Prioritisation is not only a mùatter of dates, I mostly use Total Slack to determine priorities.
And when on a futuire intervention of a subcontractor I have a SNET constraint, Project won't alert me if I'm getti,ng late on tasks leading up to that intervention.
To the contrary when I set an MSO constraint, slack in the tasks leading up to it will alert me correctly if I slip on these tasks.
So then Project predicts success based on what I have to do right now!

When any action is agreed upon solemnly between parties, it becomes MSO. Commitment is commitment.
Greetings,

--
Jan De Messemaeker
Microsoft Project Most Valuable Professional
+32 495 300 620
For availability check:
http://users.online.be/prom-ade/Calendar.pdf
"Steve House" <sjhouse at hotmail dot com> wrote in message news:eFDfoa52HHA.484@xxxxxxxxxxxxxxxxxxxxxxx
Organizational psychologists often describe positions within a hierarchy in terms of the holder having a mix of position power and personal power. The CEO's administrative assistant may have little official authority within the corporate hierarchy but none the less he or she exerts tremendous influence, they hold the keys to the throne, and as such exercises tremendous personal power.

Certainly it can be true, as you say, that the PM may have relatively little position power in the sense of being able to mandate the performance of resources. But even so, he is the sole individual charged with the ultimate responsibility for fulfilling the portion of the organization's strategic plan the project represents. Like the captain of naval ship acting on orders from the admiral, the PM is the management person responsible for *making sure* the project is completed in the most efficient manner. The buck stops with him and it's his *** that gets fired if it doesn't happen. So if they don't have the position power to mandate the performance from resources that will make it so, they have to call on personal power - negotiation skills, argument, calling in favours, astute application of

political relationships, etc - to make it sure it happens the way they have determined it MUST happen for the project to be a success. The project manager is not, in my opinion, a beaurocrat monitoring the performance of resources who might suggest that they behave and prioritize in a certain way. Rather he is the one that determines what the plan *will be* and then does whatever it takes to insure that people follow it - He, not the resources and not the resource's managers, is the one who organizes the project. While he might have to be very indirect and political about how he achieves it, the bottom line is it's still his job to tell the resources what to do and when it has to be done and regardless of exactly how he goes about it, he needs to keep clear in his own mind that that is his bottom line responsibility and no one else's. The PM is the one who determines what must happen and when it must happen in order to bring the project to a successful conclusion and then exercises both position power, if he has it, and personal power if he does not, to make certain that it happens in that manner, just like the captain of the ship always has the final decision as to its course even if he sometimes listens to the suggestions of the helmsman.

I don't know why you say a MSO constraint warns you if a negotiated start date isn't going to be met - it does exactly the opposite and tells Project to always show that the start will occur as required regardless of what's going on before it! It doesn't give you a warning at all, on the contrary it lies and shows all is well and starting on time even when it's definitely NOT well. (It would be nice to have the option of applying start deadlines as well as finish deadlines, though.)

I oppose the use of MSO, MFO, and MFNLT constraints because of the way they cripple the Project scheduling engine. It boils down to why I think one bothers to use scheduling software in the first place. I already know what the requirements are and I don't need to document them again. My task, once I sit down to plan, the task for which I'm using software in the first place, is to figure out just how I have to organize the work so those requirements are met. To do that, the software must show me the consequences of my decisions - will deploying the resources in such and such a manner lead to success or failure? Applying a fixed date constraint to a task, that means that no matter what else is happening in the schedule, Project will NEVER, under any circumstance (unless one disables "tasks always obey their constraints" in which case why bother with the constraint in the first place?), show it happening on any other than the specified date. Nothing can make it move. So the existence of the constraints means Project will not predict success or failure as it should - instead it always promises success. While indeed it may be imperative within the mandate you've been given that they not be allowed to move, that doesn't mean that reality won't intrude - unless you organize it right, tasks fail to meet deadlines all the time (unfortunately). A requirement doesn't mean it's impossible for it to move, only that it ought not move, and we all know of situations where requirements are not met. I suggest that the primary purpose of project software having a dynamic schedule calculation engine is NOT to document the requirements, it's rather to give you a tool to predict whether the plan as you have organized it is going to achieve those requirements. Its job is to predict success or failure given a proposed workflow and resource loading. Fixed dates in the plan mean that you're using the software as little more than a fancy hi-tech version of a wall calendar with a big red circle drawn around critical deadlines - forcing the schedule to always lock those tasks to the designated dates means you have crippled its ability to predict whether your workflow is actually going to achieve them. It always promises your plan will be successful even when its physically impossible for it to actually happen that way because it never shows your tasks moving away from the dates where they ought to occur.
--
Steve House [Project MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs

----------------------------------------------

"Jan De Messemaeker" <jandemes at prom hyphen ade dot be> wrote in message news:ORCJUv32HHA.2752@xxxxxxxxxxxxxxxxxxxxxxx
Hi Steve,

I'm afraid I already wrote this, but are you aware that your image of project management represents IMHO only a minority of projects?
Most organisations I know run projects in a matrix structure, such that project leaders have no (like in ZERO, NONE) hierarchic power over those who perform.
An important part of their job is to negotiate with (internal or external) subcontractors about when they will perform, or even just when they intend to deliver. That is not what I call "calling the shots".
This doesn't render the usage of MS Project less important, only different.
For instance once they have agreed with a subcontractor they may well use a Must Start On constraint, for instance to be warned by Project when a task leading up to the subcon's agreed date may jeopardize that agreement.
Management in such cases is done far more based on duration and constraints, and it is typical for that project orhganisation and management.

And BTW, I guess 7,2 hrs of work is just an estimate for 1 day, but as Project's default for Work is in hours, people may call it that way.

Greetings,

--
Jan De Messemaeker
Microsoft Project MVP
http://users.online.be/prom-ade
"Steve House" <sjhouse at hotmail dot com> wrote in message news:%23Nr6nm12HHA.3400@xxxxxxxxxxxxxxxxxxxxxxx
Just a point to ponder ... if the work only requires 7.2 hours of actual
work (how do you estimate work that precisely, anyway? That's 3% accuracy!)
why are you letting the resource have 10 times that length of time it which
to do it? As PM you should be calling the shots - go to that resource at
tell them "It looks like everything will be ready for you to start that task
Tuesday afternoon or first thing Wednesday morning so can I count on you
having it finished by the end of the day Wednesday?" Now it could be that
there are other things on the resource's plate that mean it'll take him
longer and of course consult with him so as to take that into account, but
my suggestion is to stop thinking in terms of windows of opportunity and
instead focus on how soon you can get your resources to finish the work. As
Larry the Cable Guy says, "Just git 'er done."
--
Steve House [Project MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs


"JR Winder" <jwinder@xxxxxxxxxxxxxx> wrote in message
news:epBxWUe2HHA.140@xxxxxxxxxxxxxxxxxxxxxxx
I have a task (A) that will require 7.2 hours of work but is not estimated
to finish for 10 days. Another task (B) has a FS link to task A.

My questions pertains to the best way to account for the estimated 10 days
it will require task A to complete.

Should task B have a FS+10 days lag time? Or am I better off putting a
constraint type of "Finish No Later Than" on task A.

Right now I have task B linked to A with a FS+10 Days, What prompted my
question is that task A is scheduled to start on 8/10/07 and end on
8/11/07 (7.2hrs), when in reality it isn't estimated to end until 8/24/07.

Thanks in advance for your assistance.

JR








.