I think it is safe to say that anytime any company wants to get something new accomplished they “kick off” this thing called a “project”. Now if you have spent any time in IT you have probably had a role on one of these so called projects. You know when you are on a good project:
- Everyone knows what the end goal is.
- Everyone knows each others roles.
- Everyone has a sense that all participants are accountable for their tasks.
- Things are getting done.
- Everyone feels a sense of progress.
- Everyone feels a sense of team.
You also know when you are on a bad project:
- Everyone is seemingly bumping into each other.
- No one can really articulate the goal of the project
- No one knows what the end state is supposed to look like.
- Time is going by with meetings and minutes and status reports but no real tangible work is getting done.
This series of articles will cover different aspects on how to survive as an engineer that has a role to play on an IT project.
In the previous article two concepts were introduced to help you survive. Now it is time for the most powerful concept, the “pre-task”. As much as possible at all times, create the perception that you are waiting on something from someone else in the organization. Make sure in every situation possible that the project manager or development lead or whoever is managing the checklist of project tasks believes someone else needs to complete their task before you can complete your task.
Not having a “pre-task”:
Sally the Project Manager: “So Bob, according to my plan, you should be working on that widget … are you done yet?”
Bob: “Um, yah, I’m working on it but I told everyone it was going to take me five days and this is day two.”
Sally the Project Manager: “Not according to my plan … it says you build the widget and then we start testing. You are holding up testing. I’m going to have to escalate!” And rushes out of your cube before you can formulate a response.
Having a “pre-task” at the ready:
Sally the Project Manager: “So Bob, according to my plan, you should be working on that widget … are you done yet?”
Bob: “Um, yah, I’m working on it but I can’t finish until the Architect signs off on my design document. All designs must have Architect sign-off.”
Sally the Project Manager: “Um …” <has no clue what that means but now knows there is a delay building> “I better go find our Architect on this project and get him or her involved”. And again, rushes out of your cube.
Now, in this example, there are multiple issues generating confusion. One is task duration. The likelihood that someone actually recorded your need for five days to actually do work is very low. I am continually amazed that the less technical a person is the greater the likelihood they will assume a technical task takes an amazingly short amount of time. Another is the propensity for project managers or people whose primary job it is to track other peoples work are quick to react less than rationally when their plan gets messed up. They have their plan and they remain rational when, as time goes by, the plan remains unchanged and tasks are sequentially marked complete. But when the plan itself appears to have a gap, panic and irrationality can ensue.
Ok, why does someone whose sole job is to track a checklist loses their marbles when there is a missing tasks or four additional tasks need to be inserted somewhere? A quick glimpse into the project manager’s world reveals their greatest value to the organization is in their ability to predict the future with their plan. Based on the future date their plan indicates, all kinds of business-ish things could be set to kick off. Thus, something as simple as a plan that says when a system upgrade will be deployed could also be the starting point for a marketing team to formally kick off a set of media ads, plus a customer training/education packet could be already in the mail with dates for when each customer will be forced to use the new upgrade system, plus an accounting group could be poised to show a drop in license costs (i.e., save big money) due to the upgrade, plus, some executive is counting on the license money savings making his departments balance sheet come just under a magical finance number that triggers a quarterly bonus. Hence, when the upgrade implementation date starts slipping from a failure of the future predictor (aka. project manager) being accurate, all kinds of heat from all kinds of folks downstream from any of the technical work associated with the project can come out of the woodwork and come down hard on the project manager for giving bad data. Hence, fearing such heat, project managers react in a variety of ways and some of which are not particularly 100% rational.
In the next article, I’ll outline how to use this panic to work for you.
Related posts:
- How to Survive Your Role on a Project as an Engineer, Part 2
- How to Survive Your Role on a Project as an Engineer, Part 3
- How to Survive Your Role on a Project as an Engineer, Part 1
- How to Survive Your Role on a Project as a Manager, Part 1
- How to Survive Your Role on a Project as a Manager, Part 3
Articles RSS 2.0 Feed
Follow Midwest IT Survival on Twitter
As I commented over on my own blog, I love this approach because it's clever and gives you some desperately needed wiggle room. But it still makes me laugh because of the hint of deception. Nice job!
Thanks for the feedback … as I re-read my original post, I could see how the “hint of deception” could be construed. Depending on how one constructs their “pre-tasks”, you could very well be helping the overall organization collectively move forward by assisting those in charge of moving everyone forward (project managers). The larger the organization in my experience, the more likely a new project manager just doesn’t have the depth of the organization’s methodological knowledge to be immediately efficient. Taken to the extreme negative, the use of the “pre-task” to redirect folks requesting your services to another provider would be the way to use this “pre-task” nefariously.
Thanks again for the perspective!