Internal Audit Plan_ – an essential part of the [ISO 9001] quality management system (https://www.pdqm.cz/o-nas/terms/standards/iso-9001) plans internal audits throughout the year.
Project Plan_ – according to some of the project methodologies or standards, e.g. PMBOK ISO 26262
Risk Management Plan_ – concerns both the project (one way or another required by all project methodologies with PMBOK at the forefront) and the organisation where risk management should cover individual areas; more attention is given to this Risk Chapter

What the plan contains

The plan is a description of the concrete implementation of the activities to be carried out. It may be ad hoc or methodologically based. The methodological template is the definition of the plan.

The detail of the plan depends very much on how much of the activities is defined elsewhere. For more information, see the example of the project plan

Project plan

Plan without methodology

If a methodology is not available, the project plan must include:

Definition of roles and the entire project team
For each role, a description of what the job of the role is, what its competencies and responsibilities are
A description of how everything that is being worked on will be handled in the project. Typically, it is information (including records and documents), but assets acquired and produced, i.e. things of a material and intangible nature. The loading will include
Who is in charge
How they are generated
How they are identified
Where they are stored
How they are valued (includes, for example, how much the customer will be charged for them)
Project risks and how to work with them
All project links to other projects, participants
Project limits, relevant legislation

The project plan sometimes includes an overview of the activities that will be carried out. other times, the overview is separately in the schedule.

Project plan associated with the methodology

If the project plan is derived from the project methodology (typically from a methodology built on a general methodology, e.g. PMBOK, SPICE, CMMI, etc.), most of the above content is defined directly by the project methodology and the [sample project] described in it(/doc/en/tsk/tskDefProject).

Roles are defined within sample project roles
Project risks are derived from sample risks
Timetable results from prescribed project activities
Location of files and their markings are determined by the methodology and standard templates for unique record identification
Links to legislation, standards and other externally defined obligations are described within the [obligation] methodology(/doc/en/tsk/tskObligation).

How a plan arises

A plan arises at the beginning of the rep. before the planned activity begins:

A project plan is prepared before the project starts, along with other plans related to the project – a safety plan, a risk plan, communication, supply plan, etc. (always depending on methodology.
Plans resulting from SMJ typically arise at the beginning of the year for a given year. It is no exception, however, when, for example, an internal audit plan is three-year, i.e. approved once every three years, and a schedule of audits for a given year is created for each year, fulfilling the terms of reference set out in the plan.

In any case, a plan is a document that relates to a project or area. It should be created as a concept that is approved. If it is created on the basis of a methodology, the methodology will include workflow in the form of a sample task, which will describe in more detail what needs to be done in the preparation of the plan. Details can also be found directly at sample plan.

Plan is not a schedule

The section title is slightly provocative, because of course a schedule of tasks is typically part of the plan. However, the provocativeness was intentional, because often the two terms are equated and the plan is then understood only as an inventory of who will do what when.

Of course, it is also necessary in the planning to say who will do what when, but as we described above, this is not the only thing and there are quite a lot of reasons to separate the schedule from the plan.

The schedule of tasks is not in the document

As mentioned, the schedule of tasks is part of the schedule rather than the plan itself. The main reason for splitting the schedule and the plan is the very different life cycle of the two types of information.

Example – changing the schedule of the project

Project Plan is typically approved at the beginning of the project and unchanged throughout
Project Schedule_
It often comes into existence only after the project has been approved, a lot of information from the project plan affects it and it is therefore necessary to take the plan into account in the schedule
Under the change procedure, the schedule is updated, but not the project plan
More people are involved in the approval of the plan – e.g. quality manager, project office management, client representatives. The change of the project schedule is approved by the project management board, where there are representatives of the customer (internal customer for internal projects) as well as of the contractor (implementation team), but not everyone who has commented on the project plan is there.

Differences suggest that it is advisable to split the schedule and schedule for larger projects.

Other plans and schedules are similar

The situation for other plans is similar. For example, changing the schedule of internal audits according to ISO 9001 can usually be done by the head of the quality department without approval by the company management, but the audit plan must be subject to approval by the management.