Re: Actual work from unopened projects not reflected in resource u

Mike,

You've obviously given this a lot of thought. Before I go further in
suggesting approaches, could you explain to me why it is important to have
information on Actual work when you are trying to do resource leveling? I
don't understand that, but I also don't want to assume your approach is
mistaken. Understanding that may help me better appreciate what you're
trying to accomplish, and the environment in which you're working.
--
Reid McTaggart
EPM Architect
Microsoft


"MikeR" wrote:

> Hi Jan,
>
> Thanks very much for the response. You are indeed correct. Opening
> all the files involved (either individually, or through the use of a master)
> does work. The difficulty I'm having in my environment is that opening all
> the relevant files is not always easy - we have hundreds of files here -
> though for a given resource the number of files is quite a bit smaller. It
> can be done, but it's not fun ;-)
>
> The thing that puzzles me is that the levelling (and everything else
> having to do with resources) sees the "work" but not the "actual work" of
> closed files. It would make our work much easier if the "actual work" from
> closed files were exposed as well.
>
> Thanks again,
> Mike
>
> "Jan De Messemaeker" wrote:
>
> > Hi,
> > I'm not a Server specialist but here is what I heard in a course.
> > You have to create a master project with all the projects using that
> > resource(s) inserted.
> > When that maste ris open all projectcts are "open" as Microsoft Project
> > files
> > The enterprise pool then will act as a normal resource pool and one can use
> > resource leveling normally, i.e. using a resource pool without server.
> >
> > Hope that is true - give me a feedback??
> >
> > --
> > Jan De Messemaeker
> > Microsoft Project Most Valuable Professional
> > http://users.online.be/prom-ade/
> > +32-495-300 620
> > "MikeR" <MikeR@xxxxxxxxxxxxxxxxxxxxxxxxx> schreef in bericht
> > news:A672CEAB-C61F-452D-A9BA-E36EE0BDE738@xxxxxxxxxxxxxxxx
> > > Hi Reid,
> > >
> > > Thanks for the response. You have confirmed what I had deduced. You
> > > are indeed correct that PWA will give the proper picture of the work
> > across
> > > all projects. However, for my situation the solution is incomplete. Let
> > me
> > > explain.
> > >
> > > Suppose I want to use load levelling. Typically I would open up a
> > > file, go to Resource Usage, select the resource I want to level, and have
> > at
> > > it. But, actuals in other projects appear to be ignored, as per our
> > > discussion, and I wind up overcommitting my resources by the amount of
> > > actual time. In a nutshell, this means that resource levelling doesn't
> > work,
> > > at least not in any useful way.
> > >
> > > Do you have a suggestion that would allow resource levelling to be
> > used
> > > in my environment?
> > >
> > > I have been watching others trying to deal with the problem, and am
> > > seeing all sorts of schemes being tried. The most common is to set up
> > > massive numbers of dependencies between tasks in order to "waterfall"
> > them.
> > > Unfortulately, this creates "spaghetti code" projects, and in most cases
> > > (ie., where the dependencies are strictly to force a schedule, and do not
> > > represent actuall task relationships) are a misuse of the dependency
> > > mechanism. A second is to force dates on tasks (ie., "must start on" and
> > the
> > > like. This is problematic because as time information is entered every
> > week,
> > > the schedule owners have to go back and redo all the dates.
> > >
> > > I'm not sure what the limitation is here. I imagine that some sort
> > of
> > > database is created that represents time in all projects. If so, does the
> > > information on actuals get into this (in which case, perhaps a 3rd party
> > > levelling product might do better), or is it left out completely?
> > >
> > > Thanks,
> > > Mike
> > >
> > > "Reid McTaggart" wrote:
> > >
> > > > You can use PWA to get your rollups of Actuals and other such data. The
> > > > behavior is not a bug because the tool was never designed to do what you
> > want.
> > > >
> > > > Showing all work across all projects is useful for planning assignments.
> > > > Analyzing Actuals is a retrospective analytical activity that is handled
> > in
> > > > PWA.
> > > >
> > > > I do agree that the advice to open all projects is not practical. It
> > should
> > > > say to use PWA.
> > > > --
> > > > Reid McTaggart
> > > > EPM Architect
> > > > Microsoft
> > > >
> > > >
> > > > "MikeR" wrote:
> > > >
> > > > > Hi All,
> > > > >
> > > > > I have a perplexing problem. It appears that when I open one or
> > a few
> > > > > files (out of many) from Project Server, actual work from unopened
> > projects
> > > > > is not reflected in the work rollup. See article 888638 on
> > Microsoft's site
> > > > >
> > > > >
> > http://support.microsoft.com/?scid=kb;en-us;888638&spid=2525&sid=global
> > > > >
> > > > > The suggested workaround is to open all files relating to the resource
> > in
> > > > > question. While this works, this is impractical in my environment
> > because:
> > > > >
> > > > > 1 - there are hundreds of files
> > > > > 2 - some files, such as those representing administrative time, were
> > not
> > > > > meant to be managed by any other than a few admins (this is a current
> > > > > business practice of ours)
> > > > > 3 - I may not have access to every relevant file
> > > > >
> > > > > Is there another way around this? Anyone know of plans to fix it?
> > > > >
> > > > > As an aside, this behavior certainly looks like a bug to me - after
> > all, it
> > > > > appears that I can see the planned work from unopened files just fine.
> > The
> > > > > article cited above spins this as a "behavior" rather than a "problem"
> > or
> > > > > "bug", though I haven't found any reference in the regular
> > documentation that
> > > > > would lead to this conclusion. I would hope that someone is looking
> > at a
> > > > > more satisfactory resolution than opening all files. Anyone out there
> > have
> > > > > additional details on what might be in store?
> > > > >
> > > > > Thanks,
> > > > > Mike
> >
> >
> >
.

Relevant Pages

  • Re: Performing tasks seqentially
    ... When Project does its levelling, it ONLY DELAYS tasks until the resource ... So, if you see a Duration of 21 days, it ... >> Project is specifically designed to do exactly what Andrew is asking ...
    (microsoft.public.project)
  • Re: how do I make resource levelling work?
    ... In addition to Mike's comments it is worth perhaps pointing out that levelling a plan may well be an iterative process. ... After a first pass at levelling, you can fix those elements you are happy with using the priority field, adjust durations if your tasks have become split as in your example. ... Whereas I want to specify a task with an elapsed time and an amount of effort. ... And actually I don't care whether the resource does 100% for the first 5 days and nothing for the rest or whatever. ...
    (microsoft.public.project)
  • Re: Is there any way to view the cause of a levelling delay.
    ... a single shared resource pool. ... see where the levelling is working. ... sequential tasks and it is due to a levelling delay one of which is ... There are also instances where low priority work is being scheduled ...
    (microsoft.public.project)
  • Is there any way to view the cause of a levelling delay.
    ... a single shared resource pool. ... see where the levelling is working. ... sequential tasks and it is due to a levelling delay one of which is ... There are also instances where low priority work is being scheduled ...
    (microsoft.public.project)
  • Re: Leveling question
    ... You can do this by adjusting their duration as necessary (and moving resource allocations around on the Task Usage view - although this could end up by being a lot of work). ... Firstly you have to understand that the levelling algorithm is complex. ... I normally use Priority, Standard because then the priorities that I impose are given high importance in the decision process. ... Project will keep all the work together and move it around as a single chunk rather than breaking it into smaller chunks which it may be easier to slot into the schedule at points where the workload is low or lower. ...
    (microsoft.public.project)