Re: Leveling problem

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

I sympathize! I've had the same problems with some of our people. If only it
was legal to use a baseball bat to "motivate" certain individuals into
actually entering information into their timesheets... PWA made this so
easy, there is no excuse for not completing timesheets, but still some
"highly educated" people are unable to do this "menial" task.

Other than being sarcastic, this best solution I have found is education and
training - but that doesn't come cheap. However this is a classic analogy to
cost of quality versus the cost of non-conformance. You have the upfront
cost versus the backend over run costs...

The feeding the beast problem has existed since the first database was
created. Sales organization (ours at least) struggle with maintaining the
their CRM systems. The question is why? Answer - because they are not used
as part of the core work process (hence my orginal statement). If you use
such system as part of your hourly/daily work process, the beast is fed as a
by-product of just doing your job. Bill Gates actually does a great job of
explaining this in his Business @ the speed of light book.

Then I make as much information as I can available to those who feed the
animal so they can see why I want it. If you fail to close the feedback
loop, then there is little understanding of the value the informaiton
provides.

I laughed when I saw your "how long" - "As long as it takes". Can remmber
how many times I've heard that.

Simon



"John Sitka" <johnsitka@xxxxxxxxxxxxxxxxx> wrote in message
news:OCRK3Gk1FHA.3560@xxxxxxxxxxxxxxxxxxxxxxx
> No worries, In practice though, it is always a little harder than writing
> about it.
>
> I did a pretty intensive investigation of other planning/scheduling
> software
> packages, mostly in terms of how they fundamentally differed from Project.
>
> What I came up with was that no matter what you use you have to "feed the
> beast"
> My best visualization of this was within the walls of the Enterprise the
> scheduler could
> hire a staff of folks to run around, hand out to-do lists then routinely
> revisit each
> resource and 'Ask, are you done yet?' Then sit at a bunch of Project
> terminals and
> do data entry constantly. In contrast distributed shared/load data entry
> is twice as efficient
> and I'd guess about 3 times as valuable. So the "staff with the
> clipboards" idea was out; BUT
> the beast still needs to be fed.
>
> If you think the scope of getting a few skilled people running project
> and training others to use PWA is big. I think it is X10 to integrate a
> Full ERP backed schedule/tracked to-do list
> because the whole company needs massive discipline for that. For example,
> exploitation of Job routings, barcode
> scanners, installation of client applications.
> But we have a skilled environment with PC's always within reach, a huge
> active Intanet so folks know how to
> enter web data, Project Server provided that "most" important piece "the
> feeding of the beast" via the web
> at the lowest cost of all the systems I looked at.
> Most of the rest of the needs can be derived or represented in some way or
> another, some clunky, some pure.
> But they are often a little difficult to explain at first because eveyone
> has a lifetime of "Gantt chart"
> scheduling paradigm at their disposal,
>
> 1.) Putting dates down on paper as a declarative contract rather than
> having them dynamically calculated for them.
> 2.) Never getting smiles and agreement from their peers when responding to
> "How long?"
> with
> "As long as it takes"
> 3.) Giving false estimates based on a legacy of mutlitasking experience
> not on what their actual
> performance or capacity is.
>
> An olympic athelete, dosen't stop half way around the track to answer his
> cell phone,
> A painter walks miles down the seashore to be alone and away from
> distraction to create
> something beautiful
>
> But we go to work and we present ourselves
> 1.) as juggling a thousand different things as a sign of being busy.
> 2.) make bold claims about what you "will" accomplish even though you have
> no way of
> seeing the whole picture, and that external influences that will fall upon
> you just a few short hours from now.
> 3.) measure success with false accountant metrics
> 4.) back lean and efficency objectives to the point where a distinct lack
> of excess capacity sends costly shock waves
> through the whole system when a mouse craps on the line.
>
> Simon Dullingham" <Simon.Dullingham@xxxxxxxxxxxxx> wrote in message
> news:eXdLBge1FHA.1028@xxxxxxxxxxxxxxxxxxxxxxx
>> John,
>>
>> I just wanted to express some thanks for the response - your points were
>> well made.
>>
>> What I think was of most use:
>>
>> Breaking longer term tasks into smaller chunks - QC/month, Project
>> management/month, Data Management/Month and basically assigned at the end
>> of the month. When the month is complete, zero what is left and move onto
>> the next month. If zero has been booked, then start asking why no QC
>> activities have been expended. This gives much better oversight in the
>> usage of overhead-type activities.
>>
>> Agree on the splitting of tasks - even why I have gotten the leveling to
>> do what I want, I have always allowed tasks to be split. This then
>> creates the time to do the data management block, etc.
>>
>> I think the filter on the overhead tasks is a good idea - ignore Metrics
>> on these activities.
>>
>> I'm eager to see what Project 12 brings to the table. Project Server was
>> a big step forward, and if MSFT has been listening, then 12 should be
>> just a big, if not bigger.
>>
>> Simon
>>
>>
>> "John Sitka" <johnsitka@xxxxxxxxxxxxxxxxx> wrote in message
>> news:uedG%23oN1FHA.3188@xxxxxxxxxxxxxxxxxxxxxxx
>>> Some key points here
>>>
>>> ->16 hours of data management is going to occur over this 4 week period,
>>> but I'm not sure when.
>>>
>>> Put it at the end of the 4 week period. If you are not sure when, then
>>> you also do not care when.
>>> And even more importantly, you do not know that data management must be
>>> completed before any other
>>> task.
>>> See the abstraction in the logical model here. You know that at some
>>> point somewhere along the 4 weeks
>>> some data management will get done. Where exactly segments (divide it
>>> into as many imaginary bits as you want)
>>> of that task are going to occur, you don't know, so just accept that you
>>> do not know this, and leave it at the
>>> resources discretion when to do data management. But require them to
>>> record actuals when they do that work.
>>> The reason here is obvious. Say you have a project due tomorrow but the
>>> final task is datamanagement and there
>>> is 24 hours left on it. that's 3 days. Your resource says Oops, I did
>>> that along the way over the last 4 weeks,
>>> sorry I didn't update it.
>>>
>>> The reality is the first day right out of the gate your resource DOES DO
>>> some datamanagement.
>>> There is nothing preventing him/her from recording actuals against this
>>> task. No matter how far in the future it is scheduled.
>>> You can even train them to give you their best estimate of remaining
>>> data management say half way through the project,
>>> or everyday which is best or better best is when one of the three
>>> tracking rules kicks in.
>>>
>>> On task completeion
>>> On task change
>>> On end of shift
>>>
>>> Then you can see that their latest estimate combined with their other
>>> work load will result in an unfavourable
>>> delay in project completion. And you get up to date budget cost stuff.
>>> But please always try and differentiate the dynamic
>>> piloting and traking in Project server from the reporting/auditing
>>> aspects of what you want from the product. It's almost like
>>> you need to think differently about the two parts. Estimates vs actuals
>>> will always fall out of the act of planning vs tracking
>>> and that is all you need.
>>>
>>> Ok so what if you have continuous projects of indefinite duration and an
>>> unknown net quantity of work. A running project or a manufacturing
>>> type situation. Well again apply the concept of abstracting tasks into
>>> logical discrete units. Ever 4 weeks plan a task of 16 hours
>>> datamanagement.
>>> at the end of a four week cycle. As time moves on the PWA resource will
>>> see a persistant data task at the top of their sheet that is overdue if
>>> they did
>>> zero datamanagement. Tell them that it is their job to evaluate that
>>> task as being within the "time chunk" of applicability.
>>> If it is no longer a slot that serves any practical purpose because we
>>> have moved on to the next chunk.
>>> Drive the remaining work to zero and record data management on the next
>>> one that will appear somewhere down the task list.
>>>
>>> Ok, convinced of the importance of understanding what an abstracted idea
>>> of a task can do for you, Now about this putting the task at the end of
>>> a project
>>> business. Well it works because you are going to allow task splitting..
>>> Where does the actual work recorded against the data task end up after
>>> you update the status,
>>> there are various options for how to handle it. move it back to status
>>> date, etc. the dreaded calculation options.
>>>
>>> The only hurdle you have is the PWA user has to have knowledge that
>>> these rouge ongoing tasks, part of what they do for a living are their
>>> responsibility
>>> to seek out and record against. It's a simple pattern, not difficult to
>>> figure out.
>>> That kind of addresses your point . 1) PWA is going to tell resource X
>>> to spend 3 hours on this task on a specific day. Edumacation, routine
>>> and disciple.
>>> They have to be in there somewhere
>>>
>>> Not to be too harsh with point 2) and 3), ..... but "yeah so".........
>>>
>>> change the stop lights and or filter out the ongoing type tasks.
>>>
>>>
>>>>However, Project Server changed all that that. Now we have a tool that
>>>>can be a fundemental part of the work process.
>>>
>>> Yes indeed but not everyone sees it as profoundly as that. I think it is
>>> the most meaningful thing Project brings to the table.
>>> Microsoft themselves might have missed the significance when they did
>>> not include an level of resource ownship at the reporting level.
>>> That is, I will report on behalf of other resources as their agent. One
>>> would think that limits they came up against were desktop to enterprise
>>> convesion
>>> ones and datamodel issues. But after reading the documents, scenerios
>>> there isn't even a hint that the concept was even thought of. To bad, it
>>> is crucial.
>>>
>>>
>>>
>>>
>>> "Simon Dullingham" <Simon.Dullingham@xxxxxxxxxxxxx> wrote in message
>>> news:u6lQOLM1FHA.2212@xxxxxxxxxxxxxxxxxxxxxxx
>>> Jan,
>>>
>>> I understand that assigning 10% to a task like "data management" may be
>>> causing the problem. In reality (and we use Project with Project Server
>>> and timesheets are completed on a daily basis ), I'm not interested in
>>> assigning 0.5 of an hour per day on data management. In practice, I want
>>> to have a budget of 2.5 hours/week and in truth, I don't really care
>>> when it is done during that week. Using the example, what I am trying to
>>> plan is that 16 hours of data management is going to occur over this 4
>>> week period, but I'm not sure when.
>>>
>>> If I move away from my simplistic example and to the real world, we have
>>> a number of overhead tasks on projects - one being the Project Manager
>>> himself, and another being QA, etc. I've always scheduled these as fixed
>>> duration tasks with a low assignment rate. For example, I might have 120
>>> hours of project Management on a twelve month project, 150 hours of QA.
>>> These are continuous, on-going tasks which need to be correctly budgeted
>>> and scheduled.
>>>
>>> But if I follow what you are saying, this is probably a really bad way
>>> of doing it - from a budget management and schedule management
>>> perspective. What I really want to do is to say "Resource X can spend 3
>>> hours this week on this task".
>>>
>>> Any suggestions on how this is best implemented?
>>>
>>> One thought is that I set up these types of activities as recurring
>>> tasks - i.e. a weekly task of say three hours. But this has downsides.
>>> 1) PWA is going to tell resource X to spend 3 hours on this task on a
>>> specific day. 2) If he doesn't do it, my stop-lights are going to go
>>> yellow/red everywhere, and 3) we use SPI as a Metric which may result in
>>> incorrect escallation of delayed tasks.
>>>
>>> I guess what I am saying is that historically, tools like MS Project
>>> were primarliy planning tools. Once the project went live, the effort
>>> required to keep a schedule "live" was so huge, many did not do it.
>>> However, Project Server changed all that. Now we have a tool that can be
>>> a fundemental part of the work process. If I have to fudge things, then
>>> I lose the ability to generate "exceptions" that are meaningful. I think
>>> that counts as going off on a tangent...
>>>
>>> Regards,
>>> Simon
>>>
>>>
>>> "Jan De Messemaeker" <jandemes at prom hyphen ade dot be> wrote in
>>> message news:eYuSSQI1FHA.4064@xxxxxxxxxxxxxxxxxxxxxxx
>>> Hi,
>>>
>>> Let me answer the why.
>>> Project assumes that you know what you ask for when you ask for 10% of
>>> the resource for the small task.
>>> It will never change that.
>>> And that you know what you want when you ask for 100% on an other task.
>>> It will never change that.
>>> For all Project knows that resource may be a machine that you cannot use
>>> at 90%.
>>>
>>> So the two tasks cannot run in parallel because that yields an
>>> overallocation.
>>>
>>> In anothe rpost you say I hesitate to assign 90% to the other task
>>> because than I am leveling by hand and not by Project.
>>> You are absolutely right, and I am glad somebody made that remark, it is
>>> the reason for 99% of the compaints on leveling not working properly.
>>>
>>> Thre problem is "you started the war" when you defined the small task as
>>> being done buy somebody at 10%. That as such is already leveling by
>>> hand, and your chances of having a properly leveled result have gone.
>>>
>>> If you want the best results for lmeveling DON'T use percentages.
>>> When people work they are supposed to word at 100% of their brain.
>>>
>>> Introduce "many slmal interventions" as many small taks (maybe a
>>> recurring task) with 100% allocation, in othe rwords don't start leveing
>>> by hand.
>>> Leveling will work nicely.
>>>
>>> Hope this helps,
>>>
>>>
>>> --
>>> Jan De Messemaeker
>>> Microsoft Project Most Valuable Professional
>>> http://users.online.be/prom-ade/
>>> +32-495-300 620
>>> "Simon Dullingham" <Simon.Dullingham@xxxxxxxxxxxxx> schreef in bericht
>>> news:eE#srvE1FHA.3924@xxxxxxxxxxxxxxxxxxxxxxx
>>> I'm trying to performing leveling on a project, but it's clear to me
>>> that I don't understand how this works as it is not doing what I want it
>>> to.
>>>
>>> I'm going to use a simple example which hopefully will enable someone to
>>> tell me why does not do what I expect.
>>>
>>> I have three basic tasks - a) My main task, b) my back up task, and c)
>>> my weekly meetings. I have one resource, ME. Tasks are defined as
>>>
>>> My main task "A" - ME assigned 100% (160 hours over a 4 week period);
>>> priority 500
>>> My backup task "B" - ME assigned at 10% (16 hours over a 4 week period);
>>> priority 600
>>> My weekly meetings "C" - a reoccurring task set weekly; ME assigned for
>>> 2 hours at 100%; priority 1000 (no leveling).
>>>
>>> If I level, no matter what the settings, it pushes the 4 week main task
>>> to the end of the 4 week period. The daily resource load looks like:
>>>
>>> M T W T F M T W T F M T W T F M T W
>>> T F M T W T F
>>> 0.5 0.5 0.5 0.5 2.5 0.5 0.5 0.5 0.5 2.5 0.5 0.5 0.5 0.5 2.5 0.5 0.5 0.5
>>> 0.5 2.5 8 8 8 8 8 ...
>>>
>>> This is obviously not want I want. I want each day's total to be 8
>>> hours. I want task C to be assigned first (2 hours on friday), Task B to
>>> be assigned next (0.5 hours per day), and then task C to use the
>>> remainder of the day that is free. i.e.,
>>>
>>> Day M T W T F M T W T F
>>> A 7.5 7.5 7.5 7.5 5.5 7.5 7.5 7.5 7.5 5.5
>>> B 0.5 0.5 0.5 0.5 0.5 0.5 0.5 0.5 0.5 0.5
>>> C 0 0 0 0 2.0 0 0 0 0 2.0
>>>
>>> So I guess the question is, why is not doing this? Or, am I missing
>>> something dumb that will make it do this?
>>>
>>> Thanks in advance
>>>
>>> Simon
>>>
>>
>>
>
>


.

Relevant Pages

  • Re: Leveling problem
    ... My best visualization of this was within the walls of the Enterprise the scheduler could ... > Agree on the splitting of tasks - even why I have gotten the leveling to do what I want, I have always allowed tasks to be split. ... > This then creates the time to do the data management block, ... >> The reality is the first day right out of the gate your resource DOES DO some datamanagement. ...
    (microsoft.public.project)
  • Re: Leveling problem
    ... Agree on the splitting of tasks - even why I have gotten the leveling to do ... > ->16 hours of data management is going to occur over this 4 week period, ... > The reality is the first day right out of the gate your resource DOES DO ... > assigning 0.5 of an hour per day on data management. ...
    (microsoft.public.project)
  • Re: Leveling problem
    ... you do not know that data management must be completed before any other ... The reality is the first day right out of the gate your resource DOES DO some datamanagement. ... But if I follow what you are saying, this is probably a really bad way of doing it - from a budget management and schedule ... In anothe rpost you say I hesitate to assign 90% to the other task because than I am leveling by hand and not by Project. ...
    (microsoft.public.project)
  • Re: So many questions...so little time...on scheduling and leveling
    ... synchronous after leveling. ... give the resource a max. units of 100+x% ... has no other assignments on that day? ... What does it mean to assign a resource to a summary task while leaving ...
    (microsoft.public.project)
  • Re: So many questions...so little time...on scheduling and leveling and more
    ... What you ask for IS resource leveling, ... > schedule time that is different from the currently scheduled time. ... > I also envision a mode such that if two assignments overlap in time ...
    (microsoft.public.project)