Project schedule management is a well-recognized term in project management practice. The project schedule is carefully researched and regularly changed to ensure that the project remains within the budget and provides at the end of the product, which will be in demand by the market.
By creating a timetable at the beginning of the project, the project manager can seriously reduce project cost overruns, resource conflicts, and the need to make changes to the project during its implementation phase. Here are some tips for professional project managers to build a project schedule framework.
Recognize the central role of the schedule.
The project manager and team often do not consider the schedule to be a key document of the project and do not pay enough attention to the schedule.
However, a good schedule should have an impact on all 9 areas of project management knowledge listed in the PMBoK standard.
For example,
f a project lag is found in the schedule, the project manager should prevent backlog through tools and procedures for managing project risks and problems.
Project schedule changes affect all areas and aspects of the project and can have multiple effects that are not always obvious at first sight. Thus, the project schedule becomes the main tool by which the manager can effectively manage the project.
Identify the capabilities of the project team members.
Inventory of resources is necessary both for project planning and for deciding in which direction the project will be implemented in a given situation.
Who will be able to implement the project? Are there gaps in the necessary competencies or can each team member cope with the required amount of work? Knowledge of this kind is especially important in projects whose budget is difficult to fulfill and difficult to attract additional staff to the project.
At the moment when the project team is defined, ask each of them to outline their competency zones in the current schedule to make sure that it is doable.
Build a schedule based on the results of the project.
A person is so arranged that it is easier for him to build a schedule based on the tasks of the project, but this method threatens serious problems.
The downside of this approach is the inability to link the schedule changes transparently and the impact of these changes on the content and products of the project.
Also, such a schedule is not able to answer the question of the necessity and sufficiency of certain tasks in cases of changes in the content of the project. A good project schedule should be based on the final and interim results of the project, as such a schedule has material confirmation, is easy to verify and allows for project management requirements.
Include periodic checkpoints in your schedule.
Identify the checkpoints in the project schedule and check them at a given frequency. For example, if your project lasts 8 months, you don't have to wait four months to check whether the project is on schedule or behind it. Create a checkpoint at the beginning of the month and check it every time during the entire project.Expect the schedule to change.
You should be aware that the schedule will never be permanent, as both the status of the project's tasks and the requirements of stakeholders for the project are constantly changing. Schedule is just one of the project's assumptions - when and what should happen.
And the job of the project manager is to make a decision whether or not to change the schedule depending on the external and internal conditions of the project. And this work should be carried out throughout the project.
Build a change management process.
The project manager must have the tools to ensure the legitimacy of the changes in the project. Determine what conditions or events should trigger procedures for making changes to the project. And what should be the procedures for making changes. For example, if the proposed change delays the project by one day, the project customer (or project management committee) must approve the changes in writing.Look for "stupids"
The basic rule of scheduling is: "Each task must have at least one predecessor and at least one follower. Exceptions are the start point of the project, which does not contain a predecessor, and the project finish point, which does not contain a follower.
"If a task loses a predecessor and/or follower it turns into a so-called "stupid" that means an unintended rupture of the project's network chart.
The problem is that if you have such "stupids" you cannot correctly calculate the length of the tasks that is necessary to calculate the critical path of the project and correctly determine the project's time reserve. And without knowing a credible critical path, you are not able to adequately manage the schedule of your project.
No comments:
Post a Comment