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.


Comments

Popular posts from this blog

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 i...

Designing for Accessibility

The software world has starting being more inclusive. After serving only the geeks and the techies, a lot of the software that is produced in this world has started looking at how it can be mor euseful. One of the key constituencies of software usage is people with disability. The ADA (Americans with disability Act) has forced a lot of the software developers to look at this issue. The software world has also responded sensitively and with care making as much of the software usable by people with disability. One of the key components that we are looking at in this are people with visual impairment. Over a period of time, a lot of the software has made sure that the user experience is adjusted in such a way that is is intuitive. Google has been a front runner in this and a lot of others are also not left behind. Text The size and the font typology is very important. Choose those aspects with ADA in mind. Media like Images A lot of the media , including video and images ,...

The cost of delayed decisions in Enterprise

Large enterprises have started their IT journey in earnest. However, they are miles behind what is happening.  Some of them have been trying to learn faster by creating research programs or separate business unites to try out and learn a few exotic ideas that have not yet gained acceptance in the industry or enterprise. Enterprises have moved record collection and data to IT long back and were pioneers in that. However, since the advent of personal computers, they have been left behind. Internet and mobile have left them far behind. For example, Network security, big data, mobile apps. social applications are solved problems that the enterprise choose to ignore.