listen

we just finished the implementation part in a well overdue project, and I want to write 'bout "listening"

  • there were some problems that were raised even before the testing phase but then de-prioritized (hence forgotten). they did come up later and bit us

  • there were some good suggestion that were also de-prioritized due to the wrong application of 80-20 rule (we think they are out of those 20 but it turned out they are in), or sometimes we care 'bout the people who say than what they actually say

it's also about balance. everyone will want the project to finish on-time with quality. however, some will focus on "time" while others are more concerned 'bout "quality". last but not least, people do care 'bout "cost" also

how to be a middle-man and effectively balance all those stuffs ? what to compromise (well, because in life, you can't have it all) ? how to manage the expectation ? how to involve people, make them feel important, realize the benefit and enable them to contribute as well as tracking their execution effectively ? when to be nice & how loud you should shout ? if things are sux, how to proceed ?

still thinking, at least I know what to focus next time

{http://blog.plonely.com}