Skip to content.


Home » Resource Center » Real-World Decision Support (RWDS) Journal » RWDS Archives » Volume 1, Issue 27 - April 2005 » Waffa Karkukly: Resolve the SDLC and PLC Conflict?

Waffa Karkukly: Resolve the SDLC and PLC Conflict?

By Waffa Karkukly


In my January 2005 article, I went through the PLC model and SDLC model. I have highlighted issues and conflicts that take place within some organizations regarding who runs what framework and which framework these organizations should adopt. At the end, I offered what I called a solution or a new framework combining both SDLC and PLC showing that there is no conflict if each of the models is to perform what it was intended for to perform.

Both PLC & SDLC have their different sets of deliverables that need to be fulfilled to build a successful project and a successful software development engagement. While there are similarities in some inputs and outputs, there are more differences that make each model a unique one. In this article, I will cover the inputs and outputs in each model, and the control/support elements that govern PLC and SDLC

Unified PLC and SDLC Model

Refer to Figure 1 for PLC and SDLC process alignment. An organization can unite efforts to benefit from best practices in the industry from both PLC and SDLC. Each of these processes is governed by almost unique sets of inputs, outputs, and gates that govern the dynamics and handovers of these inputs and outputs. Two important elements in particular that stretch across each model are control for PLC and support for SDLC. I will provide details on what I mean by these 2 elements and the role I see them playing.

Figure 1:- Aligned SDLC & PLC

Image 01

PLC & SDLC Inputs and Outputs

Refer to Figure 2 for PLC and SDLC inputs and outputs. There are some common inputs that need to feed into both processes (i.e. the company’s mission and vision), and there are distinctive inputs and outputs that identify each process uniquely. The expectation of these inputs and outputs are that they must be fulfilled for next stage to occur. An output of a process must be completed if it becomes the input into the next process. Dependencies make a huge impact on the overall process if there are delays in completion, or quality is not as expected.

Figure 2:- Inputs and outputs

Figure 2 Inputs and outputs

Similarities and differences

While a company’s mission statement and objectives are one of the main inputs in the early stages in both models, clearly the outputs are different. In the PLC it results in the project scope document and in the SDLC it results in the business case and preliminary requirements. For some organizations the above might be the same or described in one detailed document. While in other organizations, the above will result in two similar outputs, one addressing the building of the product (the SDLC output), and the other (the PLC output) addressing the project scope, and establishing project boundaries (inclusions, exclusions, etc).

On one hand the inputs are different in the last stages between closing in the PLC and evaluate post release in the SDLC, whereas clearly the outputs are very similar. In the PLC, lessons-learned is performed to determine success of the project and learn from the mistakes and establish historical record. On the other hand, the SDLC evaluating post-release process is to determine success of the current release and establish process and defect improvements. They are both similar in taking a current picture and assessing the outcome to plan to improve similar and future engagements.

Control for PLC and Support for SDLC

Why is control important in PLC? Without control the triangle scale tips (Scope, Time, and Budget). There is an element of balancing the competing changing priorities among the three parameters that will only be balanced through project control. Project control is one of the process groups that get repeated with other processes. There is an element of planning and control, another element of execution and control. Successful PLC will control the planning and the execution to drive to the desired outcome of the project. Without control, the project team will not be able to determine the health of the project or establish a baseline for measuring the quality of their deliverables. Control will allow the project manager to monitor each process area as well as the entire project to identify problems early on, assess them, and take appropriate action.

Why is support important in SDLC? I would like to clarify what I mean by support here. It is not the maintenance phase that comes after a product is deployed, it is the on-going support that other entities within the organization provide each other for a phase to be complete. It is very important because software product development is not done in isolation - even when following a waterfall approach, there is an element of all functions needing to operate smoothly to ensure timely product delivery within scope and budget; hence, making customers satisfied.

For example if the phase of work is in development, other functions such as infrastructure should have provided what is required, and be available to assess any infrastructure issues. Another example is if the phase of work is in development and validation is required from the previous function phase architecture; in addition, to such verification should be documented and formalized, the Architecture department should provide the support required and not consider that since they handed development of the design, it is no longer their responsibility to go and re-assess. Re-assessment by IVV will be much better than development making an assumption and proceeding based on development’s understanding - and missing an opportunity to confirm with the Architecture.

More important in support of individual function which sometimes gets into the quality of the reviews and handovers and it is different in every organization; there is a more important element of support and that is organizational support for each of the SDLC processes to ensure appropriate resource availability whether it is skill sets, man-power, infrastructure, decision making, and future vision that drives the overall support; hence, the individual support for each of the process elements.

About the Author

Waffa Karkukly is the Manager of Enterprise Technology at Deloitte & Touche Tax Technologies. She is a project management professional, PMP certified, and dedicated to improving the understanding and standards of project management. She specializes in managing enterprise-wide initiatives in multi-disciplinary environments. Her recent focus is on planning and implementing customer relationship management (CRM). Waffa can be reached at