Daryl Deffler

@daryl_defflerprogressive-com

Active 5 months, 1 week ago

Forum Replies Created

Viewing 14 reply threads
  • Author
    Posts
    • #492752
      Daryl Deffler
      Participant

      Matt;
      I’ve been out of MS Project for a few years now, but let me suggest the following.
      Scheduling/Leveling is an extremely complicated component in MS Project. There is a series of articles available along with two webinars that go into it in detail. I know the author. 😉
      Here is a link to the first of the series. https://www.mpug.com/resource-leveling-scheduling-vs-leveling/
      Links to all the articles and webinars are located in each article.

      I’d suggest reviewing these to get more of an understanding of how the many options actually work. The articles explain the scheduling / leveling priorities which will help you configure your training courses and other tasks so they stay put, or moved as expected. For example, the task scheduling priority of 1000 is the highest priority tasks in leveling and with a priority of 1000, project will not move them, but in most cases, will simply move other lower priority tasks instead.

      I’ve also found thru many experiments that MS Project levels things much better when looking at larger intervals, such as weekly. Yes, the schedule may show overallocations on a specific day, but overall, across the week, the resource will not be overallocated. For example, resource allocation may look like: 14h, 10h, 8h, 8h, 0h
      Generally speaking, the tighter you try to control the scheduling intervals (15 min), the worse Project schedules. The broader the intervals (weekly), the better Project works. Also, one point I used to make to PMs I worked with. Don’t try to micro manage/schedule the work. What’s critical is that Project forecasts the amount of work in the week correctly. It really doesn’t matter if, within that week, Project shows a task occurring on Monday or Tuesday. The resource will perform the task when needed and the work will be done in that week.
      Hope this helps
      Daryl Deffler

    • #479183
      Daryl Deffler
      Participant

      Guy;
      MS Project supports something called “Hammock Tasks” where the duration of one task is dependent on other tasks. I found this MPUG article which may help.
      Not sure if this is exactly what you’re looking for.

      https://www.mpug.com/dos-and-donts-using-hammock-tasks/

      Hope this helps

    • #479182
      Daryl Deffler
      Participant

      Bob C.
      I think the confusion your seeing is based on the way we (people) think of % complete and the way MS Project actually calculates it. As per MS:

      “The % Complete fields contain the current status of a task, expressed as the percentage of the task’s duration that has been completed. You can enter percent complete, or you can have Project calculate it for you based on actual duration.”

      Typically, we think of a 40 hour task that takes 1 week for example. In this case work effort is pretty much tied 1-1 with, and drives duration. As a result, %complete seems to work as our expectation of how it works. In your case however, you have 18 hours of work spread over 3 weeks so our expectation that %complete is based on hours of work completed doesn’t align with how MSP actually calculates it (which is duration based). As a result, %Complete numbers seem to make no sense. As you mentioned, if you increase the hours to match 100% allocation for 3 weeks, the %Complete now presents numbers you expected to see.

      See if this MSP posting helps explain it further:
      https://support.microsoft.com/en-us/office/percent-complete-fields-84ec5068-4a34-497c-97eb-e12b6dc47cc5

      Hope this helps.

    • #478936
      Daryl Deffler
      Participant

      Robert
      There’s a couple ways to answer this.
      Generally the simplest answer is to create a fixed duration task, assign the resources and give the resources, for example, 4 hours of work. This will then spread the resource usage over the entire duration at, for example, .1 hr/day. A second way might be to manually enter the resource load pattern or work contour for the projected work. On a grid showing the resource assignments and planned work, you can simply type values on the daily grid, for example: 2,0,0,0,0,2 to represent a 2hr meeting on first day and another 2 hrs on the 6th day. But as with all Project options, there are ramifications/costs.
      Simply defining a fixed duration task spreads the work, but may result in resource leveling conflicts on tasks that could/should run in parallel. For example Bob is on the meeting task and another parallel task at which his assignment units is 100%. Because Bob is allocated at 1% on the meeting, the leveling algorithm may not schedule Bob’s next task until after the meeting completes because Bob is not available at 100% (to start the next task). The result may be a large gap (during the meeting tasks duration) in Bob’s forecasted usage.
      Manually entering a work contour could also cause issues primarily because you as the PM, are taking full ownership of that task and the leveling algorithms will pretty much just ignore the task you now own.
      Another option is to simply schedule a task for each meeting day. It’s more tasks, but it gives the cleanest result from a scheduling/leveling perspective.
      But I would also ask how critical it is that these meetings be tracked to that detail.
      Do they drive key dependencies? Maybe one final sign off on testing for example, does, but does every review meeting? In other words, does that meeting completion need to drive a successor relationship down stream in the logic.
      How critical are they in terms of tracking/reporting progress? Do they need specific visibility to management or is this simply overhead that’s part of the development or testing process?
      Who is involved? Is it a business leader meeting that needs to maintain visibility on the forecast, or is it internal developers/testers?
      I’m asking because these questions may help determine how you set up the schedule to most effectively allow you to have the easiest job to maintain the schedule but still provide needed visibility and tracking levels.
      One thing I’ll do is create a “development Phase Meetings” overhead task spanning the entire phase, for example. I’ll determine how much time per week each resource will average on all overhead type tasks such as team meetings, code reviews, testing reviews, testing support, and so on. Then I’ll create one task with the appropriate duration and assign the appropriate resources with the determined allocation. Any time spent on that topic is simply reported to that task. For example, I may determine the entire team will spend 5% on team meetings/status updates, etc. So that gets a task. I might determine that during the testing phase, the developers estimate they will spend 25% of their time doing testing support, in support of testers who have very specific testing tasks. So in that case the developers get a 25% allocation to a testing support task that spans the entire testing phase.
      However, to ensure that Project will schedule other work in parallel to these overhead tasks, I then ensure that these other tasks have a resource allocation sufficiently reduced to allow parallel work. For example, the developers providing testing support are allocated 25% to testing support and 5% to meeting overhead. Therefore, I will only allocate the developers assignment units at less than 70% (100%-25%-5%) on any other tasks occurring in parallel with testing support.
      I hope this makes sense.
      Bottom line, if there’s a NEED to create separate meeting tasks, then by all means. But if not, don’t make your job as the PM any more difficult than necessary by muddling up the schedule and creating dozens of tasks which provide you no real benefit from a tracking the schedule perspective. Think “what’s key to manage in that phase” and try to simplify the ancillary work (in the schedule).
      Hope that helps and provides some additional thought.

    • #478896
      Daryl Deffler
      Participant

      Robert
      Re-reading Larry’s response, I now think I’ll agree with his take. Summarized, build the schedule based on task dependencies. For example you can’t put the roof on the house until the walls are constructed to hold the roof…even if the roofers are available already. One thing a schedule should help you do is to plan “when” you need resources. So in my example, the schedule might tell you that you won’t need to schedule the roofers until the 3rd week.
      His next comments refer to “how” you apply resource constraints/dependencies, by either allowing Project to do it based on it’s internal resource leveling logic, or by you doing it yourself and adding additional non-task construction sequence specific dependencies. Another way of looking at that is that you’re adding prioritization to tasks. Meaning that when the carpenters are available, I want them working on Task A first, even though both Tasks A and B could be started at the same time. So you would add what is sometimes referred to as a false dependency simply to ensure that Task B follows Task A.
      Additionally, here’s a link to an article that discuses task scheduling versus resource leveling that may help. Its also the start of a multi-part series on resource leveling if you wish to dig deeper.
      https://www.mpug.com/resource-leveling-scheduling-vs-leveling/

    • #478867
      Daryl Deffler
      Participant

      Robert
      I highly recommend utilizing a Product Breakdown Structure which is part of a Prince2 methodology. It can be used to help organize any project work.
      In a nut shell, identify the end product of the project. For example a car. then break that end product down to the next level products. For example, drive train, body, interior, etc. Then break those products down until you hit a level where the product can be estimated relatively easily/confidently. Make sure you define a scope for each product so that estimates for each product are based on a commonly understood and agreed upon scope. It doesn’t matter how the scope of each is defined, as long as the scope is clearly understood by all. For example, a car door contains a frame, window, lock mechanics, etc. Does it also include the interior panel with all the switches as well? Doesn’t really matter as long as those are included in the scope somewhere logical, like maybe the interior, as opposed to the door assembly.
      Also look at the end product from both a business perspective and a technical perspective in this process. Business: What does the business want out of the project and Technical: What will it take for IT to both develop and support the resulting business end product. Meaning, do you have a development environment, test data, test tools, developed test cases, trained staff, capable staff, etc. and are there sufficient product environments to support the anticipated thru put levels or response times.
      I’d strongly recommend looking at this specific step in Prince2. My last company adopted this as part of their standard Project Development Life Cycle and project estimate accuracy improved significantly.
      I hope this helps

    • #415680
      Daryl Deffler
      Participant

      Ben;
      When you manually defined the task duration as 1 week, MS project behind the scenes changes the task to Fixed Duration. Meaning, that pretty much the only way the task duration will change will be if you manually alter it.
      The solution is pretty simple. Change the task type to Fixed Units. Once you change the task type, change the Work value from lets say 40, to 39, then back to 40. This change will force Project to recalculate the duration as explained in the additional info below.

      Additional info
      Project has an internal formula “Duration = Work / Availability” where availability is resource assignment units equated to hours of work time available per day. This formula must always be in balance. When you define a task as Fixed Work, you are locking the Work portion of the formula, meaning if you manually change availability, duration is recalculated. It works the same for Fixed Units (availability), meaning the Availability is locked and if you change the amount of work, the Duration will be recalculated.

      Generally speaking, if you are working on projects where duration should be driven by work and resource availability, you will probably want to set your task types to Fixed Units. For example, Bob is available to the project at 60% so by setting the task type to Fixed Units, you’re telling Project not to change Bob’s task assignment units value.

      Hope that helps! 🙂

    • #415615
      Daryl Deffler
      Participant

      Jeff;
      The ability to do just what you are asking is a feature we’ve been asking Microsoft to add for years. Meaning while their enterprise Max units is 100%, provide the ability to define project level max units at 60% for example, and then let the default task assignment units to stay at 100% (which would be 100% of 60%).
      As Larry noted, you can change the Max Units in the resource list for enterprise resources, and this remains in effect for that session. This makes it usable for initial schedule entry since the Resource Max Units becomes the task level assignment units by default when adding a resource to a task. However, as indicated, Project resets your resource list entered value and resets it to the enterprise max units value every time you open the schedule (for enterprise resources only).
      Essentially, the only way to do what you need is to ensure that the task level resource assignment units value is set at (or below) what you want that resources availability to be for that project engagement… on every task.
      You can set up a resource usage view showing both the resource level max units and the task level assignment units, grouped by resource. This gives you a quick view to easily view/scan each resource across all tasks on which they are assigned.

      hope that helps

    • #415506
      Daryl Deffler
      Participant

      Matt
      What are you trying to accomplish? There may be other, sometimes easier, ways to accomplish your end objective.

    • #415435
      Daryl Deffler
      Participant

      Jebir;
      Based on your response, it appears your biggest problem is not in MS Project. Your bigger problem appears to be an unstable operational environment resulting in an unpredictable operational work load that regularly consumes all your available resources, leaving minimal to no time for project work.

      Operational or “keep the business running” work is definitely highest priority. I would suggest that you have several courses of action that must be discussed and agreed upon with Sr. Management.

      * Stabilize operational work. No new projects until the operational work is under control and somewhat predictable. You might need some root cause analysis here to determine what is actually causing the operational issues so those root causes can be fixed, as opposed to constant on-going patching.
      * Dedicate existing staff to operational work, obtain new resources that would be dedicated to project work. Yes, this means adding resources, which management often doesn’t want to do. Note these could be contract resources or full time and contract resources could be assigned ownership of stabilizing the operational environment, which means they could be whittled down over time as less and less operational work is needed.
      * Get management to accept/sign off on the current environment. Meaning operational work may consume all resources and project work will never be predictable and may never get done. (probably not acceptable)

      Either way you look at it, it appears the problem is too much work for available resource capacity.

      Sr. Management should help set, agree to, and then help you manage towards an operational/project work distribution goal. For example, Management may want a 20/80% work split for operational/project work. The key is defining what they think is an acceptable operational work ratio, agreeing on a plan to get to that ratio, and setting an organizational goal to obtain that goal. How you get to that goal is not as critical as recognizing the root issues and addressing them.

      Unfortunately, I don’t think there’s anything you can do in MS Project at this time that will help you manage this. You can be an MS Project expert with the coolest, most sophisticated schedule, but if the resources aren’t available to do the work, the schedule is irrelevant.

      Hope this helps

    • #415430
      Daryl Deffler
      Participant

      Jebir;
      You may be trying to do too much in one schedule, meaning operational AND project work.
      One technique I’ve used was segregation of operational tasks from project tasks by having them in different physical schedules.
      For example, we’d configure one schedule for operational work. If for example, 15% of a resources time is to be spent on operational work each week, we’d add resources to operational tasks with an assignment units of 15% (setting up the task as Fixed Units). These operational schedules may have very few tasks, but those tasks may extend for the entire year. What you put in these schedules in terms of tasks is really dependent on what, if any type of reporting/breakdown management may want to see related to the operational work.
      As the second part of this technique, we would then have project specific schedules that only contained work required to produce that project’s specific deliverables. To keep the example simple, we’d allocate resources to project tasks at no more that 85%. (100% – 15% operational allocation) Scheduling these tasks becomes much simpler since we’re now isolated only to that project work.
      The key is to ensure that resources on the project schedules don’t exceed 100% when combined with their operational allocation.
      Different resources could have different operational demands. Joe might need 20% operational allocation while Sue might only need 10%. So manual work is required to make sure that the project task work plus the operational task work doesn’t exceed 100% for all involved resources.
      Its a manual coordination process to identify those resource specific operational allocations, but once defined, it greatly simplifies the individual project schedules by allowing them to focus only on project tasks.

      As a side note, I used this technique in a 2013 and 2016 Project server environment where resources tracked task progress using the MS Project provided time sheets. Time sheet users didn’t really know/care which task was in which schedule since they saw all current tasks in their weekly time sheet.

      Hope that helps

    • #415339
      Daryl Deffler
      Participant

      Chloe
      I don’t know that I can tell you a fool proof means of doing what you want. I’ve never had the need to set up a schedule in this manner. However, here’s a couple suggestions.
      * Add the time value to the date displays. What you want to see is the Start/Finish fields also showing the time value. This will help you understand what IS happening and why successors start on the same day. For example, Task 1 may finish on Monday at 4:30 PM and Task 2 starts on Monday at 4:31 PM but only applies 30 minutes of work on Monday.
      * By default, the predecessor/successor Lag relationship is 0 days, or immediately. Try adding a Lag value of 1 day on the successor relationships. This should move the successor task start date out to the next day. I haven’t had the need to do this, so it’s only a suggestion. Experiment to see if this works.

      Hope that helps.

    • #415321
      Daryl Deffler
      Participant

      Amy
      I’ve run into an inability to paste several times in MS Project. Every time it was because the table used by the view was corrupted.
      Try copy/paste in another table/view and if that works, then it’s definitely the table definition.
      To fix the table;
      Open the table definition and scan down thru the rows listing each field in the table. You should find one row that indicates something abnormal, meaning the field name will say something like “Invalid”. I can’t remember exactly what it will say, but it will be obvious.
      Delete that row(s) from the table definition, save the table and you should now be able to copy/paste in that view again.

      Hope that helps

    • #415314
      Daryl Deffler
      Participant

      Rob
      I have been P6, MS Project 2013 and 16 user.
      I’ve not worked in an on-going mixed Project version environment so I can’t comment on the cause being the multiple versions. I did experiment in a mixed 2013/16 environment during our migration from 2013 to 2016 and I can say that scheduling and resource leveling will produce different results between 13/16, but these process don’t update baseline fields.

      What I can tell you is that there are two basic ways in which baseline fields are changed in MS Project.

      First, Project in it’s infinite wisdom allows the PM to manually edit ALL baseline fields. Unlike P6, Project doesn’t lock any baseline fields from manual update. So it’s possible the PM could be manually typing over existing values. Note that the PM would have to be manually entering values directly into specific Baseline fields. Meaning manual updates to (non-baseline) fields such as Start, Finish, or Work will not automatically replicate those manually entered changes into Baseline fields.

      Second, Project will add/update baseline field values using the PM invoked Set Baseline function. Having used P6 and understanding the complexities of trying to update baseline values for select task(s) in a P6 schedule, Project’s Set Baseline function is much much easier to use. But with that said, the Set Baseline function also allows you to do illogical things like update a task’s baseline values without rolling up the impacts of those changes to the rest of the baseline, thus creating a baseline where summary baseline numbers won’t actually match the task details. The Set Baseline function also makes it very simple to accidentally update baseline values on every task when, for example, the PM only wanted to update one task.

      What I haven’t seen is a scenario where Project changes the Baseline fields on it’s own.

      Here’s a few suggestions.
      * Familiarize yourself with all the Set Baseline capabilities. How to take a full baseline, how to update individual tasks, how to copy full baselines.
      * Establish rules with the other PM(s) to never manually change baseline fields and for when and how to use the Set Baseline function. As a side note, one PM I worked with years ago updated the baseline values on any task if they made changes to the task, because they didn’t understanding what the baseline was used for.
      * Understand that Baseline (0), which is the baseline fields with no appended number, is the standard reporting comparison baseline fields unless specifically changed in the schedule.
      * Establish rules for and the use of Baseline (0) and Baselines 1-10. For example, storing the baselines at different key project checkpoints. To illustrate, Baseline 1 could be the ROM baseline used to initially approve the project start. Baseline 2 could be the baseline at the first major checkpoint/gate. Baseline (0) is the current baseline (with approved change requests). And baseline 10 could be used to store the most recent copy of Baseline (0), the current baseline.
      * Use the Set Baseline function to copy the current baseline into another set of baseline fields (for later comparison). For example, copy Baseline (0) to Baseline 10. Doing this also allows the baseline to be reset if needed by copying Baseline 10 into Baseline (0).
      * Establish a view displaying tasks only when key baseline fields (such as Start, Finish, or Work) are not equal when comparing Baseline (0) and Baseline 10 values. Using a view like this daily will allow quick identification of Baseline (0) changes so that actions can be taken to investigate what somebody did to cause those changes to occur and then correct them.

      While I can’t point to anything specific as the cause, I think these items will help establish baseline guidelines and help you identify how the baseline values are changing.

      Hope that helps

    • #415159
      Daryl Deffler
      Participant

      Hey Clint;
      Might I suggest that rather than messing with date formulas, you explore relationship with positive or negative lag values. This might be easier as it does not require the use of custom fields and date formulas. Meaning all milestones would show their appropriate start/finish dates using the standard MS Project fields. Additionally, if milestones are used for each, they can also be displayed n the Gantt timeline view to provide a better visual presentation.

      So, for example, You could set up milestones for each of the events you noted with 0 work and duration. Then for example, DAD Submission would be a successor or Inaugural Construction but with a lag of -12W (meaning it occurs 12 weeks prior). Project Approval date would be a successor of DAD Submission with a positive lag of 6W (weeks).

      If some of these relationships aren’t providing the correct results, you can also try a different twist on the relationships using a task constraint of As Late As possible.
      For example, DAD Submission would be a predecessor of Inaugural Construction with positive lag of 12W but the DAD Submission would also contain a task constraint of As Late As Possible. This constraint causes the DAD milestone to be pushed as tight as possible up to the successor task but the 12w lag forces the constraint to honor the 12 week gap.

      With these approaches, you may need to add the appropriate constraint to the Inaugural Construction milestone to ensure it occurs on 7/1 in your example. These constraints could be Must Finish or Start On, or Finish/Start On or After, depending on what else you have in the overall schedule.

      Lag values can usually be entered where you assign predecessor/successor relationships.

      With both these approaches, if the starting point (Inaugural) moves, all related milestones will move also!

      Hope that helps

Viewing 14 reply threads