Nov 7 2021

My ISD Planning Framework & Efforts Are Not a Waterfall Approach – Despite the Imagery

My approach to ISD – Instructional Systems Design only looks as if it’s a waterfall approach. But it isn’t.

Graphical representations of process flows are limited in how they might show iterative data additions, without becoming quite messy.

I won’t attempt to show that messiness.

I addressed this in my 15^th book, published in November 2020, on how I conduct Analysis in each and every phase of my ISD methods for Instructional Content development – which I branded as MCD back in the early 1990s.

Waterfall Methods

Let me next explore ISD and the Waterfall concept a bit.

Waterfall Efforts – The waterfall approach to development is often framed and represented as a set of linear, sequential phases. Each phase takes what the last phase dropped on them, and like a waterfall, it falls over the edge to the pool of water below, repeating that as the water continues down the mountain to some endpoint, usually an ocean.

A waterfall effort in ISD would take a handoff of a Design, and Develop the Instruction without ever looking back or updating the Design based on new information, and then hand that off to the next step – after taking forever, as if trapped in Design Paralysis – a close cousin of Analysis Paralysis.

IMO, waterfall approaches are often misunderstood, in that the hand-off between phases, or stages, or segments of the overall process, means to some, a total disconnect from the prior efforts, and that there is nothing new added to the previous outputs as they inform those downstream efforts.

While development efforts can be run like that, most are not.

And, the notion of waterfall efforts run precisely like that, are used as a proverbial strawman, and unable to bayonet back when attacked in such a ridiculous manner by such false notions.

The waterfall complaint is often used in attacks of ISD – Instructional Systems Design efforts.

Back in early 1981, it was suggested to those of us who did ISD – Instructional Systems Design work, that we should create a Design Document so detailed and tight that we could then hand it off to a Developer, who would simply generate the Instruction all by themselves. And that they would not need to interact with anyone else to complete their assignment. The Design Document had to contain everything needed.

“As if they were to finish the effort in a closet,” I thought to myself at the time.

I resisted that notion back then.

That notion, decades later, is now generally known as a waterfall model/approach.

By that point in 1981, I had been in the ISD – Instructional Systems Design field for two years, and I had been involved in project planning, analysis, design, development, and implementation efforts for several dozen ISD efforts. And the hand-off to a developer who didn’t get to conduct any additional analysis, or data gathering, just didn’t sit right with me.

There was no way that I could have captured everything needed during the analysis efforts, and then reflect that in the design. I even said so in response to those suggesting that that was how we should do it. I offered that perhaps we should just create the content and skip the design effort if the Design Document had to be that complete.

I had learned things in my prior Development efforts, additional information that resulted from what could have been called analysis. If I’d taken forever and gathered anything and everything – not yet knowing if it would/could be used, or not.

And in my design efforts, I had gathered more of what could have been the results of analysis efforts after my Analysis had been reviewed and the scope of what I was working on had been re-Scoped – wider at times, and narrower at others.

“Guy, let’s keep Topics/Tasks, A, B, and C, but drop E and F.”

Or, “Guy, we need to add G, H, and I, to A, B, and C.”

Now we were targeted on specific aspects of the job tasks, but not every task. Some tasks had fallen by the wayside and were no longer going to be addressed, while new aspects were added by the client.

That was okay because we simply rolled with the client’s punches (so to speak) and address those changes in our next Phase – Design or Development.

During the Development efforts, we’d obtained additional details and nuances from our sources.

And when we did the initial Deployment – which I framed as a Pilot Test, we learned additional facts that were added in during the Revisions, post-Pilot.

Waterfalls & Transoms

Before waterfall became the language used – it was transom – the small window above a door. As the saying went, one party would throw their deliverable over the transom, for use downstream. I first heard that version in the TQM – Total Quality Management movement back in the late 1970s.

I dislike the “throw the data over the transom” and then “let the next group run with it” kind of hand-off. That would be a pure waterfall approach, in my opinion.

I prefer to use two kinds of hand-off mechanisms:

Kick-Off Meetings
Briefings

I use these when I have employed a divide-and-conquer strategy for the various roles across an ISD effort so that the development effort may be accomplished by multiple people, working in parallel, and not in series.

Either one ISDer does it all, or the ISD development roles and responsibilities are divided between two or more people.

And sometimes, I have downstream players overlap with earlier phases and tasks – especially when the performance is complex and extremely high stakes.

When the Instructional content is tricky, and we are in a hurry to get the Instruction ready for learner/Performer Access and Deployment, I have my Lead Developer participate in the Design Phase, and maybe the Analysis Phase as well.

For example, I might have a Lead Developer attend the Design Meeting; or I might have the Designer attend the Analysis Meeting.

Ensuring Continuity Phase to Phase

I assign the person with the assigned project role (but not necessarily the job title) of Project Planner/Manager, the responsibility to facilitate the hand-offs.

They are the continuity, the glue, from one phase to the next in my 6 phase MCD framework.

The other roles – or “hats” – as I sometimes refer to them, include these in the next graphic:

A Hand-Off Doesn’t Mean Waterfall

I use hand-offs between phases, and within phases. I prefer careful hand-offs that are both effective and efficient.

I prepare handoffs at the end of a phase, for use at the beginning of the next phase.

Avoid Analysis Paralysis and Be Flexible

It has always seemed to me that approaching Analysis as a single, one-shot effort was a silly notion. One time and then you are done, was more than just a bit misleading, as my experience by 1981 was that analysis can and should happen throughout the undertaking.

As Rigorous as Required and As Flexible as Feasible

In 1982 I became an ISD consultant. I joined a small consulting firm as the ISD Practice Leader, and I began to formalize my ISD methods to both develop project plans and to offer either fixed fee or time and expense pricing to my clients, and to build the skills of my consulting staff to conduct those projects, to plan.

The last thing I needed was my team working as an artist colony, with everyone doing their own thing, their own way. I wanted a more engineering approach. I wanted an architectural approach.

The intent of my 15th book was to share how Analysis can be a part of every step or phase, in a systematic approach to Instructional Development that does go that last mile to authentic applications, for a positive, worthy Performance Impact.

My ISD approaches certainly did not reflect a waterfall approach, although I appreciate that the graphics that I use undoubtedly could be misread as such.

Modular Curriculum Development/Acquisition (MCD) is my ADDIE-like methodology-set. It produces Instruction, including Job Aids and Training.

The graphic above depicts the 6 phases of MCD, which facilitate project planning and management efforts. And it certainly isn’t a “design model.”

And it is sometimes reconfigured, especially if that effort follows a CAD – Curriculum Architecture Design effort – where a fair amount of the Analysis and Design had been done and just needed to be detailed further. Perhaps that post-CAD effort would be framed as follows.

Note: the upside-down traffic lights in the graphic, also known as Stop Lights, represent Project Steering Team Gate Review Meetings (PST GRM), where the effort and data generated to that point are reviewed and approved or modified or rejected.

To me, they are Go Lights. That’s why they are upside-down.

The Gate Review Meetings gives my client and their clients the Command & Control mechanism they wish – and the Empowerment mechanism I want and need.

I get to pose the Business Decisions I come across to an authority group at critical points in the process via these Gate Review Meetings, so that the stakeholders can make those business decisions that are inherent in almost every ISD effort of consequence. Those often involve tricky trade-offs, business trade-offs.

It’s in those meetings with the Project Steering Team at the end of 4 of my 6 Phases, that scope get’s reviewed, approved, or modified. And in the following Phase, “we swim back upstream” – so to speak – and recover by getting what we need downstream.

Note 2: I’ve extracted the “traditional” Pilot Test effort from the Development Phase – and made it its own Phase – so that I could highlight that effort, as I’ve always thought it to be a critical step – where my final Analysis would/could happen before the final Phase of Revision & Release.

Release to the systems and processes in place for On-Going Access and/or Deployment – which could include Coach and Instructor Training, on-going evaluation, maintenance, etc.

The Last 3 of My 17 Books

I’ve attempted to share the critical aspects from what I’ve learned about ISD – now LXD – and how to impact Performance Competence back-on-the-job.