Fig. 1
Fig. 2
Fig. 3
Fig. 4
High-ranked and low-ranked flexibility enablers from different participants’ (N=43) points of view
| Perspectives | ||||
|---|---|---|---|---|
| Trust | Scope flexibility by contractual flexibility | Proactive management | ||
| Client organisations | High-ranked flexibility enablers |
|
|
|
| Low-ranked flexibility enablers |
|
|
| |
| Consultant organisations | High-ranked flexibility enablers |
|
|
|
| Low-ranked flexibility enablers |
|
|
| |
Hypotheses regarding the effect of project management flexibility on project performance
| Hypothesis | Result of testing |
|---|---|
| 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 |
Examples of flexibility from practice
| Case | Situation | Flexibility score | What has to be improved in flexibility | What went well | Related flexibility enabler (s) |
|---|---|---|---|---|---|
| 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 |
| |
| 2 | Complex project environment due to number of involved stakeholders Required changes | 9 | Involvement of all the parties in the process |
| |
| 3 | Scope changes because of underestimation of the project scope by the client | 8 | Less hierarchy to enhance possible changes |
| |
| 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 |
|
| 5 | Good scope, time and cost management | 9 | The Agile team Committed team |
| |
| 6 | Involvement of multiple governmental parties with different management systems | 9 | Building trust for the involved governmental parties | Consensus in decision-making |
|
| 7 | Took the lead by a single party in a joint- venture collaboration | Less hierarchy | Daily meetings to solve the problems |
| |
| 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 |
| |
| 9 | Poor team cooperation both internally and with external parties | 8 | Good results because of the application of non- standard approach |
| |
| 10 | Focus on delivering within conditions (time, budget, etc.) while applying the changes | 8 | Adaptation to the changing circumstances |
| |
| 11 | Unstable scope in early phases of the project | 5 | Management of changes during the project's progress |
| |
| 12 | Clear goal, flexible path, creative team, maintaining trust | 9 | Open to alternatives Reflection on the way of working Trust-based working condition |
| |
| 13 | Rework due to external changes and uncontrolled risks | 8 | Broad overview of the process, knowledge of change Management |
| |
| 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 |
|
| 16 | Dealing with a lot of changes during the execution phase to fulfil the project | 2 | Flexibility towards the changes |
| |
| 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 |
|
| 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 |
|
| 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 |
|
| 20 | Tight deadline | 9 | Periodic planning (every 6 weeks), weekly progress meetings for management team, daily progress meetings for subteams |
| |
| 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 |
|
| 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 |
|
| 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 |
|
The practice of Sc rum versus the theory
| Explored items | Scrum based on theory | What is happening in practice at the company (3 projects) | Aligned | Misaligned | Neutral |
|---|---|---|---|---|---|
| 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 | × |
Flexibility enablers of project management
| Category | Flexibility enablers | Main source |
|---|---|---|
| What | 1 Broad task definition | (Koppenjan et al. 2011) |
| 2 Embrace change as much as needed | (Olsson 2006; Priemus and van Wee 2013) | |
| 3 Functional-realisation-based contract | (Koppenjan et al. 2011) | |
| How | 4 Self-steering of the complete project team | (Koppenjan et al. 2011) |
| 5 Open information exchange among different groups | (Koppenjan et al. 2011) | |
| 6 Shared interface management | (Koppenjan et al. 2011) | |
| 7 Contingency planning | (Olsson 2006) | |
| 8 Seizing opportunities and coping with threats | (Blom 2014) | |
| 9 Trust among involved parties | (Atkinson et al. 2006) | |
| 10 Standardised process and design | (Giezen 2012; Perminova et al. 2008) | |
| 11 Visualised project planning and progress | (Beck et al. 2001) | |
| 12 Possible alternatives | (Priemus and van Wee 2013) | |
| 13 Network structure rather than hierarchical structure | (Beck et al. 2001) | |
| 14 Continuous learning | (Giezen 2012; Perminova et al. 2008) | |
| Who | 15 Consensus among team members | (Cobb 2011) |
| 16 Stable teams | (Beck et al. 2001) | |
| 17 Self-assigning of individuals to tasks | (Cobb 2011) | |
| 18 Team priority over individual priority | (Beck et al. 2001) | |
| 19 Team members as stakeholders | (Beck et al. 2001) | |
| When | 20 Late locking | (Olsson 2006; Huchzermeier and Loch 2001) |
| 21 Short feedback loops | (Cobb 2011) | |
| 22 Continuous locking (iterative) | (Olsson 2006) | |
| 23 Iterative planning | (Cobb 2011) | |
| 24 Iterative delivery | (Beck et al. 2001) | |
| Where | 25 Joint project office | (Osipova and Eriksson 2013) |
| 26 Have flexible desks | (Osipova and Eriksson 2013) |