I typed the initials "SDLC" into Amazon.com's Books section and got 257 hits for books that at least mention SDLC or Software Development Lifecycle. So, maybe 257 or so authors and their readers aren't going to agree with me when I say do not waste your time documenting, developing, or devising in any way, shape, or form a software/systems development lifecycle. Fahgettaboudit!

A quick look at Wikipedia and at least one understanding of SDLC is project planning and feasibility, systems analysis and requirements definitions, systems design, implementation, integration and testing, acceptance-installation-deployment, and maintenance. Project planning is a laudable goal. Requirements gathering is a necessary step. Actually designing software is important, too. I am not advocating that you not employ an SDLC; rather what I am saying is that you not take the time to define or document one internally.

If one knows nothing about SDLCs, then embarking on a software project is probably not a workable idea. However, if building software is your business, then what I am touting is that you adopt an existing SDLC that fits your situation.

Better than documenting an SDLC, better than using an SDLC, is to assemble a team of specialists that know their roles from an expert perspective. For example, if I hire a project manager that really knows how to manage a project, then no one needs to tell this manager that they need a plan, what goes in a plan, and when a plan is sufficient for a given situation. If I actually hire a business analyst, then that analyst knows how to talk to customers; and an architect knows how to actually design a solution taking risks, costs, and schedule into account.

The reason there are so many books on SDLCs and such is that projects are not comprised of specialists. There are way too many generalists in our business. Our business is top heavy with programmers and project managers, so an SDLC is created or adopted to tell the programmer how to play analyst, designer, or tester. If we had more specialization, then we wouldn't be spending time on writing coding standards and requirements gathering how-to guides.

SDLCs? Fahgettaboudit! What you need are people who know and are passionate about their roles and tasks, who know how to do them, and who really know what to do and when. When teams start to look like hit squads of expertly trained specialists, projects will start having better dependability and delivery rates.