Monday 10 September 2018

FUTBAL (c) framework for transformation

I was reading this article posted on LinkedIn.

https://www.cnbc.com/2018/09/06/companies-worry-more-about-access-to-software-developers-than-capital.html

It got me thinking into the various aspects of digital transformation and future of IT across all industries.


  • Understanding your company

This is probably the most critical aspect. Everyone has a different viewpoint and each viewpoint can result in a completely different direction the company can take in order to transform itself. While some of the directions taken could be outrightly wrong, most of the directions can take the company forward. But not all of them will take the company to the destination expected and that too within the given time and cost. That's where a leader or leadership team that understands the ramifications of each path is needed. Unfortunately in many cases, that's where the issue is. There's a tendency to either overestimate or underestimate the company capabilities. Not every company can be Amazon or Google like mentioned by the author in the article. Saying that we are not Amazon or Google - is it defeatist? Not at all. It is defeatist when you are deciding this only to abdicate your responsibility. However, if you really understand and accept your own or your companies limitations, then it is the most realistic way of achieving your target

  • Buy vs Build

This debate has been there for as long as IT has been in place - and it will never end. There's no one size fits all solution for this. A balance is needed between the two. There are many applications and products available in the market that you can straightaway use instead of reinventing the wheel. What you definitely cannot outsource is your IP or intelligence of the company. There are many things that every company does in a specific way and that could be a game changer when it comes to the industry. Processes can be standardized when you have inefficient ones, and they can be made specialized when you are really bringing value into it. Specializing or standardizing just for the heck of it doesn't work. Spend time creating value rather than wasting it reinventing the wheel. Yes software developers will be important for the things that you are going to build, but thinking that only software developers will see the company through, sounds naive.

  • Foundation and All speed IT

IT development model started from Ad-hoc development in the early years and moved on to Waterfall to Agile to Devops to Bimodal IT as prescribed by Gartner. While going through these modes, there was a clear change in thinking. With Adhoc, there was barely any documentation and thoughts around overall foundation or Architecture of the company's IT stack. Moving to Waterfall ensured that enough time is spent on these aspects but it reduced the speed and increased the cost of implementation and changes. Moving to Agile was a way of getting over this limitation and provide a better way of dealing with things. However most of the companies ended up implementing a pseudo-Agile model and conveniently left out some of the most important aspects of architecture and documentation. To overcome with pseudo Agile (and to bring some more advantages) Deveops method was developed. However devops has limitations in the circumstances in which it can be implemented. Gartner came up with a Bimodal way of working where some projects were to be implemented in an agile/devops way and some in a traditional waterfall way. This was a good model however we soon realised that 2 modes are not enough. We needed more. We needed specific mode or speed for specific type of projects. That's where the All mode development model has come into picture. 

The problem with this model is that we might move towards the original Adhoc methodology while trying to implement this. This is what we need to guard against. A very clear direction, push and understanding is needed to go for All speed IT to make effective use of it. It will help in getting all core foundation layer and architecture managed in a different way and all other projects managed in different ways depending on the situation. Documentation and collaboration will be the keep to avoid the traps

  • Leadership

Buy vs Build applies to the leadership team too. The company may have excellent leaders who understand the technology and the business and also know how to drive transformation. If such leaders exist, they should be retained and given the responsibility of taking things ahead. However, not all qualities maybe existing in the company - so getting someone from outside to compliment the existing leadership is needed. There's no point in going to the extreme on either side of Buy vs. Build. Neither in technology nor in Leadership.

  • Trust

This is one of the key pillars of any Transformation journey. Trust among the members of the leadership team, trust between managers and the team members, trust between teams and trust across the organization. Without this, no transformation can succeed. It's easy to say that we are a very trustworthy company (or we have a very trustworthy and trusting organization culture) but the reality that we often see is that it is not the case. Many surveys across organizations from various industries (especially anonymous surveys) have shown this to us. Building trust is a slow and tedious but necessary process. There are high chances that one action can bring the trust quotient crashing down but unless you persevere, there's no way forward.

So what is this framework called? FUTBAL (c)
FUTBAL (c) Framework
There are many models for transformation. But considering the more comparatively "non-technical" aspects of the transformation journey, FUTBAL (c) model would be able to provide a way ahead.

No comments:

Post a Comment