Process Improvement

Please login or join to subscribe to this thread
Can I get input as to what differentiates a Project Management Lifecycle from a Software Development Lifecycle. My company is currently in the process of developing project management methodologies (the company has been around for many years but is very new to project management)- these methodologies will need to tie into the Business as well as the IT departments. We have done both "basic" project management and software development project management. So we continuously have discussions and differences of opinions regarding the PMLC vs SDLC. Do they share a common thread or are they two completely separate Lifecycles?
Page: 1 2 next>

All IT projects begin with the Project Management Life Cycle which at a later stage converges with the System Development Life Cycle.

The Project Management Life Cycle (PMLC) begins in the Project Initiation (or Pre-Planning) phase and extends to the Planning tasks in the Planning & Design phases. These phases require a copious amount of preliminary work to be done before a project begins. The quality of effort and thoroughness applied in completing these tasks will determine a project's destiny. Project completion on time, within budget and meeting customer expectations can all be foretold by the quality of work done during these phases. It is therefore important that the role of these phases in the overall success of a project not be downplayed.

With that said, the Anonymous question should be focusing on establishing a PMO for all project types, not just IT.

File attached.

I like to divide and conquer and so think of the PMLC and SDLC as two concentric circles/cycles. The inner cycle is the SDLC which represents the IT work (i.e., need/problem analysis, requirements analysis, architect/design, etc.). The outer cycle is the PMLC and represents the PM work (i.e., scope mgmt, time mgmt, cost mgmt, risk mgmt, etc.). The PMLC bounds the SDLC. The SDLC work is excuted sequentially by SDLC phase. The PM work is executed repeatedly on top of each SDLC phase. Check out my website ( for a more detailed explanation.

Typically the product development process is decomposed into major activities to achieve specific objectives by phase (or stage), culminating in the end goal. Two of the most popular process diagramming methods to represent this kind of information are IDEF0 and Rummler-Brache. IDEF0 emphasizes the activities of an enterprise, whereas Rummler-Brache emphasizes the functional units of the enterprise performing the processes. It is often easiest to model the activities first before assigning functional responsibility for the activities. It is difficult to combine process design with organization design. Typical product development activities are widely known, yet each company's product development process will be unique to the organization's structure and to the special kind(s) of products being created. Separate from the product development processes are the project management processes. The latter are used to manage the former. For more on this topic, visit

I have been working with organisations to separate the two for some years. If you establish a PM culture it can be applied everywhere in the organisation. The way I explain it is that PM methodology says break a task down into parts or phases. SDLC says the phases are Analysis, Design, Code and Test for example. PM methodology says define roles and responsibilities. SDLC says the R&R's are.....
If the organisation wants to move buildings, a PM methodology fits. It just has different phases, R&R's, Activities, etc. If it wants to produce a review of staff salary structure, same story. The key thing is to get people thinking about the process rather than the specifics of each type of project. If you can establish a project mentality, plugging in an SDLC or any other type of life cycle becomes easy.
Neville Turbit -
It seems there is a considerable agreement on the value of keeping them separate. I agree with this opinion.

I would like to stress what Demian Entrekin has said: "It's important to define for yourself what is similar between the two and what is different. For example, you may have metrics that span both and some that don't. Also, you will undoubtedly have resources that span both, and it helps to have them working in the same overall framework."

I believe this is a key issue. It is important that people understand that processes interact with each other and are not isolated entities. Understanding the context in which a process takes place is of great importance.

Lucas Rodríguez Cervera
Nevant - Methodology and process
Of course all of this is assuming that you are meaning Software Development Life Cycle and not System Development Life Cycle because the System Development Life Cycle is more consistent with being the PMLC

I also endorse separating PM and SDLC. Many organizations are seeking to "refresh" their static PM and SDLC methodologies with process oriented approaches that provide not only the "what" of what is to be done, but the "who", "how", "when", and "why" of what is to be done and in the context of both IT project management departments and the project management that is performed by the outside of IT line of business departments, the "informal" project managers. Organizations are also seeking to ensure that Continuous Improvement is part of the PM and SDLC process, rather than an afterthought. Most PM and SDLC methodologies poorly address continuous improvement or omit it altogether. Rather than debate the merits of PMLC verses SDLC, I would seek to introduce a culture of continuous improvement in project management. There are a number of models such as Harold Kerzner's PMMM, PMI's OPM3, and SEI's CMMI and a number of project management process solutions such as BOT International's Processes On Demand, PM Solutions' PMCOP, IBM's Rational Unify Process, and others that can help your organization rapidly set up, optimize, use, and continuously improve your project management processes and best practices. Hope this helps. Mark Perry, Vice President Customer Care and Product Development, BOT International.

Keep them separate, but be able to relate them.

RUP and some other SDLCs have PM as a separate thread. In this case, the PM thread is really a mix of Project Management and Program Management in an iterative and incremental process such as RUP and the Agile processes. If each iteration is "mini-project" then the whole effort is program. Forgetting the program management aspect often leads to "one more thing..." never-ending projects, or ones where development work is deferred to maintenance.

If you look at RUP closely, you'll notice that the phases have variable numbers of iterations, and each iteration ends with a milestone. There are different types of milestone depending on the transition to the next iteration. A small effort may just be a single iteration and project. However, a very large project may have several iterations just in the Inception Phase. These larger efforts also often have several "approval to proceed cycles" which can fall at various milestones within the RUP phases and iterations. For example, you might have a project approved to develop the concept, one for a feasibility study, a third for requirements elicitation, and one for detailed design; each of these would be part of the Inception phase, though design may overlap into the Evolution phase. Each would be treated as projects (the next project's proposal would be one deliverable; RUP's Iteration Plan), and follow the PMLC. Overall, all the efforts would follow the SDLC. One of the most important capabilities is that a project can be "shelved" until resources, technology, marketing, etc. changes make the product/service/system feasible to continue with.

Also, the SDLC is for development of software systems. In many cases, a project involves a lot more than just developing software. This means that a project may have to include things like business process changes, reorganization, marketing a new product/service, building a customer support structure, etc. The PMLC needs to be generic enough to handle all of these, and bring them together and coordinate the activities. When do you do test marketing? This will probably be done multiple times as a part of the feasibility study, detailed requirements, detailed design, and as a "test phase" for the marketing plan.

The two need to be related, however. Any project needs to elicit requirements, design the final product, and produce a WBS and estimates. A software project certainly needs the SDLC both to guide the requirements and design process, and also as a skeleton for the WBS and estimates.

It's important to define for yourself what is similar between the two and what is different. For example, you may have metrics that span both and some that don't. Also, you will undoubtedly have resources that span both, and it helps to have them working in the same overall framework.

Avoid arbitrary lines of separation which divide departments (product management, support, QA, Services, etc.) but at the same time don't force processes and measures on groups where it won't add value.

Remember that the process only exists to help you achieve the desired outcomes. When the process exists for it's own sake, you may have a problem. Revisit the defined processes at a sensible review step and ask the team "What's not working here?"

Include the team leads in the planning process. Otherwise, they won't comply to your satisfaction. The ideal is seamless cross-functional harmony.

When done well, integrating these processes can have a huge impact on your life.

Have to be another to strongly endorse separating Project Management from Work Management (SDLC).

It keeps things cleaner and as one observor has noted, makes the whole area of PM more understandable and 'trainable'. It also ensures that the PM aspect is generic and reusable in other contexts.

A lot of organisations fall for the line that "we are a software house so all our projects are software related' That is one of the great urban myths; surely a reasonable slice of any organisation's projects are corporate in-house projects running from market development programs to planning the CEO's annual think tank get away.

It also means in a customer-facing sense that you can take on initiatives in completely new areas and use the PM component confidently while adding just another works management layer.


David Hudson, Brisbane, OZ
Page: 1 2 next>  

Post to This Topic


"More than any time in history mankind faces a crossroads. One path leads to despair and utter hopelessness, the other to total extinction. Let us pray that we have the wisdom to choose correctly."

- Woody Allen