The ‘Environments Stream’ was a project embedded within a larger digital learning platform programme. The project objective was to build a set of environments on the clients Kubernetes backed PaaS so that microservice applications could be developed, tested and production hosted in order to prepare a product for a digital education pilot. 

As the ‘Environments Stream’ project delivery leader, I analysed the programme using the NCTP diamond framework in order to think through a suitable delivery management approach for the project.

An analysis of the dimensions indicated the following :

• Platform novelty. The microservice applications were innovations that would create a core platform to host digital education software product models, replacing the clients old product technology. New product development is subject to significant analysis and market research with requirements changing frequently until mid / late in the project.
• High technology. The product comprised a combination of recently matured technologies. A large number of project staff were not familiar with the technologies.
• Array level complexity. The product composition was a complex system of interface integrating software technologies integrating beyond their boundary with other peripheral systems. Application development was being undertaken by an external vendor on legal contract and their activities were coordinated with an array of internal project teams in the programme.
• Time-critical pace. The window of opportunity for the pilot was linked to a fixed date.

Reflections that would influence the delivery management approach were the following. The innovation end state was known but it was not a simple derivative of the past – it was a new type of platform. The technology used to build the platform was not yet known by the entire DevOps project team and the environment delivery management approach would require dynamic capability building, flexibility and an expectation of frequent changes. The project would be operating in an environment of array level complexity.  That is to say – interactive systems of systems complexity. Human and technical systems interacting with other systems across numerous boundaries. Furthermore the schedule was time-critical due to a fixed date.

Project Lifecycle

A Hybrid approach 

• In the analysis phase a Systems map was used to understand the structure of the clients product, architecture, engineering and security teams, the vendors architecture, development and QA teams and reflect on the intra and inter interactions in and across both groups.
• The initial life cycle phase resonated with spiral. The DevOps engineering team delivered a set of environments on the clients strategic PaaS via a series of prototype stages and technology risk was managed by starting with the common architectural components on which later iterations were dependent.
• In phase 1, an adaptive agile approach was used to manage environment builds via incremental planning, implementation and reflection.
• In phase 2, an integrative baseline had emerged, and a predictive linear approach was used to more rapidly manage subsequent baselined environment builds.

Project Software

Jira	Scrum for managing adaptive environment build activities. Kanban for managing predictive environment build activities.
Google Drawings	Systems maps and causal loop diagrams for systems thinking analysis. Activity on Arrow (AoA) for the project network diagram. Resource loading chart for time limited scheduling. Ishikawa fishbone diagrams for cause and effect analysis while working on operational stability.
Spreadsheets	Work breakdown for scoping.

The delivery management situation

The first set of environments was built slowly in prototype increments using an agile approach to iteratively discover and adapt to changing requirements coming from stakeholders. The resulting baseline of configuration items, the major milestone of project phase 1, had resulted in the definition of authoritative blocks of build scope and these had been captured in an environment build play/run book. The codified sections of the play/run book, analogous to work packages / epics comprised series of activities that could now be used as a blueprint for building additional environments at that baseline level via a subsequent second project phase.

For phase 2 I had a hard working DevOps delivery team that was committed to the project and implied access to project external resources via functional managers. The managers were under pressure in different parts of the programme array and generally reluctant to supply staff. I reflected on the following before considering techniques to increase the pace of delivery :

• How could the delivery management speed up its phase 2 delivery?
• Which activities needed to be given closer attention in order to deliver on time?
• Which project external resources need to be involved, by when must they be made available, what will they be doing and for how long?
• How can the delivery manager avoid making excessive or unjustified resource asks of functional managers?

Analysis and discussion

Using the documented environment build play/run book, activity level tasks were captured in a spreadsheet, creating sections of baselined scope. These low level activities grouped together became analogous to stories/tasks in activity work packages, and were to be processed using Kanban to build the phase 2 environments on a tight schedule. The tasks had been estimated for duration by component and the judgement of the most experienced engineers involved in the phase 1 environment builds. However, reflection was in order as there were numerous weaknesses with this approach.

Weaknesses of the approach :

• A task list does not easily show dependent / independent activities and the precedence constraints for dependent activities.
• It is difficult to determine which tasks on the list have most schedule importance / significance relative to the others.
• It is difficult to determine how many resources are required to build the environment on time and what those resources would be doing on any particular day of the schedule.
• It is difficult to use the task list to manage across functions for resource asks.

After reflection, the pace of phase 2 delivery was improved by using the following concepts and techniques.

Float and Critical Path

Certain environment build activities can within limits take longer than the duration estimated without the project phase running late. Others have to be completed on time!  Distinguishing between these two types of activity, the former is said to have float. Determining the float, or lack thereof, of all the in-scope environment build activities is a useful first technique for then identifying a critical path, a sequence of activities that must complete on time for the project to be delivered on schedule. The advantage of this technique is that it focuses the delivery manager on the tasks that matter – in the context of the schedule.

Calculating float and plotting critical path is preceded by creating an activity table with duration estimates and then using a network diagram to sequence the activities. The Activity on Arrow (AoA) network diagram below illustrates how the technique was used in phase2. Using activity estimates a ‘forward pass’ and ‘backward’ pass analysis established the earliest start times and latest finish times for the activities which have also been arranged to show which can run in parallel and which are sequential. Activity level milestones – in this case M1,M2 represent significant build stages.

In this write up the individual task level durations and earliest / latest event times have been excluded from the network diagram. They can however be interpreted with the subsequent resource loading chart which shows activity durations on the basis of a 10 day time limited schedule for an environment build.

Time limited scheduling

An advantage of having done a network analysis for float and critical path is that the outputs can along with activity resource estimates be fed into a technique called time limited scheduling to look at the specific resource loading required to finish an environment build in for example, 10 days. The resource loading chart below demonstrates the technique with activities on the critical path loaded at the base and activities with float higher up.

An allocation of named resource and analysis of the loading chart allowed me to :

• Determine how many resources I needed to complete the project phase split across core and external, when they were needed and what they would be working on.
  • The core project team
    • Eng1, Eng2, Eng3, Eng4, Eng5
  • External resources from functional managers
    • Con1, QA1, Dev1
• Use the chart, along with the network diagram, to negotiate lead times on the external resources, indicating clearly to the functional managers what their staff will be working on and for how long.
• Allocate the most experienced core engineer to work across the critical path to prevent context switching from demotivating him. A disadvantage however is that this became a risk when he was away due to emergency, illness or holiday.

Conclusion

In conclusion, consider projects where a first phase of exploratory / adaptive prototype activity delivers a baseline product such as a built environment of configuration items that then needs to be quickly reproduced / cloned in subsequent phases. Switching to a predictive approach in the second phase and using techniques such as critical path management synthesized with time limited scheduling and resource loading charts can increase the probability of the second phase meeting its scheduled delivery end date. This is demonstrated in figure2 and figure3 of the analysis where the analysed outputs of a sequenced AoA network diagram have been fed into a resource loading chart to provide direction for managing a time limited schedule.

Making a human resource ask can be frustrating to functional management when it comes as a demand out of the blue. When in a predictive phase the resource loading chart can be used as a tool for the delivery manager to rationally communicate lead times for project external resource asks and to accurately state what the resource will be doing and for how long.

Recommendations

In many companies adaptive agile delivery management approaches, excellent for prototyping in conditions of technology and market uncertainty have become a default project approach.

A point for reflection however is :

• Depending on the phase context of your project, are certain predictive techniques appropriate to a particular phase and can they be used to improve managerial performance related to managing critical tasks, time limited scheduling and facilitating the efficacy of project external resource asks?

In delivery management situations analogous to the one in this report, I offer the following four recommendations :

1. Consider your project fluid and use an adaptive approach until a baseline of value has been developed that you now choose to quickly clone or scale out as a second phase.
2. Rather than continuing with an adaptive approach, change this second phase of delivery to a predictive approach and use Float and CPM planning techniques with a network diagram to identify the activities that matter so that you focus on these to deliver the value on time.
3. Also in the second phase create a resource loading chart to time limit your schedule and load resources accordingly. Identify which external resources you will need outside of your core project team in order to deliver within your time constraints or because you do not have certain activity skills in the core.
4. Use the resource loading chart to better manage across functional management for the project external resource asks. You will be able to tell these managers how long you need their staff for and precisely what their staff will be doing.

Ethical considerations  :

• In projects where the critical path of a second or subsequent project phase like the one described in this report is time limited but of a longer duration and the delivery managers intention is to use the same set of highly skilled individuals on the critical path activities, consider the impact of the sustained and prolonged workload on the health of these individuals. Design substitutions and handovers into the plan.
• Make sure that the team, or substitute team working on the critical path activities are getting rightful recognition for their performance and reliability.
• In technology projects, automation is an option for repeatable activities. Take a strategic approach by focussing the automation efforts on the critical path activities as this will build an on-schedule delivery capability that offloads manual work from your critical path team. Automation should ideally be designed and built in from the start but the power distribution, politics and competing delivery pressures in complex interdependent delivery environments means that automation will sometimes need to be tackled retrospectively.

Patrick Hyland