Re: Lag / Lead Time

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance

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





.

Quantcast