- 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
Practical World
Many of my friends and colleagues work in the IT industry. Many work in service organizations and quite a few work in IT groups of large corporations. We have had several discussions on the concept of ownership and with every conversation, a new challenge arises. The real world is far murkier than the pristine idealism of cooperation and partnership.
Competing Priorities
These days, customers commonly ask for key project personnel to be mentioned in the contract. However, a “seasoned” service organization manager would never put his stars on that list. In fact, delivery managers take pride in ensuring that the real performers of the team do not get caught into the contract trap. The moment the incumbent team’s management realizes that they are losing business, they will focus all their efforts on finding new pastures where better business opportunities may exist. This is a classic case of competing priorities. In an Agile paradigm, teams need to spend time in handing over ownership, but if the parent organization of the incumbent has a conflicting interest and seeks to pull out key members, this will never occur. There are no easy answers to this practical problem, and most often, the issue cannot be resolved using contracts. Customer organizations need to think from the viewpoint of the incumbent vendor and understand what would appeal to them and keep them on-board. In our case, the EuroT CIO himself suggested that we use this exercise as a way to build a center of excellence on knowledge transfer. That sounded ambitious to many of us. Some of us had already experienced knowledge transfers in prior engagements, but the opportunity to look upon this as a discipline in itself and elevate it to a higher order added a new level of enthusiasm. Since then, we have carried over what we have learned as we moved on to other engagements.
Rebadging
A transition often means hiring some of the employees from the incumbent organization. The industry-accepted term for this is rebadging. Rebadging derisks the program and application to a great extent. However, rebadging can also have its pitfalls. Employees may not be ready for a rebadge. The good ones may find better options and move on. In most cases, employees may not be happy with a move from a customer organization to a vendor organization, for example, or across vendors. Personal equations and egos get in the way. Eventually these people quit, taking their knowledge with them.
However, rebadging has become an accepted norm. Many of my colleagues vouch for the efficacy of this practice. In reality, what these organizations are doing is buying more time for their intended team to build context. The members who have been rebadged will go through a completely different transition—a new organization, a new culture, and perhaps a different career path. Many may have transferred to the incumbent because it seemed to be the safest option at that time; but most will reconsider.
A client with an Agile organizational culture would have a fairly sound idea of the real performers from the incumbent. The incumbent management runs the risk of losing some of these employees if the client or the new vendor decides to make offers. These types of situations can become lose-lose very quickly. Therefore, it’s in everyone’s interest to sit down and make a commitment to make the transfer successful.
The Evolving Nature of the Program
Areker Bank is one of the largest banks in the U.S. Their current banking platform, named Lothar, has been running for the last thirty years. Over time, their customer demographics began to change. Customers had become more connected, empowered, and demanding. The bank implemented a next-generation banking product to serve this new-age customer—Banker, a product of Sofa Technologies, one of the largest software companies in the world. This program was christened as Nerup.
Areker planned to utilize Agile methodologies for the implementation. They took over direct responsibility for implementing Banker from Sofa. Areker engaged LeanAgile, Inc. in the transition program. The plan was for LeanAgile to take over the Banker product implementation from Sofa within a span of six months, but as the engagement progressed, they realized that Sofa Technologies brought deep product knowledge, something that neither Areker nor LeanAgile would be able to pick up within six months. Because this was still a fairly new product, only personnel within Sofa technologies had enough knowledge of the product to effectively implement it. Such skills were not available elsewhere in the market.
As this realization dawned on the parties, they extended their engagement with Sofa Technologies. The teams have now been working on Banker implementation for more than two years. Even to this day, the implementation team is largely comprised of Sofa engineers. They were able to change course because at some level they were following the Lean principle to defer commitment.3 This principle states that decisions must be frozen as late as possible in the process, especially those decisions that become irreversible. If they had made up their minds to take over and sealed down contracts and timelines accordingly, the banking system would have crashed, and most likely Areker Bank would have gone out of business.
Politics
Most IT organizations take a radically different approach than what Areker Bank chose. Knowledge transfer often begins with a surreptitious agreement between the customer and the new vendor. This period sees heavy negotiations. The client is keen to get good rates and a robust set of SLAs (service level agreements).4 The vendor is keen to win the business. All of the negotiations are centered around rates, the SLAs, and how soon one can take over. In effect, all of the negotiations are about improving IT efficiency. There is little to no focus on business outcome. The vendor uses their prior knowledge with similar engagements to negotiate. The client uses their historical experience with the incumbent to negotiate. All through the process, both IT parties overlook the purpose of the product.
Unfortunately, these discussions and the negotiated contract are what drive team behavior. Given the need for discretion, both the client and vendor make many assumptions about the product and the environment in which it will be used. The vendor is most interested in winning the account and making a sustained profit on the account. The IT organization is looking to drive down costs and maintain SLAs. Teams are trained to show their SLAs are within limits. If the product fails, it could be marketing’s fault or the business team’s mistake because they did not know what their customer wanted. However, the IT organization and the vendor are happy if they are within their SLAs.
After the contract is signed, the onus is upon the incumbent. The obvious reflex is to resist and turn hostile. Even if the technical team on the ground is open to help, the incumbent’s management might make it as difficult as possible. The incumbent account manager might be worried about his job. Last-ditch efforts are made to win back confidence. A number of concessions are provided. However, given that the client and the new vendor have signed what is considered a rock-solid contract, there is no wiggle room for the incumbent. When this becomes obvious, the incumbent management may lose interest. They might try to pull out their best members to focus on “rising accounts.” And so, all of the team’s and management’s energy goes into getting everyone to interact in a productive manner. Driving this behavior creates a lot of waste in the system. Nine times out of ten, the clauses mentioned in the contract will fall through. The SLAs become unachievable. Many of the original assumptions turn out to be wrong. The product suffers.