Having been “thrown under the bus” a couple of times in my career managing projects, I have always been curious about the reasons why this behavior appears in different organizations.
I think there are several factors at play, a key one been a pervasive fear. Fear of making mistakes, fear of stepping out of line, fear of been noticed, fear of been called to the boss’ office. This is a clear warning sign, sooner or later something will go wrong and people will start throwing others under the bus out of fear of been the target of the consequences (real or imagined).
If you find yourself in an organization where this happens, why not approach your manager about it? Suggest a small project and discuss ahead of time what can go wrong and how will you respond to it. Make sure you capture what you learn in a way that is very visible so you can turn one mistake into everyone’s experience.
Sure, it’s riskier. But the only way to improve is to take risks and an organization that rejects this may not be the right place to be.
The only man who never makes a mistake is the man who never does anything.
– Teddy Roosevelt
If you get to work on Monday morning and you have seven different projects demanding your attention urgently, you will pick one to start with. How will you pick? Usually by selecting the project that is about to be late, or is already late.
While you’re working on this immediate red-hot item, by definition you are procrastinating on the other six. It does not make you a poor worker, after all you’re likely working more than 8 hours a day trying to keep up with the stream of urgent tasks. This cycle means that the work that for one reason or another can wait, will wait, regardless of its importance.
Breaking this cycle is not easy, as it requires a change in the culture of your organization. Looking at all the pending work and focusing your resources on the important work over the unimportant (but urgent) requires the courage to question why the unimportant work is been done in the first place.
For quite some time, I used Trello as my task management system. It is flexible and very intuitive. One of the drawbacks was that I could not set up a recurring task inside Trello.
My first approach was to create a digital version of David Allen’s folder-based tickler file, using a board with one list for each month and 31 cards, one for each day. I would place a task card right after the card for the day it is due, and every day I would move those task cards to my main board and the date card to the next month list. This worked well for the most part, except when I needed to plan something several months in advance.
My solution was to again use
remind and its ability to execute a command on a certain date to add a card to my inbox. Trello has the great feature that you can add cards via e-mail, so my laptop e-mails any task that I need to know about for the day, thanks to
anacron. What if my laptop is not on, you ask? It’s rare, but it can happen. I pondered this problem for a while, I even tried using IFTTT to add my tasks in when they released a Trello integration, which works well. My only problem with using IFTTT is that I find maintaining a large list of tasks and reminders is very cumbersome in their interface, and I find that I use
remind‘s ability to create complex triggers (like only firing on the 15th of the month if it is not a Monday or a Friday).
remind it is, with an additional script I wrote that checks the last time my laptop was on an then executes all reminders since that point until today to catch up.
If you cannot determine exactly how long will a task take, how are you expected to plan a project?
A different perspective can help: what if, instead of telling people when something should be complete, you tell them when to start?
By accepting that the estimated duration for a task is just that, an estimate, and expecting that it may take less or more than that, the team can focus on the execution. Your job then becomes making sure that the hand-offs from one task to the next happen smoothly and soon you’ll notice your project is moving faster than you expected.
Consider this, you’re trying to determine how long it will take to perform a task for a project. You approach the person with the most knowledge about the task (because that is where you get your information, right?) and ask “How long does it usually take?”.
You may be inclined to treat the response as the average duration of the task, but is it? In most cases it is not. If it were, you could execute the task 1,000 times and half of those would take more time than the average, the other half would take less. I’m confident this is not the case with your projects.
We have worked very hard to train our teams to “not be late”, so hard in fact that they will go to great lengths to avoid being in that position. This includes adding plenty of padding to the duration. This does not make your team “bad”, it is an example of how the cultural norms of the environment where the team operates shape their actions.
I think it is interesting that so much is narrowly done, designed, built and planned around the average. The idea that the average is merely a point of reference around which a range of possible values occur seems to have been left behind in many applications of the concept.
At some point, the expectation of something been around the average (and you can mathematically determine how close to the average you think it’s close enough) became the expectation of something being the average.
The next time you find yourself using an average, consider for a moment if it might be better to add some flexibility to account for the variability, rather than hope that things will be close to the average.
Never confuse movement with action.
As I wrote in my first post, this past winter I contacted city hall to try to clear a sidewalk of snow in the neighborhood.
I was incredibly surprised that the very day I received a response from the city, a crew was cleaning up the sidewalk. I was very impressed by the city taking action to solve the problem for the neighborhood even though they could have acted like a bureaucracy, sending the institution on that sidewalk notices and argue about the problem without solving it.