“25 billion dollars.”
Sorry, could you repeat that?
25 billion dollars.
We were sitting in one of QGC’s meeting rooms overlooking the Brisbane River, trying to make sure we heard correctly.
Was that with a B?
Yes.
And what does this thing do exactly?
It’s not just one thing; it’s a whole infrastructure project. But the bit we’re interested in is this plant on Curtis Island. It’s a liquefaction plant. It’ll convert coal seam gas to liquid natural gas.
Converting coal seam gas to LNG was a world first, and there were going to be lots of production technicians and engineers running the plant who would have never have seen anything quite like it. So QGC wanted an online learning program to show them how to run this multibillion-dollar plant.
Sounds complicated.
Oh, for sure. We reckon there’s about 19 different modules. Each one is going to have to be written by a different subject matter expert. But they’re obviously in the process of constructing and commissioning the plant, so they’re pretty busy.
Right. So when will they be done with construction?
In about six months.
And when do you need this training course?
In about four months. Is that achievable?
We thought about it. From the top of the QGC building you could see right out to the bay.
practice… well, maybe.”
How to push a big project through quickly
QGC’s need was not that unusual: a high stakes, high pressure enterprise project needing technical training and documentation in time for launch. One approach is to divide up the work and set a team in motion as quickly as possible, confident that your team’s production will be linear and consistent.
The problem is that projects that scale up too quickly tend to accumulate small but crucial mistakes in the early output. These problems then compound until the efforts to fix it all up devolves into something that rhymes with blusterduck.
The other approach is to use production line thinking, and that means producing one complete piece of work that allows you to test your process from end to end — including revision and feedback cycles — and then once you have truly ironed out all the kinks and have a model that everyone agrees on, then you scale up to meet your production deadline.
This process works, but it takes patience and discipline in the face of a terrifying deadline.
“Have you SEEN it?”: Laying the foundation for good work
Oh. This is what you’re doing?
For us, the first step in a project is to look around, so we went to see the plant under construction.
It’s not entirely obvious why this is necessary: after all we’re not engineers, what benefit do we get from a field visit? Can’t we just use supplied documentation and interviews over the phone?
The reality is that context is everything. We needed to SEE the thing, to stand amongst it, to get a feel for the scale and complexity of it — the security clearances, safety training, ferry rides, the massive equipment, the thousands of people, the spatial relationships between buildings and equipment — so that ultimately we had some frame of reference for all the technical information that was going to come our way.
From all that complexity came clarity. There was only one way forwards, and the first step in the path was assembling a team. A crack team, at that.
Forming an A-Team with good coping skills
Fred Brooks’ book, The Mythical Man Month, argues that adding people to a knowledge project does not necessarily make the project more efficient, and we know the truth of that from our own experience. So we wanted to form the smallest possible project team.
First, we needed a content expert. QGC had 19 different domain experts at the plant. That was too many to deal with separately. We needed someone from QGC embedded in our team, someone to fully represent the needs of the production technicians and project owners.
Enter Linda Varghese. A QGC instructional designer with an engineering background, Linda was our engineering translator, champion and guide.
Next we added a senior instructional designer of our own, one who was experienced, innovative but also pragmatic.
We also needed a smart developer who could think about efficiencies and economies of scale, so we added one of our lead developers who had a very full-stack temperament.
Finally we needed a project manager to manage scope, make hard decisions, and communicate on a daily basis with the client. Since we were trying to create efficiency with the smallest possible team, we took the opportunity to double up: our lead developer became project manager as well. For many people this would be an impossible burden; for him it was just a problem in need of a solution.
So that was the core team: three people, for a project that would normally take a dozen.
Now these three experts had to find a way to tame the beast.
Making the template
To create a production line you need a template, and that template needs to be bulletproof.
A template is not a theoretical tool; it needs to afford flexibility while managing complexity — it needs to able to handle whatever gets thrown at it, and real life content tends to be full of spikes and thorns. In this instance we were lucky that QGC already had a well-developed draft for a first module.
So to begin, our senior instructional designer flew out to the plant to interrogate content experts about the purpose and use of the content, trying to figure out what was essential. Meanwhile Linda tried to define global requirements as well as anticipate idiosyncratic needs based on specific content, and our developer started designing a presentation framework and overall technical approach.
By working with authentic content and getting lots of expert feedback, we were able to create a lightweight but robust template in PowerPoint. At 60 pages long, it helped us figure out how to sequence and chunk information, what kinds of activity types were required, what kind of visualisation techniques could be used and so on, with a high level of confidence that the decisions would hold up when applied to other modules.
But the same issue kept coming up: stakeholders could see the logic in the content structure, but they couldn’t imagine how it all came together in practice. That was a big gap that needed to be filled quickly.
Developing a prototype
The PowerPoint template was great, but we needed to help the content experts and test our own assumptions, we needed to take it a step further: we needed a prototype.
The core team worked closely together, and they brought in the Liquid design team to help work out standards. How would information be arranged on screen? What could be efficiently layered? Where could animation add value? What elements benefited from interaction?
And how would this plant be visualised? That was a huge problem. The plant was under construction, so there were no photos. QGC had a limited range of schematics, but they were too dense for instructional purposes. So using the materials at hand, plus some promotional flyover footage for reference, the team came up with an infographic art style that was technically accurate while also being beautifully elegant.
At the same time as all that, our developer was considering production-line requirements: building a content management system and component library, laying the technical foundation for when other developers would come on board for the big push.
Through iterations of the prototype, experts began to see how a final module would work, and this gave them the vision they needed to begin completing their content templates.
But we couldn’t stop there. A prototype is just a prototype, it doesn’t test everything. We had more to do.
Oh. This is what you’re doing.
Completing a unit of work
As experts began sending in their first completed content templates, we kept working on the prototype to get it to release standard.
Why? Because any problem that gets through at prototype stage becomes 19 issues at deployment stage. But if we can complete a single unit of work, end to end, we will have at least tested every point in the development chain and eliminated as many issues as we can find.
That meant going all the way to the end of the process, through content reviews and acceptance tests and test deployment. Every step was checked, flushing out one annoying problem after another, but resolving them as they came up, with no need for mass rework.
The only problem was that this approach came at a cost: anxiety.
Starting the production line
So we’ve spent 25% of the time?
Yes.
And we’ve produced 5% of the work?
Yes.
So that means this project will take 20 months, not 4
No.
Time was counting down, and the giant to-do list of 18 new modules was entirely unticked.
But now all that careful set-up was about to pay off. With a complete piece of work and a bulletproof template in place, we were finally ready to ramp up production.
While Linda helped subject matter experts across the plant submit their final content templates, our guys scaled up the instructional design and development team, and began pushing content through the production line with minimal onboarding, confident that the client would be happy with the output.
So if the biggest issue on this project was scalability, how did we go?
Like a well oiled machine
In the first month of the project we visited the plant several times, developed relationships with key QGC stakeholders, built templates and development infrastructure, defined processes — and most importantly we tested these end to end on a complete unit of work.
So in the first month, we made one module.
Then in the next three months, we made 18 modules.
That’s a 600% increase in throughput, and the reason why this was possible was because we didn’t have to do any rework. (At least nothing outside of bounds we’d already anticipated.)
Our three-person core team expanded at its peak to have 20 subject matter experts, three instructional designers, three developers and two QA staff. However instead of losing time in bringing people up to speed, checking work and doing lots of revisions, the core team helped everyone follow clear standards and precedents, and had confidence in the quality of the work.
In the end everyone was pushing hard right up until the deadline and then bang — suddenly all the modules had been delivered, and the whole team both at LI and QGC breathed an enormous sigh of relief. Everything had been shipped, the QGC team were delighted, and we were looking at what might be the world’s first digital operations manual for a major piece of energy infrastructure. All conceived and delivered in less than six months.
Linda’s thoughts
This project seemed a daunting task at first. Its success solely depended on a team that was essentially on the same wavelength and embraced the objectives and the brief alike and worked seamlessly. Working with Liquid Interactive made this possible – it never felt like we were two different companies.
The manner in which the Liquid Interactive team embraced developed the 2D simulation for the plant and implemented simulated process flow diagrams almost perfectly at the first go was a big ‘WOW’ moment in the project.
The initial reaction to the work has been very positive. It is engaging, and the visualisation and interactions maintain interest. It empowers the learner and achieves the objective of equipping the operator with information and motivation to the right thing on the job.