The general blueprint I use when dealing with such issues is as follows. First, I divide IT projects into three categories - CA, Transition and CODB. Then for each category I take a different approach :-
With CA like projects (i.e those which are novel and new in the industry, few examples in the wild, minimal whitepapers, some percieved value and relevant) then use more of a VC like approach (IT Finance) or Worth based development. Focus on worth and dynamic like processes for development (e.g. SCRUM, XP etc).
With CODB like projects (i.e. those which are common in the industry, necessary, lots of examples, lots of whitepapers, even conferences on the matter) then focus on cost reduction, standardisation and static like processes (e.g. Prince2 etc).
With Transition like projects (i.e. those betwen CA and CODB) then either:-
* If new to the field then calculate potential worth, risk and costs and then it's a judgement call - wait and adopt or disrupt.
* If already in the field then attempt to move your service to become the standard product for the industry and hence reduce cost of migration.
Now this is my method, there are many others ... this is not about which method is better. I used my own blueprint to illustrate what I believe is an important point:-
the type of approach which should be adopted depends upon the nature or the class of the problem you are trying to solve
It's not about one approach, a magic cure to solve all problems.
