Tips for How Not to Make a Deadline (Rant)

Just to be clear, these are examples of things nobody should really do. Don’t try this at home…or at work for that matter. Do the opposite of these things to be successful in every way (and avoid tormenting others). In other words…

DON’T…

…continuously require updates on status and progress. This is like pulling carrots up out of your garden every 30 minutes and wondering why they aren’t growing.

DON’T…

…get into a continuous revision loop. This is where you review something, send it back for corrections, then review it again and send it back for additional corrections, and then review it again and send it back…you get the idea. This means nobody is ever sure when it is done. And you can always find something to correct. (Don’t believe me? Go on IMDB…multi-million dollar movies, which use teams of people watching for inconsistencies over a year or more of development, still miss things. Underfunded but accelerated training development projects are certainly going to have some errors, no matter how many times you check.)

DON’T…

…mistake errors for problems. Agreed, nobody likes typos. Some grammatical rules are at least somewhat arbitrary and, in those cases, it is preferable to be consistent across the program. However, even though those things should be corrected, they shouldn’t be the primary focus. People will learn if you have the right content and practice, even if you botch a hyphen or two. They won’t learn (or will learn it wrong) if you have bad or missing content or don’t include any practice using the new learning. Basically, focus is a finite resource so prioritize how you use it.

DON’T…

…Focus on technical accuracy at the expense of instructional effectiveness. Sure, fix the technical errors and make sure the information is complete. But, if you want people to learn, you have to show them, let them try it, and then give them feedback. You might need to work through a simple example, followed by a more complex example. You might need to work through how the new learning applies to their specific situations. Not saying anything wrong is not going to make a difference if you don’t include application practice. Because, they probably won’t remember anything you said. But they have a much better chance of remembering what they did.

DON’T…

…become the critical path and blame everyone else. In project management, the critical path is the series of tasks within which any delays cause the deadline to slip. This chain of tasks has no cushion…it is the “longest pole in the tent.” If you have never heard of this, it is pretty easy to conceptualize — think about when you are in a hurry to get out the door to get to work on time. If you set up your coffee maker the night before so you can push the button, then take a shower while the coffee is brewing, you were basically removing the coffee brewing process from the critical path. The coffee is no longer the thing that will make you late. (In my case, it is letting the dog out and waiting for him to finish his business..but that is beside the point.)

Anyone involved in development of any kind knows that, sooner or later, we become the critical path because we have the last task to complete. However, before that, if we have published draft versions but the client/SMEs haven’t reviewed them, the reviews are the real critical path. This is not good for anyone because the reviewers often don’t realize that. They assume the developer has magical powers that enable them to finish things instantly no matter when how long it takes or how close to the deadline the changes get to the developer. We don’t.

Also, kind of a more subtle point, but large amounts of last-minute change churn means that it is less likely that you will find real gaps or issues because there is no time to step back and look at the deliverable as a whole. (This is why we prefer to work top-down and not focus on details upfront but start with a design, then frame the main exercises and content, then address all the details with proofing for typo’s, formatting, etc. in later drafts.)

DON’T…

…Change requirements after the project starts. Duh. Or at least don’t expect it not to impact the schedule or cost.

DON’T…

…Bring key reviewers into the process late. We understand that the higher in the organization the reviewer is, the busier they are, and the more likely they will tell you to “put something together and let me look at it before you send it out.” This is a good way to waste time because they will give you any direction they think makes sense, even if it requires a complete re-do. Better to get them to provide that input upfront, so you don’t do everything twice.

DON’T…

…Start the project unless the necessary resources are committed and available. It is easy to make the assumption that people are conceptually on-board and they can always fit in a few additional meetings or document reviews. Maybe but not always. And not always the people you need. Someone popping into a 4-hr meeting for an hour may not be sufficient — you may need to add another meeting later. Or someone taking a week to fit in a one-hour document review may mean your next version is a week later. In either situation, your deadline is in jeopardy.

We suggest building a team plan for the project upfront where you fit the activities into the calendar end-to-end and then get team commitment to make their dates and hand-offs. This doesn’t guarantee you won’t have hiccups, just that the deadline isn’t only your problem.