In the first part of this article, we reviewed the concept of Total Cost of Ownership (TOC) and outlined five key variables that determine the TCO for software development projects: Process, Quality, Risk, Productivity and Cost. Each of these variables is critical to keep in mind when selecting a nearshoring or offshoring vendor. In this article, we will review the remaining three variables in depth and provide suggestions and conclusions for maximizing TOC.
Studies point to an extremely significant risk of failure in software engineering undertakings. The famous Standish Group CHAOS Report, for example, reviews over 8,000 software engineering projects every two years. The 2010 study determined that close to 42% of software engineering projects were considered challenged; 21% were considered failed, and only 37% were determined successful.
Many factors, of course, impact project risk. However, choosing an organization with a strong technical background and –most importantly—a strong software engineering process greatly diminishes the chance of failure for a project. Caper Jones supports this conclusion in the chart below[vii], ascribing a significantly lower level of risk in dealing with a CMMI level 5 engineering company. In fact, the level of risk is 20 times lower than that of dealing with a CMMi 1 corporation, or close to 6 times lower than dealing with a mature CMMi level 3 vendor).
PSL is one of the world's most experienced companies in deploying software engineering processes at the highest maturity levels. In 2002, we became Latin America's first CMMi level 5 company (and the eighth in the world to achieve such recognition). PSL has remained at the highest level of this quality model since then.
Risk mitigation is the result of correct execution on many fronts; one of the most important ones being early risk identification, so that corrective action may be taken before it is too late. Transparency is critical in order for the risk to be actively perceived, and it is a variable in which PSL excels. As a company, our policy is to provide our clients with full and unrestricted, real-time access to all project repositories. Furthermore, we monitor (at least weekly) and maintain a record of key productivity and quality variables during all of our engagements. Consequently, we are ready to take corrective action as soon as a problem arises, preventing risk to carry-forward and momentum gains.
Now, employing a strong and disciplined engineering process alone is not sufficient to mitigate risk; one has to have the right process in place. In this regard, PSL chooses SCRUM as its methodology of choice. We are convinced SCRUM provides the agility, flexibility, and team commitment (client and vendor) required to minimize project risk.
PSL is an expert in SCRUM, leading Latin America's implementation of the methodology since 2006. In fact, our company's SCRUM mentors are chosen from the best of the best, including the renowned Mitch Lacey from the US (SCRUM coach to Microsoft, Yahoo, Motorola).
One variable often not taken into account when calculating project risk under a nearshoring relationship is Churn Rate (or employee rotation per year). Chun rate in the outsourcing industry can reach levels of 20 to 30% per year, requiring expensive team re-education and causing project delays.
PSL's current churn rate is best-in-class, boasting an average of less than 6% per year for the last three years.
There are many ways to calculate the positive economic impact risk mitigation has on Total Cost of Ownership (or the extremely negative impact of its correlate, risk materialization). Although the economic cost of risk is specific to each project, we believe there is significant value in working with PSL: a vendor that, in 30 years, has never had an aborted project or a troubled initiative where the client has resorted to legal action to recoup a lost investment.
This fact, although not initially reflected in the "sticker price" of a rate per hour analysis, undoubtedly diminishes the expected Total Cost of Ownership of a solution or project undertaken with PSL.
Common technical definitions of productivity consider person-hours as an input, and either SLOC (Source Lines of Code) or Function Points as an output (a Function Point represents a normalized measure of software effort, or a unit of measure for software effort that separates software "size" from coding language).
Total Cost of Ownership depends on productivity in a straightforward manner. Here is a simplified example: Team A produces 2 units per hour, while team B produces 1 unit per hour. Team A charges $ 2 per hour, while Team B charges $ 1.20 per hour. Here, Team A is 66% more expensive than Team B. However, because Team A is twice as productive, so long as it charges less than twice what Team B charges, one is better off working with Team A. Clear enough, but how to measure this in the real world?
Luckily, Caper Jones has investigated this issue in depth. Recent productivity statistics from Prof. Jones, stated in Function Points, are as follows (they are taken from over 13,500 software projects in over 600 corporations of all sizes within the US)[viii].
Notice that the smaller the application, the higher the productivity per staff per month (which points to how hard it is to maintain high productivity in enterprise-class applications):
Unfortunately, comparatively very few companies have the discipline or process to measure their actual productivity, the reason for which statistics often turn mute. PSL is one of those scarce few that does monitor productivity.
It is important to note that productivity statistics are tricky and can easily be misleading. Producing many Function Points of trashy and insecure code might be fast, but certainly does not lead to a low TCO. At PSL, our productivity is bound by quality. We do not release code that is hard to maintain, that does not respect internal coding standards, or that is insecure. In fact, our net productivity metrics (discussed below) are inclusive of processes that filter for such type of code.
Going back to Caper Jone's statistics, the following chart establishes typical productivity ranges for different types of applications:
Within the previous context:
PSL's average productivity under agile projects is of 40 to 60 Function Points per Developer per Month. This means PSL is able to reach and exceed "maximum productivity levels", as defined by Caper Jones in the studies quoted above.
Our above-par productivity is one of the key factors establishing PSL's ability to provide an exceptionally competitive Total Cost of Ownership for its clients.
At this point, we hope to have conveyed the message that the final cost of a software endeavor –it's Total Cost of Ownership—is very much dependent on variables that go significantly beyond "sticker price". Via short but telling examples, we have underscored how process, quality, risk (mitigation), and productivity all directly impact TCO.
With this in mind, let's revisit Caper Jones and his statistics on Cost per Function Point within the United States: