Adaptive Project Framework in Celebration of Change...

A colleague pointed out the article from which I have pasted the excerpt below. Since my primary job is that of a learning solutions consultant and designer of training to corporate organizations, I tend to  apply my learnings to today's training design scenario...

The traditional world of project management belongs to yesterday. There will continue to be applications for which the traditional linear models we grew up with are appropriate, but as our profession matures we have discovered a whole new set of applications for which traditional project management (TPM) models are totally inappropriate. The majority of contemporary projects do not meet the conditions needed for using TPM models. The primary reason is the difficulty in specifying complete requirements at the beginning of the project. That difficulty arises from constant change, unclear business objectives, actions of competitors, and other factors.

While the article is targeted at project managers, anyone who is involved with designing training for a product that is being developed in tandem will understand the challenges such a scenario poses. Trying to pin down the overall scope at the initial stage is like trying to hold on to a handful of sand...You cannot prevent the grains from trickling out no matter how tightly you close your fist. And waiting for clarity on scope and all other "changeable" aspects of a project at the outset will be akin to Waiting for Godot...

The only constant will be the change and change can no longer be perceived as a challenge...

Change will now be a constant parameter in all projects and how we deliver the end solution while embracing change is what will distinguish today's project management from yesteryear's TPM.

What this also means is being comfortable with less-than-perfect information, being able to envision the end without knowing each and every step in-between, being able to ADAPT as the project moves without going off-track, having a finger on the pulse and thinking innovatively...

"From its very beginning to its very end, APF is designed to continuously adapt to the changing situation of a project. A change in the understanding of the solution might prompt a change in the way the project is managed, or in the very approach being used. Learning and discovery in the early cycles may lead to a change in the approach taken...Nothing in APF is fixed. Every part of it is variable, and it constantly adjusts to the characteristics of the project."

I think such dynamic projects have three key requirements for successful delivery:

1. Collaboration
2. Communication 
3. Creativity

I urge all concerned with project management or designing training solutions that the client can use to read this report...Personally, I look forward to such dynamic projects. I will share my recent experience on one such project in my next post.

Introduction to the Adaptive Project Framework

A perfectly executed project is but a flawlessly directed play…

Preamble:
To briefly set the scenario, I had been involved in a project where an organization was rolling out e-learning for the first time, making a shift from pure instructor-led training (for the formal learning bit) to a web-based environment. The key people involved—the trainers, the business clients, managers, target learner groups—were all folks in their late forties and early fifties, and their average tenure in the organization was 15+ years.

It is easy to imagine the radical shift this move to an e-learning environment meant for them. Most of them had no idea what it entailed except that the training would now be available on their desktops—click and access. The whole experience was wonderful for me because I got an opportunity to consult, guide and handhold an organization into taking the steps necessary to make the transition.

What ensued:
The actual development and delivery of the e-Learning Program started. However, I soon realized that although things appeared to be moving smoothly with deliveries, deadlines, SME calls, and all the other stuff common to an e-learning project, there was something radically wrong.

For some time, I just could not isolate the problem. It was a nagging ache that I could not articulate. Eventually, I stopped thinking about it telling myself that I was being over-analytical, a navel gazer.

Probably because I had stopped thinking, a very small incident led me to the answer. It was one of those innocuous comments that suddenly made everything crystal clear. I was onsite along with another colleague. We were in a meeting discussing process flows and project-related tasks when a comment from my colleague startled me.

The comment was innocuous enough. “I will complete the Course Design Document before I return,” she was telling the client. I was too startled to react (and good I didn’t since we were with the client)…At the face of it, there is nothing startling about this comment.

However, to the best of my knowledge, a Course Design Document is a high-level instructional design work that instructional designers with quite a few years of experience in organization and learner analysis, mapping of performance to business outcome, and understanding of learner levels and content can effectively perform. It requires rigor, analysis, and experience. I won't even go into what Dr. Karl Kapp would say.

Hence, the casual comment coming from someone who is not an ID caught me off guard. Furthermore, the client’s acceptance of it set my brain spinning. The following thoughts raced through my mind in quick succession:

• My colleague doesn’t know what she’s talking about
• The client doesn’t know what course design entails
• My understanding of my task was seriously flawed
• We don’t have clarity on our roles and responsibilities

The moment the last point occurred to me, I realized I had hit bull’s eye. To me, this confusion of roles and responsibilities, however inadvertent, seemed like an ominous portent, and I realized where the void lay.

There was no one sitting the client-side stakeholders and the project team down and setting expectations and goals. Each individual was doing his/her bit with sincerity, but no one was gluing it together. There were too many disconnects and parallel tracks; too much of "ad hocism", which led to constantly shifting expectations and a sense of confusion.

The project lacked a leader. The project had a project team and a project manager, but there was no project leader. This play was running without a director.

The role of a project leader was all the more important since the client was transitioning to a medium of training that was new to them. Just as someone had to handhold them through the transition, they also had to be introduced to the functions and roles of the project team. Similarly, the project team internally needed to know who was responsible for what.

To me, a project resembles a finely scripted play where each individual has a unique role to fulfill. The cohesiveness of the play comes from the melding of individual performances into a unified act. Just as the success of a play depends on picking up the right cues, perfect timing, collaboration, and following the right sequence of events, the same applies to a project. And this is what a director enables.

This project was lacking a director. The players were all set to act but the script was not distributed. No one really knew which script to master and which role to adopt. The actors were present but no one knew when to enter the stage or exit, and when they did enter, exactly what their dialogue should be.

Project Management for Trainers: Key Concepts and Learning

I have just finished reading the book, Project Management for Trainers by Lou Russell. At the outset, let me admit that this is a somewhat unusual book for me to read. I am more into books about learning and performance, training, design, creative thinking, innovation and management, writing, and the like.

However, increasingly in my role as an Instructional Designer (ID), I have run up against the necessity to not only multi-task but also to think beyond training solution, learning needs and design. I have also realized that to be an effective ID, there are certain aspects of a Project I would need to understand better and get a handle on.

With this thought in mind, I took some time out to sit down and take stock of the tasks I have found myself doing in the last three months (in varying proportions). I have listed the broad categories of the tasks below (each task has many and varied sub-tasks that I will take up in subsequent posts):

1. Business Needs Analysis
2. Performance Consulting 
3. Learning Solutions Design and Development
4. Project Management (PM)
5. Communication (both internal and client facing)
   

Having arrived at the list above, I did the next level of analysis to find out my weakest area. Project Management jumped out at me in a font size 10 times larger. I admitted to myself that I sucked at PM...no, not sucked...had no clue about PM.

This self-analysis became the stepping stone for my research into the kind of books I need to be reading and the resources I should be referencing.

And I picked up the book I have mentioned above. This engagingly written, practical, interactivity-filled, slim book is a wonderful introduction to the basics of Project Management. It covers all the fundamentals in a manner that is easy to understand and does not overwhelm with details. It gives you enough space and opportunity to think over what you have read and apply that practically. The book also provides a list of references and resources and is a must have on the shelf if you want to learn how training projects need to be managed and executed.

Some of the key concepts explained in the book that I have found particularly useful are:

1. Differences between project and process
   
2. Project Management Activity vs. Project Development Activity
3. The Dare Approach (Define, Plan, Manage, Review)
4. Arriving at Business Objectives mapping to IRACIS (Increase Revenue, Avoid Cost, Improve Services)
5. Creating a visual scope document/project charter as baseline
6. Risks and constraints analysis (measurable methods)
   
7. Risk-scenario planning (extremely useful, especially for high-risk project with changing busienss needs)
8. Building the project plan--step-by-step (creating the Work Breakdown Structure [WBS])
   
9. Creating the schedule using the Critical Path anlaysis
   
10. Difference between and measurement of Project Duration and Project Elapsed Time (Two Types of Time in Project Schedules)
11. The Learner First Approach for accelerated learning 
12. Managing change and change request (everybody's bug-bear and a must know)
13. Time, Cost, Quality: what's the most important?
14. Post-project review process--using Systems Thinking 
15. Using the PACT model to carry out Performance Consulting 
16. Differences between Learning Event Development and Performance Consulting
17. Managing external suppliers and vendors

I am planning separate posts on each of the topics above--mainly for my clarity and depth of understanding.

One self-discovery I had post reading the book: I immensely enjoyed reading it. And I can see how if one truly gets involved in managing a project, it can be a challenging, innovative, analytical and highly satisfying task. There are a multitude of variables one can play around with, and these keep changing from point to point within the same project. I have seen it happen and now reading about the levers that can be used to control these make the task so much fun...I also feel it could be addictive...

Some of the resource and reference links from the book:

1. The International Project Management Association 
2. International Society for Performance Improvement
3. Project Management Forum
4. Project Management Institute
5. The Training Professional's Gateway

In Response to "My Take on the Typical E-learning Project"

This post is triggered by Sumeet Moghe’s My Take on the “Typical E-learning Projects”. You have to see his post first...


Why what happens happens the way it does?
The customer is typically in a hurry to have the project delivered. Timeline is always crunched.

a. The key reasons are:
1. Rapid change of content around which the training is being designed
2. Need for the training to be in place before the product/service/whatever is rolled out to all
3. Realization that a training is needed at all comes a little late in the day
4. Realization that the traditional method of training may not work comes even later


b. What ensues?
A training-solutions designer is engaged and asked to deliver a training program. The timeline for delivery is mentioned as a very crucial factor, which it is.

c. What gets sacrificed?
Often, in a bid to meet the timeline and begin with the delivery, the Analysis Phase is either shortened or completed summarily. Still, the analysis report may look good enough to begin work with.

d. What happens next?
Based on this report, an implementation plan/project plan is drawn up with all the subsequent delivery milestones. Still good.

e. The resultant confusion:
The loopholes in the report begin to show up when put to the test—that is, when the solution is actually developed and presented to the customer.

Branching 1.1

The scope of salvaging the situation: Rapid Prototyping
If the designer happens to follow the Iterative/Agile methodology and believes in rapid prototyping, then everything is not lost. The customer gets to see the prototype and while their BP may shoot up, s/he would be glad once the purpose is explained, fixes done and the solution approximates the needs.

What should the smart designer do?
I am a believer of a good analysis. A good, well-defined analysis report can be the guiding document for quite some time. A smart designer would take some time and go back to the Analysis Report and update it. S/he would then create a design document that captures the approved solution and sit with the PM (if they are not one and the same) and work out a project plan.

Branching 1.2

What happens in a linear approach? (No Rapid Prototyping)
Remember Point e above? In the absence of a rapid prototype, there is no way of testing the analysis. If the delivery plan follows a linear process (Waterfall Methodology), the designer and team could end up with a very very disgruntled customer. Someone who looks like this:




With some good communication and smart thinking, we can of course have a customer looking like this: