So the guys over at Target Process just informed the world that Project is based on the waterfall process and is therefore unsuitable for use in managing a software project! LOL Wow that is news to me and the thousands of others that have used to manage iterative software development projects! :-)
I posted a comment on their post that talked about my disagreement and have had this response in draft form ever since and had forgotten about it until Glen posted on the subject. It was not until I read Glen’s post that I realized that Target Process markets a product that competes with Project! This certainly casts the post in a different light. When I first read it I did so with the thought in mind that the writer was just not understanding how scheduling software really works or what the basis is for building and indeed using such software. But knowing that the poster works for a company that competes with Project it now just smacks of an intentional distortion of the facts with the end goal of boosting sales of their product. While this certainly may NOT be the case (I really want to believe that this was not the thrust of their post) it certainly starts to look that way.
Microsoft Project is not based on “Waterfall”
It just isn’t. Neither are the scheduling engine components of Primavera, Niku (sorry I meant CA), Artemis, Planview or any other major scheduling application that I have seen. You can MAKE them do waterfall. You can make any application do waterfall. I can make Basecamp do waterfall and you could likely make Target Process’s tool do waterfall too no mater how centered it’s design is on Agile. Hell, I can make 3x5 cards like the ones used in XP\Scrum do waterfall!! Waterfall is a process for planning a project. It is not tool specific. It is project environment specific. Waterfall can work as a method for scheduling software projects. Not many in my opinion but they are out there. The method you use to plan your work (be it a software project or the creation of marketing materials or the building of a dam) should be context sensitive. If you have the requirements up front and they will not likely change through the course of the project then waterfall might be the thing. In a case like this an iterative approach might add loops that are a waste of time given the locked down nature of the requirements. If you are building something there the requirements are fuzzy and likely to change over time then the obvious choice is a method that is iterative at it’s core (whichever method that might be for your case.)
As I mentioned in my comment on the original post I agree that the Help file that comes with Project should address other planning processes. In fact in my Outlook outbox (I’m on a plane right now without Internet access) there is currently an email to several people on the Project development team suggesting just that. However, the mere fact that the Help only mentions waterfall type methods does not mean it is based on waterfall nor does it mean that you cannot use Project to do iterative projects. To suggest otherwise is like saying you cannot toast a bagel in your new toaster because the instructions only mention bread and English muffins. :-)
Project IS “Connected”
These comments really just seem like marketing spin to me and have been covered in my comments on the original post and in Glen’s post. Suffice to say that Project Server addresses these comments have little to do with the suitability of Project as a scheduling engine for software projects. A deck of 3x5 cards used to organize SCRUM or XP tasks are not ‘connected’ either since only one person can ‘hold’ them at a time so give me a break. :-)