The Last Ten Percent

The 90/10 Rule: “90% of the work gets done in 10% of the time” and its corollary: “10% of the work takes 90% of the time.”

In computer programming and data migration projects, you also have the humorous aphorism that says: “The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time.”

— Tom Cargill, Bell Labs

Perhaps one of the most common problems encountered by management when trying to get a project over the finish line is what to do about the last ten percent. You know what that is. It’s the time in the development lifecycle between “substantially complete” and “Deployment-ready.” It’s the part you know is coming; there are so many jokes written about it that they have gone from humor to ubiquity. But why does it happen and what can we do about it?

It’s likely that you’ve been conditioned to do the easiest parts of any task first. It’s a common test-taking strategy that you probably learned by High School and it served you well… then. You start off by doing the problems on a test that you know well, and then go back to pick up as many time-consuming problems that you know will suck the life out of you. By taking a test this way, at least you get credit for the 90% you knew already and hope for the best on the rest. Ninety percent is still an ‘A’, right? Problem solved.

Or is it?

By conditioning yourself to approach problems this way, you can sometimes get into trouble when the real world doesn’t align with test-taking. In the software and data migration world, deployment usually demands 100%. Even so, you still want to avoid that last 10% for a number of reasons:

1. It’s scary. We all fear the unknown and the last 10% is usually the part you’ll put off because you don’t know the answers. You know it is probably going to require skills you don’t have yet and you don’t know how long it’s going to take to get them, or what it is going to cost.
2. Over-commitment of resources. As a project progresses, the entire assigned staff has already been assigned to other tasks, some important, some not so much. And, as your project drags on, management is likely to “beg, borrow, and steal” your resources for other projects. You are always faced with deciding who gets pulled to do the last 10%. It’s a pain, but somebody has to do it.
3. Surprises. Since no one on your team knows, specifically, how to do that last 10%, you are likely to run into methods and constraints that you did not expect. You simply were not able to anticipate what you did not know was coming. Yikes! Pretty risky.

If you are a contracting house, you know you are not going to get paid (and get a good reference) if what you deliver simply meets what is written in the Requirements Document. The Requirements Document is rarely 100%. But the client is not going to deploy a “substantially finished” product to a production environment.

If you are an in-house development manager, you have a similar problem: You cannot deploy a product that “mostly” meets expectations. It does no good to waste everyone’s time deploying a system that no one is going to use, even if it matches the specifications in the Requirement Document. And it’s hardly likely to lead to career advancement (in fact, quite the opposite!). So, what can you do to make sure you don’t become the “joke?” It’s actually pretty easy.

Step One: Assume no float.

In Critical Path project management, a task is determined not just by how long it will take someone (or a team) to do it. It’s also relevant to determine when something is needed by before it begins to affect the delivery date of the entire project. The difference between those two things is called “float.” Unfortunately, human nature dictates that, if we know we have any float time in a task, we will usually procrastinate beginning it until we have used up all of our float time. Once there is no more float, the task becomes critical, meaning that if it “slips”, it will impact the finish time of the entire project. Spoiler: It usually slips. By simply scheduling by task duration and assigning a start date, you are telling the programmer when they have to start. Is there float? Probably, but don’t start by building it in. You are going to need that float for the last 10%. (In Critical Chain Project Management, this is often done using “buffers” and creating both resource and task constraints.)

Step Two: Identify the tasks you believe represent the skillsets you do not possess and the time you do NOT have at the BEGINNING of the project.

Of course, you will need to not only be honest with yourself, but you will also need to know the truth about your staff. Case in point: On one complex migration job, a senior-level manager hired our company to help his staff finish the last 10% because they had fallen significantly behind schedule. They were struggling to understand how all of the pieces fit together because the datasets and methods were unfamiliar to them. When the manager introduced us to his full-time staff, one of the query writers was quite miffed, and blurted out, “We don’t need these guys! We can do this stuff ourselves.” Our project lead’s swift but courteous reply? “Then, why haven’t you?” Crickets… until the manager said, “Let’s get to work!”

Step Three: Determine up front whether or not it is cost-effective to bring in someone from outside of the organization that specializes in the skillsets you know you don’t possess.

This one is tricky because you don’t know what it SHOULD cost, and often, you don’t know if you will be able to choose a vendor that actually has the skills you lack. They could blow smoke at you and you wouldn’t know the truth. You’re not the expert, they are (or at least they claim to be). How do you know you can trust them?

Choose a Well-Referenced Specialty Firm Over a Large One

Once you’ve decided it would make sense to bring in some outside expertise to finish off the last 10%, you will be tempted to go with what you think, at first glance, is the safe option. Often, you’ll go with a large firm because you have heard of them before. You resign yourself to paying exorbitant hourly rates because, hey, they are in the right Gartner quadrant, right? But, if ever there was a case where size doesn’t really matter, this is it. What you are looking for is a specific skill set, targeted toward a specific problem. Sure, the large firm likely will be able to solve your problem, eventually. But ask around and you’ll find out that specialists don’t often work at big firms. Real specialists typically work at specialty firms. And it’s not that hard to find out if a firm is going to be able to perform well for you (regardless of their size). Just do a few reference checks and find out if a.) they have ever done the type of work (specifically, and successfully) that you are looking to do, b.) do they deliver what they say they will deliver, and c.) did it cost what they said it would cost, without a lot of hassle and change orders? References DO matter. Make sure they are willing to stand by their work without a lot of finger-pointing. To illustrate: We have a large, diverse, conglomerate customer on the U.S. East Coast that had a particularly sticky problem to solve but couldn’t figure it out (the last 10%). They hired one of the largest consulting firms in the world at top dollar to help them but, after two years of trying, they were still coming up empty, with each side blaming the other for the lack of clarity. They had heard about our firm from another large utility company (one of THEIR customers) and they gave us a call. They started the conversation with, “We have a particularly difficult problem that database experts haven’t been able to solve for the last two years. We’ll open a P.O. for two months using your standard rate. How fast can you get someone out here?” We sent one of our most creative analysts and expected him to be on the project for at least a month. Within a week, he called and asked us what his next assignment was. “Is there a problem?” we asked. “No,” he said, “the problem is solved. They just needed to view it in a specific, non-traditional way.” A problem that had vexed the client for two years (and likely cost them hundreds of thousands of dollars) was solved in one week. The I.T. manager took a failing, cost-overrun project and turned it around completely.

So, which service provider turned out to be the bigger risk? The large, traditional consulting firm that charges very high rates, or the smaller specialty firm with more creative solutions?

So What?

The importance of successfully completing the last 10% without huge schedule delays and cost overruns (or worse, a failed project), can mean far more than lost money and embarrassment. People lose their jobs over the last 10% all the time. Entire careers of those that took what they thought was the safest route litter the corporate landscape. Consider the case of a large U.S. energy provider who attempted to move to a new project management system to more closely align with their ERP system. They were a publicly traded company with a big problem: Their project cost data did not match with their ERP system of record, the one that they used to report data to the SEC and investors. They brought in a large team of highly paid consultants and experts from a large firm to manage the migration to a new system. After three years, $20 million over budget, and NO working system, they put parts of the project back out to bid, including the most important part: the migration of an older Project Management system to a new one. Our company maintains a specialty practice that manages the complete migration process between the two project management systems being considered. We won the contract and completed the project ahead of time and under budget. But the story doesn’t end there. Virtually the entire in-house project team received promotions and raises as a result.

If you are contemplating a new software development, data migration, or even a metrics project, consider using a specialty house for that last 10%. It could save money, time, and your career.