Reference Books

Focus Books

Study Guides


The Complete Pragmatic Family of Frameworks


◄◄◄ Previous Page         


          Next Page ►►►

Let’s get some definitions out of the way:

¨      Resources - money, time, people, etc - whatever is required to effect a transformation.

¨      Requirements - the resources associated with satisfying the requirement of the work.

¨      Guidance - the Resources associated with satisfying the things that guide and influence how we satisfy the Requirements. Things like Principles, Policies, Standards, etc, but also things like conforming to the structures and methods imposed on us.

¨      Required Resources - the Resources that are required to satisfy the Requirements and conform to the Guidance.

¨      Assigned Resources - the resources that are actually provided - which are always less than those that are required!

Don’t forget that Governance & Lobbying happens at each level of the Transformation cascade and therefore each level has to conform to (or lobby against) the guidance (Structural and Transformational) from the level above.

Now, lets consider these three worlds…

The Perfect World

In the perfect world, the Assigned Resources (what we are given) would always equal the Required Resources (what we need) and there are therefore no problems. But that never happens...

The Real World

In the real world, the Assigned Resources very rarely (aka never) equal the Required Resources

From the point of view of satisfying the Requirements, this discrepancy is usually managed as part of Requirements Management. Any requirements that cannot be met are usually identified and either resource is brought to bear to satisfy them, or they are “de-scoped”. This is not where most of the problems that derail Transformation efforts lie.

From the point of view of satisfying the Guidance, this discrepancy is usually not managed, or if it is, not managed well. Often the discrepancy is ignored, or an entry placed in a risk register that is never acted upon. In fact, many Enterprises take a very dim view of exposing these problems. There may very well be valid business reasons for this, but a lot of the time this restriction is pretty arbitrary.

For example, I have personally worked on countless projects that had drop dead go live dates that, if missed, would mean the world would end - but, it never did. I have also worked on countless projects where the money required was not made available - again for some pretty arbitrary reasons - but in reality, those restrictions meant the project ended up spending far more. I am sure you have too.

Restriction of resources tends to be the very simplistic (and ultimately severely damaging) control mechanism that management uses in relation to Enterprise Transformation, as well as the simplistic management style of always asking for more for less. This leads people to produce inflated estimates (assuming they will be cut) and management to not believing them (assuming they will be inflated).  Two well-known phrases come to mind:

“There is never time to do it right, but always time to do it over.”

“A short-cut is the longest distance between two points.”

For most Enterprises that’s where it stops. People just have to knuckle down and muddle through somehow - put their nose to the grindstone - work as team - forge ahead - think positive thoughts - don’t be negative - just-do-it etc. Perhaps some lip service is paid to this gap - some entry in a risk register that is never used for anything - but that’s about it. There will be implications, but those implications are not fully known and will only be discovered later when nothing can be done about them and those that could have done something about them have moved on to far more important things.

But, let us be clear.

Not providing what is required is not the problem.

Ignoring the implications is…

The Pragmatic World

In the Pragmatic world, things start off the same as in the real world i.e. the Assigned Resources very rarely equal the Required Resources. However, in the Pragmatic world we accept this inconvenient truth and do something about it.

We recognise that we are creating Transformation Debt™ and there are three things we need to expose and consider:

¨      Cost of Compliance - What is preventing the Enterprise from complying with the guidance and what is required to allow the Enterprise to comply?

And, assuming what is required is not provided…

¨      Cost of Non-Compliance - What issues and risks going forward will this non-compliance create for the Enterprise?

¨      Cost of Remediation - What will it cost the Enterprise to become compliant in the future?

Transformation Debt™

Transformation Debt™, is what it will cost to service the debt going forward, and what it would cost to bring the work being done up to the same standard as would have been produced if the Assigned Resources had been provided. Note that the Cost of Remediation is bigger than the difference between the Required Resources, and the Assigned Resources. This is because it will always cost more to do something one way and then change it to another than it would have cost to just do it right the first time.

It should also be noted that while Transformation Debt™ can be incurred when doing Transformation, it can also be incurred when not doing Transformation, by just the passage of time. For example, by not keeping operating systems up to date or by not maintaining a building or people properly. In many ways, this type of Transformation Debt™ is more insidious as it can creep up on you unawares.

Having exposed these three key pieces of information, a Business decision can then made to either provide what is required to comply (Cost of Compliance) or to accept the implications of not doing so (Cost of Non-Compliance + Cost of Remediation).

If the Business decision is made to not provide what is required to comply, this Transformation Debt™ adds to the overall Enterprise Debt™.

Enterprise Debt

Enterprise Debt is a measure of the overall debt an Enterprise has incurred and is literally a list of the debts the Enterprise has on its books. It is a well understood accounting term meaning short and long term loans, accrued wages and utilities, income taxes payable, and other liabilities. Pragmatic believes that Transformation Debt™ should also be listed as a liability of an Enterprise and accounted for in the proper way.

Transformation Debt™ (like any financial debt) also has to be serviced in the form of interest payments, for example increased support costs. Like interest payments on a loan, this is a recurring cost and will continue for as long as the Transformation Debt™ it is servicing exists.

In addition, if the thing that was transformed now needs to be transformed again, there will also be an increased cost to effect that change. This change also requires resources and if the Assigned Resources for this change does not equal the Required Resources for this change we are introducing even more Transformation Debt™ into the Enterprise - a double whammy! This is akin to taking out another loan to pay the interest on a current loan!

However, it’s not all doom and gloom. If it is recognised that we need to do some remedial work, (or more likely, things just get so bad the Enterprise has no choice but to do some remedial work) this reduces Transformation Debt™ and is therefore akin to paying off (some) of the overall Enterprise Debt.

Recognising and managing Transformation Debt™ provides a simple and extremely effective control mechanism for management to get back in control of their Transformation initiatives and for those working in them to produce quality work (and to be able to sleep at night!)

Managing Transformation Debt™ is not an exercise in making sure that the Assigned Resources always equals the Required Resources.

Managing Transformation Debt™ makes sure that when the Assigned Resources does not equal the Required Resources (most of the time) that the implications are exposed so that management can make informed business decisions in the light of that information.


◄◄◄ Previous Page          

          Next Page ►►►

Questions to ponder...

Do you have experience of any of these scenarios?

What happened?

Do you think the “Pragmatic World” scenario beneficial and why?

© 2008-2018 Pragmatic EA Ltd