Project Management exercise from StackOverflow

Here's a mindmap I put together based on a question from StackOverflow

http://stackoverflow.com/questions/922559/how-should-i-begin-this-kind-of-project

The Master and His Three Sons

There was once a great master of kenjutsu (sword) renowned throughout Japan who, when visited by another great master, wished to demonstrate the teaching he had given his three sons.
The master winked at his guest and placed a heavy metal vase on the corner of the sliding doors, wedged it with a piece of bamboo and a small nail in such a way that the vase would fall on the head of the first one who came into the room when the door was opened.

While chatting and drinking tea, the master called his oldest son who came immediately. Before opening the door, he felt the presence of the vase and its position. He slid back the door, put his left hand through the gap to catch the vase and continued opening the door with his right hand. Then, clutching the vase to his chest, he entered the room, shutting the door behind him and replaced the vase; he came forward and greeted the two masters. 'This is my oldest son', said the host smiling, 'he has learnt my teaching well and one day he will undoubtedly be a master of kenjutsu.'

The second son was called and he entered without hesitating and only caught the vase at the last moment: it almost landed on his head. 'This is my second son', said the master, 'he still has a lot to learn but he is improving every day.'

Then the third son was called. Entering the room hurriedly, he was struck on the head by the vase. The blow was a heavy one but before the vase hit the tatami, he drew his sword and, in one quick action, cut the piece of metal in two. 'This is my youngest son, Jiro', said the old man, 'he is the baby of the family and he still has a long way to go.
______________________________________________

Question for the project managers out there:

Which son are you when it comes to risk management?

Value of Teams on mid-size projects

There’s a gray area of project size (scope and complexity) that may or may not require a team to complete, this is the focus of this discussion. The determination of what that gray area is, is a completely subjective/fuzzy call by those in position to make that decision.
Personally, I have always leaned towards having the fewest people involved in any project, this is based on my feeling that any additional communication, management or human interaction than required exponentially adds to the risk level of the project – however – I might be wrong. What if the team is well established, mature and requires minimal management? (Ideal situation of course)…what value could having more people than required on a single project?

• Higher quality product and more productive if an XP type of team programming is in place.
  
• Chance to develop a Jr. member on the team
  
• Continued reinforcement of the team model and on-going success record
  
• Direct transfer of knowledge to a backup person
  

I’m beginning to think, with the right team, on a project that can be team-developed or is decoupled enough for multi-people to work on – the leaning towards more people rather than fewer is the right approach.

Ed Yourdon - Enterprise 2.0

One of my hero's of IT....there's enough information in this presentation to keep a person busy and thinking for a VERY LONG TIME!

Enterprise 2.0

View more presentations from yourdon.

What Project Management Lessons I learned from watching bowling

Bowling is one of the few sports I can enjoy watching and I’m sure it’s a sign of my increasing age. Here are some bowling lessons I’ve learned that I think are directly applicable to project management:

• You’re known for your last lose (failure) more then all the prior wins
  
• No matter how good you bowl, know the lanes, no matter how many prior frames you had strikes in, the next frame is an unknown…
  
• Few bowlers bowl a perfect game
  
• The professional bowlers don’t look at each other much….they tend to focus on their own game and not how the other bowler is doing 
  
• No matter how geeky your shoes look, how out of date your shirt is, if you’re good people will pay you and others will watch in admiration
  
• One bad frame does not always mean a lost game
  

Standish 2009 CHAOS Report – what could it mean?

Like any other report, The Standish CHAOS report will have it issues – what defines a failure? How do you validate the sources? What does it really mean to fail or succeed? Does this represent to broad or to narrow of a segment?

These are all good and valid questions, to me the most important is the report data gathering and reporting consistent with prior years? The final #’s have little relevance (to me) compared to the overall trending….and the overall trending is interesting - more projects are failing this year than last. A lot can be read into that, here’s my take (assumptions):

• As the economy continues to slow (or remains slow) the better managers will cancel the less important project, focusing on the key business drivers (end of day a good thing)
  
• Companies are cutting resources, causing the remaining people to be overloaded causing lower quality deliveries (a bad thing)
  
• People have more of a negative view and will tend to be more critical of what is being delivered and lean towards reporting failures more than successes…one of the bigger issues with any subjective type of reporting – BUT one that can be understood and used to adjust the findings.
  

My view of the report is that it’s a great value and solid indicator of what is happening in IT – my view of IT based on the report….we need to get a lot better 32%...that’s a failing grade in my book.