I spent the morning over at the HQ of the Open University  being interviewed by BBC presenter John Waite about the best method for IT project management.

The Open University are just about to launch a new module combining IT Project Management and IT Service Delivery and invited three of us veterans, myself plus former APM Chairman Miles Shepherd and Geoffrey Darnton, over to be interviewed by the BBC to illustrate how theory works in practice.

To the question, ‘which is the best method’, we counselled that the most appropriate method not only depends on the organisational capability and the type of project, but also the stage of maturity of the requirements.

If we consider the well used parameters of method v outcome, then for projects where we know what we are trying to achieve and we know how to do it, what Eddie Obeng referred to as ‘paint by numbers’ projects’, then traditional ‘waterfall’ methods can usually be deployed with some certainty.  For projects where the client isn’t quit sure what they need, and we are not quit sure how we are going to deliver it, eg developing new capabilities at the bleeding edge of technology, what Eddie refers to as ‘Quest’ type projects, then a waterfall approach gives us no predictive ability as the uncertainty is too large.

Over and above this uncertainty around what and how, we add the dimensions of size and complexity, as measured in models such as  the Office of Government Commerce’s ‘Risk Potential Assessment’.  As one of the top 8 reasons for project failure summarised by the OGC and National Audit Office is failure to break projects down into manageable chunks, we really want method to help us to de-construct where practical to give us lower complexity.

We all agreed that the organisation’s maturity in delivery was a deciding factor.  Agile methods, rather than requiring no governance and assurance actually require a lot more in order to remain within the overall constraints of the over-arching business project.  Moving from un-governed waterfall approach to un-governed iterative approach loses a level of control and increases uncertainty.

And what are we trying to achieve?  Is it an incremental improvement or are we attempting to transform the way we deliver services that requires new hardware and software platforms and cross application access to data-sets?  There is no agile way to turn a bike into a car.

For a mobile phone app, transition into ‘live’ for the user through multiple releases does not pose a particular problem and we are all used to it.  The migration and release of enterprise software across a global organisation, however, requires a lot of investment and has significant impact on the business.  As well as a battery of testing, from functional testing to co-existence and penetration testing,transition to live probably means training of users and help desk, and maybe re-engineering of business processes.  Not something that you want to do too often and stay the right sight of your business users.

So there you have it.  Like most things, it all depends.  One thing that we did all agree on, what separated out successful project managers, whatever the method, was transferable behavioural competences.