CHAPTER 2

Project Start

2.1 Introduction

The project start is a very important part of your project! During this phase, you build your project base. If this is not done properly, for example, due to high pressure from management to start your project as soon as possible, you will face trouble during the project execution phase.

The following subjects will be discussed in this chapter:

1. Project kickoff
2. Project file
3. Business case
4. Contract
5. Stakeholders
6. Communication management
7. Project definition
8. Change management
9. Risk management
10. Issue management
11. Deliverable management
12. Resource management
13. Financial management
14. Expectation management
15. Project planning

2.2 Project Kickoff

2.2.1 Introduction

The project “kickoff” is an important starting point of the project for all involved.

This implies that all stakeholders and the project team members should be invited and in any case the sponsor must show his/her commitment to the project.

2.2.2 Tips

Often the project team that consists of people who have not worked together in this combination can be a good start. Ask everyone to share in the round of introductions. You could ask each person to introduce himself by:

1. Full name
2. Role
3. Expectations
4. Sharing something personal

Then the project manager can discuss the following:

1. Why this project (business case).
2. Project goals.
3. Project scope (what we do and what we do not do).
4. Dates of milestones.
5. Project deliverables
6. Dependencies (e.g., from other projects or departments)
7. Identified risks
8. Project organization
9. Communication plan
10. Project file
11. Electronic collaboration (Skype, e-mail, etc.)

At the beginning of a project everyone is usually full of energy as everyone is ready to start the new challenge. This is usually put to the test during the project implementation.

You can arrange for instance something to eat and drink during or after the kickoff. However, beware of things such as the following:

1. If you are going to an external location after the meeting you need to make a reservation.
2. People could be allergic or have religious reasons not to eat or drink particular food (or gluten free for instance) or alcohol.
3. How to get to the external location, by car or public transport. How easy is it to get there? Arrange carpooling for instance.
4. Try to arrange a separate room or area in order to prevent other people not belonging to the team from hearing confidential conversations.

2.3 Project File

2.3.1 Introduction

The project file is the conscience of the project! This implies that the project file is the only place where the project documentation is saved! So it is “forbidden” to have project documentation on local computers, USB sticks, DVDs, etc., unless there is a copy of the project file.

However, it is important as a project manager to also take care of “privacy” and “security” of the project data so if people have project data in different media, monitor the risk of loss and all other possible consequences that can be avoided. Of course, the project file has basically a backup where changes, for example, from a month ago can be picked up today. Apply version control as well for documents.

Note: when using “requirements management” or project management tooling, the project file is normally integrated in this environment.

2.3.2 Tips

The project file may have a structure like:

1. Standards, procedures, and templates
2. Organization, people, and other resources
3. Project planning
4. Minutes
5. Risks
6. Issues
7. Changes
8. Delivery
9. Sponsor and stakeholder information
10. Third parties
11. Functional and nonfunctional requirements
12. Quality management

It is also important, as applicable, of course, to save the project file on the following considerations:

1. License overview of software that is purchased at the expense of the project.
2. Overview of the hiring of people (who, start and end dates, etc.).
3. Who, what, and when given access to the project file and when such access is removed.

2.4 Business Case

2.4.1 Introduction

The business case is the project justification. During the project execution, the business case must be validated continuously while for instance the circumstances may have changed in such a way that it is no use to continue with the project.

This document needs to be SMART! If not, you can expect all kinds of discussions both during project execution and during project closure!

In fact the business case must also contain a cost/benefit analysis taking into account ongoing operations and maintenance (also called often “business as usual”). This final part is rather important too!

2.4.2 Content

The business case can be composed of the following subjects (e.g., Prince2):

1. Executive summary. This part highlights key items and should describe the most important benefits and the return on investment. Keep in mind who will read this part in particular: executive management. They make the decisions based on this part and will look for more details in the other business case chapters.
2. Reasons. What is the reason for this project? How will this project contribute to the company’s strategies and objectives?
3. Business options. Which options have been considered including the option to leave it the way it currently is.
4. Expected benefits. This must be SMART.

   The benefits should be both qualitative and quantitative. Furthermore, the benefits must be aligned with the organization’s benefits. For each benefit, tolerances must be defined.

5. Expected disbenefits. Not all outcomes could be seen as positive for some stakeholders.
6. Timescale. Describe the project duration and the period over which the benefits will be realized.
7. Costs. Supply a cost overview of the project, the operations and the maintenance costs.
8. Investment appraisal. Compare the aggregated benefits and disbenefits. The objective is to define the project value as an investment.
9. Major risks. What are the key risks in relation with this project? Describe the likely impact and plans in case the risks become a reality.

2.4.3 Approval

Only after formal approval of the business case by the proper executive management (project board), the project manager is allowed to start. Store this formal approval as quality record in the project file.

2.5 Contract

2.5.1 Introduction

Before a project really starts many steps have to be taken.

The trigger for a project is normally an idea or business need. By means of a business case, the justification is obtained to start the actual project. A project could be executed within the own organization or outsourced to an (external) organization/company.

Whatever option is selected, a formal agreement needs to be arranged, such as a contract, between the requesting and delivery organization. In this context, the delivery organization is the organization that is going to execute the project. After the project has been finished, the deliverables need to be handed over to the organization that is going to execute the business as usual activities to make sure that the deliverables are up and running. This is contracted by means a service-level agreement which is beyond the scope of this document.

2.5.2 Contract Types 1

In the case of a contract with external parties this could be a “real” contract but also a letter of intent (LoI), memorandum of understanding (MoU), “authorization to proceed” (ATP), or a “statement of work” (SOW). LoI, MoU, and ATP are precursors of a contract and already regulate some cases, particularly in the legal field between the parties where the liability is also recorded. Without a formal contract or agreement, a large (legal) risk is possible and should be avoided!

Proceed as project manager to what extent it is possible to charge the external client using LoI, MoU, or ATP (this may not be possible).

When using an SOW, it should be possible to invoice an external client.

In the case of internal parties like India, for example (in a global delivery center), it is normally sufficient with a document of understanding. Do not proceed as project manager before the contract is formally approved by the appropriate management level.

If you start without a contract you lose your negotiation position as well!

2.5.3 Contract Types 2

Apart from the types of contracts mentioned in the previous paragraph, another set of contract types is applicable (the commonly used):

1. Fixed price or lump sum. A contract under which the client agrees to pay the supplier a specified amount for completing work without requiring a cost breakdown. In this type of contract, the financial risk is mainly at the supplier. During the RfP process, you need to find a balance between, for example, risk/profit uplift and being not too expensive, otherwise you’ll miss the boat anyway.
2. Fixed date. This type of contract is applied for instance when the project needs to be completed, left or right, at a particular date. An example is the Olympic Games. I don’t think that the end date could be discussed in case this project is being delayed.
3. Cost (plus fee). This type of contract gives the client maximum flexibility and the supplier minimal profits. A mutual termination period (e.g., one month) should be agreed to be reasonable for both sides.

   An option could be to use the bare cost hourly rates and apply uplifts (e.g., 20% or different uplifts depending on roles) to make an offer.

   Some big client organizations have even standard rates you are allowed to charge so at that stage you can already see if you want to get into the project.

Apart from these contracts, all kinds of other constructions are possible such an incentive fees to push the supplier to deliver as quickly as possible by means of a financial gain.

Then you should also scan the contract for obligation of effort or obligation of results. The main difference is that the first one only states that the supplier will do his best and there is no guarantee regarding the results.

The second one states that the supplier is responsible for the results and in case of not meeting the results (who have determined these and how SMART are they?), the supplier has to achieve the results (costs for the supplier). If the results are not achieved by the supplier, the client is likely to call this a breach of contract and I think there is a pretty good chance you will end up in court.

2.5.4 Tips

Here are some issues that you should consider as a project manager in a contract (and if these are not present then pull the plug):

1. Is the contract actually signed by both the client and the supplier?
2. Have the right parties granted approval within the organization?
3. What deliverables are specified in the contract? Take this explicitly in the project definition/plan and project planning.
4. Who owns hardware and software licenses? Pay particular attention to software licenses purchased because of ownership and use.
5. Have assumptions been listed? Take this explicitly in the project definition/plan and project planning.
6. Pay close attention to (hard) delivery dates and take this explicitly in the project definition/plan and project planning.
7. An initial risk analysis? If so, where are the results? If not you better get an initial risk analysis.
8. Does the contract contain a detailed description of the cost structure? If so, are the project management hours explicitly stated and realistic (not wishful thinking)? If not, then get behind the cost structure unless there is an “hourly invoice” contract. In this case, you should know the hourly rates in the context of financial management.

2.5.5 Terms and Conditions

The negotiation regarding the terms and conditions takes place before the actual contract signature. Governmental organizations for instance have their own terms and conditions and the supplier needs to agree with these. This is a process between the procurement organizations of the involved parties.

As project manager you also need to check these to sort out what you need to keep in mind and need to be compliant with.

2.6 Stakeholders

2.6.1 Introduction

The stakeholders are those who in one way or another have an interest in the project. Stakeholders are also those who can exert a direct or indirect influence on the course of the project. It is important to perform a stakeholder and influencer analysis also from a risk management point of view.

2.6.2 Steps

First it is necessary to get a “picture” of how the organization is structured. This could be an organization chart. However, the organization regarding the project may be different especially when an organization has a matrix form where one dimension is the line organization and the other dimension is of the project organization. Make a chart of the roles of the persons involved in the project and then link names to these roles.

The next step is to gain insight into the informal sector in the company or the “old boys network.” This informal network is often very powerful and of great influence. Within the “old boys network” is a fast communication alive and everything is arranged informally often outside the formal organization. Maybe the decisions are made in this network and communicated via the formal management structures.

Sort out who really makes the decisions within the organization that affect the project. Also determine which persons have hidden agendas and interests.

It is key to perform the analysis of the corporate culture and the local culture. The way people deal with each other within the project should be in line with this. Example: the use of Amsterdam culture (very direct) in Limburg (kind of relaxed) is asking for trouble and opposition.

After the analysis, the stakeholder and influencers are placed in a matrix and the strategy can be determined on how to deal with these people. Persons who minimally affect the project could be disregarded.

Note: in the course of time things can shift in which people who first had a minimal impact on the project suddenly have a much greater impact and vice versa! So it is important to keep an eye on the proportions.

A proposal of an analysis matrix:

Another important analysis that should be done is which stakeholders are “involved” and which are “committed” (this is big difference). What are the (personal) interests of the stakeholders (ask yourself “what’s in it for them” and try to get this confirmed or ask them directly)?

2.7 Communication Management

2.7.1 Introduction

Communication management is in my opinion one of the most crucial tasks of a project manager. A project manager spends approximately 90% of his/her time on communication. Once a project starts, when the project manager is appointed, it must be established how, with whom, how often, etc., communication will occur. The communications management plan is one of the first deliverables of the project. The business case must show which parties should be involved during the execution of the project. On this basis, the stakeholders are determined.

2.7.2 Content

The communications management plan describes the following:

1. What language is used within the project (e.g., British English) and the format in which the date is used (e.g., 02/04/2017 is April 2, 2017). This is extra important when you are working in an international environment.
2. In how many working days should a document have been reviewed and what will be done in case people didn’t review the document. If documents, which could also be deliverables, are not approved in time this could cause project delay so you need to keep the pressure on this. I suggest that in case people don’t review within the agreed timeframe this will be considered as “approved.” It would be polite to send an e-mail message, quality record, to that/these person(s) stating that he/they didn’t react within the agreed time frame which resulted in an implicit approval.

   When people are on vacation for instance they should delegate the review including the authority to approve/reject the material.

3. What tooling is used (e.g., project file, project reporting, requirements management, documents, electronic discussion, risk management, issue management, change management).
4. Structure project file (please refer to Section 4.3 for a possible structure).
5. Project reporting structure. Agree one report type and prevent that various stakeholders want different reports. The sponsor pays and thus has the last word in this.
6. Describe how risk management, issue management, and change management are operated at a high level.
7. Today, projects are often carried out by team members who are not physically working together. This communication is complex and becomes even more crucial. Determine how you are going to be gathered, such as using Skype. Also use video conferencing if possible.
8. Create a joint project calendar so that everyone looks at the same calendar.
9. Enter through an organization chart how the project looks and the immediate vicinity of the project. Also specify escalation paths.
10. Define the meetings (such as purpose, frequency, location, participants, agenda distribution list).
11. Stakeholder management. One of the many studies of major problems in projects shows that over 75% of the problems are caused by incorrect/insufficient “stakeholder management.” What are their goals and interests? Perform an analysis to determine the power/influence they have and to what extent they actually support the project.
12. Describe the project reporting with the various topics (progress, financial, etc.) at high level by means of traffic lights (red, amber, green). Thus, the status will be determined for the various topics of the project at a glance. Of course, when needed, more details must be given.

The project communications management plan is one of the “deliverables” and as such should also be included in the project definition. Also, related changes should be documented in a new version, and the various parties should be informed of this new version.

All stakeholders should be involved in assessing the communications management plan.

Also take into consideration any cultural differences when drawing up the plan, especially when persons are located outside the country where the project is implemented. Be punctual in making and keeping appointments especially, explicitly saying “no” (which is not very common in particular countries and cultures), etc.

Finally, take time zones into consideration when it comes to meeting times. In some cases, wide time zone differences occur. When the time differences are large (e.g., between the United States and India) where there are no overlapping “normal” working hours, then change the meeting times so that the meeting times during and outside of normal working hours are (evenly) distributed between the locations.

2.8 Project Definition

2.8.1 Introduction

The project definition is called “Project Initiation Document” in Prince2 and is the basis of the project. Changes in this document need to be under strict change management! Changes can impact for instance the contract, design, duration time, and costs.

2.8.2 Possible Subjects

This document describes for instance:

1. The background and so the need for this project.
2. The objectives and what should be delivered. List the deliverables and link to the contract (this is why you are executing the project!).
3. What will be and not be done (scope).
4. Assumptions and limitations.
5. Road map (i.e., how to get to the end of the project).
6. Business case.
7. Governance including the team organization.
8. Strategies for communication/quality/risk/configuration management.
9. How the objectives will be realized (project plan).
10. How to control the project.

2.8.3 Tips

A number of practical tips:

1. Be very SMART in this document! While this is the project base it is so important to define exactly the project. If you don’t you will face challenges later on due to different interpretations.

   Consider this document the base document for building your own house . . .

2. At the beginning of the project, a number of things are not clear/certain yet and you’ll definitely face changes during the project execution. Document as much as you know at this stage including assumptions and prerequisites.
3. Don’t duplicate other documents but make references. These references should include very specific details such as version, date, etc., of the documents you are referring to (these documents might also change of course).

2.9 Change Management

2.9.1 Introduction

Change management is unfortunately not always implemented as intended in practice. If change management is not running properly (may well be described but the practice is not in accordance with the theory) within a project, the chances of major problems are very high.

Problems, which often occur as change management is performed incorrectly, could include the following:

1. Exceeding budget
2. Later than planned yield
3. Not delivering what is asked

One of the most common causes of misery in projects is that from the beginning of the project the baseline is not explicitly clear. The baseline is the fundament/base of the project, especially in functional terms (the baseline). If the base is not clear how can you keep changes under control?

This is real . . . (Colorado, United States)

2.9.2 Tips

Why is change management often causing issues during project execution? Here are a few common reasons:

1. The baseline of the project is not clear (in particular, specific measurable acceptable realistic timed, SMART).
2. The project will satisfy the customer by making adjustments (changes) quickly. This literally could mean that the customer is watching over the shoulder of a developer and asking the developer to make changes on the spot.
3. The change management process is too bureaucratic or the process is not followed correctly.
4. The changes are not well maintained (in the project file).
5. The impact analysis of a change is not done properly.

General tips:

1. Implement a change only if all steps have been completed (especially, formal approval), in particular the financial clearance is obtained (and save the approval of the project file for the change).
2. Instruct your team members not to accept any change without your formal approval. In case the client is looking over their shoulder and asking to make changes on the spot refer the client to you as the project manager.
3. The impact analysis should be performed by the appropriate (technical) specialists and monitored by the project manager critically.
4. Do not deliver a Mercedes when a Fiat has been sold.
5. Provide authorization to implement the change by the right people (particularly by the sponsor as the change impacts on cost and time).
6. Communicate the change within the appropriate forums and document it in minutes.
7. Save all communication and documentation about the change in the project file.

2.10 Risk Management

2.10.1 Introduction

Risk management does not always get the attention it needs or is too late . . . (when the problems go skyhigh). As project manager you have a radar up and running all the time scanning for possible risks. Doom thinking is too negative but thinking a bit this way could be an approach as well.

A risk is an event, something unwanted normally, which has an impact on your project with a probability that it will occur.

Rather often a risk is considered to be negative but this is not always true. A risk could also have a positive impact on your project (an opportunity)!

The intention is that you are already thinking ahead about potential risks and in the following manner:

What measures can the project manager make in advance to prevent risk (“mitigation”)?

When the risk has occurred what options are possible to eliminate as much as possible the resulting problems (“contingency”)? Prepare beforehand for it.

2.10.2 Approach

Risk management can help you to reduce the impact of having a secret team member onboard called Murphy . . .

Prince2 has a good risk management approach in my view.

Risk management consists of the following steps:

A project must have central risk register to capture and maintain information regarding identified threats (and opportunities while risks could also have a positive impact). The register should contain at least the following items:

1. The name of the person who raised the risk.
2. The date when the risk was raised.
3. The risk description (cause, risk event, and possible effect).
4. Probability, impact, and expected value.
5. Proximity (how close is the risk).
6. Risk response actions.
7. Risk status.
8. Risk owner.
9. Risk actionee.

Beware of items 8 and 9 while this could be different persons.

2.10.3 Budget

No project is without risks and during the course of the project you will be confronted with risks and risks will become a reality. This is one of the very few certainties you have as project manager.

During the financial project definition, a risk budget should be assigned. This budget is intended to be used only to cover costs of risk analysis, etc. Not for changes or anything else. Your experience as project manager in this field is very important, so make a realistic estimate.

You can’t make a rough estimate of, for example, 5% of the project costs, you need to dive into the project and have a look at items such as:

1. Team experience (including your own). Do you have the right people onboard?
2. New or (field) proven technology
3. Project size both in human hours and other costs
4. Quality of the requirements
5. Solution design
6. Number of involved (extern) organizations
7. Dependencies (especially out of your span of control)

2.10.4 Risk Response

A rather standard list of how you can respond to risks is given below. Beware that you need to prepare these responses in advance and not when the risk has become a reality.

1. Transfer the risk to a third party regarding, for example, the financial impact.
2. Make a fallback plan.
3. Accept the risk.
4. Avoid the risk.
5. Reduce the probability that the event could occur and the impact.
6. Share with other organizations.
7. Exploit by means of turning the opportunity into something positive (that has a positive value for the client).
8. Improve by means of, for example, the project will be finished earlier than planned.
9. Reject the opportunity and, for example, stick to the project planning.

Risks can have a positive or negative impact so always look at the bright side of a risk as well as opportunities.

2.10.5 Tips

1. Risks can be transferred to another party. When transferring the responsibility to another party, it should be transferred in full. After the transfer, the possible effects have not been removed and this is now a project dependency. The big question is whether this is appropriate for the project.
2. Risk management consists of several steps and also requires cooperation from the right experts whether or not they are involved in the project. Involving the right experts simultaneously increases “commitment” which you will need as project manager in case the risk becomes a reality!
3. The first step in risk management is risk identification. In other words, the identification and description of the risk. After that it is important to quantify the impact of the risk. A risk that has a direct impact on the duration or cost of a project requires attention of course. Each risk has only one owner. Then, in collaboration with specialists, it is decided which measures should be taken to reduce the likelihood of the risk occurring. Finally it needs to be determined if the risk has become a reality. Take measures with the cooperation of specialists and also make an estimate of both the “mitigation” and “contingency” actions in terms of costs (e.g., extra human hours or hardware) and time.
4. Risk Management is not only the responsibility of the project manager! All team members must have an active attitude and once they identify a risk, they should report to the project manager and from their own expertise, knowledge, and experience contribute to the control of risks. Contributing to this risk management is a team affair.

2.11 Issue Management

2.11.1 Introduction

Issues in this context are in fact problems, whether or not arising out of a risk, that cause a disturbance in the project.

2.11.2 Tips

These may be not only issues within the project, for example, a team member is sick for a long time, but also issues that come from outside the project and affect the project. The internal project issues should be resolved by the project manager with possible assistance from “outside” (e.g., for getting replacement of human resources).

The external issues are outside the span of control of the project manager, and need to be raised to the Steering Committee members to take action. In the latest case, the project manager needs to track the progress.

The communications management plan describes how the escalation path is constructed when you book insufficient progress or do not achieve the results you want/need.

2.12 Deliverable Management

2.12.1 Introduction

Each project has one or more goals and ultimately is “something” to be delivered: “deliverables.” Deliverable management is the way these deliveries will be arranged.

2.12.2 Tips

A few practical tips:

1. Here, the project manager needs to know what is contractually agreed upon: “completion” or “acceptance” criteria. This is a large (legal) difference. The criteria should in any case be discussed with all its consequences. A good place to include these criteria is in the project definition. A risk of the use of “acceptance” criteria is that many discussions may occur and therefore a lot of time and money could be lost (and damaging the relationship between the client and supplier) because the client is not accepting the deliverables. To reduce the risk of these (endless) discussions, you could for instance show the results step by step instead of the entire deliverable at the end.

   To prevent a lot of discussion it is crucial to have the acceptance criteria very SMART and have defined, and agreed with the client in advance, test cases in order to show that the deliverable meets the acceptance criteria.

2. Every “deliverable” should be approved by the project manager before it is made available formally to the client. Keep the status of all deliverables well within the project file. Approval may be given by the client (also by e-mail and save this e-mail in the “deliverable” section in the project file).
3. Apply version control to deliverables. Especially with software releases document for each individual deliverable (piece of software in this context) which version is required for a particular software release.

It is preferable to deliver documents as “pdf” format to the client so that changes cannot be made easily. However, this should be stated in the contract, for instance, what should be delivered in which format.

2.13 Resource Management

2.13.1 Introduction

In this context, resource management means the management of the persons working on the project.

The modern project manager should, according to me, pay special attention to managing the human resources. First of all we are dealing with human beings just like yourself. I guess you also want to be treated with respect, for instance. Treat other people the way you want to be treated yourself.

Secondly . . . without human resources you are nowhere . . .

2.13.2 Tips

A few practical tips:

1. Getting the right people onboard with the right knowledge and experience is often time consuming and the right people are not always available at the right time, so this is not always possible.
2. Define the required roles and associated profiles as SMART as possible. Furthermore, the start and end dates of the deployment (so you actually need to have a project plan), the amount per week (this may vary during the project), and which tasks need to be performed need to be known.
3. Look for candidates in several ways. Normally there is a (kind of) resource management organization. They should have an overview of who is assigned to which project(s) and during which period, how many times per week, etc.

   Another way is the earlier mentioned “old boys network.” This is a very fast personal network where you go back to people you know. The big question is, of course, whether these people are available and whether they want to contribute to this project. In particular, within large international companies, many internal “tools” are available that can be used to search for (internal) resources. The “old boys” network might not be appreciated by the human resource management organization.

4. In case the appropriate human resources are not available internally, you need to look for external resources. Within large companies, there is normally a list of preferred suppliers. The human resource organization will look for you according to a profile of the person you are looking for. They do the negotiations and take care of the contract between the external supplier and the human resource organization. Large companies deal rather often with other companies and not with individual contractors.
5. Keep track of the period each person has been assigned to the project and take action on time. Beware of the mutual termination periods in order to prevent surprises in case people “suddenly” leave the project.

2.13.3 Global Resources

The efforts of people from other countries is a separate discussion, including legal, financial, cultural, and language, which is not covered here. Another possibility is to outsource to a party outside the project and then run by the project manager and any other specialists.

For more information please refer to the chapter “outsourcing.”

2.14 Financial Management

2.14.1 Introduction

Financial management in the context of project management is actually “bottom line” no more than:

1. How much money (and hours) so far have been consumed?
2. How much was budgeted so far?
3. How much money (and hours) are needed to finalize the project (estimated to complete)?

2.14.2 Tips

A few practical tips:

1. The consequences of “changes” must obviously be taken into account in the project finance. The project baseline is adjusted. A project often has two types of cost: internal and external. Internal costs, especially the “cost” rates so the “bare” hourly rates per person. External costs are the hourly rates with an additional uplift to make profit. The uplift percentages are often not the same for all hourly rates. These uplifts are not determined by the project manager but by management or sales departments. The same applies to the supply of hardware and software (licenses).
2. Almost all companies have accounting software which is designed for business administration and not for financial project administration. Accounting packages close years at calendar years (sometimes a financial year doesn’t end in December but the end of March, for instance). If the project passes the annual limit, there is normally no change in terms of man-hours basically. However, hourly rates are usually increased at the beginning of a new year, which might result in higher project costs.

Consider also training costs for people who have no knowledge or experience, for example, with the use of certain tooling within the project. For remote workers, it is an option that they do not take hours during training because it is for their enrichment.

2.15 Expectation Management

How often is this mentioned in ads for vacancies? To date, I have still not met anyone whose thoughts and expectations can be read by another person. The solution is simple . . . put the expectations on paper by mutual agreement and verify these regularly (to capture new insights as well during the course of the project).

The expectations are (obviously) SMART and need to be recorded. See capturing expectations (apply change management as well!), the same as capturing the “requirements” of the project.

2.16 Project Planning

First, it appears that in practice, there is confusion about “project plan” and “project planning.” A project plan is the project definition. In other words, how it is going to be, what will be, what does and does not belong to the scope of the project, etc. The project planning is about how the project activities will be carried out and the view of the completed project carried over time. This section is about the last subject. Usually a “Gantt chart” is used where the critical path is also visible (red in this example).

On the critical path are the activities that have a direct impact on the duration of the project.

The project planning can be used in different ways for different purposes such as purely for planning activities over time and progress monitoring.

The presentation of the project planning must be adapted to the target group. Executive management is not interested in details but wants to know, for example, when and what will be delivered, the costs, and when the project is completed. In this case use a simple presentation, for example, in the form of a table in which the project phases are plotted vertically and horizontally by time in months/quarters. You can also consider the project planning as a way that after “collapse” of the whole only the project phases (“summary tasks”) are still visible and do not use the “Gantt view/report” but another “high-level view/report” which is available in practically every project planning package.

You can add for instance to summary tasks the percentage complete in case you are also tracking progress.

Every project is part of a bigger picture and is therefore affected by its environment and affects its environment as well.

In short, every project has external dependencies that affect the project. You can include in the project planning a separate phase “dependencies” in which the dependencies are appointed and data are indicated. In this way, you can connect to this stage in your project/tasks and instantly see the impact on your project if a dependency in terms of date changes.

2.16.1 Tips

A few practical tips:

1. A task/activity starts with a verb.
2. Add at the end of a number of tasks a deliverable as milestone. Thus you can also use a “milestone view/report” to determine the status of the deliverables.
3. Add a “% complete” at each summary task. This not only gives you a quick overview of the project progress status but could also be used to report to (executive) management, Steering Committee, and other stakeholders.
4. Document assumptions, etc., in the task itself (“notes”).
5. A schedule of more than approximately 200 lines is not clear and time consuming to maintain. Be especially practical at the level of detail of project planning. It is rather often not possible to plan ahead for months so don’t spend too much time on details in the long run.
6. Use the project calendar for national holidays (in international teams this is certainly convenient).
7. Using the same resources as needed for daily operations (business as usual) is a pain in the neck (also based on my own experience). Planning is practically impossible because people are removed from your project on the spot when during operations severe issues pop up. From the resources perspective, the pressure on them is even higher than normal. Not everyone can switch quickly and easily between tasks, which is an additional challenge.

2.16.2 Gantt Chart versus Resource Planning

Project planning is most of the time based on tasks/activities resulting in deliverables. This works rather well within a single project where the human resources have been assigned to the project and not to other projects at the same time.

The planning is in this setting a Gantt chart.

In case the same people are working on different projects this type of planning becomes very complex and time consuming. In this case a human resource planning could be used.

Running a single project with let’s say seven human resources might already be a challenge . . . this becomes even a bigger challenge in case you are running a program or multiple projects where the same human resources are active on multiple projects! This challenge is however not linear . . .

The reaction is quite often that additional controls are added, that is, extra human resources and tools (which generates additional costs as well of course), with the intention that “we are in control.” However, a project planning is not really stable and changes in one project will result in side effects in related other projects. The overview might be lost rather quickly . . .

What the market says (based on hundreds of reviews and research):

1. 90%+ of the projects are done in a multiproject setting (Turner [18]).
2. 90%+ of the managers are dissatisfied with their portfolio management systems (Prof Caniëls and Bakens, 2011 [19]).
3. Managers don’t like planning; they hate replanning (Mintzberg [20]).
4. Multiproject management is something totally different than project management (Heroelen [21]).
5. Using project management techniques and tools in a multiproject environment can harm your organization (Heroelen and Patanakul [22]).
6. Multiproject management is all about managing your resources: Resources deliver projects, not the other way around.
7. Resource management is the most severe problem for managers without a satisfying solution in practice (Laslo and Goldberg [23]).

An option might be to make people directly responsible for planning their activities. The human reaction will be to add contingency in their planning to be on the safe side, which will result in increasing project duration (and related costs). This will become a vicious circle within the program resulting in less efficiency. This must be prevented!

One way to prevent the above-described issue is to change the approach: change the focus from projects to resources.

Resource allocation is the main challenge for management; organizational conflicts are inevitable (Laslo and Goldberg [23]).

Each project has its own dependencies, objectives, deliverables, planning, etc. and the availability, at the right time, of the human resources is quite often the critical factor of a project. People are working on multiple projects at the same time. You want to prevent people from becoming overloaded which is a personal risk not only for them but also for your program/project. People can become ill, go on vacation, follow courses, etc. When people who are performing tasks on the critical path of your project become ill for instance, this will have a direct impact on your project duration. When someone who is working on another project could step in (keeping in mind that overload should be prevented) what will be the impact on the other project(s)?

One woman can deliver a baby in 9 months. Nine women cannot deliver a baby in 1 month . . .

Excel sheets and Gantt bars are a waste of time in an ever-changing environment.

Project planning (and tracing) is not simple nowadays and can be rather time consuming. Many companies have outsourced work to other countries so virtual teams are very common. However, this doesn’t make collaboration easier. In the past you just walked to your team members and discussed with them their activities, vacation plans, etc., but this has changed a lot. Collaboration becomes even more complex when the team members are in different time zones. And I’m leaving out the cultural and language challenges of this entire discussion . . .

Wouldn’t it be great to have a dashboard that gives you a practical resource allocation (and load, etc.) over all projects and enables you at the same time to dive into particular project details? This makes life easier for everyone, saving costs as well and will improve efficiency and effectiveness of the human resources. This should contribute to a happier team, better results, lower costs, faster delivery, risk reduction, and last but not least more satisfied client.

90% of the managers are unsatisfied with the project management system (Caniëls and Bakens, 2011 [19]).

Recent studies have shown that 90% of the managers are unsatisfied with the project management system. Why? The data are not accurate, and it costs too much time to configure and maintain the system. The remaining 10% achieves far better results.

Furthermore, the majority of project management software has its roots in single project environments such as MS project. However, multiproject management requires a different approach. Using project management techniques and tools in a multiproject environment harms your organization! Projects start and finish but the human resources stay. Another approach is to focus on human resources and the progress, visibility, etc., of ALL projects is controlled, and not only the most critical projects.

Managers say planning is important, but they hate to do it (Mintzberg [20]).

A Dutch company has developed a software package that will be of great value for multiproject-based organizations. With a minimum set of effort, they can get control over their project portfolio. The project managers, team leaders, planners, and other staff can spend their valuable time on activities that really matter to them.

Based on experience, the return on investment is far less than one year. On top of this, the performance is increased significantly (please refer to case stories on their website).

Remarks regarding the software package:

Managers need to know if they have sufficient capacity and the right skills in-house. The employees need to know which task is important now.

Planning is nice for managers; your people want to know what to do now and next. The software package prioritizes their tasks based on the needs of your organization.

You need to order your tasks and set a deadline. The software package does the rest for you; no replanning and no endless juggling with Gantt bars.

For more detailed background information please refer to: http://www.sciencedirect.com/science/article/pii/S1877042815036095

Note: in our very fast developing world, the (software) development is also running at a high pace. This implies that what is not possible today could be possible next week. Maybe other software suppliers come up with similar software in the future.