Hans Christian Andersen wrote about two weavers who promised an emperor a new suit of clothes that was invisible to those who were unfit (shortsighted/unskilled) for their positions. When the emperor parades before his subjects in his new clothes, no one dared to say they didn’t see a suit of clothes until a child cried out, “He’s naked!”
As depicted in the fairy tale, operating under a pretense can be costly. Software projects may produce similar stories over the next several years as lessors begin to upgrade or migrate to new software. Lessors may likely be in a time capsule as it relates to performing these back-office assessments and migrations. It may have been more than 20 years since their companies had in-depth back office system assessments, RFPs or implementations. Based on the large impact, lessors need to carve out appropriate hours as these decisions will likely affect their businesses for the next 25 years.
Like most things in life, the more time you allocate upfront, the more likely you can expect a successful outcome. On the flip side, the following lessor scenarios illustrate what can happen when a less than robust approach is used to satisfy the requirements of a software-related project:
“The software agreement with the vendor probably had more lines then the actual code itself,” says an attorney who had previous poor experience with a vendor.
“At the end of the day, the budget was blown out of the water, our go-live date was not achieved, we actually lost functionality and the person running the project got promoted,” says the head of operations on a project.
How do lessors avoid replicating these scenarios and find a way to deal with issues in lieu of symptoms?
Time-Based Competitors
First, over the last several years, there has been an abundance of applications, best practices and certifications to help manage projects, yet projects continue to underdeliver. The project itself hinges on many important building blocks, including asking the right questions and having the proper model and approach for providing a viable systematic solution that is also cost effective. These protocols need to start on day one, before contracts are signed and third parties are selected, and continue from requirements to production.
One building block for lessors to have as a main driver is to be a “time-based competitor,” which means they should strive to respond faster. By taking time out of the process, numerous benefits will naturally accrue for the customer, vendor, sales, operations and ROI, regardless of the industry. A key indicator of this component in the process is for lessors to ascribe value to a process that improves response times using current operations as a basis for measurement.
The CJCS Approach
Another interesting observation is the positioning of various departments when deciding what functionality and technology must be included. It’s not that lessors don’t have competent people, but without a set of game rules the process is quickly compromised and the squeaky wheel or position may likely win out.
To avoid internal positioning, the U.S. military faces a similar challenge. The Chairman of the Joint Chiefs of Staff (CJCS) helps determine which parts of the military should be engaged based on the situation at hand. This helps provide governance and prevents each branch from trying to outmaneuver the other in a race to show its importance and/or to increase its power.
The CJCS approach can add discipline, which helps add another building block, enabling the CFO to play a similar role. The CFO would work with the team to establish a baseline on the cost per contract — to go live and on an annual basis — to help provide a neutral analysis of the proposed vendor solutions. The departments can then qualify its requirements against the baseline to the CFO who can determine how these add value and ROI. If IT wants certain technology that will increase costs by a factor of X, what is the risk/value ROI versus allocating those dollars to other functionality?
Main Value Attributes
Another building block lessors should look to adopt is having a proper standard or protocol to validate the three main value attributes — knowledge, arm’s length and no duress — are protected at all stages of the project. Figure 1 demonstrates why these are integrated and how one failing attribute can have a significant impact.
Figure 1 also helps provide discipline in staffing the right team members, mitigating risk by helping avoid the number of potential disputes down the road, having the proper requirements at the beginning (vendor analysis) and developing a pertinent list of building blocks and standards for the project to be successful.
Highways (Standard) vs. Toll Roads (Nonstandard)
I have found this analogy to provide an eloquent description of how software may be classified. A highway provides a standard (i.e. interstate) that works as an integrated network/approach, while a toll road is the inverse. Let’s compare these in the table below:
Author Richard Wright said, “Each time history repeats itself, the price goes up.”
Depth of experience provides the ability to see how things are similar (highway), in lieu of how things are different (toll road). Software functionality should provide an industry solution while systematically providing flexibility to structure and support multiple ad hoc scenarios to meet specific demands of the leasing company, including sales, accounting, regulatory, asset management and reporting.
From my experience, including being pulled into rescue projects that went off the tracks, individuals who have a diverse background provide the best value as they can “connect the dots” (highway) and provide the proper context in most situations.
Project Duress
Duress can come in several forms (hours, resources, internal support, unrealistic timelines or dependencies), which affect all parties. What may begin, in theory, as a great kick-off meeting can quickly dissolve. Looking to provide a competitive advantage to the business may soon become a marathon just get the code into production (solve for go live date versus project measured on delivering Value/ROI). When a lessor’s processes do not comply with the standards outlined in charts on this page, this is usually the result of two scenarios:
Lessors need to qualify the value upfront and measure the completion of these building blocks during the project and afterwards when in production. Too often the business drivers becomes forgotten as individuals focus on dates instead of delivering functionality.
Arm’s Length
This helps avoid conflict of interests, which can affect the ROI and value. Just by its very nature, IT has an inherent challenge to be arm’s length as the department likely monitors itself in lieu of other departments like credit, accounting, tax and legal, which have external standards.
An arm’s length approach helps provide a market solution (highway) which aligns well with the value and ROI. Some of the risks that may occur on the project include:
Lessors fail to establish a neutral process to help provide an open forum to discuss issues properly.
Lessors may face institutional challenges and dependences inherited from their predecessors, which further compounds the project. Having an open forum with the right team members (highway) will help identify risks early in the process by asking the right questions. Tackling these issues immediately will help mitigate risks and avoid surprises to senior management.
No categories available
No tags available
