I'm developing my first project schedule using MS Project. I am familiar with using the standard SDLC phases; Analysis, Design, Development, Testing and Implementation. I am now working for a small organization that wants its process more aligned with the PMBOK. How do you integrate the two?
Saving Changes...
Sort By:
Wayne MackRetired| RetiredSouth Riding, Va, United States
The SDLC phases are typically contained within the Execution phase of PMBoK. The Initiation and Planning phases preceed the SDLC effort and the Closing phase follows it. The Monitoring and Control phase parallels the Execution phase and the SDLC effort.
Occassionally, one may run a single SDLC phase as a project - this is most likely true of Requirements definition and sometimes true of Testing.
In general, the technical work is done in the PMBoK Execution phase.
Saving Changes...
Maybe it would help considering a schedule that runs at two different levels, or 'streams'. You can plan for the Project Management activities following the PMBoK recommendations. And then plan for the execution itself following whatever lifecycle needs to be applied. Then you would only need to take into account the required synch points between the two streams (not always obvious!). I completely agree that the product lifecycle should more or less match the execution bits of the project lifecycle.
Trying to build a single schedule mixing both management and 'construction' activities isn't always worth the effort, and can be quite confusing (both for the manager him/herself and for anyone trying to review it).
I think the confustion lies somewhere between the two lifecycles that work their way through a project.
There is the project lifecycle. Typiclly this runs something like:
Initiation, followed by planning. Then there building or 'doing it' which is followed by termination or close down. I usually abreviat it
I - P - B - C.
Running in parallel are product development lifecycles for each and every major delivery. These lifecycles typically run something like Requirements or need, design at some level, specificaiton, build or buy, test - usually at several levels, implementation or commissioning and finally handover or business as usual.
You will have a product development lifecycle (PDLC) for every major deliverable. You may be developing the software, but buying the hardware, so different lifecycles are involved.
Most the the PDLCs are in or take place during the build or 'do it' phase of the PjLC (project lifecycle), with some leakage forward in to planning. I've attached three power point slides that help explain my position.
The first slide really represents the paragraph above - most of the PDLCs are in the 'do-it' part of the PjLC. The other two slides represent two common views of PDLCs, the waterfall, and the "v" model, derived initially from the European Space Agency.
It is easy to keep them separated, and easily managed if you keep in mind that not all products or deliverables are at the same stage of their development lifecycles, but that the project is inevitably in one of the four phases of the project lifecycle. Saving Changes...
With all respect to Robert, I have a very strong recommendation:
NEVER, EVER, EVER, USE IPECC AS YOUR TOP-LEVEL PROJECT PHASES!!!
IPECC is a description of the process groups, NOT the project phases. The PMBOK Guide makes this clear in the early chapters, but people are continually getting confused about this. The PMBOK Guide actually has no recommendations for a standard set of project phases. In fact, the recommendation is that you develop phases that match your business process or type of project.
I strongly recommend picking up the "Standard for Work Breakdown Structures". It has great information about how to create a deliverable-based WBS. You can use this to figure out the right top-level structure (phases or deliverables) for the different type of projects you face at a smaller company.
I worked on a variety of project types at a small company, and I found that there was no sensible, single, standard set of project phases. There was just too much variety in the type of projects we were doing. We would develop a top-level WBS for each project, occasionally borrowing ideas from previous projects.
Back to the original question -- if your company wants a process "more aligned to the PMBOK Guide" then they should be developing unique, deliverable-based WBS structures for each project. Only similar types of projects should get the same top-level WBS items. Also, deliverable- based plans are preferred over phase-based plans in the WBS Standard, so you would not use phases at all if you want to follow that recommendation.
The way you integrate the IPECC approach with an SDLC method is to recognize that all the processes (IPECC) take place within each and every phase. Some tasks are initiating, others are planning, others are executing, and so on. They are not sequential phases, though. IPECC is a classification system that describes the work that happens continuously in every phase of a project.
I am sure some people will disagree with me, but after years of teaching and studying this stuff, this is my best understanding of the material. Saving Changes...
Robert ProlProject Manager| KPMG LLPEast Sandwich, Ma, United States
Thanks for the recommendation. You are welcome to continue to spend your time recreating the wheel, but I'll continue to do what I do and get the same results. If you create a new and exciting way to manage projects that requires you to teach every new hire a whole new way to think about projects, you'll continue to spend all your time teaching.
Sounds like it is best if we agree to disagree. I have used IPECC as top-level phases and had poor results. I also have watched many people struggle with plans organized that way.
I do fully support departmental standards for WBS templates, assuming the project types are similar. I worked in a software development groups that had great templates that made reporting and management much simpler. A good SDLC can be very valuable. I have also seen terrible problems when a hardware development effort or a training effort was forced into SDLC-based phases. Over time, I have become an advocate of the deliverable-based WBS. Saving Changes...
Robert ProlProject Manager| KPMG LLPEast Sandwich, Ma, United States
We also use delivery based WBS, but they are organized in IPECC (although Controlling/Monitoring is iterative). This is a pretty common approach, especially where PM isn't mature yet. It provides people a framework of understanding PM. As far as the phases being present in all aspects of the project, I agree. But I find that looking at the project wholistically provides that needed framework, and becomes the table of contents for the knowledge management system. I find that point-of-use resources are more easily utilized this way.
There's no reason to agree or disagree; project management should be contingency based. I'm a PMO builder, and use what works for me.
Remember, if PM were easy, anyone could do it. Have a virtual beer on me. Saving Changes...
I agree 100% that methods and tools ought to be tailored to fit the need. If it works well for you, then that is great. I had not met anyone before where IPECC worked well as a top-level WBS. Thanks for providing a fresh perspective. Saving Changes...
