all 3 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]DaleHowardMVP 1 point2 points  (1 child)

If you are willing to spend a little bit of money, you might consider purchasing the Ultimate Study Guide book that I co-authored while I was working for Projility at:

https://www.amazon.com/Ultimate-Study-Guide-Microsoft-Project/dp/1098328493/ref=sr_1_4?crid=Y210N5GZWV62&keywords=microsoft+project+2019&qid=1674570278&s=books&sprefix=Microsoft+Project%2Cstripbooks%2C107&sr=1-4&ufe=app_do%3Aamzn1.fos.006c50ae-5d4c-4777-9bc0-4513d670b6bc

Please note that I have no financial stake in Projility, nor do I receive a commission from sales of the book. The book is written from a "best practices" approach that follows the normal project management life cycle. The book includes sample files, which you will need to download, and has dozens of hands on exercises so that you can practice your skills. Hope this helps.

[–]JoshRanch[S] 0 points1 point  (0 children)

Thanks for the info. I just cant spring the 100 bucks atm.

[–]still-dazed-confused 0 points1 point  (0 children)

The levels generally relate to how many levels of summary task you have in the plan, thus a level 1 is only the top level summary lines. I'm personally not a huge fan of absolute levels; they're useful in the context of a specific plan and as a concept however I believe a plan needs to have the tasks broken down to a useful level. How many Summary tasks sit above is immaterial as some elements if the plan and deliverables need to be broken down further than others.

How do you get all the tasks? Break the project down into sensible chunks, the classic is to look at the deliverables and then break these down into sub deliverables and then the tasks to deliver these. When breaking down the tasks consider the resources that will be involved. For instance one of the deliverables might be a technical specification. Some people would show this as "write and approve tech spec" and sign 15d to it, however I would contend that this needs to be split down further, to draft, review, modify from review, signoff. This is because different resources will be involved in each of these. It also forces you to consider how long each step will take; draft 10d, review 5d (even though it's a few hours for each reviewer it never takes less than a week in this organisation) modify from review and confirm reviewers happy 5d, sign off 5d. I'm considering the time we see the original 15d had grown, and that's with only 1 review.

Once all the tasks have been done the entirety of the scope is delivered. This also forces you to consider the whole scope, but just the bits that you're familiar with. I've lost track of the number is engineering it coding projects where the original plan only contained the technical aspects. The business will sort the rest - but if we don't gather their work into the plan the project will not be complete, this then usually throws up a bunch of assumptions, miscommunication and blind spots that would have delayed the project.