Automatic Checkpoints

[Gordon_Smith]

I'm trying to combine a variety of (somewhat inefficient) scheduling systems into a Project File.  There are certain structures that tend to happen within a larger "broad" time definition.  For example, I might have an estimate come in as 220 hrs to be spent on a project.  In a perfect world, I'd like to be able to estimate a 220hr task, and have Project automatically generate a rough framework of what that comprises. It might look like:

220hrs input feeding into 

• 44hr (or 20% of the total task time) assigned to a new "R&D" phase, with a FS dependency to...
• 132hr (or 60% of the total task time) assigned to a new "Design and CAD" phase with a FS dependency to...
• 44hr (or 20% of the total task time) assigned to a new "Documentation" phase
  
  
• and/or
  a 0d marker for 50% target completion (located 110hrs after the start)
• a 0d marker for 100% target completion (located 110hrs after the start)

Appreciate the creative help to an (admittedly "why would you want to do it this way") question.

[#2]

Gordon --

I would opt for the first approach, but to include a summary task that includes the R&D, Design and CAD, and Documentation phases as subtasks (each of them might actually be a summary task with multiple detailed subtasks indented below them). Assuming you status your project by entering a % Complete value for each task, the overall summary task I just described would show the cumulative % Complete value for each of the subtasks (the phases). Just a thought. Perhaps others in this group will have an idea or two for you as well. Hope this helps.

[#3]

@Gordon_Smith 

No need to ask, "why would anybody...", there are a lot of ways to approach a plan. What you've described is a typical top down approach often used by management to "throw down the gauntlet", so to speak. Personally, I think a bottom up approach is more realistic as it normally uses estimates from people at the performing level to "develop" a plan based on a statement of work or statement of objectives. Ideally the bottom up estimates are not too far off from the top down estimate. In your example, where did the 220h estimate originate? If it's based on actuals from previous similar projects then it's an excellent basis but if it's "off the top of someone's head", it's suspect at best.

Nonetheless, I agree with Dale, that each of your phases should comprise summary groups of more detailed subtasks below. For example, what activities need to be accomplished in the R & D phase, in the Design and CAD phase, and in the Documentation phase. And just for reference, Project will not automatically generate any kind of "framework", it is simply not that sophisticated. You'll have to put the plan together, Project will schedule the plan based on your input and even let you know if resources you assigned to perform detail tasks are overallocated (e.g. "Joe" assigned to concurrent tasks such that his work availability is exceeded).

Milestones are often included in a plan to mark the start or completion of important parts (phases) of a plan but those milestones should be based on actual expected completion and not as arbitrary 25%, 50%, 75% overall plan completion.

That's my 2 cents.

John

[#4]

But the hope would be that Project could autopopulate some of this. Can I set up a mechanism that would take the 220hrs, and a predefined relationship of 20%/60%/20% to define the durations of the subtasks?

[#5]

Right now that "220" is somewhere in between. It's a magic number based on historical projects of similar complexity. What I'm fighting is a top-down "we've always done it that way" sort of thing where numbers just "get popped in" using a spreadsheet (the thumping you hear is my head on the desk). Completely separately, a MSProject file is created using the client's desired schedule for the project (more, and louder, thumping) with no regard/correlation to the estimated hours provided in the spreadsheet. That schedule is largely not worth anything, except when the client wants to use it to beat us over the head. After all, we did submit the schedule....

Right now, I'm trying to link the two in a better manner that actually treats time as something that relates to schedule, while also making the point that scheduling needs to be driven from the bottom up. So my hope was to set up a "semi-automatic" approach to creating things so that the traditional overall estimate could simply be entered, and all the subtasks autofill (again, based on past experiences). If I can get them thinking about the details without huge exertion, I'm hoping the needle can begin to shift on expectations.

[#6]

Gordon_Smith,
I feel for you and you might want to take a couple of Excedrin for that head.

Perhaps one way to fight the "but we've always done it that way" and the client's "desired schedule" is with a counter-point approach which is a bottom up, based on detail or WBS level actuals from historical projects. If you have those actuals creating a good (realistic) plan shouldn't take that much effort. What you don't want to do is to sign on to a plan that's based solely on desires. Everybody loses.

And again, I'll re-iterate, there is no automated process in Project for creating a plan, given a framework or not.
John