March 23, 2007 by jimstogdill
A Big Bet
I had dinner with a colleague from a previous company this week whose firm is making a massive bet on a new software platform. The company, which is in the financial services arena, has been spending 10% of gross revenues on R+D for three years and expects to continue doing so for three more in a huge effort to modernize and globalize their core offering. When it is all said and done the development of this new platform will probably cost half a billion dollars.
We read every day about how Google, Amazon, and Yahoo do software development and we try to take lessons from them back into the DoD. Each of these companies offers important lessons to the way we work, but the analogies are not always directly applicable because of the size of the projects involved. Often these companies are building a large number of relatively small projects that may or may not have any relation to each other. The project my colleague is working on is different in that it is one massive platform development and the company’s future is literally dependent on its success.
I think it is really interesting to look at how this company most people have never heard of is delivering such a massive project.
Of the approximately 650 developers and technologists working on the project, at least 400 of them are in India, 100 work for the company that is commissioning the system here in the states, and the balance work for as many as eleven contributing technology product firms.
Considering that those 400 developers in India are probably billing out at less than 1/3 of the fully loaded rate of a DoD contractor, this project would probably cost more like $1.2B or more if it were being developed at DoD contractor rates (assuming the same efficiency was maintained). This is a big software project even by DoD standards.
From the start of the project until the final instance of the legacy system it is replacing is turned off will probably take a decade or even as much as fifteen years. However, it is important to note that three years into the project one customer of some of the early capabilities is already being implemented. The company views this as important to prove its technology and to begin generating development-offsetting revenue early.
How else does this effort differ from an equivalent DoD project?
For starters the business owners who are sponsoring the project (and whose customers will be consuming it) are in the same building, and on the same team, with the technologists who are developing it. From the beginning the company signed up customers committed to early adoption whose representatives also participate in the development process in very direct ways).
Because of the number of developers involved, and the breadth of organizations that they represent, the overall program manager has set up a highly choreographed delivery cycle that has a fully tested and deliverable release coming out of the development every four to six months. This approach is being taken to ensure that all of the parts are integrated and working and to keep the risk down.
What is notable is that, though the company outsourced the bulk of the development and purchased a number of best-in-breed components, all of the project management and key product management roles as well as sizable architectural and development roles are being maintained in house.
These in house managers are, as expected, incented to deliver the platform on time. However, because of the impact of all this spending on the company’s EBIDTA and the fact that much of their incentive compensation is tied to company performance (bonuses and options) they are equally incented to keep costs in line. This is in contrast with a fully outsourced model where contractors can be subtly or not-so-subtly financially incented to grow scope to enhance the revenue opportunity.
It is probably also worth noting that as long as the program continues to track toward success, the leaders of the program (both business and technical) are very well compensated and the company is able to attract talented players in key positions of leadership.
Additionally, that team of 100 in house developers are presumably going to have to live with their creation after it is done. Subpar quality or incomplete functional scope during the development will not be opportunities for future business, they will be failures that these folks will have to live with long after the offshore contractors have moved on to their next gig.
The key insight though is probably that all of the program leadership, business and technical, is in the same building. This is not a situation where leadership is coming from multiple requirements and program management organizations and their widely dispersed SETA contractors. All of these equivalent functions for this very large program are in one building.
It is well documented that large programs in the commercial space struggle to get finished on time and on budget and this one will face all of the same risks. But when I look at the way the DoD does similar-sized software projects the structural choices that are forced by the acquisition and government hiring practices in my view seem to push the risk past the tipping point in way too many cases. Sometimes a few key choices can make a tremendous difference.