It's been long time since the last post. (Well, ok, not that long, but still longer than usual)
There was a darn good reason why I didn't post anything in this time, but I forgot about it because I ran into a strut, which was surprisingly close to the ground.
Of course it was not the strut's fault, it was just doing its job as it had been doing it for 178 years. After such a long time you tend to become rather are good at your job. The strut did indeed an awfully good job, since the house it is a part of has stood there for 176 years (originally, the house was built a little more uphill, but it obviousely didn't like the view there and caught the next best landslide 2 years after).
I felt fluffy and knotty after the crash.
I can't really describe what feeling fluffy feels like, but it somehow fits perfectly. The knotty feeling wasn't caused by knotted and twisted parts of my body, it was more my state of mind that was knotty.
It took me a awful lot of time to end one specific thought, because other thoughts thought they needed some quality time with my consciousness and jumped out and started yelling and shouting at it. In order to get some order my consciousness redirected the most hideously looking thoughts to my subconsciousness. At least that's what it tried to do, because my subconsciousness was out for lunch, together with my libido.
So long
Tim
PS: Another reason I hadn't written anything may be the exam session coming closer terribly fast. If it's coming any faster than now it will travel back in time...
Monday, February 19, 2007
Wednesday, February 07, 2007
Proper Project Planning
There are many guides to handle a project properly and efficiently. Most of the contain fancy graphics and tables which, when it comes down to real life usage, most precisely fail to be of any use.
It's not only the graphical depiction of the processes you're supposed to apply that are wrong, but also the whole processes seem to be terribly inaccurate if you look back on a finished project.
That's also something that's suggested by those guides so you can learn from your mistakes. However, I recommend not to do so, because most of the time you'll end up so depressed about all the things you did wrong or didn't do at all that you need a really stiff drink afterwards.
I'd propose you just skip the looking back part and go out for a drink immediately after having handed out the project report.
Most people already do that, but they disguise it by calling it an "end of project celebration", which is basically the euphemistic equivalent to a nice and hefty booze-up.
Here's how projects are really handled, regardless of any advice.
Person A comes up with solution F, Person B has the idea for solution G, C knows how the solution H works and Persons D and E are arguing about the report layout.
While A tries to convince everyone that F is the best, B and C try to win D and E for their course. The next day A says that solutions G and H are equally good, B now says that F is perfectly fine, D can't decide which of F, G and H she hates the most and E has lost track of everything. C has called out sick that day.
The following day E has finally caught up to the rest and has many issues about each solution, A is discussing with C the happenings of the previous day, B is violently trying to get F to be the final solution, C keeps unsuccessfully insisting on a democratic selection and D is nagging about the lousy teamwork and how the project is failing.
After the more or less worst solution has been found, everyone agrees on going on with it so they can finally have their cup of coffee (except D, she hates coffee, she's just lazy). After everything is thorougly calculated and estimated and the deadline is drawing closer, E finds out that the solution is not working after all and that A,B and D are lousy jerks nobody can possibly work with.
The following quarrels and lengthy nightshifts result in a completely reworked report, which is all but correct or even useful.
Despite all these problems, the projects are usually a striking success and nobody really knows why (and nobody actually wants to know).
So long
Tim
It's not only the graphical depiction of the processes you're supposed to apply that are wrong, but also the whole processes seem to be terribly inaccurate if you look back on a finished project.
That's also something that's suggested by those guides so you can learn from your mistakes. However, I recommend not to do so, because most of the time you'll end up so depressed about all the things you did wrong or didn't do at all that you need a really stiff drink afterwards.
I'd propose you just skip the looking back part and go out for a drink immediately after having handed out the project report.
Most people already do that, but they disguise it by calling it an "end of project celebration", which is basically the euphemistic equivalent to a nice and hefty booze-up.
Here's how projects are really handled, regardless of any advice.
Person A comes up with solution F, Person B has the idea for solution G, C knows how the solution H works and Persons D and E are arguing about the report layout.
While A tries to convince everyone that F is the best, B and C try to win D and E for their course. The next day A says that solutions G and H are equally good, B now says that F is perfectly fine, D can't decide which of F, G and H she hates the most and E has lost track of everything. C has called out sick that day.
The following day E has finally caught up to the rest and has many issues about each solution, A is discussing with C the happenings of the previous day, B is violently trying to get F to be the final solution, C keeps unsuccessfully insisting on a democratic selection and D is nagging about the lousy teamwork and how the project is failing.
After the more or less worst solution has been found, everyone agrees on going on with it so they can finally have their cup of coffee (except D, she hates coffee, she's just lazy). After everything is thorougly calculated and estimated and the deadline is drawing closer, E finds out that the solution is not working after all and that A,B and D are lousy jerks nobody can possibly work with.
The following quarrels and lengthy nightshifts result in a completely reworked report, which is all but correct or even useful.
Despite all these problems, the projects are usually a striking success and nobody really knows why (and nobody actually wants to know).
So long
Tim
Subscribe to:
Posts (Atom)
