Don KimPROJECT-TO-PORTFOLIO MANAGEMENT EXPERT| Seeking opportunitiesSacramento, CA, United States
The following was blogged about and posed on LinkedIn, but I'd like to know what the Gantthead community thinks about this:
The 4th edition of the PMBOK is coming out and a draft edition was made available for current PMP certified and non-certified experienced project managers to review and comment on it. A section that particularly interested me was Section 2.1.3-2:
An iterative relationship, where only one subset is planned at any given time and the planning for the next period is carried out as work progresses on the current deliverable. This approach is useful in largely undefined, uncertain, or rapidly changing environments such as research, but it can lead to rework and reduce the ability to provide long term planning or scope control for the project. It also entails having all of the project team members (e.g. designers, developers, etc.) available throughout the project.
This section was no doubt influenced by the Agile software development and project management movement. Though in all fairness, the PMBOK has acknowledged that many project would be better served using a more iterative approach in the form of progressive elaboration or "rolling wave planning" since the 2000 version, I believe.
This notion addresses the idea of planning near term work in detail and later work in less detail. Then as new details emerge, going back to the plans and updating them with the new data. This is common sense to those in the Agile community, yet it seems that many in the Agile community seem unaware that it has been in the PMBOK for the last 8 years since, unfortunately, many Agile evangelists choose to ignore these important principles in the PMBOK Guide.
At least in regard to PMI, they seem to have acknowledged the importance of a more iterative approach and seem to have made it more explicit in the upcomming 4th edition of the PMBOK, since as they state "for multi-phase projects, more than one phase-to-phase relationship could occur during different parts of a project".
For those in PM and/or lead technical roles who have or are utilizing Agile, PMBOK or a combination of both, what are the implications or influences if any, that the above will have on your current practices?
Wayne MackRetired| RetiredSouth Riding, Va, United States
From my LinkedIn response to this question:
For those utilizing Agile practices, I doubt the wording in PMBOK will make much of a difference and I doubt the wording will cause those not using Agile practices to adopt them. I hope that future iterations of PMBOK will better address Agile practices and help introduce them to a wider audience.
Although PMBOK has long had statements in it concerning iterative projects and much of PMBOK is at a high enough level that it could be considered agnostic on Agile versus sequential approaches, where PMBOK goes into details, for example dependencies, networks, and GANTT charts and EVM, it challenges Agile approaches. Furthermore, the PMBOK definition of a project puts many commercial product development efforts (no fixed scope or time period), O&M work, and even T&M contracts outside its scope. This, I feel, has been a major oversight in bring PMBOK to software development efforts.
There are changes on the horizon and PMI is in the process of forming an Agile Project Management SIG (see quoted information below). I think that in the long term, many Agile practices will be accepted as main stream by PMBOK, but the current version is not at the point where it will cause anyone to shift positions.
Quote from e-mail concerning new PMI Agile SIG:
'Over the last couple years, PMI has been overhauling the way all their communities (SIGs, Colleges, Chapters) are chartered and run. During this time PMI has placed a moratorium on the creation of any new SIGs, until a new community governance model has been developed (Phase 1), piloted (Phase 2), and rolled out (Phase 3).'
'2007 saw the completion of Phase 1, the development of a new governance framework. It addresses issues like community incorporation, budgeting, membership, etc. During the first half of 2008, a subset of existing SIGs & Chapters have been asked to pilot the new framework for Phase 2. Therefore, PMI won't begin selecting subject areas for new “virtual communities” (the new official term for SIGs) until the second half of 2008 at the earliest.'
'If you have any questions about the finer details of PMI’s Virtual Communities Project, send an email to [email protected].'
Saving Changes...
George JucanManaging Partner| Organizational Perfomance Enablers NetworkWoodbridge, Ontario, Canada
To set the stage of my comment I must disclose that I am an Agile Manifesto signatory (and managed agile projects), and I’m also a PMI advocate, including leading the committee for writing one of the chapters of the upcoming PMBOK 4th Edition. From this position I think that there is no conflict between PMBOK and any SDLC practiced by the IT/IS industry, including Agile.
First at all, PMBOK is a guideline, a collection of best practices, not a prescriptive methodology. It simply states what “most projects, most of the time” apply to efficiently manage their activities. It does not say that this is the “only way”, or that all projects should apply what is described in PMBOK. Moreover, it explicitly indicates that companies should create their own – particularized – project management methodologies, using PMBOK as a framework. For example, I’ve seen companies using simplified versions of EVM, or a different monitoring and forecasting technique altogether, while still following PMBOK principles and techniques in other areas.
From a different perspective, we are not comparing apples with apples here: PMBOK is focused on the project, Agile (and other SDLCs) are focused on the product. The 2 life-cycles overlap and interact, but are certainly different. One can choose to treat the entire development of a software construct using Agile as a single project with phases, while another could consider each sprint as a project in itself. In both cases the same concepts of initiation/planning/execution/monitoring&control/closing apply, with same tools and techniques (from PMBOK or your own).
The same concept applies to continuous development of commercial software, where each release it’s a project (in fact a program) in itself, or T&M project that still have a clear scope and estimated completion date. However, with the penetration that project management has in the IT industry, PMI should consider creating an IT Extension of the PMBOK to better address issues specific to our projects – I would say that IT is as large and as specific as construction or government areas, both of them having their own extensions to PMBOK. An IT extension would better clarify the relationship with SDLCs and specific applicability of PMBOK concepts into the IT/IS world.
Saving Changes...
Still a little puzzled why so many project managers focus on the methodology (looking to the inside - to the methodology) instead looking to the outside environment of the project - why are you doing the project for this client.
Triggered by the remark that "PMBOK is focused on the project, Agile (and other SDLCs) are focused on the product. "
I hope the project or product have not become an objective in itself.
Í'd rather see the difference made because the methodology has a focus on the client's business objective or the project business case. Saving Changes...
Dave PriorTrainer/Consultant| LeadingAgileNew York, Ny, United States
I think that as project managers, we face some fundamental choices that tend to push us into one camp or the other. If you are raised in the Church of PMBOK, you believe that, even though it is only a “Guide”, that PMBOK is the net under your high wire act. It keeps you sane when things come unglued and you rely on that process as the foundation against which you build your case for getting things done. You measure yourself against the plans you define using that process and at the end you check back to evaluate your usage of the process.
When someone from the PMBOK camp reads this part of the Agile Manifesto:
Individuals and interactions over processes and tools ?
Working software over comprehensive documentation
?Customer collaboration over contract negotiation ?
Responding to change over following a plan
It tends to read as being in opposition to the PMBOK. (I’m not saying this is correct, I’m saying that for the majority of the PMs, especially for the ones who are still in the stage of development where they have not embraced the word “Guide” and are trying to figure out how to apply ALL of the PMBOK to their work, this is heresy. )The very idea of process taking a backseat to interaction, documentation taking a back seat to anything and being reactive to change as opposed to following a plan seem at totally odds with that we take from the PMBOK. (Of course, you can be reactive to change instead of following the plan, as long as you complete the appropriate documentation to make sure you have a record of your decision to deviate from the plan and behave in a reactive manner.)
It seems to me, that in order to truly embrace an Agile process over PMBOK, it requires a fundamental shift in your value system if you grew up with the PMBOK. They both work, they can be incredibly effective when used together, but it absolutely is about putting the chocolate bar into the peanut butter. No matter how much the PMBOK embraces pieces of Agile as it evolves, the value systems are in opposition with one another. This is not a bad thing. Hopefully, for those of us trying to use both, the conflict will allow us to put together customized approaches to our work that are best suited to serve the client, produce the desired deliverable and enable the teams to stay focused on the work over the process.
Senior Advisor to the CEO| PMISterling, Va, United States
Here is a related question from Bob Tarne, [Traditional vs. Agile PM] who has been involved with PMI for years, holding several elected and volunteer positions. Being a Scrum Master, while deeply involved in PMI gives him a fairly unique perspective. So I think its worth engaging him in this conversation. BTW, the posting below is from Dave Prior who is also a PMP and Scrum Master. Both are very worth getting to know and connecting with here on gantthead. Saving Changes...
I think we want projects processes to be more than they are. We want them to include all temporary endeavors, both development and deployment. Projects are plan-able. Not all temporary processes are plan-able. The artisan process is used when skilled artisans are inventing products. Creating something that has never existed before.
Artisan processes are not plan-able. That is why they have an entirely different body of knowledge and different association. A sister to PMI, the roots of the Product Development and Management Association (PDMA) go back to the turn of the century, when Edison and Bell were pioneering new methods. Agile, Scrum and Extreme methods are all derived from practices outlined in the PDMA Handbook of New Product Development.
Saving Changes...
Jesse FewellAuthor, Speaker, Coach| JesseFewell.comFalls Church, Va, United States
There is a growing body of work that maps Agile processes/practices to the PMBOK in a compelling fashion. Mike Griffiths, Stacia Broderick, Michele Sliger, and James Goebel have been leading the way. After seeing their work, you realize the PMBOK doesn't need to "go Agile", practicioners do. In the end, whether you call it phases or iterations, scope or backlog, what works is what works.
As an update to Wayne's comment about the PMI stance on Agile, a formal component dedicated to Agile has been chartered and is scheduled for launch in Q2 of 2009. For more details, go here: http://finance.groups.yahoo.com/group/pmiagile Saving Changes...
Jim DicksonProject Manager| Governement of British ColumbiaVictoria, British Columbia, Canada
While the Agile approach has software development as its main area of focus, I am encountering the need for a similar approach (although perhaps more structured) for business related projects. I get push back from business area executives who say that producing detailed charters, project plans, communication plans, change management plans, etc. is time consuming, add cost and too much rigor. They do not see the value-added. I am sure most of us have experienced this reaction to the PMBOK approach. The Agile approach (although not called that) was used in the 60's, 70's and 80's before PMBOK. The approaches used were iterative development and Rapid Application Development for software projects and no project management processes for business projects. The results were the disappointing project success rates we have all read about and some of us experienced.
I don't think it is wise to discourage the use of proper PM methodologies for planning, risk management, etc. but we need to find a gentler yet effective approach (PMBOK-lite?) that is less about process and more about getting the job done properly and successfully.
Perhaps the concept of a Project "type" process seems difficult for many people. However, it is in fact one of four process types. The other three are Artisan or Invention; Operations and the last is Automated.
It should be noted that the detailed work of inventions can not be planned because we have never been there before.
Thus, those parts of projects that have never been done before, and are impossible to plan, require a different method that may be found in the inventing type process.
It should also be noted, that as industries mature, they do less and less inventing. Building houses is a more mature process than software. However, for those who have been around since 1980, software is doing less and less inventing as it matures.
Saving Changes...
Re: The 4th edition of the PMBOK is coming out and a draft edition was made available for current PMP certified and non-certified experienced project managers to review and comment on it. A section that particularly interested me was Section 2.1.3-2:
An iterative relationship, where only one subset is planned at any given time and the planning for the next period is carried out as work progresses on the current deliverable. This approach is useful in largely undefined, uncertain, or rapidly changing environments such as research, but it can lead to rework and reduce the ability to provide long term planning or scope control for the project. It also entails having all of the project team members (e.g. designers, developers, etc.) available throughout the project.
This section was no doubt influenced by the Agile software development and project management movement. Though in all fairness, the PMBOK has acknowledged that many project would be better served using a more iterative approach in the form of progressive elaboration or "rolling wave planning" since the 2000 version, I believe.
=====================
I don't that it's a case of PMI being influenced by Agile software/product development as much as a case of theI.T. sector (as with other sections, such as manufacturing and R&D) along with PMI were all, collectively, influenced by the same thing which resulted in adding an interative focus to planning. In the case of I.T., the iterative focus has resulted in new application/product/development management processes. In the case of PMI, it has resulted in new project management processes. In fact, the PMI standard has spoken of "progressive elaboration" for many years, as far scope definition and cost/schedule baselines are concerned.
In fact, the relationship between the process groups defined in the PMBOK® Guide (as well as in the Standard for Program Management) has always been iterative, with montoring & control feeding back into project planning.
Remember, the PMI standards are sector/industry agnostic. The PMBOK ® Guide, for example, is not an IT standard nor does it even touch on IT. In fact, the only thing it has to do with IT is the fact that, IT projects, just like any other products (construction, R&D, political campaigns, marketing campaigns, government projects, etc.) need to be managed differently than operational work or functional work. Therefore, the same PMI (or other PM standards) that are applied to construction, marketing, etc. projects can be applied to I.T, as well.
Since construction and government were the first sectors to adopt PMI standards industry wide, PMI has released construction and government “extensions” to the PMBOK® containing specific standards for those sectors. With the rapid adoption, during the current decade, of PMI standards in the information technology sectors, PMI is considering developing an I.T. extension to the PMBOK Guide. I don't have any information about how far along they've progressed on that front. There is at least one project management methodology that I know of that was actually designed for managing I.T. projects: CompTIA Project+. Unlike the PMBOK® Guide, which is a guide to a "standard", CompTIA Project+ is actually a methodology.
I think much of the confusion has come from the fact that large numbers of technology professionals (a cohort of people who are really into taking "certification" exams) are now pursuing their first, non-IT related certification, in this case, the PMP credential. This has resulted in the myth that PMP is some kind of IT-related credential. In fact, it's about as related to IT as the CPA credential is related to IT. In addition, unlike an I.T. vendor "certification", the PMP credential involves a lot more than just making an appointment at the Prometric center and taking an exam.
Many of these folks, who are pursuing the credential, are learning for the first time the difference between application development management, used for the product development life cycle (e.g., SDLC, Scrum, Waterfall, etc.) and project management which is used for the project managment life cycle (e.g., Prince2, PMI, etc.). Hopefully, as more and more of these folks move out of technical work and into PM work, the technicians and business analysts who they manage will start to understand the difference too.
All of these standards and methodologies (product development, project management, lean operations, etc.) have been developing in the same environment, so I don't think that it's a coincidence that a focus on iterative methodologies are appearing across all of them.
PMI Team Member
