SDLC vs. Project Execution Process
By Jason Becker
This one seems like such a no-brainer that we don’t even need to discuss it. So, why post it then?
Because I still encouter people on a regular basis that discuss Software Engineering in the context of Project Management who fail to make the distinction between the Software Development LifeCycle (SDLC) and the Project Execution Process (PEP).
This failure to recognize the larger process has a litany of perils associated with it and it deserves some discussion as a way to put the PEP back in the Project Driver’s Seat.
No Matter which SDLC your company or team has embraced it is probably safe to say that it is a set of processes and procedures that govern the way in which we develop software products and ultimately deliver them to their customer or sponsor.
Whether it be Agile Methodologies, Waterfall, or Spiral methodologies, the mechanics may be very different but the goals, objectives, and overall outline remain similar. Plan, Design, Develop, Test, etc.
There are many different variations on this theme but most Project Execution Process maps have a “beginning”, where the products or services are brainstormed, a “middle”, where the products or services are developed, and an “end”, where the product is ultimately delivered.
Initiate, Plan, Execute, Deliver
Again, a no-brainer.
The problem occurs when someone involved in the SDLC views the project as “Complete” when the software product is delivered. An even bigger problem occurs when the Project Manager makes this mistake because the entire project or program is jeopardized when those responsible for “The Project” take the view that “The PRODUCT” is “The Project”.
What’s the Difference?
In short, the difference between the two is the level at which you focus on deliverables. For example, while the SDLC requires that we Plan, Design, and Develop, most of those activities actually take place within the “Execution” phase of the PEP. So, why does SDLC “Planning” take place in the “Execution” portion of the PEP and not in the “Planning” portion?
This answer lies in the true understanding of Project Execution instead of in the imagined nature of Project Management.
For example, there may be a great deal of prework that goes into getting approval to begin a project and get budgetary approval. So “Initiating” in the PEP speaks to gathering the necessary approach documents, approvals, impact studies, and the like. One could argue that you could start Planning the software engineering portion of the project at this time, but if you do that you run the risks that the budget could be refused or that the project simply doesn’t survive the first Go/No-Go decision.
In the context of the PEP, the Software Engineering Team would not be engaged until after the necessary funding has been secured and the project is already on the strategic roadmap.
Further, in the “Closing” portion of the PEP, there may be a rather involved process by which the product is delivered and aftercare undertaken to which the SDLC is oblivious. Contracts that require closure, marketing endeavors that must cease, post-mortem PEP activities, etc.
So, while some people tend to think in terms of the PEP and the SDLC as one in the same, it is more accurate (and safer!) from the Project Manager and Leadership perspective, to consider the SDLC as simply a set of critical activities that takes place during PEP “Execution”.
I am certainly not telling you that someone doesn’t need to manage the SDLC as a project, I am simply telling you that it should be part of our jobs to make sure we can see above the here-and-now and think in much broader terms for greater Project Success.
Jason Becker, PMP, CPM, has 14 years of experience in designing, developing, and deploying Enterprise-Level software products for the Banking, Manufacturing, Real Estate, and Information Technology industries. He is an expert in Project Management surrounding Software Products Development with an emphasis on disciplined delivery techniques and visionary software development methodologies. He is an experienced leader with skills in IT PMO setup and management and strategic IT projects alignment. Jason’s website can be found at http://axisitconsulting.com/ and he can be contacted at email@example.com.