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? Saving Changes...
If your company produces software for internal or external customers than the SDLC can be the PMLC. If, however, the result of your projects are some other product or service, than your PMLC should be generally structured to your industry or simply a generic life cycle. The generic I use is:
Initiation Planning Execution & Control Turnover
You can find this and other examples in the PMBOK published by PMI at //pmi.org Saving Changes...
While PMLC and SDLC tend to have significant overlap in most of our experience, there is still value in keeping them separate, as they are independent disciplines.
Project management as a discipline can be applied to any domain - from developing software, to building houses, to planning your holidays. I have found it valuable to focus on Project Management as the mechanism for getting work done. It has processes (as Rita points out, there is a lot of value in the PMI material) and should be managed for continuous improvement in your PM processes and for capturing knowledge to improve the performance of your PM's and other team members. Concern of project management include risk assessment and management, issue management, schedule management, status assessment and reporting, etc.
SDLC on the other had is a specific discipline for the development of software. It's processes and practices are independent of project management methodology. These process are important to manage, and collect data on for improvement. Concerns of Software development life cycle include gathering requirements, systems architecture and design, development, release, maintenance, etc.
Again, in every practice these disciplines are very intertwined in getting our work done. It is important to insure that they combined processes function together well. But it is my experience that you are dealing with different disciplines and will find that people tend to excel at one or the other. Very few are very adept at both (there are some, but for most, their interest lies primarily in one and not the other).
Steven hit it on the head, and I wholeheartedly agree: there is considerable value in keeping them separate based on my experience as an IT PM professional and as an IT PM Principles instructor. I find this concept is one that takes time for both clients and students to grasp, so be patient at it, especially if your audience is still new at SDLC. Consider the Allstate image: "you're in good hands with Allstate", where the hands are the PMLC that hold the SDLC. I have successfully used the analogy of building a car to help get the point across (assembly line activities are the SDLC; determining components of the assembly line, what tasks should be done to build the assembly line, etc. are activities in the PMLC). Saving Changes...
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.
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. Saving Changes...
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. Saving Changes...
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. Saving Changes...
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 Saving Changes...
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.