Software Change Management Industrial Case Study: Utility Moving to the Clouds

Outcomes and lessons learned

Your next meeting with the IT general manager and the head of Infrastructure Services is stormy. It is apparent during the meeting that the head of IS is unhappy with the results. He continuously bombards you during your briefing with nasty remarks, and he accuses you several times of deliberately ignoring his people’s inputs. In addition, he blasts the legitimacy of the numbers and asks for details on how each was derived. You respond with the spreadsheets that provide backup and tell him that his own people reviewed the numbers and found them reasonable.

Your boss finally has no option but to tell everyone to cool down. He states that even though the numbers speak for themselves and seem to present a solid business case for change, he has concerns. His major trepidations, he says, are the risks associated with the transition and the displacement of personnel. He says that equipment has to be changed no matter what option is chosen because it is wearing out and the reliability declines have to be fixed. Based on his remarks, it is not surprising that he accepts Option 2. In response, you and your team take the action to move to the next step in the process by preparing and issuing an RFP. You hope that several of the vendors who replied to your RFI will respond to your RFP with proposals that provide good value for your money.

Your team meets and tries to scope what goes into the RFP besides the requirements and boilerplate text. A member of your team who has been through a large purchase like this before advises you to pay attention to the boilerplate text because this is where the evaluation criteria for selection and the terms and conditions for the purchase go. That’s good advice, you think. So you schedule a meeting between your team and the Purchasing staff.

The meeting with the Purchasing staff goes very well. They had lots of experience and advice about what to put in the solicitation document. Key provisions include rewards for delivering early and penalties for being late. They also provide options to acquire several products and services (additional applications and services, more equipment, training, and other such items) that can be taken after the contract is awarded at a fixed price. Maintenance terms and conditions for the first five years of operations were also spelled out so that you can get the vendor’s immediate and undivided attention when problems occur after delivery.

At the suggestion of the Purchasing department, you send the solicitation out to the prospective suppliers for comment prior to releasing it. You get back a lot of constructive criticism and suggestions. You find that the most controversial clauses are those associated with late delivery and maintenance.

The lessons learned in this industrial case study were many and include, but are not limited to, the following:

• Even when you think there is a clear choice, resistance to change can pop up from unexpected sources. Therefore, also anticipate resistance and plan to deal with it.
• Resistance to change comes primarily from those whose power, staff, and budgets are threatened. In this case, such cutbacks are real threats to the Infrastructure Services group.
• Those who foster change need to anticipate the perceived threats and develop plans to help address them as part of their effort. In this case, figuring out how to find other positions for staff who are no longer needed might have alleviated some of the pain.
• There might be hidden issues that influence decisions relative to change. In this case, aging equipment and reliability issues did not surface until late in the process when options were being compared. Yet, the issue was one of the major drivers in determining which option was selected.
• Using competitive market forces to seek the best alternative can be beneficial, especially if you can get an expert review of your solicitation by stimulating the vendors to provide you inputs as to which of your requirements are feasible and which are not.
• However, relying solely on vendor inputs is dangerous. Because they want to make a sale, they might stretch facts and cloud reality by confusing current capabilities with future capabilities.
• Using strengths and weaknesses along with costs and benefits permits stronger cases to be made for recommended alternatives.
• Getting a vendor on contract takes considerable time and effort. It also forces you to solidify your concepts of operations, requirements, and contract terms and conditions.
• Getting selected vendors to deliver what they promise often takes patience, effort, and due diligence. Many will do a good job. Others may let you down after the contract is issued. To succeed, plan to manage rather than monitor the contract. Otherwise, you probably will get less than what you expect and less than what you are paying for.
• The challenge will occur after the cloud products and services are delivered and accepted. If you are not one of the vendor’s key accounts, keeping their attention during operations and maintenance might become an issue. That is why I strongly recommend negotiating terms and conditions for any follow-on maintenance contract as part of the original acquisition.