SOA Project Management - killing Waterfall one step at a time

One of the saddest facts in IT is that Waterfall project management, something agreed for probably over 20 years to be a bad thing, is still not only in existence but thriving. Brilliantly parodied by the Waterfall 2006 conference its just amazing how often people fall back into this "learnt" behavior that Waterfall is somehow safe.

A quick wander around finds some waterfall pictures that show the wonder of the process
and (from the same site) the wonderful phrase

"The traditional or waterfall methodology is the forefather of all other methodologies and we find it is most suitable for projects where the requirements are clearly stated and static or where it helps to have a rigid management structure."

Sorry to pick on the folks but it was the first one from Google I could find, and they do also mention DSDM. But really "requirements are clearly stated and static"... the management argument is pure rubbish as Waterfall's management approach is basically wait till the end to identify issues, this isn't a rigid management structure. And there are other crackers around "If you are working on a somewhat traditional project (for instance, an accounting system) where the features are defined a priori and it's possible to freeze the specification, the waterfall process is your best bet." which is the FIRST bloody thing on the page. Are people really in such a head in the sand belief that Waterfall actually delivers what is wanted and is the best approach, that requirements WILL NEVER change, and that the screens you designed on paper will work the way the users imagined?

So quite clearly its pointless trying to change everyone in the world in one go, we have to face the reality that Waterfall project management is out there and pushed and praised "I believe most, if not all projects, can be delivered with the waterfall methodology". This is good old Fred Brooks Mythical Man Month territory, and if Fred says its wrong its wrong. Given that, and in order to make our SOA projects actually work we need to "fake" waterfall.

Fortunately SOA gives us a way to do that, it helps us turn big projects into Programmes which has two benefits

1. Helps us get SOA projects into iterations by default
2. Makes the Project Manager feel important by calling them a programme manager

The last point is probably a little harsh, but if it helps sell iterations in then I'll handle harsh. The trick here is to get people thinking that each "Service" project should be looked at individually, this might still mean Waterfall in that project, but your aim now is to get the Service definition at a level where it meets a couple of objectives

1. Small team delivery - max of 4 - ideal of 2
   
2. Short delivery timeline - max of 60 working days - ideal of 20 working days

This then gives us a series of small projects that are delivering continually. To make it easier for the PM you might want to align your deliveries on "Milestones", i.e. try and get everyone to hit at the same time, but in reality that just means you will pad some of the simpler service projects out.

So each Service project will still look "Waterfall" but will be small enough hopefully for Waterfall to cope.
This is and example of a 9 service project in this sort of approach. Some of these services will be business services, some will be technical, and of course the highest risk elements should come at the start. Unfortunately we still have the massive tailend of Testing to worry about which is where the concept of "Project UAT" can come in, the approach here is to sell UAT for each project as an increase in formalism, so getting people testing earlier is all about adding extra process to the project. The reality is of course that this testing reduces your risk as you are getting eyes on the solution earlier. This can then be used to either reduce the testing at the end, or demonstrate your genius by waltzing through it without an issue.

Lets be clear though, I'm not advocating this as the best approach, just as a way to get Waterfall project managers and organisations working in a more iterative way using Services as the mechanism. Its not rocket science and its not ideal but until there are no more muppets posting things about Waterfall being an option and I stop seeing projects being delivered in a waterfall way its at least better that what was there before. And if you can keep all your waterfall projects inside a month then its hard to tell the difference from agile.