Beyond Repair: The fixed-price modelWritten by Steve Pickard
Don't get me wrong. I certainly don't think majority of vendors who use a fixed-price model are trying to rip you off. In fact, when I started my business that's way we worked—which is why we have such great insight into flaws in system. But there needs to be a transparency to work. You need to know exactly what you're getting, how long it takes, and how much it costs. You need to know that you're only paying for time actually spent on your account. And you need to know that no risk will ever be taken with your system just to maintain your contractor's profitability. The inherent structure of fixed pricing makes this kind of transparency an impossibility. Here's why:
Fixed pricing is designed to function with absolute minimum amount of human attention. The more company does not work for client, higher profit. This creates an adversarial system where caretakers fight to do as little work as possible no matter how much they are being paid.
Fixed pricing encourages wastage. Since a fixed price contractor has an hourly rate in mind - say $120/hr - then when they quote $12,000 per month, that really means that they intend to spend no more than 100 hours per month on your account. But if near end of month they have only done 20 hours, for example, then what happens to other 80 hours? Nothing. You would have received inferior services for an astronomical hourly rate and have no recourse to approach contractor and ask that they put in a little TLC.
Fixed pricing encourages increased risk. This one has a little math behind it: If a problem can be corrected in 1 hour but has a 10% chance of reoccurring in 2 months, or can be corrected in 5 hours and will never happen again, fixed price contractor will always pick 1 hour solution. Why? Imagine that they have 10 different clients with same problem. They can spend 50 hours fixing it right way for everyone, or spend 10 hours fixing them all wrong way knowing that only 1 in 10 (10%) will have a problem in 2 months (incurring another 1 hour then). Therefore, total time saved by doing it wrong way is 39 hours. A huge savings to contractor.
Now imagine if that problem has downtime or data loss associated to it. This will never factor into their profitability equation.
Fixed pricing can be deceptive as far as measure of quality. Take database administration, for example, since that's what I know best. The measure of DBA job in a fixed price model is to ensure that database is up. Performance improvement or dealing with performance decline is not even in contract. Also missing is any diagnosis of complex performance or network issues which may involve more than one piece of architecture puzzle.
Get Down With OCP: Evaluating DBA Job Applicants in an OCP WorldWritten by Robert Hamel
Not long ago, weeding through DBA applicants with a tech interview was a straightforward process. You'd ask candidates 200 or so technical questions. If they got 100 correct answers, you knew they'd been around block; 150 or more and you knew you were on to superior talent. But once Oracle Certification Program (OCP) became popular in late 90s, traditional tech interview lost its effectiveness. These days, candidates can answer 180 questions correctly and you still won't know whether they're talking from experience or simply regurgitating what they memorized at OCP a few weeks earlier. Although it has become increasingly difficult to determine whether you've found a seasoned, highly qualified DBA or a newly minted OCP Graduate, there are ways.
First, start by throwing out questions. Any candidate who has been through OCP knows answers—all of them. That list that helped you find superstar employees in past is unfortunately useless now. Second, if you are a manager without solid database experience, enlist help of an experienced DBA to help you prepare that critical interview. IT Managers have varied backgrounds and here it's important to pull from right background, be it yours or someone else's.
You also need to analyze your needs. If you're looking to hire a junior person and mentor them, OCP program ensures that candidate has been exposed to most areas of Oracle RDBMS. You can assume you'll have an employee who knows commands and has a general concept of how a database works. But if you select an inexperienced OCP candidate thinking you're getting a skilled veteran, you'll be in for countless unpleasant surprises. Typical horror stories sound like: A DBA restores backup for first time in a real-life situation, finds out backup strategy was flawed and loses whole database. S/he probably also forgot to make a backup of database before attempting recovery, therefore rendering Oracle support intervention nearly impossible.
A DBA recommends technical implementation decisions based on limited experience with a single user database that has 10 tables of 100 rows each. Of course, system hangs a few hours after launch—as soon as 10,000 users start pounding on a 500GB database.
The most damaging aspect of newer DBAs is that they don't know when they are in over their heads, or how to plan properly. Senior IT professionals, no matter their field of expertise, have a gut feeling when it's happening. They know they have to step away, talk things over with a peer, roll everything back, and try another day. Inexperienced IT professionals are fearless and can therefore be dangerous, especially if they're expected to run show.