Okay… let's get back to our discussion on how to look at the PMI knowledge areas from a more Agile point of view. Last time we tackled Cost Management, this post let's look at Scope Management
According to the third edition of the Project Management Body of Knowledge, Scope Management includes the processes required to ensure that the project includes all the work required, and only the work required, to complete the project successfully. PMI states that project scope management is primarily concerned with defining and controlling what is and is not included in the project.
I find it a little entertaining how these statements seem to be universally interpreted as "define everything you are going to do up front and make sure you deliver what was originally defined". While that may have been the intent of the PMBOK Guide, some projects don't lend themselves to that kind of up front planning. Some projects must allow for discovery. Some projects must adapt to changing markets, or at the very least, adapt based on the teams understanding of the emerging product.
For some of us working in more dynamic problem domains, ensuring that "the project includes all the work required", is a process of discovery. Controlling what is included, and what is not included, is an ongoing concern rather than something done once for the entire project. We need a project management framework that embraces this uncertainty rather than wishing it away or pretending it doesn't exist.
I am becoming convinced that Project Managers default to this static point of view because we have never been taught another way of managing projects. We just don't have the tools to deliver projects any other way. So… that said, let's take a moment to look at the PMI Scope Management processes from a more Agile point of view. I bet we find another way of approaching Scope Management that does not involve defining everything up front and then locking it down for the duration of the project.
Scope Planning
PMI Definition: Creating a project scope management plan that documents how the scope will be defined, verified, controlled, and how the Work Breakdown Structure will be created and defined
Agile project management practices are really the embodiment of a scope planning approach. As a project manager, especially a traditional project manager making the switch to Agile, I have no problem documenting this for my organization. An Agile Scope Management Plan is going to address things like creating the backlog, characteristics of a good backlog item, how we are going to establish velocity or throughput, how we are going to measure burndown against the backlog, and how we are going to deal with changes to the backlog.
Scope Definition
PMI Definition: Developing a detailed project scope statement as the basis for future project discussions
Scope on an Agile project is defined in the product backlog. The backlog is a listing of the features that your product owner would like to have included in their project. One of the most important considerations to keep in mind is that every item in the backlog should be independent of each other. This is the secret sauce that makes it possible to reprioritize and make changes on the fly. Bill Wake has a great explanation of what makes a good backlog item on his website: http://xp123.com/xplor/xp0308/index.shtml.
Rather than looking at the product backlog as a static indicator of what WILL be built, look at it as the baseline for further adaptation. It is expected to change as we learn more about the emerging product.
Create WBS
PMI Definition: Subdividing the major project deliverables and project work into smaller, more manageable components
This is one of the toughest things for traditional project managers to get their heads around. There is no WBS on an Agile project, at least not one in the traditional sense. From the Scope Definition section, we learned that our backlog represents the scope of the project and that each of the backlog items should be independent of each other. Independence is key because it allows us to do just in time scheduling.
Agile projects are broken down into smaller projects called releases. Project releases are broken down into smaller time-boxes called iterations. Content is pulled into a release just prior to its start, and only as the previous release is winding down. Likewise, content is only pulled into the upcoming iteration as the previous iteration is coming to a close. The idea here is that we are going to review what the team was able to complete and make decisions about the next increment based on what we learned from delivering the previous increment.
As an Agile Project Manager, I am generally comfortable laying out a high level plan to understand where I expect to be at certain points in the project. I am also comfortable keeping a chart of external and internal dependencies to help manage commitments. The key is to use these as guidance for decision making and indicators of progress. Problems arise when these tools restrict our ability to learn and adapt to the realities of our projects.
Scope Verification
PMI Definition: Formalizing acceptance of the completed project deliverables
Each iteration we will decide the next best increment to build and then review the outcome once we are complete. The stakeholders either accept or reject the outcome of the iteration and work with the team to decide the next best set of features to build.
Because we want to maintain the ability to adjust the product as we learn more about the emerging solution, we focus on making and meeting commitments in smaller increments. Scope verification is done based on the outcome of these small increments of product and how they align with the product vision and the goals of the release.
Scope Control
PMI Definition: Controlling changes to project scope
Agile teams take a value driven approach to delivery rather than an activity based, or even deliverables based, approach to delivering projects. The product owner can change the scope of the product at will, but is always focused on delivering the most value possible given the available times and resources.
Agile teams give the product owner a tremendous amount of discretion over how the system is constructed and even accommodate changes even late into the life of the project. It is understood by Agile teams that changing scope involves tradeoffs. The product owner is substituting features that add greater value for those that provide less. To add one thing, something often has to be taken away.
Next Up… Communications Management
Subscribe to this blog
Tuesday, July 8, 2008
Refactor Your PMP: Scope Management
Tuesday, May 27, 2008
Refactor Your PMP
In software engineering, refactoring a module of code means that you change its internal workings while leaving its external interfaces intact. A developer might do this to make the internal workings of their software simpler, more efficient, or easier to understand. The key is that refactored code maintains it's contract with the surrounding system. Everyone can still get what they need from the refactored system component in exactly the way they have always gotten it.
There is something here we can draw from as project managers. As we make the switch to agile project management, we must stay plugged in with the language of the organization. We need to maintain the contract the business has come to expect. Over time we may be able to influence how our organizations think about project management best practice. At some point we may even be able to renegotiate the contract.
For now, we need to take what we know about adaptive and traditional project management and establish a framework for delivering in the language of the business. The PMI process groups and knowledge areas provide a well thought out and disciplined foundation on which to build. Our challenge is to approach the discipline of project management with an agile mindset. To figure out how to leverage agile practices within the constructs of the accepted project management best practices.
Over my next few posts we'll break down the PMI process groups, knowledge areas, and processes to explore how we can build an effective agile framework using the established contracts. If you are interested in a little pre-reading, check out the following posts from my blog and a few others:
Thursday, May 1, 2008
Straw Men and Red Herrings
Whenever I get into a discussion on Agile Project Management, I inevitably find myself contrasting Agile methods with "Traditional Project Management". I use the phrase "Traditional Project Management" as a label for that style of project management advocated by the PMI, documented in the PMBOK, and certified through the PMP. It's the kind of project management we often characterize as big up front planning followed by a blind adherence to the plan.
Setting up the conversation this way gives me an easy way to establish contrast and teach about Agile methods. The problem with this approach is that reality is never quite so simple.
A well run "Traditional" project does adapt and respond to its environment. A good "Traditional" Project Manager does lead and empower their teams. While good "Agile" teams are structured and disciplined, many are unstructured and chaotic. Establishing an us vs. them mentality isn't going to lead us any closer toward developing more adaptive project managers or more adaptive project management practices.
We will always be able to find examples of misapplied process no matter what management or leadership philosophy we happen to hold.
Rather than setting up the "Traditional" crowd to take the fall for all our project management problems, we should acknowledge that there is a time and place where it does make sense to apply a more "Traditional" approach. Let's focus on making the Project Management community aware of those domains where it doesn't. If we can clearly communicate what makes some software projects different, in a language the "Traditional" crowd understands, we will be better positioned to open minds.
Agile is pretty risky for people that have been immersed in 30-40 years of conventional project management wisdom. As Agile becomes more mainstream, we are going to need to deal with people that are not ready to drink the Kool-Aid. If we want the PMOs out there to see Agile as a viable project management approach, we need to meet people where they are and guide them gently into this new way of thinking.
So here is my new formula for having a discussion on agile project management
- Validate the traditional project management processes
- Explain why these processes break down in certain problem domain
- Listen for objections and understand their point of view
- Explain how agile project management solves some of these problems.
What do you think? Subscribe to this blog
Friday, April 18, 2008
The Message or the Messenger?
Sometimes we need to separate the message from the messenger. Whether we are talking about religion and politics or project management, there is often a disconnect between the message of the organization and the practice of the people in the organization.
Somehow when people get involved, the purity of the message is subordinated to getting stuff done.
We certainly see this in the Agile community. As people try to implement the principles, values, and practices they are forced to make compromises that sometimes don't feel very Agile. People on the outside will often even claim that Agile doesn't work because their particular implementation of Agile did not work. Was that failure because of Agile or because of the myriad of compromises we made along the way?
In all fairness, I think traditional methods suffer from this same disconnect between the message and the messenger. I can't find anywhere in the PMBOK where it says you have to do all the planning up front, but in practice, that is what often happens. Likewise, there is nowhere in that document that says you should not respond to change or adapt your plan, but again, that is how traditional methods are often implemented.
Is that the message or the messenger? It is inarguable that traditional methods lean more toward predictive project control and Agile methods lean more toward adaptation. In practice though, should we hold PMI accountable for advocating rigid up-front project planning? If so, we need to hold Agile responsible for advocating no project control and ad-hoc coding practices. We need to separate the message from the messenger.
Here is my take… you can run a software project using traditional methods. You can even run a highly uncertain project using traditional methods. You could use rolling wave planning and progressive elaboration. You could do most of the design up front and create a nice big Gantt chart for your project stakeholders. As we begin to build and learn more about the product, just document your changes, assess the impact to the triple constraints, and get stakeholder sign-off.
Send the team off to update their design documentation, recode the application, and retest anything that was impacted. Clearly if the change was approved, you have the additional time and budget to do all the work necessary to accommodate the change. If you dig deep enough into the PMBOK, you will find that everything you need is right there. You could even make the case that if you are not adapting your project and managing change, you are not responsibly managing your project.
So if the traditional processes have everything we need to support a highly adaptive project, why do we want to do so much planning up front? Why do we become so resistant to change?
Cost and time to market.
Traditional project management processes are heavy and slow. They make our products more expensive and take longer to build. Most of us are not willing to invest in the full adaptive capability of these methodologies, therefore, we try to take shortcuts. We believe that if we do our planning up front, and work to eliminate change, we can keep these costs in check. The root of this problem isn't that PMI processes don't accommodate change, they don't give us an INEXPENSIVE way to accommodate change.
As companies, we need to decide if we really have a strong enough business driver to use these heavyweight methodologies. What does your company value more: process control or cost and time to market? If you NEED this much structure and control, and I am sure that some of you do, by all means, leverage the full capability of the PMI planning processes and adapt through change management.
If you need to get product to market quick and inexpensively, because you know if you don't, your competitors will, you need something else. Agile methods are that something else. Don't pay the price of methodology unless it is absolutely necessary. Ignorance of another way is no excuse.
Monday, March 31, 2008
Herding Project Managers
Last week Glen Alleman published a post called "The Role of Project Management". Glen has been exploring some of the concerns people have with the PMI and the PMP certification. He is challenging us to tell him what process groups and knowledge areas we should leave out. What should we NOT be doing that the PMI prescribes? If we think that the PMI has it wrong, what should we be doing differently?
It dawned on me after reading his post that most Agile Practitioners I talk with don't really have much first hand knowledge of the PMI, the PMP, or the PMBOK. They know of these things through the people that they have worked with over the years. Quite a few folks I meet have had pretty bad experiences with PMP certified project managers and therefore think that it must be the PMI or the PMP that is making them bad.
For the sake of helping everyone rise to Glen's challenge, I have attached the PMI Process Groups, the Knowledge Areas, and as an added bonus, the Project Management Processes. My guess is that the Process Groups and Knowledge Areas are going to make the cut. What about the PM processes? Any low hanging fruit? Activity sequencing maybe? What about activity resource estimating? How about managing the team?
This is looking to be a pretty tough assignment.
PMI Process Groups
(these are the high level components of the process)
Initiating
Planning
Executing
Monitoring and Controlling
Closing
PMI Knowledge Areas
(these are the areas we are managing within the process groups)
Integration
Scope
Time
Cost
Quality
Human Resources
Communications
Risk
Procurement
PMI Project Management Processes
(these are the actual process prescribed in the PMBOK)
Develop project charter
Develop preliminary project scope statement
Develop project management plan
Scope planning
Scope definition
Create WBS
Activity definition
Activity sequencing
Activity resource estimating
Activity duration estimating
Schedule development
Cost estimating
Cost budgeting
Quality planning
Human resource planning
Communications planning
Risk management planning
Risk identification
Qualitative risk analysis
Quantitative risk analysis
Risk response planning
Plan purchases and acquisitions
Plan contracting
Direct and manage project execution
Perform quality assurance
Acquire project team
Develop project team
Information distribution
Request seller responses
Select sellers
Monitor and control project work
Integrated change control
Scope verification
Scope control
Schedule control
Cost control
Perform quality control
Manage project team
Performance reporting
Manage stakeholders
Risk monitoring and control
Contract administration
Close project
Contract closure
Check out this link just for fun: http://www.ibiblio.org/Dave/Dr-Fun/df200210/df20021001.jpg Subscribe to this blog
