Client organisations | High-ranked flexibility enablers | Trust Short feedback loops Continuous locking Seizing opportunities and coping with threats Continuous learning | Broad task definition Functional-realisation-based contract Shared interface management Visualised planning and progress Seizing opportunities and coping with threats | Seizing opportunities and coping with threats Stable teams Self-steering team Broad task definition Iterative delivery |
Low-ranked flexibility enablers | Standardised process and design Self-steering team Consensus among team members Late locking Self-assigning individuals to tasks Broad task definition Flexible desks Iterative delivery Consider team members as important stakeholders | Iterative delivery Stable teams Continuous locking Flexible desks Contingency planning Standardisation of process and design Self-steering team | Flexible desks Standardisation of process and design Functional-realisation-based contract Joint project office Open information exchange Continuous locking | |
Consultant organisations | High-ranked flexibility enablers | Trust Short feedback loops Self-steering team Consider team members as important stakeholders Seizing opportunities and coping with threats Visualised planning and progress Self-assigning of individuals to tasks | Embrace change Broad task definition Functional-realisation-based contract Possible alternatives Self-steering team | Possible alternatives Continuous locking Contingency planning Joint project office Iterative planning |
Low-ranked flexibility enablers | Broad task definition Late locking Contingency planning Possible alternatives Network structure Functional-realisation based contract | Consensus among team members Iterative delivery Stable teams Visualised planning and progress Contingency planning | Flexible desks Consider team members as important stakeholders Self-steering team Functional-realisation-based contract Visualised planning and progress Late locking Broad task definition |
Project management flexibility in terms of project scoping and contracting (what) has a positive effect on project performance. | Rejected |
Project management flexibility in terms of process (how) has a positive effect on project performance. | Supported |
Project management flexibility in terms of project team organisation (who) has a positive effect on project performance. | Rejected |
Project management flexibility in terms of scheduling the project and task delivery (when) has a positive effect on project performance. | Rejected |
Project management flexibility in terms of location of team (where) has a positive effect on project performance. | Rejected |
1 | Inadequate governance Strict budgetary regulations, inflexible procurement law, constraints from permits | 3 | Full and adequate support from project owner to have freedom to operate project management | Management support | |
2 | Complex project environment due to number of involved stakeholders Required changes | 9 | Involvement of all the parties in the process | Close involvement of stakeholders | |
3 | Scope changes because of underestimation of the project scope by the client | 8 | Less hierarchy to enhance possible changes | Close involvement of stakeholders Self-steering of complete project team Network structure | |
4 | Little trust with the client Predefined tight scope | 8 | Close collaboration with client (and other parties) More flexibility and less rigidity, in similar cases | Capturing the lessons learned here to manage similar projects | Continuous learning Close involvement of stakeholders Trust Broad task definition |
5 | Good scope, time and cost management | 9 | The Agile team Committed team | Team priority over individual priority Iterative planning (Agile) | |
6 | Involvement of multiple governmental parties with different management systems | 9 | Building trust for the involved governmental parties | Consensus in decision-making | Trust Consensus among team members |
7 | Took the lead by a single party in a joint- venture collaboration | Less hierarchy | Daily meetings to solve the problems | Network organisation Self-steering of complete project team Short feedback loops | |
8 | Keeping the balance between a number of managerial procedures to follow | 8 | Multidisciplinary team (education, experience, attitude, soft skills, gender diversity) Providing a safe environment to discuss the problems Right person for the right task | Self-assigning tasks to individuals Team members as stakeholders | |
9 | Poor team cooperation both internally and with external parties | 8 | Good results because of the application of non- standard approach | Close involvement of stakeholders Trust | |
10 | Focus on delivering within conditions (time, budget, etc.) while applying the changes | 8 | Adaptation to the changing circumstances | Embrace change Broad task definition | |
11 | Unstable scope in early phases of the project | 5 | Management of changes during the project's progress | Embrace change Broad scope definition | |
12 | Clear goal, flexible path, creative team, maintaining trust | 9 | Open to alternatives Reflection on the way of working Trust-based working condition | Trust Possible alternatives Short feedback loops | |
13 | Rework due to external changes and uncontrolled risks | 8 | Broad overview of the process, knowledge of change Management | Embrace change Seizing opportunities and coping with threats Contingency planning | |
14 | Little flexibility in process | 6 | Application of fixed procedures and processes | ||
15 | Difficulty in management of internal organisation Scarcity of right people in the team | 8 | Problems in following the standard procedures | Implementation of flexibility Top management support | Management support Network organisation |
16 | Dealing with a lot of changes during the execution phase to fulfil the project | 2 | Flexibility towards the changes | Embrace change Broad task definition | |
17 | Implementation of new management process with attention to schedule and control systems | 8 | Good and visible communication with mother organisation | Keeping the focus on project objectives | Close stakeholder involvement |
18 | Management team comprises people from three different companies | 8 | Flexibility in cooperation between involved companies | Keeping the balance between organisational interests and project interests | Close stakeholder involvement Trust Team priority over individual priority Interactive decision-making |
19 | Major scope changes, hierarchy in design-management team | 8 | Less flexibility in individual task performance due to high workload | Flexibility to apply scope changes Less attention to budget barriers | Embrace change Broad task definition Functional-realisation-based contract |
20 | Tight deadline | 9 | Periodic planning (every 6 weeks), weekly progress meetings for management team, daily progress meetings for subteams | Iterative planning Short feedback loops Open information exchange | |
21 | Good management of quality, time and stakeholders but not costs | 9 | Flexibility at all times and not at specific moments only | Close contact with costumer, dealing with all the issues by a very flexible modus operandi | Close stakeholder involvement |
22 | Rigid project management process between the lead advisors from multiple companies in the Consortium | 8 | Generating information regarding project management (time-consuming and not always used) | Flexibility to manage client expectations, team members and involved organisations Working together in the same location in order to manage interfaces, Align decision support information and provide insight into the process of activities | Network organisation Open information exchange Joint project office Interactive decision-making |
23 | Too much effort on project management process due to introduction of a new method | 5 | Flexibility not an objective of project management system at the company | Coping with unexpected incidents | |
24 | Poor relationship with the client, enormous amount of changes | 8 | Too much focus on controlling the budget and not much on customer satisfaction | Close stakeholder involvement Embrace change |
Overall success of the project | Successful from the client point of view, successful from project teams’ point of view, not successful from the company point of view | N/A | |||
Time | Time is fixed | Mostly projects delivered within time; for those delivered with delay, it was acceptable by the client because the client was the source of delay | × | ||
Cost | Maximum budget is fixed | One of the negative aspects of Scrum within the company; mainly because of learning costs | N/A | ||
Quality | Accepted by the client, delivery of products with high quality (company strategy) | N/A | |||
Client satisfaction | Main value driver of Scrum. | Clients were satisfied | × | ||
Conditions of client satisfaction | Conditions of client satisfaction should be known and addressed explicitly | There was a set of quality criteria as client satisfaction conditions, but overall, there was no common idea regarding what the client satisfaction conditions were | × | ||
Team building | Scrum team should be constant /fixed and the project should be assigned to the team | Few problems; first of all, lack of capacity at the company, teams vary in size during the project, teams are not constant, in contrast with the principal team which is being assigned to the project | × | ||
Multidisciplinary team | Team should be multidisciplinary | To some extent, teams are multidisciplinary | × | ||
Multitasking in team | It should be avoided | It happens always | × | ||
Integration | Working in one room, rather than individually in separate offices | Scrum teams were integrated. In the case of multitasked people in the team, the level of integration decreases considerably | × | ||
Exchange of information/knowledge | Working in one room, rather than individually in separate offices | Easy/doable in face-to-face communication | × | ||
Documentation | Proper/enough documentation, excessive or too much paperwork | Enough for the project itself but not enough for use as lessons learned for another project; in the case of multi-tasked people in the team, the amount of documentation increases | × | ||
Overall picture of the project | Visualising the overall project | Scrum creates the big picture of the project; the inconsistency of the Scrum team is a problem here | × | ||
Within team | Daily stand-ups/sprint meetings | Different opinions; examples are as follows: it is difficult when a team member is a multitasker; generally, a waste of time but saves time according to team alignment | × | ||
With stakeholders/clients | Client involvement/participation in weekly/every sprint meeting | Not enough client involvement/no interest from client side to participate in all meetings | × | ||
Definition | Value should be defined at the beginning | No definition of value | × | ||
Tracking | Value should be tracked during the project | Since there is no value definition, there won’t be any tracking of value | × | ||
Product backlog | Work is done in small batches, which are listed in the product backlog | Product owner defines the product backlog | × | ||
Sprint meetings | Value orientation over process orientation; delivering something that has value for the client in 2–4 weeks’ time | It worked well in doing the tasks, but there is doubt if something that has value for the client is delivered in each sprint meeting | × | ||
Duration of tasks | Realistic time planning by means of poker game | Estimation of the duration of tasks (products) by poker game | × | ||
Within team | More face to face, less paperwork | Informal face-to-face discussion, rather than official reporting; digital Scrum board, which is updated regularly | × | ||
With client | Client involvement/close cooperation with client | Monthly report to client/no client involvement in the Scrum process | × | ||
Time buffers | Time buffer is needed | Because of tight deadlines, there are no planned buffers | × | ||
Response to scope change | Responding to change (scope change) | In contrast with contract conditions, it results in requests for extra budget and time | × | ||
Problem-solving | Problem-solving should be planned/clear; impediment should be resolved | Not really planned; product owner/project manager is the source of problem-solving | × |
What | 1 Broad task definition | ( |
2 Embrace change as much as needed | ( | |
3 Functional-realisation-based contract | ( | |
How | 4 Self-steering of the complete project team | ( |
5 Open information exchange among different groups | ( | |
6 Shared interface management | ( | |
7 Contingency planning | ( | |
8 Seizing opportunities and coping with threats | ( | |
9 Trust among involved parties | ( | |
10 Standardised process and design | ( | |
11 Visualised project planning and progress | ( | |
12 Possible alternatives | ( | |
13 Network structure rather than hierarchical structure | ( | |
14 Continuous learning | ( | |
Who | 15 Consensus among team members | ( |
16 Stable teams | ( | |
17 Self-assigning of individuals to tasks | ( | |
18 Team priority over individual priority | ( | |
19 Team members as stakeholders | ( | |
When | 20 Late locking | ( |
21 Short feedback loops | ( | |
22 Continuous locking (iterative) | ( | |
23 Iterative planning | ( | |
24 Iterative delivery | ( | |
Where | 25 Joint project office | ( |
26 Have flexible desks | ( |