Appendix B: Forming and Defining the Project
ISBN: 978-1-78714-830-7, eISBN: 978-1-78714-829-1
Publication date: 10 October 2017
Citation
Mikkelsen, H. and Riis, J.O. (2017), "Appendix B: Forming and Defining the Project", Project Management, Emerald Publishing Limited, Leeds, pp. 427-467. https://doi.org/10.1108/978-1-78714-829-120171018
Publisher
:Emerald Publishing Limited
Copyright © 2017 Emerald Publishing Limited
B.1. Tool Sheet: Project Challenges
What
To varying degrees, every project is difficult and demanding due to internal and external complexity. The complexity implies challenges and uncertainties regarding success, cost, resource effort, and time. This tool sheet presents a model for describing and analyzing complexity.
Use – Where and When
The complexity and challenges should be analyzed at the initial planning of the project and later at important milestones, and at the beginning of new phases. It directs management effort toward these important issues. Challenges and points of special attention should be on the agenda at every project management meeting.
Method
One starting point is “The project portrait” as described in tool sheet A.1. Another starting point is the model of project complexity as described in Figure B1. The project complexity has five dimensions:
Opaqueness
Diversity
Instability
Tensions
Changes
Opaqueness may be caused by nontransparent connections, incomprehensible results of experiments, specialist language and conceptions, interested parties’ ambiguous attitudes and irrational behavior, etc.
Diversity may stem from many different systems, many interested parties with different opinions, different technologies and disciplines, several changes at a time in the user’s organization, etc. The task is difficult to overcome and has many interfaces.
Instability may originate from changes in the project environment – competition, laws and rules, economic fluctuations, etc. Changing attitudes and understandings of the interested parties and changing sponsorship. Unexpected results of experiments also cause instability.
Tensions may come from conflicting interests, different languages, different problem understanding and solution methods, incompatible technologies, conflict between budget and quality ambition, changes in user’s work processes and organization, major changes in user’s work conditions and required competency and performance.
Each dimension is related to the four elements in the project portrait – see Figure B2. The form is used for analysis, and the identified complex circumstances are noted. Some typical challenges or sources of challenges are already filled in – partly as an illustration of typical challenges and partly as a “think of …” checklist. The form is meant to be an extension of the portrait. The analysis is done by the project team together with the project owner and other key persons.
The project has a set of conditions (terms). We choose to see them as a separate phenomenon, separated from complexity. The reason is that conditions are not always given by nature, but imposed on the project by one or more parties. They are, e.g., a small budget, a tight time frame or requirements to use certain resources. Figure B3 shows some examples of conditions.
The identified complexities are analyzed for identification of challenges – negative risks and positive opportunities. Each challenge is analyzed with respect to:
Seriousness. Threat to project success, acceptable result, acceptable economy, acceptable time, etc., or promoting these factors.
Possible actions. Clarification of how and when? Probability of acceptable result?
The related uncertainty – for how long?
The form in Figure B4 may be used. The challenges are prioritized, sorted, and used in the planning and control activities. Many of them are mitigated as soon as possible or at certain milestones. However, some may last to the end of the project. The document “Points of special attention” is a practical list – see Figure B5.
References
A.1 Tool sheet: The project portrait
Chapter 2
B.2. Tool Sheet: Analysis of Interested Parties (Stakeholders)
What
The analysis of interested parties should provide useful information about the stakeholders – creating a basis for:
formulation of mission, benefit goals, and success criteria related to each interested party.
identification of tensions, (potential) conflicts, and (potential) coalitions.
planning of the approach – especially with regard to understanding and acceptance.
organization of the involvement of interested parties and their influence on the product and implementation.
These actions are not part of the analysis, but activities in the planning and control process. An essential aspect is to identify potential reactions from the interested parties and to use this information for adjusting their expectations. See Figure B6.
The insight into the interested parties’ expectations, ideas, understanding, and reactions are essential for project scoping, planning, and organizing.
Depending on the involvement in the project, some of the interested parties may become real stakeholders.
Use – Where and When
The analysis is carried out at the initial project planning and adjusted at important milestones and new phases. New parties may emerge during the project and interests and attitudes may change.
Method
The analysis has three steps:
Identification of the parties
Analysis of position
Analysis of potential conflicts and coalitions
Identification of the Parties
Interested parties may be affected and may have certain interests in the product, the results, the approach, the implementation and change process, etc. Ask the following questions:
Who are project owner and sponsor?
Who will use the product/result?
Who will benefit from the project?
Who should contribute to the project?
Who should accept or approve the result?
Who will finance the project and deliver resources?
Who should approve the approach and plan?
Who will be affected – notice, be bothered, suffer, achieve benefit, get new conditions, etc.?
Other ways of identifying interested parties are to:
identify all steps in the project and product life cycle (value chain) until product disposal. Find the parties in each step. For example, a new product has the following steps: Marketing, sales, manufacturing, distribution to retailer, sales and distribution to end customer, installation, use, service, and disposal.
identify all the steps in the project and product life cycle (value chain). See the project and the product as systems and find interfacing systems in each step. Identify the interested parties related to the systems.
The interested parties are not only those who express interest, but also those whom the project manager wants to involve in the project.
The parties are persons and groups of persons – companies, public authorities, departments, trade organizations, etc. Some are organized with official and competent representatives or leaders. Others are not organized and may be difficult to identify, e.g., users and neighbors. What at first sight may seem to be a group may after a closer look consist of several fractions or subgroups with different interests.
Analysis of Position
The next step is to characterize the attitudes to the project by means of the following elements:
Subjects of interest
Which elements of the project and the product will affect the party? How? Which changes may the party experience?
What are the interests of the party – in the project and in the product?
Understanding of the project
How does the party see the project value and its necessity?
How does the party see the project product?
How does the party see the final consequences?
Perceived balance between contribution and reward
What should/will the project deliver to the party? What does the party want?
What will the party gain from the project – and how does the party experience that?
Which disadvantages and costs will the project entail? How does this influence the attitude?
What is right and wrong in the party’s understanding of the project?
Attitude to the project. Motives
Attitude to the project and the product?
Motives behind the attitude?
Possible misunderstandings?
Power
Power and influence – direct and indirect?
Importance for the project approach, results, and success?
Expected influence
Which expectations does the party have regarding participation and influence?
Attitude to other parties
Opinion of and attitude toward other interested parties?
Tensions and sympathies?
Opinion about potential alliance?
Who influences whom? Who are opinion makers and who are listeners?
Conflict behavior
How will the party act in conflict situations where a joint decision is necessary?
Possible actions from the party in such situations – opinion maker, supporting activities, resisting activities?
Potential contribution
Potential deliveries and services to the project?
It is essential to know the interested parties’ attitude to the project, to the approach, and to the results. The position analysis should be adjusted to new information during the project, especially concerning implementation, and the change approach.
The position analysis is based on knowledge about the parties, direct communication (dialog and interview), observation of behavior and mutual characterization. Organograms, procedures, rules, etc., may also lead to interested parties and their interests. It may be a problem to unveil hidden motives and bluff. Observing behavior in different situations is useful, because there may be differences between words and action.
The analysis may be documented in a form – see Figure B7. An overview may be illustrated as in Figures B8 and B9. However, the analysis is not done just by filling in a form. The information, reflections, and understanding of situations are the real quality of the analysis.
The Analysis of Change
Some interested parties – especially the users in every step of the product lifecycle – will experience changes during the project and at implementation. It is necessary to analyze the character and size of the change as a basis for arranging the change approach. See tool sheet C.5, The change process.
Analysis of Tensions and Coinciding Interests
The next step is to describe potential conflicts between parties and potential joint interests as well. This may lead to considerations regarding coalitions between parties. Typical subjects are:
Project mission and goal
Choice of solutions
Choice of methods and approach
Project organization – participation and roles
Cost, resources, and financing
The potential conflicts should be prioritized:
Real conflicts concerning mission, scope, and solutions
Formal conflicts concerning influence and contribution
Pseudo conflicts caused by misunderstandings, lack of information, and preconceived opinion
Sociogram
It is useful to illustrate the relations in a sociogram if there are many parties with established mutual relations, communication patterns, sympathies, dislikes, etc. For example, a relationship diagram as shown in Figure B10. It is useful and may be necessary to draw diagrams for different types of relations, e.g.:
Power. Who directs whom? Who dominates whom?
Opinion making. Who expresses opinions and who listens?
Feelings. Who sympathizes with whom? Who dislikes whom?
Communication. Who frequently talks with whom? Who works together?
Geography. Who is close to whom?
Interests. Who has joint interests?
Do not forget personal relationships outside of the daily work.
Think of
Use facts and avoid vague assumptions and preconceived opinions. It is better to raise questions and collect information. Several persons should participate in the analysis to ensure identification of parties and more reliable data.
Be careful with access to documentation. Controversial descriptions in the wrong hands may cause problems.
References
D’Herbemont, O. & César, B. (1998). Managing Sensitive Projects. MacMillan Press.
Eskerod, P. & Jepsen, A. L. (2013). Project Stakeholder Management. Gower.
B.3. Tool Sheet: Project Values and Goals
What
The project goals express what the project should lead to – tangible end products and effects (values) from using the products. The goal expresses the reason for the project and guides the project work. We distinguish between benefit goal (utility value) and product goal.
Use – Where and When
The first version of the benefit goal should be documented in the project charter and in the project plan. The solutions concept should add a description of the product goal. It is fulfilled at the beginning of the implementation phase and the benefit should be obtained during and after implementation.
Method
The goal picture has several elements:
The interested parties’ satisfaction with the results (product and benefit)
Benefit goals – The expected (required) value from using the product
Product goal – Specific required functions and features
Change goal – Achieve users’ understanding and acceptance of the project, the product, and the correct operation/use
Project deadlines
Cost budget and resource budget
Interested parties’ satisfaction with the project process and management and cooperation
Learning from the project
Figure B11 illustrates connections between these types of goals.
The phrase “common goals” is heard as a desirable situation for the interested parties. It might be utopia. It is more realistic to recognize the real and legal interests and strive for a solution which the parties will accept as reasonable with due regard to their interests.
The picture of the goals should show the relations to interested parties and coalition of parties. The picture may also show who accepts or does not accept goals from other parties. Goals are typically expressed in positive terms, but projects also have negative effects on some interested parties. The goal picture should also consider this aspect.
Another typical phrase is “clear goal” – right from the beginning. Benefit goals and desirable future operations processes are in many situations expressed clearly and measurably. However, this is difficult to do in some development situations. For example: How to use the Internet for customer contact and dialog? An ambitious and capaciously defined vision may be better. It sets the direction and can be a basis for a stepwise development process with test and learning, and it allows room for new ideas and for interpretation of ideas.
The phrase “success criteria” describes what an interested party would like to see in order for the project to be a success. The question: “When will the most important interested parties call the project a success” may accentuate the important goals in a complex gathering of goals and expectations.
Goals are concretized and revised during the project, and ambitions are changed. However, there should always be an actual formulation of the goal.
Benefit Goals
The benefit goals come from the project mission and value creation and should be described as future benefits for each interested party using the project product. Benefit goals are related to future operation and use. Benefit for the producer and seller of the product may be increased competitive position and business value. Benefit for users of the product may be business values, reduced costs, better environment, etc. Neighbors to the project and product may benefit from it – at least avoid unpleasant effects. Benefit goals can be related to each step in the product life cycle (value chain).
Benefits are specific in most situations:
Deliver at least 95% of all customer orders on time.
Create new product business with a net profit of EUR 3 million in year +3, +4, and +5.
Corporate top management can consolidate monthly account and profit for all business units 2 days after end of month at the latest.
Patients’ risk of too high blood pressure should be reduced to max. x mmHg.
X thousand theater guests will get an actual music experience.
Figure B12 shows types of benefit goals. It may be used as a checklist or a model for goal structure.
You should begin by asking Why? several times to define a hierarchy (more levels) of benefit goals – which are often vaguely expressed and general. For example, “contribute to increased competitiveness” or “ensure market position.” Asking Why? should stop when the answer is an element of the actual company strategy. A project is justified when it is in agreement with the strategy and business plan. Any vague expression should be sharpened by asking how much. Scenario technique may be useful to describe the expected future after the project.
Company management will ask: “How will this project influence our economy – annual results?” Not all projects have a direct effect on the bottom line or top line. Their effect is indirect and combined with other initiatives. Another aspect is that effects such as reduced man-hour consumption in certain operations processes will not always lead to a corresponding reduction of staff.
| Project benefit goal (purpose): | Answer: | Ask: |
|---|---|---|
| Expected effect of the project product – for each interested party |
|
To achieve…? |
Product Goal
Product goals are the specific requirements to the project product. They are described in a requirement specification or a basic product specification, describing mainly functional features, esthetic features, and product economy. They are derived from the benefit goals (as solution answers), but there are other sources such as functional interfaces to other products and systems, technology, and manufacturing.
The starting point is the required functions and features and their quality related to the use of the product. This is supplemented by requirements from each step in the product life cycle (value chain). This description is often called “the basic product specification.” Product solutions, manufacturing solutions, distribution solutions, etc., are defined during the development work and they may lead to further requirements. More detailed pictures of the product are developed – e.g., models and prototypes, which may be seen as new editions of the goal description – but the basic description should be kept in mind.
Goals expressing users’ requirements to functionality (users’ needs) should be described without solutions although examples may clarify. There may be several solutions and the project task is to develop an appropriate solution. However, needs are sometimes not visible and expressed until a solution idea is presented. The need is latent. Keeping the need visible also guides the level of ambitions. Ambitions might increase in a creative project team surrounded by creative interested parties. Product ideas should be “tested in acid” and its value analyzed. Do they relate to needs? Will they be appreciated? Which value do they represent? Experience with control of level of ambition have led some companies to prioritizing functions and features:
Must-have properties – Absolute necessary basic functions.
Positioning properties – Making this product special compared to competing products, and making it very attractive.
Wanted properties – Useful, valuable, and attractive, but can be ranked due to value.
Nice-to-have properties – Valued by some interested parties, but may be seen as luxury and will only be delivered if there is enough money and resources.
It is natural to create ideas and think of solutions, when you are analyzing needs. They may be noted in a separate column along with the needs in the basic product specification – to be remembered as possibilities. Some of them might give the product a positioning characteristic.
| Project product goal: | Answer: | Ask: |
|---|---|---|
| Required product/solution, functions, and features |
|
With a product/system that is able to ……? |
Other Goals
The ultimate goal is satisfied project owner and users. This is not guaranteed by fulfilling the basic product specification. Not until the users get the product in their hands and use it do they really know how it should be! It is difficult to communicate all expectations and some expectations are never formulated – because they are seen as natural for the users, but not for the developers. Users’ expectations may change during the project, as they learn and their conditions change.
Implementation goals are related to satisfaction: Users’ understanding of the product and its effects, how to acquire necessary operations competency, and their acceptance and will to use the product.
Other goals are the deadlines for product delivery (launch) and for business results (benefits). And there are the economy goals as well. There are goals for learning and acquiring new technological experience.
Process goals are another type, e.g., observance of milestone deadlines, quality in deliveries, engagement and atmosphere, communication with interested parties.
Description of Goals
Three points of view for identification of project goals:
The interested-party view. Identify the steps in the product life cycle and the interested parties in each step. Analyse and describe requirements and expectations – benefit goals and product goals.
Process view. Identify the steps in the product life cycle and analyze the processes and functions in each step. Describe related requirements.
Environment view. Identify the steps in the product life cycle. See the product as a system surrounded by other systems. Analyse and describe interfaces and related requirements.
It is probably not possible to identify all goals from the beginning. The analysis must be updated during the project, in the light of new information.
Goals may be more or less ambitious. Visionary and ambitious goals can be challenging and force the project organization to reach higher than more realistic and humble goals. Not reaching the ambitious goal should probably not be regarded as a complete failure. The project organization should have some freedom in reaching goals. Some may be conflicting and some may be too expensive. Limits for the goals are useful:
Desirable/maximum fulfillment – Best result to be achieved.
Acceptable/minimal fulfillment – Just acceptable and on the border of being unacceptable.
A general checklist for describing goals is the SMART model. Goals should be:
Specific – clear, well defined, limited.
Measurable – visible and measurable, although opinion poll sometimes may be the way to go.
Accepted – by the managers, team members, and users.
Realistic – achievable under the actual circumstances.
Time-defined – to be achieved to deadline or in defined period.
The above-mentioned frame for goals may be seen as a quality scale. But it also allows the project manager to exploit opportunities and possibilities during the project. Defining goals too early may not be possible or suitable, especially product goals. The project is a goal setting process itself – aiming at maximal benefit.
Value analysis
When there are several ideas for new projects, but scarce resources, project initiatives should be evaluated:
Is the project absolutely necessary – Because of authorities and regulations requirements?
Is the project an element in company strategy execution – Is it part of a family of initiatives (a program)?
Is the project profitable – Will the investment pay back in an acceptable period of time?
Is the project better than other projects?
Figure B13 shows a typical model for calculating value in new product development. Similar models exist for investment in facilities, equipment and systems. The models can handle the quantitative sides of benefits and values – measured in money. The figures are estimates with uncertainties and assumptions. Best case, worst case, and most likely case should be calculated by looking at the assumptions.
Nonquantifiable elements may be attached a value or be compared to the costs – using the question: Is this worth the investment?
Business case
Cost and value considerations are often illustrated in a business case, e.g., the model in Figure B14.
Measuring results
The project organization (manager) is responsible for fulfillment of the product goals, but in most cases not responsible for fulfillment of benefits. The user organization (operations organization) is responsible for achieving the benefits – to some degree supported by the project organization in the implementation and running-in phase. The definition of goals should, therefore, be accompanied by placing the responsibility and ensuring authority.
Arranging the measurement of achieved benefits is part of the project work – in cooperation with the users. See tool sheet G.15. Remember to measure the state before implementation.
Think of
Benefit goals are often first described in very general and positive terms (rubber words), e.g., better, bigger, and reduced. Later, they are concretized into measurable expressions accompanied by measurement method.
Product goals are first described in user language and later converted to technical language (specifications).
Benefit goals and product goals are connected – illustrated by a goals and means hierarchy. See Figure B15.
References
G.14 Tool sheet: Logical framework
G.15 Tool sheet: Utility values and benefits
Chapter 2
B.4. Tool Sheet: Solution concept
What
The solution concept is a sketch of the project product, a specification of requirements plus a recommended solution. The concept also describes how to fulfill the project mission, how to realize the expected values.
Use – Where and When
The solution concept is presented at the end of the concept development phase and is used as goal and guide in the development (engineering) phase. However, new ideas and new information in the development phase may lead to revision of the concept.
The concept is documented in a concept report accompanied by visualization – prototype or model.
Method
The practical description and illustration of the concept depend, of course, on the type of project. Illustrating a new business process with an IT system is not the same as illustrating an electro-mechanical product, a health improvement campaign or a new office building. Text, diagrams, and figures are natural means, but visualization in the form of prototype, model, and video is much better.
The solution concept has five elements – see Figure B16:
Picture of needs. A picture of the user’s world. Description of use situations (use stories). Description of functional requirements, positioning properties, and success criteria.
Picture of the product environment. Description of market, competitors’ products, regulations and norms, interfaces to other products and systems, etc.
Picture of values. Operations and business values (benefits) using the product. Related uncertainties and points of special attention.
Picture of the solution. A picture of the solution – in use and in operation. Description of related assumptions. The solution is holistic, structured as the PPSOP model. The product architecture and structure (modules, units) are defined. The basic product specification is accompanied by a sketched solution. New processes (business process, support processes, management processes) are sketched in the process concept – with functional requirements to the processes. The related organizational structure of the user’s organization is sketched in the organization concept. Requirements to equipment, facilities, information systems, etc., are described in the systems concept along with sketched solutions. Necessary future competencies, work values, work performance, and attitudes are described in the people concept.
Picture of the effort. Resource effort and investment. Change process (approach) and challenges.
The idea of the solutions concept is to clarify and not to detail. The concept is a sketch. Important clarifying points are:
Illustrate the future – Operations, customer service, user interfaces, etc.
Find the product structure. Splitting it into modules (units) makes stepwise development and implementation possible and allows organizational structuring too.
Describe functions and features (properties) before technical solutions.
Describe product interfaces – Between modules and outwards. Especially the user interfaces.
Verify new, challenging, and uncertain solutions – New technologies, new markets, new user functions. Experiments, models, prototypes, pilots, etc., may be useful. The degree of detailing varies – less detailed in well-known areas and more detailed in new areas.
The concept documentation has four parts:
Documentation of goal and solution
Profitability calculation (business case)
Implementation plan – Resources and investment
Recommendation to project owner (management board).
References
Tool sheet C.4 – Project course of action models (especially concept-based approach)
B.5. Tool Sheet: Analysis of Uncertainty and Risk
What
Uncertainties exist in the project and in the environment, making it difficult to fulfill goal, follow plans, and keep budgets. Uncertainties should be identified and analyzed as far as possible. An uncertainty may be negative – risks threatening the approach and the result. An uncertainty may also be positive – potential new possibilities to be exploited. The analysis should lead to action.
Use – Where and When
Uncertainty should be dealt with in all phases. Uncertainty related to the project as a whole is treated in connection with project challenges – see tool sheet B.1. This tool sheet is about uncertainty related to the project plan. But the method may also be used for other aspects of the project.
Method
In the following, we will describe uncertainty analysis and SWOT analysis. Cause-effect diagrams, decision tree, and RPD diagrams will be described as tools for analysis of consequences.
Uncertainty Analysis
The uncertainty analysis is an attempt to see potential changes in the project environment and potential events and changes internally in the project – and their effects on the project plan. The analysis has two steps: to identify the uncertainties and to deal with them.
The Methodical Risk Analysis
The methodical risk analysis is a questioning technique that involves imagining things that can go wrong. There are several versions, but primarily you search for risks. But uncertainty also has a positive side. The basic procedure is:
Identify the uncertainties
- –
Choose the object – Work path, milestone, activities, methods, resources, etc.
- –
Find uncertainties – Uncertain elements, possible events and the probability of them occurring and their possible causes and effects.
- –
Deal with the uncertainties
- –
Quantify uncertainties – Effect, probability.
- –
Identify the most important.
- –
Take measures – Preventive actions, preparedness, insurance.
- –
Monitor and control – Responsibility for monitoring and action, risk stones.
- –
The procedure is described in detail below. The analysis of opportunities is similar – with slightly changed questions. You may use the forms in Figure B17. Pinto (2016) proposes four steps in risk analysis: Risk identification; Analysis of probabilities and consequences; Risk mitigation strategies; and Control and documentation.
Find the uncertainties
Choose object for the uncertainty analysis
The object may be the coordination and control schedule. The analysis is directed toward work paths and their results, milestones and main activities. See Figure B18.
Find the uncertainties – Potential uncertainties and their causes
Analyze all elements, activities and interfaces and ask:
What can go wrong or fail? Which incidents are thinkable, where, when, how?
Possible causes? Technology, systems, milieu, environment, political, human.
Think of abnormal user situations. Think of coincidences of bad situations.
Deal with the uncertainties
Quantify the uncertainties – Effect, probability
What will be the consequence if they happen?
Use a three-level scale of damage, cost/delay and inconvenience, or a five-level scale. Describe the possible effects, direct and indirect.
How probable are they?
Look at the causes and evaluate their probability. Indicate on a three-level scale.
Note the uncertainties in the matrix – Figure B19.
Identify the most important
Point out the important risks.
Probability and seriousness are indicated on a three-level scale. The two values are multiplied to find the risk indicator. Incidents with a high score attract attention and action – see Figure B19.
Arrange actions – Prevention, preparedness, insurance
Consider possible actions.
Reduce probability – How?
Mitigate effects – How?
Arrange preventive action – Toward probability and effects. For example, another method or solution, other resources, control points, indicators, warning signals, monitoring and reporting system, preventive instruction, test of prototype, experiments, rehearsal.
Ask: How probably is the risk now? Arrange actions toward very probable damaging risks. Alternative solution (plan B), back-up, budget reserve, time reserve.
Control and follow-up – Responsibility for monitoring and action. Risk stones
Enter the actions as activities in the project plan.
Enter important uncertainties on the list of points of special attention.
Arrange monitoring and related responsibility. Risk stones, signals, trigger events, log book.
The quality and usefulness of the uncertainty analysis depend on the awareness of possible incidents and the evaluation of their relevance. It is a combination of experience (previous incidents and surprises) and imagination – to be the devil’s advocate. Use checklists, but remember that they never fully cover the actual situation. Invite people with experience from other projects. A general question is: What would be the worst case – with respect to product quality, cost, time, resources? Why – which causes are possible?
Hillson (2002) has proposed to use a risk breakdown structure (RBS) to create a hierarchical representation of the project’s risk, starting at the higher, general level and breaking the risks down into more specific risks at lower levels.
Causes of Uncertainty
Uncertainty is very much tied to the degree of innovation in solution and approach – and to the possibility for testing ideas. Uncertainty is often tied to people and organizations – in terms of lack of competency, lack of responsibility, misunderstandings, etc.
Cooperation has uncertainties. Project management is often characterized as “interface management” – see Figure B20. A systematic analysis of interfaces may lead to identification of uncertainties. Interfaces are found in the technical specifications, in the organization, in plans, etc. Interfaces exist between physical, organizational, human, and administrative systems. Uncertainty is especially related to the interaction between different kinds of technology and different kinds of systems, e.g., man-machine interaction. Be aware of differences in system interfaces and organizational (responsibility) interfaces. Communication between people is uncertain – especially over geographical distances and with limited communication means.
The project is sometimes vulnerable. Be aware of deviant and unusual work situations – e.g., absence of key persons, time pressure, maintenance situations and inexperienced users. A proverb says that misfortunes never come singly. The uncertainty analysis should, therefore, include combinations of failures and incidents. Think of a potential failure or unusual situation and ask: Which risks may this lead to?
SWOT Analysis
SWOT analysis is used for identifying points of special attention in the project. SWOT stands for strengths, weaknesses, opportunities and threats.
The analysis may target the project as a whole, solutions or the team by using the form in Figure B21. Use brainstorm and checklists. There ought to be at least three and no more than eight to ten statements in each quadrant. The statements are prioritized.
Identify actions to prevent threats, to increase strength in weak areas and to exploit opportunities and strengths. The actions are added to the activity plan.
What–If Plan
Traditional planning methods presuppose that there is only one way – one activity course. They cannot handle alternative activity courses, where alternatives are examined beforehand, but decided on during the project. They cannot handle activity chains as a loop. Such plans are needed in explorative development projects, where research and test results will decide which direction to take next. They may also be useful in environmental protection projects where public interests and authorities influence the course, and in construction projects where weather and soil conditions influence the approach.
There are some methods for planning with alternative courses, among others the American GERT/GAN, which also exists in a version called PASS, and the English RPD method (research planning diagram). The RPD method is simple and in general more useful. It is an extension of the traditional process diagram with a number of logical elements known from programming of IT systems. An example is shown in Figure B22.
Duration and cost are estimated for each activity as usual. Probability is estimated for the alternative directions from a decision or from a research. The RPD diagram illustrates the possible alternative end situations and duration and cost of each alternative. The probability is calculated and consequences are described.
Decision Tree
A decision tree is used for analyzing a situation leading to alternative results. The result may be defined by events and factors beyond the project manager’s reach. The tree shows the possible combinations of events and actions and the subsequent end situations. See the example in Figure B23 that treats the construction of a new factory in a situation where there are several choices of approach and adjustment to an uncertain sales future. Note that the activity sequence is not shown – it is not a time schedule.
The end situations and consequences are described. Probabilities are evaluated and chances and risks are analyzed. Sensitivity is analyzed and worst case, best case and most probable case are discussed.
Action
It may be impossible to avert a very probable and unpleasant uncertainty. Then, a plan B should be developed. It is an alternative plan or contingency plan.
The project environment may change and events happen, influencing the project or its business case. An action plan toward the environment may be useful – an environmental plan. Typically, such plan consists of monitoring activities and influencing activities toward competitors, technological development, economic and market development, trends, change of interest and priority at important interested parties, new norms and standards, patents, etc.
Risks and opportunities in the project will change during the project due to actions inside and outside of the project. It is often possible to mark the points in the project plan where uncertainties are clarified, risks are reduced or opportunities are clarified. These points should be marked as milestones in the plan – called risk stones.
References
B.1 Tool sheet: Project challenges
Chapter 7
Chapman, C. & Ward, S. (1997). Project Risk Management. Wiley.
Hillson, D. (2002). The risk breakdown structure (RBS) as an aid to effective risk management. Proceedings of the 5th European Project Management Conference (PMI Europe 2002), Cannes, France.
Pinto, J. K. (2016). Project Management – Achieving Competitive Advantage. Pearson.
- Prelims
- 1 Introduction
- 2 Forming and Defining the Project
- 3 Planning the Course of Action
- 4 Organizing
- 5 Cooperation in the Project Organization
- 6 Project Leadership
- 7 Project Control
- 8 Management of Several Projects
- 9 Trends and Challenges for Future Projects
- Appendix A: Project Characteristics
- Appendix B: Forming and Defining the Project
- Appendix C: Planning the Course of Action
- Appendix D: Organizing
- Appendix E: Cooperation in the Project Organization
- Appendix F: Project Leadership
- Appendix G: Project Control
- References
- About the Authors
- Index