Successful Software Projects 301, Page 2
Avoiding Risk Factors
Any colour, so long as it's black.
If you simply abide by Canons #1 and #2, a very large part of the battle is won. The problem is that very few projects slavishly adhere to these concepts: high value, high risk first and assertive challenges scope creep.
If you follow Canons 1 and 2, Canon 3 will follow. If you diligently avoid these risk factors, your chances of success will be very high indeed. Here are the risk factors to avoid (that comprise Canon #4, avoid more than one or two significant risk factors):
- Avoid a brand new team
- Avoid a new language
- Avoid new technologies
- Avoid a distributed team
- Avoid outsourcing the primary deliverable, the code. (You can outsource technical writing, first round testing, help documentation, art work, basic CRUD of stored procedures, and defining test data.)
- Avoid projects that exceed previous success thresholds
- Avoid obviously tight schedules
- Avoid a heavyweight process, no process, or flavor of the month/year processes
- Avoid a dependence on heroic effort or more than 40 hours per week of work
- Avoid projects with no clear, ardent, and powerful sponsor
Assess your project against these risk factors. Very simplistically, think of each factor as an additional 10% likelihood of failing. So, if you have three of these risk factors you have a 30% chance of failing. If you have seven of these risk factors, you have a 70% chance of failing. (If you have five or more of these risk factors, you'd be better off taking your money to Vegas.) In all likelihood, more than two or three of these risk factors and your chances of failing catastrophically are very high.
Failure is missing time, budget, or features significantly. Catastrophic failure is cancellation of or removal from the project (or something worse).
Canon #5 is a risk factor and its own rule. Canon #5 is never ever outsource the primary deliverable, the code. If you can't do it yourself, what is the likelihood that cheaper labor or people speaking another language will be able to figure it out any better across time zones, and cultural and language barriers? I will even go so far as to assert that the US is still the technology center of the world, and we have trouble consistently and reliably delivering based on time, money, and features. What is the likelihood that somewhere else someone has invented a magic wand that makes them more reliable and that we haven't heard of that magic wand? Zero.
Do I mean that they can't build software in China, India, or Russia? No; of course they can. Is it substantially better, cheaper, or more reliable and consistently so than in the US? No. There is some very good software written outside of the US, but the process is universally questionable, and so consequently is willy-nilly outsourcing.
Canon #6 is to get very detailed requirements in writing. Programmers know how to program. The problem usually is what to program, and that is dependent on requirements. If you don't have detailed, written requirements, the customer's need will be lost in translation.
|Identify the ten or twenty most valuable or challenging problems—depending on the size of the project. If these are in place, and there is universal agreement that they are complete, you are in pretty good shape. If there are glaring gaps, ask "why isn't that piece done," "am I worried about it," and "how much does it worry me?" If the missing gaps worry you, the risky bits haven't been aggressively tackled first and the project is probably in trouble.|
Budgeting for Every Budget
It is not the employer who pays the wages. Employers only handle the money. It is the customer who pays the wages.
If you have made it this far, I would argue that your chances of succeeding beyond any objective standard are exceedingly good. Rigidly adhering to Canons 1 through 6 will give you a 9-in-10 chance of success, a presumption that can only be demonstrated not proven, but I believe it. The last step is to figure out ways to budget your endeavors. If you pick the right type of budget, you will almost assure your success and your customers' satisfaction.
Basically, writing software is a little like house building. Everyone knows basically how to build a house and what a house is, but every house is a little different. Software is different in that every software project is a radically different kind of house. Some projects are dog houses, some are sprawling ranches, some are Bucky domes, some are sky scrapers, and some may be radically different like a dwelling in space or one undersea. The fact that you will be building a one of a kind something once and for the first time means that any estimates of time and money will be guesses at best. However, the simpler the project or the more consistent a project is with something you have already delivered, the better your guesstimates will be.
To wrap up, I have included several kinds of budgets. Each has a brief explanation and they are listed in the order in which they are likely to help assure success. Canon #7 is pick the correct budget model, and Canon #8 is that optimism is a desirable feeling; realism is an assertible fact.
When you go to a big city and get in a cab, there is a charge. For every portion of the ride (usually 1/8th of a mile), there is an additional charge. In the taxi cab model the meter is running, you can ride anywhere you like for as long as you'd like, and eventually you will get there.
The taxicab budget is the singularly most reliable budget in the world. The customer gets the software they are willing to pay for and the vendor gets paid for all the work they do. Of course, as you know, if you take a cab from New York to Los Angeles it will cost you a small fortune, but you will get there.
The downside to the taxicab budget is that the customer can't know the total cost at the outset, and the vendor can't make ridiculous margins by delivering in a fraction of the time. In the taxicab model, most of the risk is weighted toward the customer.
The next best budget model is "paygo." In this budget model, you pay only for each phase—like analysis, planning, design, implementation, and testing. The key is to fix the time and budget for each phase based on the previous phase. At the end of each phase, you ask: Do we have enough information to proceed, should we cancel, or do we need more time in this phase?
If the answer is to proceed, you fix the time and budget for the next phase. If the answer is it's a loser, cancel. If more time is needed, you repeat the current Paygo step. Fix the time and budget for the repeated phase and repeat the phase.
The problem here is that you still may not know how much money you will spend all in (or how much you will earn, vendor), but what you have done is acknowledge that you are collaborating to build something that is brand new in the world and there is no way anyone can accurately figure out how long it will take to build such a thing from beginning to end, up front. However, if you come up with a set of requirements, you can say that "based on these 100 requirements, I/We are willing to spend x-dollars and x-months to figure out a sound strategic way to proceed" and so on.
In Paygo, you will have to repeat some steps. Repeated steps are things no one knew about until they knew. No one is responsible for that, so the logical response is to repeat the phase and pay-as-you-go for a fixed time and amount additional times until you can reliably make one of the three possible choices.
No one—not Bill Gates, Steve Jobs, or anyone else—can reliably figure out how long it takes to invent something brand new in the world. The logical and fair conclusion is then that the process should be fair and equitable for all parties. Customers should get what they are willing to pay for and vendors have to make an honest profit; anything else is chasing fool's gold.