IT Project Management During the Financial Crisis

I received following link from a colleague, holding a slide ware presentation from Clarke Ching, that ever IT consultant should read, dealing with the financial crisis and impact on IT projects.

Ching focuses in his presentation on the return on investment and controlling the project’s costs. Although the model he presents is economically very basic, it’s a good guideline when you confronted with projects being cancelled based on cash flow problems.

For the busy consultant we all are, I made an interpreted summary of his presentation and added some ideas.


  • Economic growth and decline are cyclic phenomena. The decline might sometimes by called a crisis and spread out in the media but you can expect that it will go better. DON’T PANIC!
  • If you, as a consultant or contractor, were working on viable project, either creating new systems that will support business processes or either creating (part of) applications that will be sold, the benefits will not disappear. If the project was viable to start with, this means there was a business need or a market for what you were doing. During the crisis the market might fall back but will recover. VIABLE PROJECTS JUST DON’T CAVE IN ON THE FIRST PROBLEM!

Focus on ROI!

Example: Think about a typical project where you will release a product in one year. The client will pay the contractors big bucks upfront during that year and after one year, when the project is finished the benefits or revenues start flowing in.

Because the client has to pre-finance everything there are probably penalty clauses in the contract when the contractor delivers late. Because of the penalty clauses the contractors want detailed project planning upfront. Any change in the project original requirements of the client results in costly change requests. This situation is presented by the red line in the graph below showing revenues over time. It is a very rigid way of doing projects. But the lack of flexibility means that these kinds of projects are axed first during financial crises.

It is easy to see why! During Q1 to Q4 the project drains a lot of cash from the client that is compensated by revenues that start flowing in form in Q5. In a crisis this cash drain might force the client to just stop the project because they can’t pay the contractors anymore although the project is viable. The crisis might affect the revenues in Q5 because people might spend less but in the end, even with reducing prices, if there is market you’ll see the revenues. In the example below you’ll break even in Q6.

How to tackle this: just create positive ROI-s faster!

The problem with the previous approach is that we have to wait until Q4 to get any positive ROI-effect.

  1. How can make money earlier?
  2. Well just start releasing products earlier!
  3. How can we release products earlier?
  4. Do phased development!

The idea is not to wait until we’ll have a fully finished product before we’re releasing something. Just organize the requirements into list going from functionality everybody really needs ‘High Added Value’ – to nice to have functionalities ‘Low Added Value’. Then divide the list into four groups: one for every quarter Q1 to Q4. The releases will focus on several basic 80/20 rules:

  • 80% of the functionality is used by everybody, 20% by experts
  • 80% of the functionality is not complex and can be delivered in 20% of the time, the 20% is complex and requires 80% of the time
  • 80% of the users only use 20% of the functionality, 20% of the very specialized users use 80% of the product

Phased product releases!

These phased releases mean that after the release in Q1 we can start making money. This is represented by the blue line making abstraction of any efficiencies and the assuming we have the same revenues for this product as we would receive for the fully finished product. In this over-simplified model you would break even already in Q2.

More realistic results!

More realistic results you’ll find in the green line. It assumes that the revenues for the intermediate products are less than for the final product but will evolve in that direction with every release.

  • On the one hand the intermediate releases will create overhead resulting in lower revenues:
    • products must be prepared for the release,
    • support staff must be trained to be up-to-speed with the latest changes,Š
  • On the other hand:
    • early birds might want to pay more to have already access to the product without having to wait until Q4,
    • because of the phased release the project will receive faster feed-back from customers that can be directly incorporated into the product
  • Allows for more agile project management:
    • problems are visible faster: penalty clauses will be less harsh because there is more control
    • requirements must be available at the beginning of every release cycle and not at the beginning of the project: no costly change requests because there is more control
    • more control means more trust between contractor and client: going from a supply-model to a partnership-model.


Avoid viable projects being axed because of cash-flow problems.

Look for ways to get products faster to the market resulting in faster positive ROI-s.

Look for ways to remove inefficiencies: rigid long term planning.

Organize you project so it can adapt fast to the new requirements. Focus on the requirements that give very fast added business value to your customer.

Avoid costly penalty clauses by creating fast feed-back cycles. Intermediate releases will lower the penalty clauses for late delivery and the price of unforeseen change requests because there is more control resulting in more trust between client and contractor.


Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.