Project Management Compendium

What are the minimum requirements to be able to start a new project with a chance of success?

• A properly defined project goal (see chapter definition of goals).
• A clearly defined client or contact person for the project manager in the event of technical and organizational topics.
• Defined tasks, authorizations and responsibility for all positions involved in the project (these are at least the client, project manager, project team members, usually also line managers (group leaders), decision-making bodies, quality assurance officers, etc.) (see chapter on project organization). The individual team members must be aware of the consequences of their role (e.g. changed scope for decision-making compared to the line function).

The "right" project team members in terms of:

• Know-how (what requirements does the project place on the employees in technical terms?)
• Motivation
• Availability (Can the employee really be released to the agreed percentage? Who will take over his previous tasks? Can he return to his original area of ​​work after the end of the project?) zurück?)

What other measures could help me when starting a project?

• Implementation of a project kick-off (see chapter Project Kick-Off).
• Overview of all tasks that the individual team members permanently perform during the project (minutes etc.).
• Creation of a project file (see chapter project documentation).
• Creation of a project diary.
• Setting up a project office (meeting room for the project team, equipment pin board, flip, overhead, PC network with PM software access, project wall on which all the important messages for the team are attached and the current project plan).
• Support from PM software

What is the target definition of a project?

The target definition of a project is a clearly specified point at which the project is over. This means that a clean project conclusion can only be carried out if the project goal is properly defined.

The target definition is usually the result of a coordination process between the client and the (future) project manager. The project goal often consists of:

• the actual "core objective" and
• ea detailed supplement to the content (e.g. specifications, technical concept, service description)

Why should a project goal be defined?

• So that the project manager has a secure basis for planning and action.
• The target definition is the starting point for the structure of the entire project planning ("If you don't know where you want to go, you will definitely end up somewhere else!").
• So that the client of the project knows what he is getting.
• To fix the project completion in order to avoid misunderstandings at the project completion.

What should a goal formulation look like?

You should be able to assign the following attributes to a correctly formulated project goal:

• reachable
• Completely
• free of contradictions
• not interpretable
• verifiable
• solution-neutral
• documented
• agreed between the client and the project manager and accepted by both

The following tips can help to formulate the project goal correctly:

• When formulating or reviewing a project goal, put yourself in the role of the counterpart (i.e. project manager or client). Try to speak in his words, to put yourself in his shoes.
• Try to put yourself at the end of the project and describe the situation as it should be! This helps to find more concrete formulations and to describe the project goal more clearly.
• It would be important to find and describe a point as clearly defined as possible for the end of the project.

As a rule, the two parameters deadline and costs (budget) depend on the content of the project goal.

For this reason, there are also projects in which only the content-related project goal is defined in the first step. Only after a so-called preliminary investigation, an initial rough planning of the project (the methods correspond to those described in the project planning chapter, but on a less detailed level) are dates and costs calculated and agreed between the project manager and the client.

The rule of thumb could be:

Deadlines and costs are part of the project goal if the content goal becomes largely worthless for the client if costs and deadlines are exceeded. (for example: preparation of a trade fair presentation)

What is the project organization?

Due to their complexity, projects often require the cooperation of different departments of a company. In order to still be able to organize the project management efficiently, a separate project organization is set up for each project, which only exists for the duration of a project - in contrast to the "normal" line organization of a company.

There are fundamental differences between project organization and line organization:

The project organization essentially consists of:

• Client
• project Manager
• Project team

In order to relieve the client, one or more additional decision-making bodies are often set up, such as a steering committee, a steering committee or a voting body.

In addition, other roles such as quality assurance or configuration management can supplement the project organization.

The project organization must be defined in a company-specific PM concept and expanded to include the specific technical tasks at the beginning of each project.

What is a project framework?

The project organization is defined by role descriptions in which the tasks, authorizations and responsibilities of all project participants are defined as clearly as possible. This in particular avoids organizational conflicts (e.g. between project and line organization) between those involved.

For this reason, the roles must be clearly described before the actual project start. If possible in the form of a company-wide regulation that is mandatory for all projects. The so-called project framework organization.

What is the project documentation?

The project documentation consists of all the important texts, drawings and other documents that help to understand the course of the project. The aim is to document the process for achieving the project goal. The project file in which these documents are stored is primarily used for this purpose. A distinction must be made between this and the product documentation, which documents the result of the project (e.g. the device that is to be developed or the IT system that is to be programmed).

Typical documents in a project file are:

• Project order
• Project organization including telephone numbers
• Project plans
• Amendments
• Status reports
• Plan changes
• Final report

Most project planning systems offer a variety of options for documenting the course of a project. This includes text-based reports and graphics, which can usually be tailored to the specific needs of those involved in the project with the help of filter functions. Examples: cost curve and histograms, capacity diagrams, status reports, etc.

Why does it make sense to create project documentation / project files?

The project file ensures that the current status of the project planning and the project order including change orders is available at all times. All important information about the project can be found in it. Furthermore, the project file serves as an important aid in the preparation of the final report and to secure experience.

How can project documentation / project files be structured?

The following table of contents has proven itself:

1. Project order, information from preliminary studies, profitability calculations, etc.
2. Project organization including telephone numbers and department names
3. project-specific agreements such as rules of the game, software tools to be used, documentation standards, etc.
4. first approved project planning (= initial planning) (project structure plan, milestone plan, effort estimate, schedules, cost planning, etc.)
5. last approved project planning
6. current internal project planning
7. Milestone reports, status reports
8. Meeting minutes
9. Final report
10. Telephone list of all project participants (active, temporary, informative)

Of course, a project file can also be kept purely electronically (e.g. on the intranet or internet) with a corresponding directory structure. In any case, it is important to establish who is responsible for maintenance and where the current status can be found. It makes perfect sense to offer all project members the quickest and easiest possible access to all relevant information.

A project kick-off is the first official meeting of the project team after the project assignment has been placed. It is not yet used to work on the content of the project, but is intended to give the team members the opportunity to find out about the project goal and to get to know each other.

What are the goals of the project kick-off?

The project kick-off is intended to serve various purposes:

• Organization (minutes, room reservation, decision-making, moderation, etc.)
• Communication within the team and with the environment
• Code of conduct (preparation of meetings, punctuality, maximum speaking time, etc.)
• Sanctions for non-compliance with the rules of the game ("team treasury", or similar)

Presentation of the individual team members

In order to ensure direct communication in the project team later on, it must be clear to each team member who has what experience and which areas of expertise. This is particularly important for topics that are not directly related to the actual project topic, as knowledge from other, related areas is often useful for solving tasks. This is also the right time to ask about the expectations, hopes and wishes of the team members and to correct them if necessary.

Clarification of the roles of the individual team members

For each team member there are already one or more roles assigned to them (technical and / or organizational) at the beginning of a project (see chapter Project organization). These should be addressed during the project kick-off and, if necessary, corrected or supplemented.

Creation of a common information stand for all project participants

Since rumors about the new project usually arise in the run-up to an official project assignment, the team members should be informed at the very beginning, in particular about the exact project goal and other framework conditions. If possible, it makes sense to put the goal up for discussion again and thus involve the team members in the goal-setting process.

Establishing the rules of the game for teamwork

Cooperation in the project team can be made more conflict-free by agreeing the rules of the game. They should be worked out jointly by all team members so that there is a high level of acceptance right from the start. At the end of the day, the rules of the game must be supported and implemented by all Teem members. That in turn does not mean that every rule idea applies here. That was beyond the scope. It's about a first mutual agreement and determination.

The following subject areas can be included in the rules of the game:

• Organization (minutes, room reservation, decision-making, moderation, etc.)
• Communication within the team and with the environment
• Code of conduct (preparation of meetings, punctuality, maximum speaking time, etc.)
• Sanctions for non-compliance with the rules of the game ("team treasury", ...)

How should a project kick-off work?

The following procedure for a project kick-off has proven to be useful:

• The project manager opens the meeting.
• He briefly introduces himself and also provides information about m & oumle ;, relevant experiences from the past.
• The project manager briefly presents the content of the project goal. Each team member introduces himself briefly and describes his experiences, which can be brought in from previous or similar projects. In addition, each participant can express his / her wishes and fears, which are initially recorded without comment.
• The project manager provides further details on the project assignment and also deals with the wishes and suggestions of the team members. This also includes information about the tasks and powers of bodies and committees from the project organization (decision-making committees, clients, etc.).
• The rules of the game for future teamwork are set together.
• The further procedure is agreed (next appointment, items on the agenda, etc.)

The session should last a maximum of 2 hours.

What should be avoided at a project kick-off?

• Rules of the game for cooperation in the project team dictated by the project manager.
• Content-related discussions about the procedure in the project. A separate planning workshop should take place for this purpose.
• Project managers who put themselves in the foreground and do not respond to the wishes and questions of the team members.

In each group or in each project, its members have different roles. Sometimes they are set in advance, but often they only form during the group formation phases. The following article aims to define and explain the role of the project manager in more detail.

The project manager is primarily responsible for the operational planning and control of the project. In this context, he is responsible for the achievement of material, deadline and cost targets in the context of project implementation.

In the area of ​​planning, he defines goals and the resources required to achieve them:

• Range of the competence of a project manager
• Tasks of the project manager
• Requirement for a project manager
• Summary

Range of the competence of a project manager

The scope of the competencies of a project manager depends primarily on the management structure of the project groups. A distinction is made between two types:

In non-hierarchical project groups , all group members have equal rights; they are jointly responsible for the project result.

In contrast, in hierarchical project groups, one member is given special competence and responsibility.

The scope of the competence depends largely on the form of the project organization and ranges from the mere right to information and application to unrestricted management competence within the project. It can change in the course of the project implementation.

Tasks of the project manager

In the context of project planning, the main tasks of the project manager are resource and budget planning, as well as the objective of the project.

Project definition

Formulation of realistic project goals as precisely as possible: The state that should prevail at the end of the project, measures to achieve the target state are not part of the goal formulation. If no specific project goals have yet been discussed with the client, it is the central task of the manager to coordinate these with the client. This also includes the documentation of the project order in order to secure the approval of the project by the steering committee.

Design of the project organization / culture and composition of the project team

Project organization includes, above all, the definition of roles, the integration of the project into the existing company structure and the development of project-related team and communication structures. When it comes to the composition of the project teams, the quality and number of members must be taken into account. On the one hand, all important interest groups should be represented, but on the other hand, the size of the team should not be exceeded, as you can only work really efficiently in groups of up to eight. The project management should also use a targeted organization to set structures that limit the chaos and the resulting uncertainties (structuring in project stages and project phases).

Creation of project plans and their maintenance

The project manager is responsible for planning, coordinating and controlling the project efficiently. Traditional instruments such as network planning, project cost planning and resource planning help him with this. The newer planning instruments also include project definition, analysis of the project environment, project structure planning and phase-related workshops (project start, milestone, project completion workshop).

The above-mentioned instruments help to view projects in their entirety, show dependencies and facilitate internal project communication.

Design of the project information system and communication

• Planning of suitable communication structures
• Motivation of the members for intensive communication
• Forwarding required information

Environment management

The members of project teams are often grouped together from different departments, whereby department-related interests arise. For better understanding: In a product development project, for example, the technical department primarily strives for a technological solution, while the sales department in turn wants a competitive product. It is the task of the project manager to take on a so-called integration function:

• Balance different interests
• Bridging cultural differences
• Formation of a team that pulls together

Project controlling

In connection with project controlling, the project manager monitors project performance, deadlines and costs as well as their compliance with defined project goals. The transfer of this activity to a team member is common in practice (project controller)..

Project documentation

The project manager is responsible for ensuring that department heads affected by the project are regularly informed and that the project results are jointly coordinated at agreed times or if necessary (e.g. in the advisory committee). (Lit: Patzak / Rattay

Leadership in projects

The project manager often leads employees without being their direct superior (disciplinary subordination). Even without this direct power, the project manager wants his project to be motivated and reliable - in practice this is often difficult to achieve and can only be achieved with a high level of motivation on the part of the project manager. As already mentioned, the management of the employees depends on the respective management structure. The manager has the following tasks and competencies:

• Assigning appropriate project subtasks to group employees
• Education and training of the group with regard to project results and their achievement
• Resolves conflicts within the group, as these can make internal cooperation more difficult
• Strengthening the team spirit and motivating the group e
• Creation of a creative working environment (avoidance of resistance to new solutions)

In practice, people affected by the organizational problem are often employed as project managers in order to prevent organizational or IT matters from outweighing the interests of those affected. (Lit .: Schulte-Zurhausen)

A project manager should have the following qualifications and skills:

• Social qualifications, especially the ability to lead the project group (ability to delegate, role model function)
• Mastery of PM instruments and their application. Experience in project work
• Resilience and adaptability: time pressure, dealing with resistance
• Communication skills: coordination tasks, sociability, persuasiveness, assertiveness, toughness and negotiation skills

The German Society for Project Management eV (GPM) formulates it according to the leadership skills:

• Social skills
• Methodological competence
• Organizational skills
• Professional competence

Here, attention is also increasingly drawn to social skills, as projects focus primarily on people.

Why should project planning be carried out?

Only after you have planned a project do you get an overview of which steps need to be taken next. Project planning therefore gives you the assurance that you are doing the right thing at the right time. A well-founded and realistic project planning is also the basis for a functioning project control. It is used like a map, which makes it possible to determine the deviation from the correct path as early as possible - not only when you are hopelessly lost. In addition, the achievement of intermediate goals motivates to tackle the further path until the project goal is reached. Often you only notice when you can tick off planned items as "done" that a lot has actually already been implemented.

How do I go about planning a project?

Once the project planning has been completed, the client usually approves the schedule and budget. It makes sense to inform them by means of the following documents:

• Project structure plan (to provide a complete overview of the entire project)
• Bar chart (to show the timing of the project)
• Milestone definitions (in order to agree with the client which results must be available at which milestone)
• Cost plan (to make the expected costs transparent)

Take Care!

Work package descriptions, network plans, load diagrams or other plan documents should only be passed on if this is expressly requested, as they contain detailed information that is only of secondary interest to the client.

What possibilities and limits does project management software offer?

Project management software supports the user especially during the planning and controlling process. However, there are also limits here, as the following table shows.

What is a work breakdown structure?

A work breakdown structure (PSP) is an overview (usually graphical) that contains all the activities necessary to achieve the project goal. The PSP is developed jointly by all members of the project team. In addition to the individual activities (one often speaks of "processes") it also contains the names of those responsible for their implementation.

With regard to the project structuring options, there are considerable differences between the common PM systems. Very few products support graphic representations. Even the automatic generation of company-specific structure codes with the help of code masks can by no means be mastered by all systems.

Why should I create a work breakdown structure?

There are several reasons for creating a work breakdown structure:

• Thanks to the graphical representation of the tasks in tree form, the entire PSP can be checked for completeness relatively easily - even by experts who were not involved in the planning themselves. This is also the most important purpose of the PSP - a list of all tasks necessary to achieve the project objective as complete as possible.
• The project structure plan promotes holistic thinking, since the entire project is always mapped here - even if project phases that are further away are initially roughly planned.
• Since the work breakdown structure is very easy to understand, it is also suitable for presentations. It is also an excellent means of communication, in which every project member immediately recognizes his contribution to the overall project.
• The project structuring promotes the team development process, as this is the first jointly developed result in the context of a new project.
• The PSP leads to a subdivision of the overall project into smaller, more manageable activities and thus helps to reduce complexity and to get it under control.
• With the help of the project structure plan, interesting aggregations with regard to costs, effort and deadlines can be made during planning.

What principles can I use to structure a project?

Based on the project goal to be achieved (= object-oriented, product-oriented) ->

Here, the agreed project goal, e.g. a new measuring device, the personnel development concept or the new software is broken down into its components:

Starting from the way to achieve the project goal (= process-oriented, function-oriented, phase-oriented) ->

Here, the path that has to be covered to achieve the project goal is broken down into smaller, mostly chronologically ordered sub-goals:

Project structuring principles:

The most important goal of the PSP is the completeness of all activities. It should be noted that all activities are clearly delimited from one another, especially to avoid overlapping.

As a rule, both structure principles will always appear in a work breakdown structure (then we speak of the so-called mixed-oriented work breakdown structure). However, one should try to detail an element only according to a uniform principle. This only enables a check for completeness.

Risks and ambiguities that arise during project structuring should be marked and recorded and given special attention during the course of the project.

The PSP should be detailed until all activities of the lowest level (= work package) can be assigned to exactly 1 person responsible.

The aim of the work breakdown structure is not to show a sequence of activities. The PSP serves only to break down the content of the project objective.

What are work packages and what are they used for?

The lowest level in the work breakdown structure is called work packages (WP). This is achieved when exactly one responsible person can be assigned to a work package. This ensures compliance with the promised dates and costs and the provision of the agreed results.

Each work package is a clearly delimited and self-contained unit. The work packages form the basis for further project planning.

How is a work package described?

For a more detailed description of the content of a work package (the mostly short description of the work package in the work breakdown structure is not sufficient!), At least the following information must be available:

• Short name
• WP-Nr.
• WP responsible
• Objective / results of the work package
• Requirements for delivering the results

optional:

• Task description (which tasks are to be carried out?)
• Signature fields for the project manager and the AP person responsible (the signature of the project manager and the AP person responsible is not absolutely necessary. However, it emphasizes the contractual nature of the AP description and is particularly important in the matrix project organization).

When determining the results to be achieved in a work package, the principles of the target definition (see chapter target definition) must be observed!

What are milestones?

Milestones are important events in the course of the project and mark the completion of important project steps. They result from the project structure, i.e. from a breakdown of the project goal into sub-goals (these can be product or process-oriented - see also project structuring).

What are milestones used for?

Milestones are points at which a decision can be made about the further progress of the project. For example, particularly important milestones are referred to as gateways or reviews, and when they are reached a review session is carried out. Here it is first checked whether the results specified for this milestone are available. In addition, a decision is made as to whether the project will continue as planned, be canceled or partially repeated.

A milestone is always an event (results are available, decision has been made), from which it can be clearly determined whether it has occurred or not. Therefore, an objective determination and representation of the project status as well as a well-founded reporting system can be based on this.

Milestones can be combined into so-called milestone plans. These provide a quick overview of the key points of project planning and are therefore also suitable for informing management.

In addition, correctly defined milestones are the basis for an interesting controlling instrument, the milestone trend analysis (see project controlling).

For the marathon runner, important milestones are marked in color to motivate them for the remaining distance. The definition of milestones also serves the same purpose: it motivates you to always take "intermediate spurts" and not give in to the frustration of the project goal, no matter how far away.

Almost all PM systems mark milestones with the help of special symbols. A graphic milestone trend analysis, on the other hand, is only provided for relatively few programs, for example Acos Plus.1. In almost all cases, the Graneda Professional program from Netronic can be used, which can import project data from common project management systems and then generate a graphical milestone trend analysis.

How are milestones defined?

The definition of a milestone includes:

• MS name MS responsible Date for the provision of the
• MS Results established
• MS results (e.g. documents, prototypes, decisions, etc.)

How do I proceed with the effort estimate?

The work packages from the work breakdown structure (see project structuring) are the basis for the effort estimate. Each work package is considered on its own. The following procedure is recommended:

• Estimation of the amount of work (= effort or work, specified, for example, in person-days [Pt] or hours [Ph]) that will probably be necessary to achieve the goal / result of the work package. If possible, the effort estimated here can already be divided up according to individual resources (e.g. bricklayers and unskilled workers).
• Since every estimate is based solely on experience, it is necessary to back up experience in order to improve the effort estimate. The methods to support the effort estimate are all aimed at systematizing the safeguarding of experience and making it as transparent as possible.
• When estimating the effort for a work package, the responsible employee should definitely be involved - the project manager alone will usually not be able to do this.

The effort depends on the work content of an WP!

• Estimation of the maximum intensity with which a resource can generate this effort (= use of personnel or resources, given either in [%] or, for example, [Ph / T]). There is a "natural" upper limit here. For example, 4 workers cannot dig a 1 x 1 meter hole at the same time or 2 programmers work on the same module.
• Holidays, training courses or other planned absences of resources are not yet taken into account in this planning stage; this is done as part of the plan optimization (see chapter Plan optimization).
• The time required (= duration, specified in days [t], weeks [w] or hours [h]) for the implementation of a work package can be derived from the two variables of effort and (maximum) personnel deployment. The simplest calculation formula used for this is: duration = effort / personnel deployment
• If you have already estimated the effort for the individual resources separately in the first step, each resource has an individual processing time. The longest processing time is identical to the total duration of the work package.
• These steps are carried out for each work package.

After the effort has been estimated, the estimated effort can be transferred to the project management software.

With regard to the efforts to be made, most PM systems provide more or less differentiated calculation rules. In many project planning programs, for example, it can be set so that a doubling of the resources working on a process results in halving the respective process duration. However, this automatism does not always lead to realistic results (see above: "natural upper limit"). The mapping of variable capacity curves is not possible with every PM software. Example: A developer should only work a few hours on a process in the initial phase of a project and increase his daily number of hours as the project progresses.

What are the most common mistakes when estimating effort?

• Experience has shown that effort estimates for new topics or by employees who only rarely consciously estimate effort tend to be too low rather than too high.
• Many employees do not clearly separate effort and duration. However, the effort depends on the work to be done, the duration, on the other hand, can be influenced by more or less intensive work on an AP.
• A conscious and systematic safeguarding of experience, a basic requirement for a well-founded estimate of effort, is often not done for lack of time or other reasons.
• Much of the information about the likely effort is made under the pressure of scarce resources and tight schedules - and is therefore unrealistic from the outset.
• The responsible employees are not or only insufficiently involved in the effort estimate. This is essential for reasons of motivation alone, not to mention specialist knowledge.
• Project management also causes effort! However, this is often not included in the planning. The same applies to expenses for quality assurance.

Which procedures support me with the effort estimate?

To support the effort estimation in different phases of the project planning there are different methods (e.g. function point, COMO, experience databases) in which a certain amount of experience in similar projects has to be made available as "input" so that a statement as "output" can be made about the expected effort of a project. In addition, relatively detailed information about the project is usually required so that these methods can be used.

For this reason, it is mainly the expert survey that has prevailed in practice. Essentially, one or more experts are asked about what they believe will be expected expenditure for the project or work package.

For some PM systems there are modules that support the effort estimation (Function Point, COMO, etc.)

What is scheduling and what is it for?

The work packages defined in the project structure cannot always be processed in parallel and completely independently of one another.

Many work packages have objectively necessary, logical interdependencies (e.g. the shell must be in place before the roof can be put on). These must be determined during project planning and documented in such a way that they remain traceable.

The suitable instrument for this is the network plan. In it, the work packages (see chapter work packages) are brought into the order required for objective reasons by means of so-called relationships.

Note: In the terminology of network technology, one often speaks of "processes" instead of "work packages". The term is mostly used synonymously with work package.

The main task of the network plan is:

• Making transparent which work packages are decisive for the duration of the project - the critical path. This is important because the project duration can only be influenced by critical processes - both when optimizing planning and project control!
• To create a simple and efficient basis for simulations. If all dependencies are correctly defined, it is sufficient to change a single work package duration or a date to see the effects on all other work packages in the project.

Important:

Working with network plans only makes sense if software is available for the calculation. The manual maintenance of a network plan is too time-consuming.

Although the network plans used in PM systems are almost always process node network plans, the term "PERT", which originally referred to event node network plans, has become established in practice. Nowadays the term PERT mostly indicates the presence of a graphical network plan.

The quality of the network plans generated by PM systems varies greatly. Often there are no right-angled connecting lines between the network plan nodes, which quickly results in a confusing picture in more complex projects.

What are the relationships?

Relationships represent the dependencies between the individual work packages in the network plan. The following types of relationships exist:

In addition, a so called time value / time interval can be assigned to each relationship. This means that the two work packages linked by the AOB are either separated by a certain period of time (positive time value) or overlap (negative time value).

Positive time values ​​are particularly often used in conjunction with ending or starting sequences.

How are the critical path and buffer determined?

The critical path is the connection of all critical work packages in a network plan. A work package is critical when the earliest and latest situation are identical.

The earliest position of a work package is determined during the forward calculation. For each work package, it is calculated when it can start (depending on its predecessors) or end (earliest start + duration of the process). The backward calculation then takes place. Here it is determined for each work package when it has to end at the latest in order not to postpone its successors. If you subtract the duration, you get the latest start time. The latest start and end times together are called the latest position.

Work packages that are not on the critical path, i.e. for which the earliest and latest situation are not identical, have a buffer.

The vast majority of project planning programs can show the observer the critical path by means of appropriate color markings. In this way it becomes clear which project activities must be devoted to greater care, since delaying them will result in a postponement of the planned project end date!

What is the relationship between the bar and network plan?

The bar plan is primarily used to visualize the schedule. The scheduling results from the network plan - this means that the bar plan primarily shows the results from the network plan in a less abstract, easily understandable form.

The so-called "networked bar plan" is a hybrid form of bar and network plan. In addition to the temporal position of the work packages, it also shows the relationships. This is a good compromise, especially for smaller or less networked projects. However, if the bar chart is manually created and managed, it quickly becomes confusing from a certain size.

What is the purpose of planning project costs?

As a rule, the official issuing of a project order is also associated with the approval of a specific project budget. The project manager is responsible for achieving the agreed project goal within the scope of this project budget.

In order to verify the size of the project budget, it is necessary to estimate the expected project costs. Only then is it possible to make a well-founded statement of how much the realization of the project goal is likely to cost. If the expected project costs are above the project budget, the project manager must coordinate this with the client immediately. If a corresponding budget correction is rejected, this should also be substantiated by the client. If cost planning and project budget match, then cost planning is the basis for cost-oriented project management.

Important:

The project cost planning deals exclusively with the costs incurred for processing the project. A distinction must be made between this and the product costs incurred, for example, for the subsequent manufacture or maintenance of a product (developed as part of the project). In the area of ​​technical product development in particular, there are specific methods (e.g. target costing, value analysis) to also control product costs in the context of project implementation.

How do I get well-founded project cost planning?

The basis for project cost planning is the project structure plan (see chapter Project structuring), which contains a complete list of all work packages necessary to achieve the project goal. It is therefore sufficient if the costs for the implementation of all work packages are known - the sum gives the planned project costs.

To plan the work package costs, cost type accounting is primarily used. For this purpose, the cost types of the company accounting can be used. If this is too detailed or unsuitable for other reasons, the following types of costs are recommended:

These cost types can be assigned directly to the project. Overhead costs incurred in the company such as rent for company buildings, heating, electricity, room maintenance, etc. are usually already covered by the billing rate for the staff and are not allocated to projects separately.

Most project management systems do a good job of planning and controlling project costs. Period-related cost considerations with regard to certain resources or project processes are usually easily possible. However, some products have weaknesses when it comes to realizing "real" cost type and center accounting. Even cost fluctuations and overtime rates cannot be taken into account with all common PM systems.

The so-called earned value analysis is becoming increasingly important (also called labor value analysis or earnings value analysis). Earned value analysis key figures determined by the project management systems help the project manager - provided they have been interpreted professionally - to identify cost and schedule deviations at an early stage. This means that countermeasures can be initiated in good time - “Teamwork (introduction to IT-supported project planning).

What is the planning step "Plan optimization" used for?

The planning made so far does not yet take the project environment into account. So far, the milestone dates that may have been agreed with the client have not been incorporated, nor have the availability of resources been taken into account.

This is made up for in a very systematic way during plan optimization.

Criteria for optimization?

The parameters relevant for plan optimization can relate to one or more of the three most important planning elements:

• Resources - e.g. due to limited availability, vacation or otherwise planned absences.
• Dates - e.g. in the form of milestone dates already agreed with the client, which are to be incorporated into the planning.
• Costs - e.g. through liquidity planning for large construction projects

Plan optimization based on resources?

The main interest in optimizing a project plan will usually be the utilization of resources. In order to include these in the project plan, the so-called load diagram (also called resource histogram or resource graphic) is used. Every load diagram consists of two basic elements:

• resource availability and the
• Resource requirements

The resource availability shows the probable capacity with which the resource (e.g. an employee) is available for the project. If the employee is on vacation, the line drops to zero. The resource requirement results from the previous planning:

The size of the area reflects the estimated effort (see chapter effort estimation), the timing results from the network plan calculation (see chapter scheduling).

The comparison of availability and demand provides information on whether the planned effort can be met in the time allotted. If the demand exceeds the availability (as can be seen in the graphic), the planning cannot be implemented in this way. It has to be optimized again:

1. The availability is changed because the deadline has to be kept - scheduling on schedule.
2. The dates are changed and tasks pushed back because the availability cannot be increased - resource or capacity-based planning.

If both planning approaches do not achieve the goal, namely to achieve the required result (project goal) in the required time, only the amount of effort (the hatched area in the diagram), i.e. the work volume, can be reduced - e.g. by reducing the scope of the order or the quality . (see chapter project control)

To eliminate resource overloads, most project planning systems provide the option of automatic capacity balancing. By utilizing buffer times (time margins), PM systems shift project processes in such a way that resource overloads completely or at least partially disappear.

However, the quality of the comparison algorithms implemented in the PM products is very different. In this way, the PM systems generate very different results for a given problem (project plan with resource overload) (project plan without resource overload).

Almost all PM systems are capable of eliminating resource overloads, but the project plans generated in the process differ greatly in terms of their project duration ("optimal solution (crisis management with project planning systems).

What is the procedure for optimizing appointments?

The aim is to include any dates that have already been agreed in the planning, in particular milestones (see chapter Milestones) for which a date has already been agreed (eg "Pilot version will be completed by July 15"). In principle, manually setting appointments always means intervening in the network plan logic - which should actually be avoided in order to give the network plan algorithm maximum freedom. Milestones are important, however, in order to set up an early warning system that takes effect before the end of the project is at risk.

Example:

According to the network scheduling, a milestone can be reached on 08/15 at the earliest. to be finished. Lt. Agreement with the client, the milestone must be no later than 01.09. be achieved. If you add this premise to the network plan (latest end of the milestone - deadline), all activities in the path before the milestone receive a two-week buffer. If these two weeks of buffer are used up (e.g. due to unforeseen delays), the processes become critical.

The possibilities of realistic scheduling and process planning increase if a project management system provides a large number of so-called deadline restriction types (e.g. process no earlier / later than, must start / end on, etc.). The cash flow - for example as late as possible - can be influenced with the help of special types of restrictions (see below: How do I go about optimizing plans based on costs?) But where there is light, there is also shadow: Restriction types set the flexibility of the automatic capacity leveling, which is why we recommend using them sparingly.

Special attention is usually paid to the critical path (critical path) of a project, as this affects the project end date. For this reason, almost all PM systems provide mechanisms that particularly emphasize the critical path, for example filters!

What is the procedure for cost optimization?

An optimization of the plan according to the cost incurred usually only occurs in special cases with very large projects. However, it can be important here to start certain cost-intensive work packages as late as possible - after all, high financing costs may have to be assumed.

The basis here is also the network plan. Similar to the optimization by resources, the work packages can be pushed back to get a better payment history. For example, a comparison of planned project costs and incoming payments is used for visualization.

What is a risk analysis for?

The task of the risk analysis is to identify and evaluate factors that pose a threat to the success of the project (to provide the service defined in the project order in the planned time with the planned resources within the specified budget) and to prepare or initiate appropriate countermeasures.

A distinction must be made between:

• Project-inherent risks (project risks) - risks that arise from project execution, i.e. from the process and
• Product-inherent risks (product risks) - Risks that result from the product to be created, i.e. the new engine or the new form of organization.

The project risks are also discussed in the PM primer. For risk management of product risks, depending on the type of product (technical products, software, plant construction, etc.), there are usually even company-specific concepts (e.g. FMEA), which are usually part of quality management.

How do I find out project risks?

The first step in risk analysis is risk identification. The aim is to identify all conceivable dangers to the success of the project.

There are two sources for this:

• Creativity - creativity techniques can be used sensibly here, such as brainstorming.
• Experience - they are usually "preserved" in the form of checklists and can also be "tapped" through expert surveys.

Typical project risks (examples):

• Failure of important employees during project processing due to illness, termination, etc.
• Failure to meet promised dates.
• Lack of acceptance from potential users of the product.
• Too optimistic planning.
• Delay due to an unclear definition of the project roles and the resulting conflicts of competence.
• Interpersonal conflicts between team members.
• etc.

A useful basis for identifying risks is the project structure plan (see chapter Project structuring), which you can search for project risks at every level!

Some project planning systems try to reduce the risk of a one-time estimate (e.g. too bad / well-estimated) by offering the user the option of performing a multi-time estimate (often implemented as a so-called PERT analysis). For example, the user provides a pessimistic, a realistic and an optimistic estimate of a project process duration. The software uses this information to determine the likely duration of the process. It is doubtful whether this is ultimately "more realistic", since the input parameters (three estimated values) should also be provided with a certain uncertainty factor.

How can project risks be assessed?

A risk is always a high risk if two properties are met:

• The likelihood that the risk will occur is high.
• The impact if the risk occurs is high.

Accordingly, it makes sense to enter the project risks found in a portfolio.

It is advisable to list the "top ten" of the risks when planning and to update them, for example, monthly - just thinking about possible risks shortens the reaction time when they actually occur!

What options are there to reduce a risk?

Measures to control risks can either reduce the likelihood of occurrence or reduce the effects if a risk occurs. Both preventive (risk minimization in advance) and corrective measures (emergency planning) are possible.

In any case, please note:

• There will be no project without any risk.
• It is important to be aware of the risks that the project entails. Not none but the right risks are to be borne!
• Try to find and document the causes of the occurrence of a risk - this will allow you to tackle the problem at the root!

What is project management and what is it used for?

• Project control (project controlling) means all measures that serve to bring the actual course of the project into line with the original planning. The project manager has to act and not react. He is required to actively influence and thus control the project.
The more time the project manager spends in project control on taking the necessary measures and implementing them together with his project team, the higher the quality of the individual control measures and the more opportunities there are to react to deviations.
• The aim of project controlling is therefore to set up an early warning system that shows the project manager as soon as possible and as clearly as possible when a reaction to deviations from the plan is necessary.

How do I proceed with project management?

The project control runs periodically in repetitive steps:

• Recording of actual data: The basis for every project controlling is information on how the processing of the individual work packages is going.
• Analysis and evaluation of the actual data: In the second step, the actual data collected is to be related to the planning. It is important to determine the effects of the current situation on the further course of the project.
• Definition of control measures in the event of deviations from the plan: If the evaluation of the actual data has made it clear that the achievement of the project objective is at risk, appropriate countermeasures must be taken to bring the project back into plan or to adjust the plan.

Which actual data do I need as a basis for project control?

Actual data can refer to all project control parameters:

• Events
• effort
• costs

There are two aspects to consider for all actual data:

Past-related actual data is the "classic" actual data that is recorded in many companies for business reasons. So there is often an actual effort recording that all employees have to keep, for example weekly. Interesting conclusions can be drawn from this data, e.g. with regard to the division of the entire department effort into new developments, troubleshooting, product support, administration, etc. Past-related actual data is therefore mainly used to back up experience.

The key question is "What has happened so far?"

Examples:

• Actual start and end date of an activity.
• costs already incurred (actual costs).
• Expenses already made (actual expenses).

More and more planning systems enable feedback of actual data by e-mail. The project manager checks the reported data and transfers it (if plausible) to the actual planning system. An alternative to this procedure are the feedback modules offered for some PM systems (e.g. Project Communicator for Project Scheduler 7 from Scitor). Both the one and the other alternative may make the need for a full version of the respective planning system / workstation superfluous: An e-mail client or the feedback module, for example, is sufficient.

Advantage: cost savings!

Future-related actual data:

This forward-looking information is not actual data in a business sense - rather it is updated estimates. This information (e.g. about an expected completion date) is the basis for setting up an early warning system - the main goal of project management! The key question here is "How will the remaining work be done?"

Examples:

• expected completion date of a work package.
• expected remaining effort.
• expected costs.

The question of the likely further course of the project is more important for the active control of a project than the question of the past!

What role does the degree of completion play?

The degree of completion (DC) describes how far a task (or - condensed - a project) has already progressed. It is an interesting metric for reporting.

There is a temporal and a performance-related degree of completion:

• DC (temporal) = actual duration x 100 / expected total duration.
• DC (in terms of performance. = Actual effort x 100 / estimated total effort.

Using the DC to determine the actual data is problematic:

In response to the question "What percentage are you already done?" you often get the answer "90%!" Every experienced project manager immediately becomes suspicious of this - the statement "90% finished" often does not mean "10% left to be done" - the so-called "90% syndrome" has had an effect. This is a purely psychological problem. Because the apparently exact number 90% is only intended to express that a lot has already been done, but a certain remainder still remains.

• The degree of completion is an interesting key figure that can be easily calculated from the actual data collected. However, the direct question of the degree of completion should be avoided - it can all too easily lead to misunderstandings!
• Many PM systems have an activity field% Completed, in which you can specify how far an activity has already progressed. For this purpose, the percentage of the duration of the activity that has already been completed is entered.

Why should I analyze the actual data?

The acquisition of the actual data is the first step. In order to be able to interpret these meaningfully, they must be examined more closely in the second step. The aim is to find out how the project will progress compared to the original plan and what impact the current situation will have.

There are various controlling methods for this purpose, some of which will be briefly presented in the next chapters.

Target / actual comparison

The target / actual comparison is definitely the best-known and most widely used instrument of project controlling. The aim is to make deviations transparent by comparing the original planning (= target) and current planning (= actual) and to estimate their effects on the further course of the project.

In order to make deviations from the plan visible during the course of the project, PM systems provide a more or less large number of interim plans that virtually embody a snapshot of the current project status at that point in time. These can be compared with the original project plan (basic plan), which means that deviations are quickly visible. However, some PM systems - e.g. MS Project - do not save all relevant project data in the interim plans, which they are represented in the basic plan!

The target / actual comparison can be made for all control parameters (dates, efforts, costs), as illustrated in the following graphics:

What all forms of representation have in common is that a line must be drawn that indicates the key date to which the actual data relates. This is the only way to identify which of the information relates to the past and which relates to the future (see chapter Actual data acquisition).

It is important for all representations that the future-related actual data must be incorporated into the planning in exactly the same way as was the case with the plan data of the initial planning. For example, the network plan (see the chapter on scheduling) is recalculated with the updated estimates of the work package duration and the key date as the earliest possible start time.

The result is an updated plan that contains actual data - and should therefore have a higher planning quality than the initial planning, in which no part of the project was yet implemented.

Milestone trend analysis

The milestone trend analysis (MTA) is a very simple and clear instrument for the manual display of the project status. The prerequisite for using the MTA is a realistic schedule in the form of correctly defined milestones (see chapter Milestones).

The MTA is updated in a single graphic for the entire duration of the project. This essentially consists of a triangle on the vertical of which the MS planned dates for the respective reporting times are entered horizontally. This means that, for example, every 2 or 4 weeks, the person responsible for MS is asked to state when their milestone will be fully reached. This date is entered accordingly. If the planned date is changed (or the MS results!), This must be documented. In this way, documentation of the most important plan changes and their reasons in the course of the project is created practically "automatically".

• This gradually creates a curve for each milestone, from which the trend of the project can be read: curve upwards -> delayed deadline
• Horizontal curve -> project in plan
• Downward curve -> earlier completion than planned

The advantages of the milestone trend analysis:

• The simple creation of the MTA does not necessarily require tool support.
• It clearly shows trends - and is therefore a future-oriented instrument.
• Due to the simple interpretation, the MTA is also suitable for presentations of the project status or as an essential reporting medium.
• The drastic representation motivates the project team to make corrections at an early stage.

Those responsible are periodically confronted with the entire project planning - this promotes holistic thinking.

Which control measures are basically possible?

If, when evaluating the actual data, the above instruments identify possible problems in further project management with regard to costs, effort, deadlines or product quality, countermeasures must be taken.

Possible measures in the event of an imminent delay in delivery

• Shortening the duration of deadline-determining processes through:
• Increasing the available capacity (overtime, outsourcing, changing priorities, etc.).
• higher efficiency (external specialist, training, ...) in handling activities.
• Reduction of the scope of services of tasks or of the entire project (which reduces the effort and thus the duration of the process with the same personnel deployment (see chapter effort estimation).
• Change of the order through overlapping or parallelization of previously sequential work packages (note capacities!). This can be done, for example, by negative time intervals in the network plan (see chapter Process planning).
• Moving appointments, if necessary the project end date.
• In the event of an imminent expenditure or cost overrun, the only possible control measures are higher efficiency in order processing or the
• Reduction of the scope of services

How can control measures be assessed?

Two factors are essential for the assessment of control measures:

• Costs - How much time, money and effort does a specific measure cost?
• Effect - What effects does a measure have on deadlines, budget or product quality?

In order to choose the right measure, these two factors must be weighed against each other. Unfortunately, there is no patent recipe for this!

What could a project status report look like?

The project status report is mainly used to inform the decision-makers of a company or the client about the status of a project. If a company has several projects that are regularly reported on, it makes sense to define a uniform status report.

A project status report should consider:

• The reason for the status report should be recognizable.
• It should be possible to fill out the form quickly to avoid unnecessary effort.
• The information about the project status should become more and more detailed from top to bottom so that the decision maker can quickly see whether there are problems in the project.
• There should be space for verbal problem descriptions and decisions directly in the status report.

Almost all project planning systems offer an abundance of predefined and adaptable reports, analyzes, views etc. for output on screen and printer or for publishing on the intranet / internet, which you can use for meaningful project status reports.

What is the project completion?

A project is completed when the project objective is achieved. Without a clearly defined project goal (see chapter definition of goals) it is difficult to complete a project properly! In special cases, projects also end by being canceled. Even then, a systematic project completion is important!

The project completion is the official end point of a project. Thereafter, there are no more efforts to achieve the project goal.

What is a project completion good for?

The orderly project completion serves various purposes:

• Transfer of the product created during the project to the support phase. To do this, questions such as "What happens to subsequent complaints?" "How is the further development handled?" "Who is responsible for the product after the project is completed?" be clarified.
• Future projects will only run better if we learn from the mistakes of the completed project. In addition, securing experience helps to improve the basis for future cost estimates.

During the often hectic and stressful handling of projects, latent conflicts often arise between those involved in the project. The end of the project is the latest time to "repair" any trenches that may have arisen!

How should a project closing session go?

The following topics have proven themselves in a project closing meeting:

1. Review

• What was good?
• What was less good?
• Which goals were achieved / not achieved?

2. Recognition and criticism

3. Assurance of experience for future projects

• What can be learned from the course of the project?
• What concrete measures are taken to prevent mistakes from being repeated?

4. Transfer of the project team members to new areas of responsibility.

5. Information about the project completion

• Who will get the final report?
• Who is only briefly informed about the project completion?

6. Final Party

How is a final project report structured?

The following structure is recommended:

• Project order / project goal
• Planning documents before project approval
• Actual documents at project completion
• Final analysis (comparison of the original and updated plan parameters with the results at the end of the project with regard to: deadlines, effort and costs as well as the achievement of objectives.
• Thanks to everyone involved for their involvement in the project.
• Contact person for further support of the project.

classic contract law:

for example: (german law) BGB, VOB as well as sample contracts and own constructions. This type is formulated comprehensively and completely. The start and end are clearly defined and fixed. The mutual performance requirements and performance expectations are fixed, mostly fixed. The resulting rigid contractual relationship does not allow for a relationship of intensity between the two contracting parties. The selective exchange on the agreed services is superficial.

Neoclassical contract law:

Further development of classic contract law. A long-term relationship is attached to a short-term or one-off exchange of services. For example, in the case of continuing obligations. This permanent moment of the long-term relationship can create uncertainties due to changes in framework conditions.

Relational contracts:

Negotiated contracts have more of a framework character here. The mutual obligations do not result exclusively from the contract but from a large number of elements of obligation rooted in social obligations.
The mutual performance obligations are largely vague and will be substantiated by mutual agreement as required. Conflicts are resolved without damage because the social bond is the motivation for cooperation. Consensual conflict solutions enjoy priority over disputed decision-making. Intensive communication, personal relationships, security and wellbeing take precedence over restrictive and restrictive contracts.
I In relation to the very narrowly drawn up classic contracts, which under certain circumstances can have a co-productive effect, a set of rules that is open on all sides is presented here with open and fuzzy rules.
In relation to the very narrowly drawn up classic contracts, which under certain circumstances can have a co-productive effect, a set of rules that is open on all sides is presented here with open and fuzzy rules.
Keeping gaps open enables both parties to creatively fill the current handling framework through specially developed arrangements. The commitment to the contract partner is the decisive criterion. Problems are not solved in court, but in mutual consultation in direct negotiations.
Meaning is a healthy continuation of the relationship. Possible court costs do not play a role here. The only thing that matters is the working atmosphere between the contract partners. The decision-making power remains with the parties and is not placed in judicial hands.

Practice shows that deviations and changes are almost inevitable with increasing complexity and duration.
In this case, an internal contract solution, including meditation, tends to be quicker, and a mutually cleaner solution to achieve a desired "win-win situation" instead of burning the necessary energies in processes that may take years.