“I just have to…” Project Management

(EDIT: This post was republished by PMHut.com here)

If you’ve worked in/with a software development team, in any capacity, you have heard this optimistic statement before: “I just have to <insert_trivial_sounding_technical_task_here> and then I’m done!”

  • “The new approach worked. I tested it. I just have to move this method to the other class, and then I’m done!”
  • “I’ve committed my changes in a branch. I just have to re-run the tests once more, and then I’m done!”
  • “I’ve finished everything. I’m ready to start the next task. I just have to update the README and then I’m done!”

Well, you know what they say: in any software project, 90% of the work is completed in the first half of the schedule. To complete the rest 10%, it requires the rest half of the schedule, plus another 50% schedule overrun, plus x extra resources, everyone working overtime and oh yeah, we’ll ship the documentation later because we were focussing on delivering the functionality… you get the point.

You know Brook’s Law? It applies to machines as well. When you write tools and post-build scripts to automate development tasks, when you adopt the latest DVCS, when you start using the latest test automation framework… you are adding resources to your project. And it has been clearly established that adding resources to a project that is already behind schedule (and which project isn’t) is only going to make it later.

Here are a few things I’ve learnt over the years:

  1. Nothing on planet Earth is a zero-time activity. Your plan: “I just have to move this method to the other class, and then I’m done!”. What happens in real life:
    • You need to get your code peer reviewed.
    • But there is nobody available at the moment to review.
    • You finally interrupt someone, because y’know, it’s just one method, you just have to quickly review it… (of course you would conveniently forget how you would feel if you were the one being interrupted)
    • What? It’s a public API? Then you have to update the acceptance tests.
    • And the unit tests.
    • Go back for peer review and sign off. After lunch.
    • OK, all done, just commit and… WTF now I need to merge?!
    • And rebuild.
    • And re-run the tests.
    • And re-start the PC because of that pesky Visual Studio bug.
    • WTF? Windows updates? Now?!
  1. Murphy’s Law is as fundamental to computer science as boolean algebra. It’s a pity they don’t teach it in school.
  2. Remember algorithmic analysis? When you estimate something, don’t always consider the best case. The worst case happens more often than you’d think.
  3. ABC: Always Be Collecting. Data. Statistics. Your past project data will show unrealistic your estimates really are. Nothing else can convince you as much.
  4. If you haven’t been able to solve a problem for too long (confused customer, unreliable dev environment, too many distractions or interruptions), then maybe it’s not a problem, it’s a fact. So adjust your future estimates accordingly.
  5. Say “out of scope” more often. Just because it’s software and easy to modify, doesn’t mean it should be modified. Agile doesn’t mean the freedom to constantly change requirements, it means adapting to changing requirements (amongst other things). Changing requirements doesn’t mean freedom to change fundamental constraints. Think of it this way: if you were building a bridge, it would be acceptable to try out different road surfaces. But would you change the bridge into a tunnel because it offers less wind resistance? And should there be a need in the future, you can just drop the already built tunnel underwater? Some software change requests and developer’s grand visions are equally unrealistic, and unnecessary.
  6. Life is a fractal. If you’re late every day, you will be late every month, every year… and you will feel the same way about your whole life. It happens at home too: “I just have to get dressed, and I’m ready to leave”. Real life: Get dressed, grab snack, drink water, close window, remove phone from charging, respond to missed call, tie shoelaces, oops mismatched socks, find keys, lock door, wait for stuck elevator…
  7. Work-life balance doesn’t mean work-life separation. Bring your good habits to work. Inculcate learnings from your work into your personal life. Why limit Continuous Improvement only 8 hours in a day?
  8. Learn from other’s mistakes. Every time someone is being a moron, they are secretly trying to teach you something. The daily standup is not only about you, it’s also an opportunity to improve based on others’ experience.
  9. Most importantly: Stop saying “I just have to…”  🙂
Advertisements

2 Responses to ““I just have to…” Project Management”

  1. PM Hut Says:

    Hi Kartik,

    If I had a dime everytime this “I just have to do this and I’m done” turned into a week’s work I’d be ultra-rich. Unfortunately, nobody gives me that dime when it happens.

    This is a common behavior, that even the most brilliant resources do. I have no idea why, it seems that it’s part of being human.

    Thanks for sharing this post. I am looking to republish this post, in full, on PM Hut where many project managers will benefit from it. Please either email me or contact me through the contact us form on the PM Hut site in case you’re OK with this.

  2. Recent Popular Posts | Survival of the Craziest Says:

    […] “I just have to…” Project Management, which was republished by PMHut […]


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: