Tag Archives: roi

Controlling Customizations in Packaged Products

A Model to Quantify the Degree of Customization (DoC)

Customizing packaged software products, like ERP and CRM systems, has an adverse effect on their upgradability and maintainability. Typically a company acquiring a packaged product wants to balance out the investment (ROI, TCO) with just enough adjustments that are required to make the product fit the industry or business specific aspects (usability) so the company can retain its competitive advantage.

Making too many adjustments voids the purpose of investing in a packaged product. A better solution would be a bespoke software in that case. Not enough adaptation and sticking to the out of the box functionality reduces the ability of a company to serve its clients and by that the usability of the packaged product. So there is a sweet spot for every company with the right amount of adjustments.

In order to determine this sweet spot a company must be able to determine the degree of adaptation that was applied. Quantification is difficult but not impossible as we will show in this document. Once quantified it allows to monitor the current state and trend in the adjustments that are made to the original packaged product.

The original paper I wrote on this model you can download here:

The Degree of Customization (DoC) model is a way to quantify the amount of adaptations to a software product. It expresses the degree as a percentage where 0% indicates the out of the box product and where 100% indicates a fully bespoke product.

Doc Spectrum

The DoC is based on three axes:

  • The count of the adaptations
  • The impact of the adaptations
  • The size of the adaptations
DoC Axes

The DoC determines the degree for the building blocks comprising the software. What these building blocks are and the level of granularity is up to the company to determine. However, the granular finer and more exhaustive a list of building block is defined the more detailed and accurate the DoC can be measured.

Continue reading

IT Project Management During the Financial Crisis

I received following link from a colleague http://www.tinyurl.com/rocksintogold, 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.