Why am I writing about management of products/projects?
There is something uncertain about the whole thing when it comes to defining it for Software. And this is probably why many classic MBAs do fail applying their knowledge in IT industry.
Providing help with many projects in past years, I seen many ways of how they are managed, delivered and nourished. And in some cases it might be very frustrating… Even though there is a whole MBA/PMI model present and scientifically studied, there is no “handbook” out there which will set it once and for all.
It just might be because we do not really know what it is… and just at the moment we think we know something then something new comes out. We go from strict, structured models of organizing projects to flexible and morphic which allows quickly switch directions, scope and time-lines, reassign resources, merge and divide requirements.
It all boils down to the nature of the Software Development process, where there is no manufacturing cycle per se, since a new day, client, data or regulation might change entire project in a split of the second. It is a business reality.
This is the reson why variation of Agile model thrive these days. Software business model is switching more and more toward service model and it forces a “morphic” structure into business infrastructure and therefore “old” approach does not work.
Well… it is almost true, but not all the way. In reality, everything we now see as a “new” things are really “new”. It is all the same in the core, just approach which is different: release cycles are scaled down, but they are still present; role of the project is lowered to the scope of the task; etc. But if we step back and look at the overall model, nothing is different. We have new “buzz” words which are thrown on the desk of the management through myriad of articles and news announcements, without real presentation of the transition, since it will really show that what we have now is not much different from what we would otherwise have tomorrow.
One major exception, though – flexibility. Every business is to survive only by being flexible in everyday changing world. And this is why all “buzz” changes are important – it is rapid evolution of survival, where winning practices are recognized and presented to the public, just to be adjusted, improved and re-release under a new name tomorrow.
Why we are talking about it? To understand semantic, basis, and grow from the root, allowing take advantage of the new things without paying tremendous cost of being an early adopters. Does a new thing a really new? How different is it from what we have had before? What does it give you what you did not have before?
Article above shows evolution of methodologies, its ups and downs, its transitions, applications. But it also shows common base shared by all of them and this what I am trying concentrate upon.
What gives me comfort to talk about it? Being in some kind of Product/Project management positions for many years, being successful in managing and delivering project I’ve been involved in, being able to bring expertise and helping in reorganizing unstable instances of such
Let start with basics…