Herosourcing: Sorcery of the future, malignancy of the present

This quick quip is a simple mark in the sand for a new principle of software development and information technology implementation. Herosourcing unlike outsourcing often is an unintended consequence, but it can be a planned obsolesence practice.

Mode 1: Widget International has a software development program. Having read “The Mythical Man Month” they know adding people to a project will simply not get their software into production. As the budget ceiling (the projected budget long past) is approached management begins firing low performing programmers. This causes a dip in productivity, but that is easily answered by firing more programmers. I know it doesn’t make sense, but trust me…. It happens. After some time approximately ten percent of the original staff is either left to close out the books, or finish the project. In some cases surprisingly the project is delivered.

Some of the reasons the project is delivered is 1) Horrendous requirements are ditched at the last minute allowing for a requirements derived product to be delivered; 2) Systematically impediments have been removed; 3) Staff that was on the project had the wrong skill sets and the refined team was able to balance out better on assignments; 4) Smaller teams coordinate better and poor performing programmers having been weeded out led to higher/better productivity without issues.

Thus you have Mode 1 of herosourcing. You wasted a lot of money on over vaunted, horrible requirements, and bloated specifications that were paired down to what should have been the original project. But, you still ended up with a cadre of heroes to finish your project.

Mode 2: There are a few myths lauded as metrics thrown around the software and information technology industries like the 80-20 rule and 90-10 rule. They are refined as follows. It will take 10 percent of the time to accomplish 90 percent of the project and 90 percent of the time to accomplish 10 percent of the work. In other words that last ten percent is going to be fairly tough to accomplish. The graph would be a classic hockey stick graph. Now. The 80-20 rule being much more generous suggests that 20 percent of your day/staff/week/project is actual productivity whereas the other 80 percent is facebook and Farmville.

We implement knowingly Mode 2 by slashing the team to 20 percent of the original required staff, slash the requirements by 80 percent, know that when we get about one tenth of the way into the project we’ve likely hit a stonewall on productivity and we start slashing staff at that point. This mode really requires a captain Blye mindset. One thing we can do is fire all of our programmers, hire back the heroes at substantially higher pay, and hold them to a productivity number by contract you could never expect from employees. By scoping the project so the desired goal is within the first 90 percent of production you can save a lot of money.

For herosourcing we know that in most organizations about 10 percent of the population does around 90 percent of the work (there it is again). What herosourcing does is plan for that productivity gap and source based on it. This is definitely not a project management method for the light hearted. But, I have seen it used all over the industry on dying projects. It is strange to talk about it this way, but it is what happens fairly often. Have some fun with the idea. Let me know what you think maybe I’ll develop it more or refute it.