Random Acts of IT Project Management

Project Management for Information Technology

Posts Tagged ‘lessons learned’

Real Life Project Management: Lessons From Making Sourdough Bread

Posted by iammarchhare on 3 August 2009

I have published “Real Life Project Management: Lessons From Making Sourdough Bread” on Associated Content.  Here is an excerpt of the article:

Another Example of How We Use Project Management in “Real Life”

I like fresh sourdough bread.  I also like making it because it is such a stress reliever.  It also has some lessons to it, though, so bear with me.

First, you mix up the flour, salt, sugar, oil, baking soda, sourdough starter and water and beat it with a spoon for about a total of one minute.  Then, you add in flour until the mixture is stiff, throw some flour on a surface, dump the dough onto the four and proceed to beat it up.  Literally.  Except, bakers call this “kneading the dough”.

After you let this ball rise for a few hours, you then “punch” it down.  You are supposed to let it “rest” for 5 minutes, but I often get impatient and cut that short.  You then throw more flour on a surface and, you guessed it, beat it up again.  This time, though, you are kneading it until it gets to the shape and consistency of what you want.  You then let that rise and bake it.

Who knew that baking was so violent?…

You can read the rest here.

Posted in PM Basics | Tagged: , , , , , | Comments Off on Real Life Project Management: Lessons From Making Sourdough Bread

What Is the Most Important Part of a Project?

Posted by iammarchhare on 22 April 2009

Most of the time, a project manager will say “requirements gathering”.  Once upon a time, I probably would have agreed.  But, I don’t any longer.

Toni Bowers of TechRepublic posted on the IT Leadership blog “Five reasons to discuss project failure”.  She writes:

  1. Failure is instructive. Most of us have an instinctive aversion to discussing weakness, based on concerns that criticism may hurt our pride, reputation, and so on. While I deeply respect these sensitivities, fear creates an environment where repeated cycles of failure can manifest. Breaking this cycle requires understanding the source of problems followed by developing solutions to address them.

Failure causes you to learn.  Hopefully, success does as well.  Humans have an amazing capacity to learn, and we should do so at every opportunity.  If we do not learn, we do not improve professionally or grow personally.

Teams and even companies can learn as well.  That’s why Bowers’ article is so important.  If teams and companies cannot face the facts and learn, then they never improve.  Projects will continue to fail.

A thorough “lessons learned” or “after action” review is a must.  The US Army has a tradition of sending soldiers on field exercises and then holding after action reviews afterwards to grade themselves.  Self-reflection is the key to improvement.

That’s why in the long run requirements gathering just plain is not as important!  Why?  Because a thorough lessons learned review will uncover it as a weakness and make recommendations to fix the problem.  If you do lessons learned poorly or not at all, you will never know if your requirements gathering is any good or not!

What if you had a project to create a product, it was done on time and under budget, it was delivered and the customer never complained.  Was the project a success?  How do you know?

There is a saying that for every customer that complains, there are 9 others who have the same problem but do not complain.  It could be because they are too busy or too tired, or maybe they don’t know who to complain to.  Just because no one complains does not mean the project was a success.  Again, you have to gather data after the main portions of the project have been completed.

The fact that I’ve changed my mind about “requirements gathering” is proof I’m not too old to learn.  🙂

Posted in PM Basics, SDLC, Skills | Tagged: , , , , , , , , | 1 Comment »