Sep 21 2022 09:35 AM
Sep 21 2022 09:35 AM
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
Appreciate the creative help to an (admittedly "why would you want to do it this way") question.
Sep 21 2022 10:41 AM
Sep 21 2022 11:54 AM
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.
Sep 21 2022 11:56 AM
Sep 21 2022 12:04 PM
Sep 21 2022 12:46 PM - edited Sep 22 2022 06:47 AM
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.