Staying on Schedule
You can learn how to better predict the time needed to develop software. Do your projects progress just like the project schedule and budget require? There are many reasons why IT software development take longer than predicted. It may be partly due to a poor understanding of the typical pitfalls of software development life cycles. There are many steps in any custom development process. How do you know if you have identified all the use cases? Have you spoken to all the users? Have you looked at all the existing reports and traced their contents back to the source? How can you plan for the inevitable change which will creep into the data and the processes?
Now consider for a minute another sort of a building project. Have you ever built a custom house? Think of all the decisions that have to be made - floor plans, kitchen cabinets, plumbing fixtures, bath fixtures, lighting, flooring, paint colors, door hardware, and landscaping just to name a few. If you want a specific result, you can't tell the builder I that you don't want to make these decisions. You can't say that you are too busy to answer their questions. You have to give them detailed specifications, unless they are the 'Property Brothers' and they excel at guessing at what you like and need. The more detailed the specifications, the less they will have to come back to you and ask you to make choices later. The more you answer their questions, the more closely the end result will suit your needs.
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 several of these issues are not anticipated until it is time to write the actual computer programs. Then the computer programmers suddenly have a lot of questions. 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 counter top. The contractor has to ask 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 be able to see only a very small part of the entire system. The software you see is only the tip of the iceberg compared to all the work that was done to build the system and implement the functions to which the User Interface connects you.
Common Software Life Cycle Problems
software life cycle problems generally fall into four categories:
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 need and how to explain 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.
- It takes a lot longer to get the last 8% right than was anticipated. Why? Your requirements definition phase was not completed properly. Or you were under staffed, or over budget, or your requirements are changing too quickly.
- 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 inconsistent reference data is a HUGE problem.
- 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. XML and SOA have emerged as answers to this problem. But SOA has it's limitations as well as its cost. If the client can't communicate their data requirements on an enterprise level, a great deal of research has to be done. The larger the enterprise, the larger the cost is.
Why software projects are late:
- The cycle of error reporting and bug fixes 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 exactly what they are doing when the problem occurred. Their perception of the various problems is often distorted out of proportion by their emotional reaction to it. Address concerns immediately to put them at ease. Explain what is a simple fix and what is not simple.
The technical people can not stop 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. In 33 years, I have never seen a physically scattered project staff pull off a satisfactory implementation. Why is this? There is more than one reason. First of all, people make 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.