| "Remember, it's Ready, Aim, Fire; any other | | | | project. Instead I advocate more time spent |
| sequence is counterproductive." | | | | in the early phases for better clarity of |
| | | | requirements definition and for producing |
| - Bryce's Law | | | | better specifications for the programmers and |
| | | | DBA's to follow. Under this scenario, I see |
| Having been involved with the systems | | | | as much as 60% in the early phases involving |
| methodologies field for over 30 years I have | | | | systems analysis and design, 15% in |
| been occasionally asked what percentage of | | | | programming, and 25% in implementation and |
| time in a project should typically be devoted | | | | review. You heard right, 15% in programming. |
| to a specific phase of work, for example a | | | | Why the disparity? Simply because programmers |
| Phase 1 Feasibility Study, Phase 2 Systems | | | | have long suffered from the lack of decent |
| Design, etc. Basically, the reason the person | | | | specifications and end up spinning their |
| wants to know this is to use it as a means | | | | wheels over and over again trying to deliver |
| for estimating the remainder of the project. | | | | what is needed. But if you concentrate on |
| For example, if I were to say Phase 1 | | | | better specifications upfront, the guesswork |
| represents 10% of the overall project, they | | | | is eliminated for the programmer. |
| would simply multiply the amount of time | | | | |
| spent in Phase 1 by ten. This is an | | | | Some people consider the upfront work to be |
| unreliable approach for estimating which is | | | | somewhat frivolous, that the "real work" is |
| why I usually balk at giving out such | | | | down in programming. I don't know why this |
| figures. | | | | is, perhaps programming is more tangible |
| | | | since screens and reports can be visibly |
| Systems development projects vary in size | | | | shown to people. But I do not subscribe to |
| from large to small and although statistics | | | | this notion, and believe the vital work to be |
| should certainly be maintained, I still | | | | in the early phases, but then again, I am |
| consider this an erroneous approach to | | | | considered a dinosaur by the "Agile" |
| estimating. Instead, I recommend basing an | | | | methodology people. Regardless, if you have |
| estimate on a rough design of the product to | | | | to build anything of substance, be it a |
| be built (the system), including all of its | | | | bridge, a skyscraper, an automobile, or a |
| pieces and parts, such as inputs, outputs, | | | | system or a single program, you have to do |
| files, records, data elements, etc. Some of | | | | your homework first, otherwise you find |
| these components may be reused from other | | | | yourself constantly tearing things down and |
| systems, some may require modification, and | | | | rebuilding them over and over again. If we |
| some may be entirely new. This is called | | | | built bridges the same way we build systems |
| estimating based on the system's "Bill of | | | | in this country, this would be a nation run |
| Materials," a simple concept derived from | | | | by ferryboats. |
| engineering and manufacturing. Even if a | | | | |
| project only involves a single program (as | | | | One last word on applying percentages to |
| opposed to a major system), I would still | | | | project estimates, the danger here is that |
| examine the types and number of components | | | | you might calculate you are 90% complete; |
| affected by the assignment. | | | | inevitably you will discover the last 10% |
| | | | will take forever. So, my recommendation is |
| Having said all of this, let me give you my | | | | to avoid the percentage trap and consider the |
| spin on the proportion of work in the typical | | | | Bill of Materials you are going to work on |
| systems development project. I have seen many | | | | instead. |
| companies skip through the early phases in | | | | |
| order to get to the programming phases which | | | | If you would like to discuss this with me in |
| is considered the important work. Under this | | | | more depth, please do not hesitate to send me |
| scenario, programming represents 85% of the | | | | an e-mail. |