- Post Takeover
- True Cost of Transfer
- Practical World
- Things to Know and Do
This chapter is from the book
This chapter is from the book
This chapter is from the book
True Cost of Transfer
A related issue to knowledge transfer is its limitations on business advancement. Many organizations have a tendency to pause project development while knowledge transfer is in progress. It is understood that projects may be paused for about three months. However, in reality, the impact is much longer. The entire stabilization period slows down delivery. New features and functionality may not reach the market on time. This adversely impacts the competitiveness of the organization, which may be the very reason why a transfer was triggered in the first place. This is another phase in which the relationship between business and IT is tested immensely. The confidence in IT decreases within the organization. Apart from the obvious issues of delivery slow-down, IT members may fail to have the right levels of context and domain understanding to engage with business members effectively. This leaves business members spending more time with the added task of detailing out functionalities and expectations for the IT members. Business members will also need to acutely focus on testing out the new features with the new team. However, none of the knowledge transfer metrics currently track these impacts.
For too long, we have focused on the operational efficiency of IT projects as opposed to their effectiveness. The project charter goes through deliberate discussions on the purpose of the project. Most projects quantify the expense and the expected benefits of doing the project. A business case is put out to justify the return on investment (ROI). After this has been approved, everyone focuses on staying within the cost, timeline, and scope of the project. We often do not step back to see whether the real purpose of the project is still relevant or whether there might be other opportunities along the way. The metrics on knowledge transfer continue to focus on operational aspects such as how much has been transferred, the cost incurred so far, and the team’s ability to stick to their deadlines. We don’t try to determine how well things have been transferred. So although we can have a lot of “completed” tick marks, true internalization hardly ever occurs. We get what we measure. Unfortunately, in this case, we aren’t measuring the right stuff.
The inherent costs of a transfer run much deeper than the time and effort spent directly on the activities. Costs of business disruption after the handover or during the stabilization phase can be debilitating. However, these costs may not be directly attributed to the knowledge transfer, often because the project may have been “completed” by then. The opportunity costs of failing to put functionalities in the market can be quite heavy. Needless to say, the ecommerce world is rapidly evolving. Competition exists in every sphere and customers are getting savvy and demanding. One can ill-afford to pause innovation that customers look for. Such costs are rarely accounted for within the metrics tracked on a knowledge transfer project. These costs can be several times higher than the direct cost of personnel in the project.
Agile software development has seen substantial adoption among organizations. Agile and Lean delivery focus on high-engaging, non-fussy models to deliver software. Most importantly, the cultural shift in the Agile model requires a substantial people-centric approach. Today, many software platforms are developed using Agile methodologies. More importantly, there are several benefits in utilizing Agile philosophies when undertaking knowledge transfer programs. Agile focuses substantially on business outcome versus operational efficiency, on quicker outcomes along with quicker material feedback. Agile also does not focus on “big bang” releases. Instead, it encourages us to release in short cycles, allowing us to refine our processes and get feedback. Adopting a similar approach to knowledge transfer would allow us to reap the very same benefits. Smaller milestones allow the team to get quick wins, increasing confidence all around. It also allows us to learn and adapt. This is even more crucial in a project whose execution will be nebulous. These projects will witness heavy undercurrents given teams from different groups are involved. This is all the more reason to give such projects more time to think big while starting small.