RISK ASSESSMENT

Questions for Project Plan

1. What are the names for the first and last tasks in the Project Plan? What are their durations? 2. Was the team able to view the Project Plan's critical path? Explain what it showed. 3. Do any Summary Tasks or Sub-tasks show as manually scheduled ( in the Task Mode column)? If yes, list the task ids and explain what caused that. If no, explain how that was avoided. 4. Do any Summary Tasks or Sub-tasks show as constrained? (Name of the constraint in the Constraint Type column, or date in the Constraint Date column)? If yes, list the task ids and explain what caused that. If no, explain how that was avoided. 5. Did the team approach the WBS graphically (like an organization chart) or tabularly (like a list or table), or something else? Why? 6. Was the team able to find any external reference that disagreed with these assignment instructions? Explain. • Do not over-engineer dependency links • Constraint Dates are not a good thing • Manually scheduled tasks are not a good thing

The first task in the project plan is System Testing with a duration of 13 days, and the last task is Deployment which will last for 3 months. Under these overarching tasks are several sub tasks, some of which will be recurring throughout the lifecycle of the project, and some will be worked on simultaneously as resources dictate.

Yes, the critical path can be seen starting with WBS item 2 (Record Issues) and ending at WBS item 3.5 (Revise Documentation). The critical path follows the recording of issues found during the system testing phase and ends with the final revision of documentation. The middle part of the critical path follows the development phase of the project.

There are no tasks that are manually scheduled in the Project Plan. All tasks are scheduled according to what Microsoft Project determines. Manual task scheduling was avoided by allowing sub tasks to run concurrently, as in a practical project scenario there would be a division of labor amongst all IT team members and project managers, allowing for multiple tasks to be worked simultaneously.

There are no constraints found in the project schedule. This was accomplished by ensuring that tasking in the Project Plan is independent enough that the early or late completion of project tasks will not affect preceding or succeeding tasks.

The approach for creating the WBS was tabular as opposed to graphical. The primary method for initial (the core WBS) development and further (scheduling and predecessor/successor relationships) development was performed in Microsoft Project. As the primary method of data entry for Project is in a tabular view, and all group member contributions were either via Project itself or a bulleted list, it was natural for the development of the WBS to follow the home program’s formatting. While planning the WBS graphically has its advantages, it is easier to follow the scheduling and task relationships in a tabular view, especially when planning for sub tasks.

Upon reviewing the project instructions there are several points made that are not necessarily true. The first of these is that “manually scheduled tasks are not a good thing”. Project planning can be a very complex undertaking with several factors affecting project scheduling. By default, Microsoft Project will automatically skip over weekends for work being completed. Depending on the project, industry, or company, tasks may need to be scheduled during such times (Neumeyer, 2022). Thus, manually scheduling tasks simply may be necessary. Having to manually schedule tasks is not inherently a bad thing (perhaps scheduling an entire project manually, but not a few tasks), it simply requires more work than allowing the software to do it automatically. In moderation, manually scheduled tasks can benefit a project, but should not be overused to prevent unnecessary work.

Like manually scheduling tasks, the project instructions advised against constraint dates, stating they were “not a good thing”. This is another case where, in moderation, constraint dates can be useful but in large quantities can harm a project plan. Projects are by nature “dynamic” and fluid (Ten Six, 2019). Too many constraint dates quickly make the project way too rigid and not adaptable to the changes that are very likely to happen during a project’s lifecycle. Once again in moderation, constraint dates can be useful to a project plan, but in large quantities can be detrimental to the overall project.

Overengineering dependency links is the most solid of the three suggestions. There are two major types of dependencies: mandatory and discretionary (Simpson, 2022). Discretionary dependencies are what make this good advice to follow. These types of dependencies are not necessarily bound by a particular order that tasks need to be completed in. Dependency links can, on paper, make these discretionary dependencies look like mandatory ones, where tasks must be completed in a particular order when it does not matter. This can lead to wasted time and resources over the course of the project, improper prioritization of tasks can lead to such waste and thus dependency links should be kept simple and well thought out.

References

Neumeyer, A. (2022). Adrian Neumeyer. Tactical Project Manager. Retrieved July 12, 2022, from https://www.tacticalprojectmanager.com/manual-vs-automatic-scheduling-ms-project/

Simpson, J. (2022, April 29). What are project dependencies? how to plan & map them. Hive. Retrieved July 12, 2022, from https://hive.com/blog/project-dependencies/

Ten Six. (2019, February 17). Late-date constraints and their usage in Schedules. Ten Six Consulting. Retrieved July 12, 2022, from https://tensix.com/late-date-constraint-usage/