icelava.net

Some crucial advice to fresh students and graduates about the sad nature of politics that revolve around software development IT projects, which most of us are all too painfully aware of.

http://www.kuro5hin.org/story/2005/1/28/32622/4244

Still a good read nonetheless.

Perhaps the most crucial practice, which I learnt long before beginning a career as an IT professional, is to document your own cache of all instances of communication that ever transpired. Sounds like common sense, but an easily forgotten one when you get busy trying to keep up with the amount of mess flooding in. This is key to why I preferred written communication over verbal channels - writing everything in black and white (either paper memo or email). People (myself included) do forget, innocently or deliberately.

Today I read Michael K Campbell's outdoor camping analogy with regards to work and business. He succinctly brings out the clear difference between problem management and incident management, and thereby the ever underlying universal truth that fire prevention is better than fire fighting.

The sad reality is most people will always be spending their time putting out fires and never planning to prevent the ingredients that formulate nasty bombs from coming together. What is immediately visible has preponderance over anything that is just a prediction, no matter how likely it can (or will) occur, based on historical lessons.

Why do I make a post here within this thread? Because the Politics-Oriented Software Development article has a section with advice highly relevant to this:

Descoping section:

Also remember that someone who points out a problem early is a troublemaker; someone who fixes a problem at the last minute is a hero.

In my experience, this is largely (and again, sadly) true. Yes, I want to have good foresight. Yes, I want to predict and spot out potential risks and problems that can result from a suggested tactic or strategy by the boss.

Side note: The Microsoft Solutions Framework has a dedicated white paper for the topic of Risk Management.

But no, the boss is not interested in working on things that are "not important". The boss wants results. Fast. The boss wants it to "just work". When the incidents do happen, which translates to those predicted (and unmanaged) risks manifesting into real problems, the boss has sure-fine, near-elegant ways to convince him/herself the staff had not done their job well (especially prominent with inherent Chinese pride).

So what's a poor sod to do? As with the same measure suggested above, document your planning and discussions. But back to the Chinese pride issue, bosses typically won't be happy to be proven wrong, and either way you will be in for a lose-lose situation.