Pressure Cooker

Would it be fair to say most instructional designers (IDs) have experienced the “But, we need to roll this out in two weeks.” scenario or a derivative of it? The next question is how many of you automatically cringed and felt your shoulders start creeping up around your ears? Deadlines and demands do not have to create these high pressure situations. We need to help take that lid off and slow the cooking down.

But as the IDs how do we do that? Honestly, it’s all about how you treat your role. Not how the company treats your role or how your department treats your job function, it really comes down to what we permit. Now is some of it rooted in formulated habits and expectations that have been established over time? Absolutely, but that does not mean that these circumstances should not be evaluated for improvement/reconsideration.

There are a couple ways we can look at this, but from a professional development perspective let’s focus on you, the instructional designer, first. How do you present yourself to your clients (whether your own or through your job)? Are you a consultant that collaborates and works to not only provide great service but to assist in educating your clients so that the work relationship is mutually beneficial and reciprocal? Or have you created a role where you are constantly getting caught up to be tossed another issue that puts you right back behind? Of course, that “issue” was probably some overdue work from a SME or project stakeholder right?

I cannot say that I have not done both, as I have, and I know how each play out and I would rather be in the seat of the collaborative consultant. It doesn’t win awards or appreciation every day and it can still cause stress and pressure, but it’s of the variety I would prefer. I’m less likely to be up until the wee hours of the morning fretting over giving an honest and realistic answer about how long creating a piece of training will actually take. But, I am sure many of us know the flip of this which is being up all night cursing ourselves and our client and praying we get the work done on time (and without error).

Saying No Does Not Make You Less Capable
Perhaps this is one of the reasons we chose to just say “yes” or “sure no problem” when it really is going to become just that, a problem. I think there is opportunity to demonstrate more of our knowledge and what we can bring to the table when we consult with our client, again whether they are your own or internal to a company.

If you have done your job and listened to the needs of your client you really do know what is possible, what the best approach is, and what a realistic expectation/timeline is. With that noted, then be OK to present alternatives that help you achieve the main goals of a project. Whether a project is about to begin or its one that has begun, there needs to be comprehension of what the limitations and capabilities are to the project at hand. That includes the limitations and capabilities of the stakeholders along with the other resources. And, yes that includes you, the ID.

We cannot expect our clients to comprehend the type of demands they put upon us if we just keep saying yes.

Cultivating a New Culture is Possible
As IDs we can be great about helping one another out. From empathizing to lending a last-minute hand we usually do help out our fellow training miracle maker when they need it. However, how many of us actually assert to our peers that they should tell their clients that what they want in the time they want it is not possible? Or that the new edits/additions/revisions are beyond the original project scope?

The idea of “not possible “does not equate to impossible.

Presentation of this concept is key. As IDs we are constantly tasked with seeking out and finding all possible solutions and rarely is one of them re-scoping a project that allows us to function successfully for it. Yet, it is probably one of the simplest resolutions.
We do not feel right offering that because:
• I have never said no.
• Our department has never done it that way.
• This is the way it has always been.
• It’s their money we need to do what they want.

Whatever the reason we need to step back and ask if ourselves if this decision will really help the project or just take the lid of a circumstance that’s about to bubble over.

How Do We Reduce the Heat?
There are going to be more ways than listed here. Mine is pretty basic. I stop doing what I am doing. I take the time to look at the problem at hand and the larger picture of the project. I then communicate through the appropriate channels not only the implications of the current issue, but the impact it will have on the project as a whole. The final thing I do is pose a solution or solutions or as I like to call it the “medium heat” level. It may not take away all that bubbling, but it typically takes it down to a simmer.

This stance helps to give the client what they want, alleviate some if not the majority of the pressure upon the ID and the development team, and keeps the project moving forward.

If its a new project, which I just recently encountered this issue again, I just redirect right at the beginning. I provide the true picture and scope of the project back to the stakeholders. I present it in the most basic terms and I usually provide a chart or something that elaborates the project scope visually to help folks wrap their head around all the moving parts. Again, I make sure that I present the solution and advisable next steps.

So, keep watch over the client’s stove. They hired you to come into their kitchen and help them whip up something, which means that you need to make sure that you are both ok with the size of the flame underneath the ID pot!