On how PMBOK Change management creates variability and reduces predicatbility
In the last post I tried to point out how the analytical approach of any standard (and specifically PMBOK's) will create problems for those actually having to implement those standards.
Change management in PMBOK is a particularly large problem in this respect. Scope Control (PMBOK's process for change management in scope) comes at 19 different activities. This will leave the most experienced project manager grasping for air when it comes to implementing these activities (they are not implemented in a vaccum obviously, but that does not make it easier...)
Contrast that with the approach that Scrum uses: Re-plan every sprint based on the improved knowledge you have of the product and the market.
Now, that's simple! Simple, but not easy.
For Scrum's change management to work properly the people in charge need to understand the stakeholders needs, the market needs and the current state of development. None of these is easy to achieve, but -- and this is the point -- they are easy to explain.
In Scrum, every Sprint will have a small number of ceremonies:
- The Sprint planning: where the previous sprint's result as well as the changes in environment (stakeholders, market, etc.) are input for the planning process
- The Daily meeting: where the progress is reviewed and plans quickly adjusted to meet the Sprint goals
- The Sprint review + demonstration: where the status of development is analyzed as well as the reasons for possible problems
- The Retrospective: where we analyze what went well/wrong and take actions based on that to improve for the next Sprint, i.e. change our process.
That's it. That's how Scrum addresses change in scope: by being prepared for it at the very core of the process. Every sprint change is reviewed and handled. Plans are adjusted.
Interestingly this has an important (yet often forgotten side-effect). Because the stakeholders know that their needs will be taken into account in the next Sprint at the latest, they don't feel the need to disturb the teams during the Sprint. This allows the team to focus on the ongoing work and meet their Sprint goals while at the same time not avoiding change, rather embracing it!
Implementing a process based on PMBOK will not take this aspect into account. It is my experience that in practice, a PMBOK based approach will lead to a separate change management process (often through Change Management Boards), which will regularly but at unpredictable intervals submit changes to the teams. Teams, then need to react "immediately" to those changes: reviewing, commenting and sometimes even accepting them. Anyone familiar with Queuing Theory recognizes this problem immediately: adding more work to a team will make them late and reduce predictability because of the added variability inherent in the "change" related tasks.
This is why PMBOK fails when it separates processes like change management into their own "process" within a larger process which is a software development process.
I should however emphasize: there is value in PMBOK. Read it if you can, but you should not follow PMBOK when defining your processes. Rather you should look at Scrum, Kanban or other processes for inspiration on how to run your software development processes. This is because PMBOK is useful, but not enough!
Photo credit: Will Lion @ Flickr
Labels: change, change management, kanban, PMBOK, process, scrum
RSS link
10 Comments:
Again, I am compelled to comment and applaud. May I also add Theory of Constraints to the material one needs to understand.
Initially, I personally expected everyone to embrace Scrum, its simple ceremonies and intuitiveness. But this did not happen. Many say they use Scrum but are not even close. I would like to understand why it is so difficult for people to make a simple product backlog and maintain it? Why they don't see the value in visibility, knowing what you have done and what is left? Can anyone explain that to me?
By
Jukka Talvio, at August 14, 2009 11:57 AM
@Jukka
I can't say for sure, but I would say that Scrum is difficult because many people are at the "Shu" level when it comes to "work management". This means they need more directive list of tasks to do before they can continue their work. This is why PMBOK was successful in the first place.
When people get to the "Ha" or "Ri" levels they tend to accept more methods that synthesize knowledge (like Scrum).
Ref: Shu-Ha-Ri model
By
Unknown, at August 14, 2009 12:13 PM
Vasco,
Nice post. Please note that in many organizations that implement Scrum, the big Change Control is still taking place. It is on the other side of the Product Owner and so it doesn't impact the development team on a daily basis. Planning is done at an appropriate level at the appropriate time. Again, this is not in contrast with anything the PMBoK depicts. Even in Scrum, all 18 of the processes are being performed purposefully and with discipline. They just are not divided out organizationally, performed with an unnecessary level of ceremony, and happening with excessive upfront planning.
In fact, the Product Owner role in Scrum becomes an abstraction that isolates the development team from the majority of the political, planning, organizational, reporting, and accountability issues. But the fact that this detail is isolated from the development team doesn't mean it isn't happening. This appropriate since disturbing the development team does not improve productivity.
By
Dennis Stevens, at August 14, 2009 3:04 PM
I am amazed your ignorance of project management has not been more openly questioned. Only someone with zero appreciation of project management would make the elementary mistake of assuming the PMBOK is a methodology. IT IS NOT. The PMBOK® Guide is a knowledge framework – it describes generally accepted project management practice that applies to most projects, most of the time.
Project managers are required to adapt the information in the PMBOK to the needs of their project. Virtually nothing in your last several posts has any relevance in fact because you consistently assume the PMBOK is a software development methodology. IT IS NOT and it never has been.
Before posing as some form of expert, I suggest you at least take the trouble to understand the area you are commenting in and stop misleading your readers. Any methodology can be misused including Agile and project management methodologies such as PRINCE2. The only way a knowledge framework can be misused is by making the fundamental error of assuming it is a methodology.
And by the way, the version of the PMBOK you seem to keep quoting is 5 years out of date – the 4th Edition was released at the end of 2008.
By
Pat, at August 14, 2009 3:35 PM
Pat,
You are correct that PMBoK is a framework that doesn't specify how to implement practices. It also calls for the PM to apply the practices in a way that makes sense for the specific situation.
I believe that Vasco's view of project management is shaped by his experience - just like yours and mine. I believe that his anti-PMBoK bias has its roots in a project management organization that caused what appeared to be irrational problems for a development team. This has also happened on projects I have been involved with.
In theory, these conflicts should not exist. In practice they do - at great expense to individuals on projects and to the organizations where they work.
I believe that there is a lot of benefit to be gained by improving the way the Project Management interfaces with Agile Software Development. Random and aggressive nay-saying and name calling doesn't advance the discussion.
By
Dennis Stevens, at August 14, 2009 5:43 PM
@Pat
I appreciate your comment, even if it does not feel very confortable being called an ignorant :)
I have 10+ years experience in the Software development field and more than 6 of those were in positions directly or indirectly related to project management.
I also happen to have been part of 3 waves of process development/deployment, each of those based on different frameworks and PMBOK was one of those frameworks.
It is true that PMBOK is not a method, but neither is Scrum, however you can define how a company or a group works based on what PMBOK suggests as a standard. That is what I'm commenting here.
Now, I'd be happy to hear your rebuttal about the actual content of the post :)
PS: PMBOK 3rd edition from 2004 is indeed out of date. But the principles behind it have not changed, and I hazard to guess that they will not change in the foreseeable future.
By
Unknown, at August 14, 2009 11:14 PM
My language may have been a bit sever Vasco, but I am heartily sick of people blaming bad management on the PMBOK® Guide. Doing so is about as intelligent as blaming vehicle accidents on the Highway Code. Any information framework is capable of being misused, the PMBOK is no exception.
Your whole series of posts is based on a total misunderstanding of the PMBOK:
Section 1.1 – Purpose of the PMBOK® Guide states ‘this standard is a guide rather than a methodology’.
Chapter 3 (in BOLD) states ‘This does not mean that the knowledge, skills, and processes described should always be applied uniformly on all projects. For any given project, the project manager…. is responsible for determining which processes are appropriate, and the appropriate degree of rigour for each process’.
Projects range from the construction of a power station through to small IT developments – I would suggest it is blindingly obvious the generic processes and knowledge framework contained in the PMBOK would need adaptation based on the nature of the project and this is exactly what you are doing in part.
The other error in your assumptions is ignoring the fact the PMBOK is clearly focused on project management – not operational maintenance. For more on this see De-Projectising IT Maintenance at http://mosaicprojects.wordpress.com/2009/03/06/de-projectising-it-maintenance/
Bad IT management should be your target, not the globally recognised framework contained in the PMBOK. For more on how to make Agile relevant in business I suggest you read Dr. Lynda Bourne’s latest post Agile’s Business Failure http://stakeholdermanagement.wordpress.com/2009/08/14/agile%e2%80%99s-business-failure/ - she is a manager with over 30 years IT experience including very senior executive management roles in major telecommunication organisations.
By
Pat, at August 15, 2009 4:07 AM
@Pat
(while reading replace PMBOK with PMBOK-inspired project management methods. I do this to make the writing easier :)
I am not blaming bad management on PMBOK. I'm saying that even if that is not the intention following frameworks like PMBOK or RUP will inevitably create more problems than it solves in a software development environment.
During next week I'll continue to write about why I think so. But as I've said in other comments, PMBOK is based on a set of beliefs that are inadequate for software development (or product development, any product).
PMBOK may be useful for other project-types (I wouldn't know because I work with software and organization change projects), but PMBOK is inadequate for software development.
You can succeed (or indeed fail) with PMBOK in software projects, but my experience is that anyone without a large amount of experience cannot succeed with PMBOK. People with lots of experience may draw on parts of the PMBOK to inform their software management practice, but that says a lot more about the competence of the people than the adequacy of PMBOK.
On the other hand Agile methods (which is based on a completely different paradigm and set of beliefs) brings some new characteristics to how we organize our projects. Those characteristics are not a recipe for success, but they (in my experience) focus even new project managers on the right things!
You may dispute this last statement, I did that myself when I started with Agile, but my experience (and that of others) indicates that it is true that Agile changes the way we look at work organization. And it does that significantly when compared to PMBOK and the set of values behind it.
It is my experience that because of these, and other reasons that I'll explain during next week, Agile is the right paradigm for software development.
By
Unknown, at August 15, 2009 8:04 AM
All I can say Vasco is I hope you never have the responsibility for designing and building the software that controls any of the aircraft I fly in or the financial systems of my bank.
Maybe in another 10 years or so you may begin to understand the value of appropriate planning and controls in the development of critical systems and services.
By
Pat, at August 15, 2009 2:33 PM
@Pat
Can you explain why? I'm trying to explain why I think that PMBOK does not work for Software Development, especially in a product development environment.
You seem to believe that whatever I say is wrong (and it may be), but you seem not to be able to explain why you think I'm wrong.
Believing something without proof or deep understanding is the root of many failures (some having to do with aeroplanes, military systems and other).
How can you be sure that you are not doing the same when developing those life-critical systems?
BTW: there are many good people in life-critical product development (like medical, nuclear power, aerospace, etc.) that don't espouse the PMBOK framework. How do you explain that?
Let's continue the dialogue, I'm sure I'll learn from your views. So go ahead and explain your viewpoints.
By
Unknown, at August 15, 2009 8:37 PM
Post a Comment
<< Home