I think I’ve always been a big fan of lean philosophy. Even back when I didn’t know about it or its name for that matter. And not because it looked fancy but probably because I always knew it felt natural. I must be one of those people who think the world keeps moving even when we’re pausing. Lean is all about movement. It starts with accepting that regardless of your area of practice you cannot stay still. And not because some marketing reason like „competition never sleeps” or tehnical pressure to be up to date. It is in our nature to evolve so we might as well do it in a controlled environment. It is not by accident we call the stillness, lazyness!

Any magazine we open or any conference we go, we’ll certainly come across an article or a presentation on Agile. Everyone talks about Agile and agility, and the experts came in huge quantities and any company, especially in software, claims to be Agile. Skeptics remain reserved and wishing the Agile fashion would disappear. However, the „fashion” not only does stay, but also there have been more than 10 years since it first appeared and it even seeks to develop if not explode. Nokia, Microsoft, Adobe, Google, Philips, Siemens, Yahoo are big names that bet on Agile.

All those who interacted, no matter how little, with Microsoft Project agree unanimously that it’s a very powerful scheduling tool. In other words, if we define and detail its tasks, it is very good at building a plan (the correct term is schedule), better than anything else. But, in order to define the tasks clearly, we need to know exactly what we expect from the project: what does it have to deliver, on what conditions, which standards to comply with etc. It sounds easy, doesn’t it? In practice, we all know how complicated (impossible?) it is to define the purpose of the project and the delivery from the very beginning. In this case, how could Microsoft Project help me if I (or my client) don’t know what I want from it?