It’s a strange thing when the subproject you’re working on would ideally require a different project method from the overall project. Not only is it difficult to convince the overall project management but there’s also the challenge of getting the other subprojects lined up.

The big project we’re working on at the moment has a lot of the signs of “classical” IT projects. There’s a lot of very defineable parts that can be specced out completely before building is started. Especially all the parts that include getting information from meters, calculating stuff about that information and then storing the values/making up the bills.
On the other hand there’s our part…. The portal that will serve as user interface for the information services…. These are quite a bit harder to define as look and feel has a bigger impact then the specific functionality.

So the overall project is running on a conventional waterfall method. Functional design, Technical design, Build, Test, Deploy. This is definately the way to go for all the backend logic as there are no variables. A lot of what is going on there is defined by legislation, the rest is all very defineable.

The portal subproject would much rather like to run on some form of agile method. The basic functions of the portal applications can easily be built in a short time and an agile method would give you the opportunity to make fancy stuff for those applicaitons that need it, after reviewing the basic functions.

So how does one combine those two then? The overall project needs specific points of integration testing to make sure any hurdles are recognized as early as possible but the timing of both methods isn’t really easy to allign.
So the definitive choice was to go for an amalgamation of both methods. There will be a waterfall method overall where Functional Design is done early and Technical design comes after that. The build process is, however, split into 4 time boxes. This allows for 4 specific points of integration testing, allows for the Portal part to be a bit more flexible (by doing basic design in the first iteration and then adapting where necessary) yet still offering the rigidity and planability of waterfall to the other subprojects.

I can easily say that this is the biggest challenge in projectleading I’ve had so far. I’m convinced we’ll be succesful but the road to that succes will not be an easy one.  Luckily I’m accompanied on my travels by good projectmanagers, a good mentor and a team of geniusses to do the real work