Rob
Thu Oct 28 00:20:17 CDT 2004
No debate needed. Steve and Dale have given you the "right" answers.
Focus your energy on getting your boss re-orientated and re-trained.
lamby74 wrote:
> Thanks Steve. You and Dale both gave really thoughtful (and time-consuming,
> I am sure, ) answers. I am carefully studying both of your responses and
> will be showing them to my boss shortly. I'll let you know how it all turns
> out.
> In the meantime, I welcome more opinions. The more upfront and honest (even
> if hard-edged) the better.
>
> Thanks all.
>
> "Steve House [MVP]" wrote:
>
>
>>I'm not sure on the task splitting you're getting because I don't have
>>specific information to work with but some general considerations.
>>
>>No offense intended but IMO you DON'T know what the timeline is. What you
>>know is what you HOPE the timeline might be, wishful thinking without basis
>>in fact. If Project is telling you something different from what you
>>expect, Project's version is more likely to be a valid predictor of what's
>>going to happen when you go out and try to have resources actually do the
>>work.
>>
>>The fundamental problem seems to be that your boss wants to tell Project
>>what the timeline will be. That's getting it backwards, IMHO. Project's
>>fundamental job is to tell HIM what timeline he can reasonably expect to
>>achieve given what needs to be done, the amount of work each part of it will
>>take, and the assets he has at his disposal to do it. He doesn't tell
>>Project the timeline; Project tells HIM the timeline that will result from
>>what he has input as the tasks and resources. If its results don't make him
>>happy, he can't just kludge it to make it look better by,say, turning off
>>recalculation, he actually has to change the input - change the project
>>scope, obtain more resources, find ways to work more efficiently, look for
>>sequenced tasks that could be done in parallel, etc. If he chooses not to
>>pay attention, he's trying to force a square peg down a round hole and it's
>>very likely the project will fail.
>>
>>W=D*E is not an approximation or a watered-down generality, that is exactly
>>how Project calculates in every single instance. No exceptions. The task
>>type influences it in the sense that any linear equation has an independent
>>variable, a dependent variable, and a constant. We have a task estimated at
>>5 day and assign someone to it who works 8 hours per day giving 100% of
>>their attention to it. That means the work required to create that task's
>>deliverable is 40 man-hours. Now I'm going to change something. What
>>factors in my equation are the variables and what factor is the constant?
>>If it's constant work, I can change the duration and have project calculate
>>the percentage or change the percentage and have project recalculate the
>>duration. In most cases I think that is the appropriate setting because work
>>usually takes what it's going to take and there's not a lot of control you
>>have over it. If it usually takes me a month to write a program module
>>it's not likely I can do one in 2 weeks just because someone says I have to,
>>at least not and maintain quality. Or I can choose to hold the duration
>>constant or hold the percentage constant. What determines the setting? My
>>understanding of the nature of the work and the resources assigned to it.
>>
>>If your boss has set up a timeline and it gets scrambled when you assign
>>resources, that is telling you something valuable. What it is telling you
>>is that when you have your resources work according to the way you want to
>>assign them, that timeline is unrealistic. Project is telling him what he
>>will GET, not just parroting what he wants. If what it calculates after
>>assigning resources is not what he wants the project to be and the model is
>>otherwise valid with regard to links etc, he has to do one of two things -
>>either change his expectations or re-think the resource assignments. (You
>>might show him this message so he doesn't blame you for the bad news
>><grin>.) If he is unwilling to do either, IT IS VERY LIKELY THE PROJECT
>>WILL FAIL!!!! The reason Project does what it does is to alert you to that
>>fact early enough to have a chance of doing something to prevent it.
>>
>>Work can only takes place when resources are there, available to work, and
>>not otherwise committed to other conflicting tasks. That seems obvious but
>>it is a point often overlooked by eager bosses. If Bill is scheduled to be
>>on holiday Monday and he is assigned to a task currently scheduled for
>>Monday, the task must move to Tuesday so its schedule changes to conform to
>>when he is going to be there. Non-working time is not scheduled around the
>>task requirements unless you do it manually, editing the resource calendar
>>to move nonworking time that is causing tasks to shift unacceptably to days
>>that work better for you; tasks are scheduled around resource non-working
>>time as defined by the calendar. Secondly, resources cannot be in 2 places
>>at once. If I have task A on Monday and also task B and I assign Bill to
>>both of them and expect him to devote 100% attention to each, he simply
>>cannot do it. The assignment percentage defines how much work out we get
>>for each hour of time put in and while we might get less than the maximum we
>>can never get more. In one hour of duration it is physically impossible for
>>one person to generate more than one man-hour's worth of work output. If
>>the person is scheduled for 100% on Task A for Monday and also scheduled
>>100% for Task B, also on Monday, it is impossible for that to be worked as
>>planned. You might publish such a schedule but when the time comes to do
>>the work, he WILL be late for one or both of the tasks, guaranteed! That's
>>what Project is trying to tell your boss only he doesn't seem to want to
>>hear it. So how does Project resolve the situation? It moves one of those
>>tasks to Tuesday (assuming the resource is free) when you trigger leveling.
>>Your original schedule asked for 16 man-hours of work from one person during
>>an 8 hour duration, an impossibility - the new one calls for 16 man-hours of
>>work to be produced during a 16 hour duration period, something that *is*
>>possible for one person to do. Another option is to edit the resource
>>assignment level so he's working 50% on each task, thus extending the ending
>>of both of them from Monday to the end of the day Tuesday, again resulting
>>in 16 total man-hours of work being done in a 16 hour time period. A third
>>option is to take the guy off of one of the tasks and find someone else who
>>is presently idle to pick it up. Or finally just not do one of the tasks
>>altogether, drop it completely from the plan, if you can get away with it.
>>Anything else, the project will fall behind no matter what your timeline
>>says.
>>
>>You *can* be in complete control of the timeline but you can't just
>>arbitrarily pull time frames out of thin air and expect them to happen. As
>>I've said in other posts, the command "Number One, make it so!" only works
>>in the Star Trek movies. For the real world those timelines are driven by
>>physical processes, not executive fiat, and to control the timeframe you
>>must manipulate the factors behind it that actually affect it. If I have to
>>assemble 100 widgets, one person can do a maximum of 10 a day, I only have
>>one assembler on the payroll, and my budget won't allow overtime, it will
>>take at least 10 days no matter whether you like it or not. If I need it in
>>5 to meet a contract deadline, my only options are to get a second assembler
>>somewhere or spend the money for overtime. Just plucking a mandate out of
>>thin air and declaring that I'll have the guy do 20 a day just simply won't
>>work.
>>
>>Hope this helps ...
>>--
>>Steve House [MVP]
>>MS Project Trainer/Consultant
>>Visit
http://www.mvps.org/project/faqs.htm for the FAQs
>>
>>
>>
>>"lamby74" <lamby74@discussions.microsoft.com> wrote in message
>>news:5C074B91-5E06-4C88-AF84-50529B176728@microsoft.com...
>>
>>>an addendum to my initial post....
>>>my boss wants to be able to show that recources are assigned to tasks, but
>>>have us be in complete control of the overall timeline.
>>>He is frustrated because he can set up an initial timeline and get really
>>>neat looking reports, but that once we "throw resources at it" MSP, OR
>>>make
>>>any changes at all to anything after that initial set up, MSP behaves
>>>unpredictable and messes up our timeline. He is confident in the
>>>software
>>>only from the DAY 1 set up.
>>>
>>>From there on out, it appears to him to be a black hole of unanswered
>>>questions, illogical inconsistencies, and rogue-ish behavior. I can tell
>>>him
>>>generalities why MSP did what it did, ie "MSP split task a because we
>>>selected the splitting option, automatic scheduling is on, and because we
>>>have Bob assigned to Task B which runs concurrently, yadda, yadda....., so
>>>he
>>>is overallocated...", but he wants a deeper explanation than that.
>>>
>>>We KNOW what our timeline is already...we don't want MSP to tell us. We
>>>just want it for the "pretty" reporting.
>>>Give to to me straight all....maybe MSP is the completely WRONG software
>>>for
>>>us to be using.
>>>
>>>The best I could hope out of this post is for someone to tell me HOW to
>>>completely and RELIABLY and with 100% predictability to TURN OFF MSP's
>>>scheduling engine.
>>>
>>>"lamby74" wrote:
>>>
>>>
>>>>My boss has charged me with the task of:
>>>>being able to:
>>>>
>>>>1)get back to a reliable schedule if we get off-track (meaning when
>>>>Project
>>>>"messes up" our original timeline - which he wants FROZEN in time no
>>>>matter
>>>>what resources we throw at it)
>>>>2)PREDICT with 100% accuracy what will happen in Project with every
>>>>button
>>>>click.
>>>>3) EXPLAIN why Project behaves the way it does.
>>>>4) explain HOW does it calculate???
>>>>
>>>>I am afraid that in the end I will have to tell him I can't completely do
>>>>this and my rear will be in a sling (and then my kids won't eat, the
>>>>mortgage
>>>>will fall behind, etc, etc).
>>>>
>>>>My hypothesis to #1 was that by going to
>>>>Tool-Options-Calculation-Manual-and Click the Calculate button this would
>>>>un-do any shifts in our timeline (in Gantt view). however on testing
>>>>this
>>>>hypothesis for consistency, I think this is not correct.(???)
>>>>
>>>>My answer to #2, #3, and #4, I think, will be this:
>>>>
>>>>I can predict in general what it will do, but that's it. I "get it" that
>>>>it
>>>>calculates on w = d*u (why beat a dead horse? LOL!). But how can I
>>>>predict
>>>>every time what it will do? I mean it all depends on how a task is set
>>>>up
>>>>(task type), effot-driven vs. non-effort driven, what are it's
>>>>pred/successors, what are its resources, are those resources assigned to
>>>>its
>>>>pred/successors.
>>>>I mean mathematically, I can't explain WHY (For Example...)it moved
>>>>Resource
>>>>Person #1 from working 8 hours on a task today the 27th all the way over
>>>>to
>>>>working on that task for .2 hours on Wednesday Oct 30. and so on....
>>>>
>>>>Am I right? Is there a way to predict with mathematical certainty what
>>>>it
>>>>will do based not only on inputs of w or d or u, but also of the rest of
>>>>the
>>>>schedule that we all KNOW are also a part of this calculation. I mean
>>>>w=d*u
>>>>is a completely watered-down explanation of HOW project schedules,
>>>>correct?
>>>>
>>>>Am I correct to when I say that I think my boss may be asking for the
>>>>impossible?
>>>>I really need your input, everyone. I am desperate. My boss wants
>>>>bottom-line answers and I think because of the very nature of MS project,
>>>>that I can't give him bottom-line answers. Am I right about this?
>>
>>
>>