Skip to main content

Marginal cost of delivery

Big programs of work tend to be comprised of several small IT projects stitched together.

Business architecture makes sense that way - build and release in small doses and keep building. Momentum - in both IT roadmap and business outcomes - is great and demonstrable in this way.

Theoretically, Everything goes smooth and the program is complete and every one is happy.

However, in reality, things never go as per plan. No plan survives the impact when the rubber meets the road.





When Programs go wrong

Programs of work go wrong very often. That is why most large enterprises have a steering committee. 

It is the job of the steering committee to make sure that the program is going towards its intended goal.

In a nutshell, the steering committee is supposed to do the following:

  • Reinforce the original goals of the program
  • Track progress of every project in the program
  • Reallocate resources to avoid bottlenecks
  • Delegate the operational details to the respective teams

However, there is always a conflict of interest for people who are a part of the Steering committee. The steering committee is always made up of people from the respective projects - since they have the best view of what is happening in the ground. 

However, it is not easy to compartmentalise between your project and the whole program.

Things get even bad when the goals of the program change and you have to change a lot of things - right from the way the program was structured to having new projects or closing existing projects.

Original cost of delivery

The programs are always costed based on what the projects in a program would cost and a little more to accommodate the cost of running a program. 

However, there are certain costs that all of us overlook. 

The most important thing being the cost of decisions taken by the steering committee.

Marginal cost of delivery

Simply put, the marginal cost of delivery is the difference between the real cost of delivery and the original cost of delivery.

What leads to us having a marginal cost of delivery?

Remember the original goals of the program and how you had structured the program - they are always sub-optimal. Every one improves as we go along in the program. Hence the original cost of delivery is at best a guesstimate.

The marginal cost of delivery is the cost for all the decisions that are taken - all these decisions have further impacts that are not easy to correlate to. 

For example, the constant resource reallocation could cause employee fatigue. Hence salaries or benefits would need to be increased for us to get the same benefit. This is not possible to correlate right away  It would take us some time and investigation for us to come to this conclusion.

Conclusion

We have to be aware of the concept of marginal cost of delivery and be very sensitive in communicating this to the senior leadership when we head a program.

This is important because, it is very easy for us to miss some of the obvious costs of running a program and be measured against a more static number. Such a comparison would lead to a more status and less effective program execution - something that is not good for anyone.


Labels:

Comments

Post a Comment

Popular posts from this blog

My Journey in Inquiry and Advocacy - An experience report

It is recently that I have consciously started practicing Inquiry. Let me explain. I am a consultant who constantly looks at the situation and comes up and implements the solution to progress from there. While I do that, I constantly use Inquiry as a means to progress - one of the key facilitation technique specifically in multiple stakeholder situations.
Post a Comment
Read more

Principles for developing systems that are anti-fragile

I have been trying to make sense of what anti-fragility means and how do I use that in my day job. As a Business Principal, I tend to work with the abstract but orchestrate a program of work that needs details. This makes my job a little difficult in the terms of designing for more self-preserving systems that preserve the spirit of the abstracted strategy or vision. I came across an article from Daniel Russo on anti-fragility and his attempt at creating a manifesto similar to the manifesto for agile software development. For more reading on Daniel Russo, here is his profile:  http://djrusso.github.io More reading from his paper here:  https://www.sciencedirect.com/science/article/pii/S1877050916302290 This post is an attempt for me to understand what goes into developing a program that uses every opportunity to strengthen itself and achieve its objective - the vision.  I liked the approach of principles for developing systems that are anti-fragile. It is a very valua
Post a Comment
Read more

User Personas

User Personas are a very good tool for the product owners, business analysts or product managers to be able to co-create with designers. It is predominantly a product of the user research and should not be an amalgamation of demographic data. It is the best way for us to list all scenarios that a persona would take when they want to attain a goal. It is predominantly used to build empathy with user, focus the team and build consensus in a large diverse stakeholder group. The website I referred to is here:  https://www.smashingmagazine.com/2014/08/a-closer-look-at-personas-part-1/
2 comments
Read more