I believe one of the reasons many businesses do not use the Software Development Life Cycle is due to lack of awareness that such a process exists. I have experienced this first hand from my own attempts at running projects early in my career. My first positions were in smaller companies where less formality was necessary. Those experiences with planning and running projects were for small tasks. I would do development for the solution, and I would work with at most three other people. The other technical people working on the task would test or help out in other aspects. Most decisions were made at the office kitchen table and little needed to be recorded in documents.
Once an awareness of the Software Development Life Cycle exists, the next problem is how to go about producing the artifacts that are necessary to project success. We have been given a very wide and shallow introduction to the System Development Life Cycle. This is good if you never have seen this before in your life. I have specific questions now about what is needed to be documented in each project phase. For instance, what do good requirements look like? Seeing templates or samples of existing project documents would speed an immature team’s understanding of where formality can stabilize a project and how much overhead formal process will add to the project time line.
The final possibility that may contribute to lack formal processes for development is that business management does not believe it brings as many benefits compared to the existing system of project management. The SDLC affects not only the Information Technology team, but the departments receiving and affected by the creation of an automated solution to a business problem. I found an article on the web, talking about formal methods of engineering. I think this paragraph brings some insight into the business decision of bringing formality to an existing business infrastructure:
“The decision to use a new methodology is driven by economics: Do the benefits of the new method exceed the costs of converting to it and using it by a sufficient margin to justify the risks of doing so?” [1]
[1] An Overview of Systems Design and Development Methodologies with Regard to the Involvement of Users and Other Stakeholders, SHAWREN SINGH AND PAULA KOTZ, University of South Africa