The One Ingredient Every SDLC Process Needs
A sound SDLC process relies on requirements in some form or fashion. Agile has taken the software development world by storm, and that has brought many benefits. However, many have lost sight of some fundamental realities of how to reliably deliver project success.
All products exist for a reason. A software development project will be valuable because the software solves a problem or leverages an opportunity.
There should already be a business case for why a product is being developed, and this will outline that problem and/or opportunity and the potential value of the product. With the problem/opportunity defined, the Solution Architect can define what is necessary to solve/leverage it.
This alone can serve as the foundation for the entire project charter. From a well-defined solution, you get the necessary tasks to deliver the solution. Once you have the tasks, you can map the skills needed, which will serve as the basis for the people and effort necessary to perform the project. It takes a solid, detailed approach to the problem to set roots strong enough to support everything that stems and branches from that.
Not everything needs to be set in stone. There are Must-haves and there are Nice-to-haves, then there are completely unforeseen benefits that can come out of the development process. But at the very least, the development team needs some idea of what they’re developing and what basic parameters it needs to meet.
With a foundation in place, the collaborative framework, velocity of sprints, and/or number of iterations can take any number of forms. But the front-end of the SDLC process is too valuable to gloss over too broadly.