Is your project behind schedule? You can learn how to better predict software schedules. You may be wishing now that your projects progressed like the paper charts predicted. There are many many reasons why software development can take longer than predicted. It may be due to a poor understanding of the pitfalls of software life cycles and development. There are many more steps in the development process than the development of cases and the implementation of functions. How do you know if you have identified all the cases?
Now think for a minute of another sort of an implementation. Have you ever built a custom house? Think of all the decisions that have to be made - floor plans, kitchen design, bath fixtures, lighting, flooring, door hardware, and landscaping just to name a few. You can't tell the builder I don't want to make these decisions - just give me a house in six months. You have to give him detailed specifications. The more detailed the specifications, the less he will have to come back to you and ask you to make choices later.
Working with a building contractor is a lot like working with a software contractor. There are many design decisions which must be made at a low level. Often many of these decisions are not anticipated until it is time to write the actual computer programs. The main point is that even as a system is being implemented, these mini requirements discussions must continue to occur. The time required for the working out of these additional design details during the implementation phase is usually underestimated. Let's go back to the example of building a house. The builder knew you needed a kitchen faucet, but probably doesn't know how many holes you need drilled in the countertop. The contractor has to ask exactly which model kitchen faucet you want. You then need 3 days to pick out the right faucet. So there is a delay as the buyer makes this decision.
Unlike a building which one can walk through, when the software product is done the user will end up being able to see only a very small part of the system: the user interface. This is the tip of the iceberg really compared to all the work that was done to implement the functions that the user interface runs.
Software life cycle problems generally fall into four categories:
The requirements definition phase takes much longer than expected:
| Your estimation of the time needed for requirements definition will be only accurate if: |
Your client has been with the organization a long time and knows exactly what they want and just how to tell it to you. |
You have already implemented a similar project for this same client. |
| You are using technical tools and hardware with which you are already familiar. |
| You already have a trained staff in place. |
| You are using design tools with which everyone is familiar. |
| The client has an organized and standardized set of procedures in the real world for the services or products they provide. |
Implementation reaches 95% complete, and stays at 95%:
| God is in the details |
| It takes a lot longer to get the last 5% right than was anticipated. Why? Your requirements definition phase was not completed properly. Or you were under staffed, or over budget or .... |
| Your client did not inform you about the exceptions to their rules. "Oh yeah, that office does things differently, they do not use a transaction code. They have their own codes blah blah blah..." |
| The test data they gave you does not cover all the circumstances you will encounter in the real data. The real data had no quality control measures in place. |
| You have the unfortunate task of implementing a data base which tries to merge the functions of very different organizations. None will yield their way of doing business and no one can order them to change. Note: People are put in different organizations for a reason - they have different functions - that's why they have different data! You can not perfectly merge all the data. I call this: The Myth of the Interdepartmental Data Base. XML and SOA have emerged as answers to this problem. But SOA has it's problems as well, such as cost, thoroughness, and accuracy. |
Not enough time is left for testing:
Why software projects are late:
| We have bugs! |
| The cycle of error reporting and bug fixes, ( er, alteration of software features), starts in earnest. |
| Set a goal: move the project out the door! |
| Focus on the solutions, not on the problems. |
| Non reproducible bugs are found and can't be diagnosed. Do not let your client diagnose the bugs, only let them report what they are doing when they happen. Their perception of problems is often distorted out of proportion to the effort it will take to fix it. Address concerns immediately to put them at ease. Explain what is a simple fix and what is not simple. |
No time or money is left for 'as built' documentation:
| The technical people can not stop working long enough to talk to the documentation people. |
| As a result, your documentation staff must have enough technical knowledge and real world knowledge to figure out what the system actually does. |
| The staff knows that the user will not read the documentation and are unmotivated to produce it. |
| The budget is already spent for the project and no money is left for documentation. |
| The documentation is not done is enough detail to be useful to future technical people. |
| Not even your own project staff works in the same building and as a result,
meetings which uncover old information are not happening. Warning! In 27 years, I have never seen a scattered
project staff pull off a satisfactory implementation. Why is this? There is more than one reason. First of all, people are making different assumptions with out realizing it. The different assumptions are not discovered until the software is initially delivered. Secondly, the required communications are not happening frequently enough. Thirdly, people who do not see each other on a regular basis, are not as motivated to perform. |
| The documentation is not kept updated as the project matures after delivery. |
Author Jackie Mulrooney President J P Systems, Inc. "The Art of Predicting Software Schedules" |
Back to Main Services Page