Heading Back from PMI LIM...

Okay... So I'm totally out of the habit of writing now. It's kinda sad because I've actually had a ton of thoughts lately on various topics. The challenge isn't just finding the time... It's figuring out how to slice things small enough to make a readable post. I've got lots of big ideas floating around in my head... writing about them is a whole other story.

Anyway... I think I'm just going to try to get back in the habit of posting on a regular basis. I'll apologize in advance if my posts totally suck, or are just simply off topic for a while. Be patient while I get back in a groove. I want to start by talking a little about what I've been working on lately.

As you guys know... I headed out on my own a few months back. That was probably the scariest thing I've ever done in my entire life. It's really tough when you are used to having a boss and an employer to make that leap to being totally self-employed. It's easy to have the mindset that a company is going to take care of you. I'm enjoying taking care of myself.

Anyway... while LeadingAgile the blog is floundering, LeadingAgile the business is doing great. I managed to get myself booked full time with several clients here in Atlanta through the end of the year. My business development pipeline is pretty full and I'm expecting to fill up the first quarter of next year over the next few weeks.

It's been a lot of hard work, but I've been really blessed to have the support of my family and a number of great consultants that have given me some excellent advice along the way. Seriously... I think I'm going to have to do an appreciations post sometime in the next few weeks to thank the wonderful cloud of people that have been behind me through this.

The support has been overwhelming.

For someone that works full time in Atlanta, I feel like I've been on the road a ton. I've done a few trips out to San Francisco and one to Toronto... one of my clients has offices in several locations and that's kept me on traveling a bit. I've also done a little bit of conference travel and some community stuff over the past few weeks. It's been a fun ride.

I'm getting ready to amp up my participation in the PMI Agile Community of Practice. My good friend Jesse Fewell is stepping down (but still on the board) and I am assuming the Chief Product Owner role. I'm counting on the support of Dennis Stevens, Brian Bozzuto, and Jesse and I think we are going to be able to make some good stuff happen over the next few months. I'll keep you guys posted on how things go.

Speaking of PMI, I was in DC this week for the Leadership Institute Meetings. I have mixed feelings about PMI events... the are well done, but there is so much content that just doesn't interest me. That said, like most conferences, all the cool stuff happens in the restaurants and pubs... and we had a ton of restaurant and pub time this week. You guys should see the investment PMI is making in Agile... it's coming guys... you better get ready.

I'll share some picks on my Facebook page (www.facebook.com/leadingagile) for you to check out... it's crazy.

On another note... have you guys heard about the ICAgile project yet? I had the opportunity to spend the early part of this week with Alistair and Ahmed Sidky working through the model in pretty fine grained detail. Aside from being honored just to have a seat at the table, I think these guys are developing a really solid model. Again, something exciting going on that I think you should be paying attention to.

If you want more information on ICAgile, check out their website at www.icagile.com. I plan to blog on this a bit, that that is a whole post in an of itself.

Past that...

Dennis and I have made VERY LITTLE progress on the book. I take full responsibility for our lack of progress... last year I decided to turn my life upside down leaving VersionOne and joining Pillar. This year I did it again leaving Pillar and going out on my own. I finally feel like I've arrived where I need to be, and I feel settled. I am looking forward to restarting that project over the next week or two. More to come on that too, I hope.

On a personal note... my oldest son started high school this year. That's been fun. He is in marching band and we are doing all the Friday night football games. I think I have been to more of his games that I ever went to when I was in high school. Very fun. My youngest son is playing right tackle in the 8yo football team. That's a little scary, but he is having fun with it. My middle son likes to sit on the couch and play XBox... so we are trying to figure out what to do about that ;-)

We are planning a trip to New York over Thanksgiving. We have tickets to Wicked and want to see the Macy's Thanksgiving Day Parade. Past that we are open to suggestions. If you have any thoughts on what we should do, I am all ears. Left to our own devices, I'd go do all the typical tourist stuff. So really, looking for some help here. I've also got some time blocked over the Christmas holidays and I am going to try to spend at least half of them sleeping outside in a tent... wish me luck!

Anyway... I'm excited to start writing again. Hopefully I'll be able to create some momentum here and get back in my groove. Catch you guys later.

Subscribe to Leading Agile

Let's Define Our Starting Place

I'm telling you guys... if you're not participating over on the AgilePMI Yahoo! Group, you are missing out on some great conversation. Think about it... this is THE issue going on right now impacting the agile community. We talk about agile and transformation... but the traditional establishment holds the keys in most of our organizations. Unless we can show them how to transition safely, we are relegated to bottom-up, grass roots agile initiatives... most of which have a very low probability of making any kind of meaningful difference in our companies.

That said, one of the problems I think we have... not just on the Yahoo! group, but as a community in general, is that we often talk past each other on pretty key issues. I was going back and forth with Dan Mezick and Dennis Stevens on the idea of team authorization. All of a sudden it dawned on me that Dan and I agreed in principle on where we wanted to take the organization, but Dan wanted to discuss the organization as it should be... I wanted to talk about the organization as it was, and how we can be successful in it.

It seems to me, that in any conversation, we have at least three possible starting points for debate:

1. The current state
2. The future state
3. The transition state

My guess is that most people in the group agree that something is wrong with the current state of software project management. That is why they spend time reading and posting and exploring how to do things differently. I'd also guess that most folks in the agile community agree on the ideal end state. We might have some differences of opinion around Scrum or XP or Lean or Kanban, but I think we all value the idea of empowering teams, respecting individuals, and helping organizations deliver the most value possible.

Some of us are so passionate about the way things should be, that point of view becomes the starting place, and they argue for change right now. Others of us have heard those messages and found that they don't resonate given the current regulatory climate in our companies. These people want to talk about what they can do today... without some sort of massive transformation. They don't have any clear way to make the kinds of changes that the 'future state' people are advocating. Others, like me, want to talk about how to get from point A to point B as safely as possible.

Understanding the point of view from which the other person is arguing from can be really valuable as we're trying to move this discussion forward. I hate seeing us run in circles with each other when there is probably more we agree on than we really think. The futurists hold the vision, the today people have the current reality, and the transition folks want to find a way to bridge the two. Maybe if we can start our conversations by clearly stating our starting point... and have more meaningful discussions around all three different viewpoints... we might have a way of moving this thing without constantly going around and around, without ever really increasing our understanding.

By the way... here is a link the Agile PMI group if you are interested in joining the conversation:

http://finance.groups.yahoo.com/group/pmiagile/

Oh, by the way... here is day #3 and day #4 of Summer Camp... have fun!

Summer Camp Day #3

Summer Camp Day #4

Subscribe to Leading Agile

Reflections on the PMI Global Congress

It was a pretty quick trip for me down to the PMI Global Congress this week. I didn't even try to get in early for all the LIM stuff and didn't stay for the training sessions that are happening the rest of the week. Pretty much flew in... gave my Agile PMP talk... and got on my way. I've gotten to the point where most conference sessions don't really interest me. The value for me happens in between sessions and over drinks afterwards. That said... the time in between session and over drinks is worth the price of admission.

One of the coolest parts of the conference was getting to meet and spend some time with Bas de Baar. I have been following his Project Shrink blog for a few years now and it was cool to share ideas on project management, social media, and other career related stuff. It was the first time that I got to spend any significant time with Dave Prior (Valtech) or Rodney Bodamer (AgileX). Also spent some time with George Schlitz and Brian Bozzuto... both from Big Visible... both great guys. It's the connections that make these events so special. I was sad that Michele Sliger won't sit next to me anymore ;-)

It will be really intriguing over the next few years to see how the PMI Agile community of practice evolves within a traditional top down organization. It will be fun to see if agile methods are embraced or rejected by the masses. As complexity and uncertainty in software project management goes dramatically up... I can't imagine that standard project management approaches to building software are going to hold. At some point the facade is going to implode and we are going to have to get real about what it takes to manage software portfolios. Hopefully we can lead enough change in that time to really make a difference.

As you'd expect from a conference by Project Managers for Project Managers... everything was well planned, well run, and top notch. The Gaylord Palms hotel is always a great choice for a conference (was there for the Scrum Gathering earlier this year) and the reception at Universal Studios was a nice touch. Having the conference in Orlando gave everything a much different vibe from the conference in Denver last year. Denver seemed much more corporate... Orlando felt a little more laid back. Oh... and my talk went pretty well too.

All in all a pleasurable trip... but happy to be going home!

Subscribe to Leading Agile

The Agile PMI Community of Practice

The Agile PMI Community of Practice officially launches next week at the Agile 2009 conference... and there are LOTS of things going on!

For the full scoop on all the week's happenings... visit the PMI Agile Wiki to get all the details about receptions... events... and speakers. If you are going to are be in Chicago for the conference... if you are interested in Agile Project Management... you NEED to show up... and more importantly... learn how to get involved. I am planning to be at all the kick-off events and many of the sessions. If you happen to see me... please come up... say hi... and let me know if you have any questions.

On a related note... way back when Jesse Fewell decided to start this project... I had been involved helping to create a space for some discussion and arranging a little kick-off cash. When it came time for the real work... my schedule was too crazy... and I had to bail. Jesse let me off the hook the first time around... but now that the organization is a reality... he has asked me to come back and help the team.

For the next year... I have agreed to serve as a deputy Product Owner for the team... with the plan being to assume primary Product Owner responsibilities in year two. My schedule hasn't settled down at all... maybe with the book gotten a little crazier... but this was an opportunity I just couldn't turn down.

At the end of the day... no matter what I do... no matter where I am in an organization... I am a Project Manager. I think like a Project Manager... I act like a Project Manager... and I really like Project Managers. So... I accepted this role because I want to help Project Managers... and organizations... have more effective project management.

My goal is to evangelize to the PMI membership... help them understand why agile works... and why they need agile tools in their toolkit. I am also interested in bridging the gap the other way. I want to help the agile community get some value out of this relationship and learn where and when some of the stuff from the PMBOK can actually be useful.

It will be an interesting year! I hope to see you all in Chicago.

Subscribe to Leading Agile

Slideshare Beta.... The Agile PMP: Teaching an Old Dog New Tricks

The past few days, I have been trying to figure out the best way to upload (and share) slide show presentations with my Leading Agile readers. LinkedIn offers a SlideShare plug-in but I have to send people to my LinkedIn profile in order to see them. I would rather direct traffic someplace that adds more value.

I am experimenting now with a full blown SlideShare account to see if I can embed a link right into this blog post. Please give me you feedback on how it works out. Once I test this out on http://www.leadingagile.com... we'll give it a try on http://blog.versionone.com.

This is my deck from last weeks Agile Development Practices conference titled 'The Agile PMP: Teaching an Old Dog New Tricks. The talk went really well and got outstanding feedback. Please post a reply if you have technical difficulties

The Agile PMP: Teaching An Old Dog New Tricks

View SlideShare presentation or Upload your own.

Subscribe to this blog Subscribe to Leading Agile

More Talking to Project Managers

Here is my last post for Artem's Agile Software Development... republished here for the benefit of my Leading Agile readers.

Last post we explored some ways to introduce agile concepts to traditional project managers and how to make a case for agile in a way that has a chance to really resonate. We explored how to discuss time, cost, and scope… talked a little about dealing with uncertainty… and a little about the factors that are really constraining our projects.

If you are interested in catching up with the conversation, go back and take a look at my post "How to Talk to Project Managers" at http://agilesoftwaredevelopment.com/blog/mcottmeyer/how-talk-project-man...

This past Tuesday, I was up in Vancouver doing a workshop on these very topics. About half the class self-identified as a PMP certified project manager… the others were either uncertified project managers or development leads. Most of the folks rated themselves a three or four (out of ten) on their agile expertise. We had a few folks in the class that rated their knowledge in the five to eight range, and after doing the course, I agreed with their assessment.

Most of the people in the course were there to learn more about agile or to learn how to sell agile in their organizations. They wanted to understand the agile value proposition and how to go back and communicate agile in a way that really resonated with their businesses. We were off to a good start.

My talk generally followed the outline from "How to talk to Project Managers". People were taking notes and seemed engaged... but, sometime around lunch things started getting more difficult. After laying the foundation around the triple constraints, uncertainty, and project drivers; I had hoped to move into agile principles and project management techniques. What I found is that I had left out a critical component of the discussion.

I had not addressed how their organizations were currently structured and the barriers this would introduce to agile adoption. I started talking about teamwork and collaboration and they were thinking about matrixed organizations, task sequencing, and resource management… I had needed to address this issue head on and my failure to do this caused the class to spin a little out of control.

We ended up spending a great deal of time talking about merits of generalization and the challenges associated with specialization. We talked about how to deal with agile teams when some degree of specialization is required. We explored what it meant to be a team and what creating teams would mean for their organizations. We talked about the differences between iterative and incremental development versus agile development. We explored what it means to be a project manager in an agile organization.

What I learned was that there is a bunch more we needed to talk about before we could move to agile principles and practices. We needed to introduce a few more concepts before we started talking about agile project management. We needed to address matrixed organizations, building teams with specializing generalists, and the role of the project manager on an agile team.

Here is some thinking I've done on these topics over the past year:

http://www.leadingagile.com/2008/07/managing-too-much-complexity.html
http://www.leadingagile.com/2008/04/what-about-me.html
http://www.leadingagile.com/2008/10/agile-or-iterative-and-incremental.html
http://www.leadingagile.com/2008/06/project-managment-is-not-enough.html

Happy reading. Please comment on how you are talking to your organization about agile and what messages you have found that resonate. If I use something you submit in a talk, I make sure to credit your contribution.

Subscribe to this blog Subscribe to Leading Agile

How to Talk to Project Managers

Last week, I had had the distinct pleasure, the rare opportunity, to attend the PMI Global Congress in Denver, Colorado. I missed the deadline to propose a talk but there were at least 5 agile presentation happening over the course of the event. That is really good news. The PMI crowd is interested and trying to understand what this agile stuff is all about.

I was working the VersionOne booth, so while I had a full conference pass, I did not get to go to any of the talks... bummer.

Note: This post was written last week, so I am writing like I am there now. I decided to leave the language that way... hope it is not too distracting!

Talking to Project Managers

It has been really fun talking to all the folks that have come by to see our software. The people that stop to talk to us have already been exposed to agile on some level, so my perspective might be biased, but there are many more agile friendly people that I expected. Again, people are interested and want to know more.

After my first full day of meeting and greeting the conference attendees, there is one thing I would like to share with the agile community. When you talk to a traditional PM about agile project management, you need to be prepared to speak their language. While teamwork and collaboration are important, that is not the language of the PMI crowd. Empowerment is essential but can be very threatening to someone that is accustomed to being "in control".

I've found that a good place to start is with a discussion of the triple constraints.

Managing the Triple Constraints

Most traditional projects start with some assessment of scope; an assessment of what the stakeholders want to be built and what they are willing to invest money to have. From there the team does some analysis, figures out how big the request is, and what will be involved in building it. We do an assessment of the team, understand who is available (and when), and begin to lay our dependencies and calculate the critical path. From there we determine a date.

Ask your PM friend if that sounds much like their personal experience? They will inevitably nod 'yes' because that is what project managers are taught to do. Next ask them what happens after they communicate the project costs and delivery date of the project? I would bet money that their response will be somewhere along the lines of: we are given a date, we are given a budget, and then we start de-scoping the project.

Sometimes, if management really does not care about successful delivery, they are just given the date, and the budget, and are made to deliver all the requirements anyway.

Our Real Project Drivers

This is where you can explain that they are given the date and the budget because those were really the project constraints to begin with, not the requirements. We pretend the requirements are the constraint because, like most people, stakeholders hope that we will be able to get everything we want for what they are able to spend. Most of the time that is not the case.

So, where do we go from here? I will typically explain that agile project management starts with time and cost as the primary constraints and introduces techniques that enable the business, in partnership with the team, to decide what is the best set of requirements to build. After delivering this line, be prepared for the blank stares.

But I Have to Deliver Everything

The blank stares are because project managers are trained that they have to deliver everything. The executives demand it and the stakeholders cannot take the product to market unless they have everything. Now it is time for more questions. Ask them if that approach ever works? The answer is always 'no'. Ask them what happens when projects start this way. They will answer that the project is always late or over budget.

The reality is that by demanding ALL the scope, in the face of data that says otherwise, the business is making the implicit decision that their project will be late. You are generally not rewarded, or very popular with your stakeholders, if you bring this to their attention. Project managers are often incented to keep their heads down, do their best, and take their lumps when things are late.

As a quick aside this is the main reason most project managers rely so much on process and documentation. It allows them to cover themselves and be 'successful' in an impossible situation.

Most Project Managers Don't Make the Call

The reality in many businesses is that the project managers are not empowered to make the time, cost, and budget decision; and even if they bring these issues to the attention of senior management, they may be forced to proceed with the project anyway. This is your hook to talk about why agile can be such a valuable addition to their PM toolkit.

Delivering in short cycles and measuring done gives you real data about the health of your project. Managers often assume the team has overinflated the estimates. They assume the team is sandbagging. Agile gives you real empirical data about the status of your project and what the team is capable of delivering. Agile gives the business real data, and real options; options that go beyond just how late and over budget do you want the project to be.

Put the Business Back in Control

Agile gives the business the opportunity to effectively de-scope on the fly, to change their mind, to increase the cost of the project, to lower the cost of the project, to deliver early, to deliver late, or to kill the project all together if the business objectives cannot be met. They get this information early, when there is still time to deal with it and make a rational business decision.

The senior managers I have worked with will make good decisions when presented with good data and real alternatives. Bad decisions are made in low trust environments with poor information.

Now Let's Talk Agile

So, with that groundwork in place, you can start talking about teamwork, collaboration, and empowerment. You can start talking now about pair programming, continuous integration, and test driven development. Those things just don't mean much to the PM community until you help them understand how agile will fundamentally put them in a position to deliver quality projects: on time, on budget, and with the highest value that can possibly be delivered.

Until then, people are just not going to get it. So next time you are talking to someone with a PMP next to their name, make sure you are speaking a language they can really understand. The traditional community is willing to listen, we need to make the most of our opportunity.

Reposted from Artems Agile Software Development blog: http://www.agilesoftwaredevelopment.com

Subscribe to this blog Subscribe to Leading Agile

Refactor Your PMP: Human Resource Management

Back so soon? I told you guys it was time to get this knocked out! Last post we talked about Quality Management, this post we are going to hit Human Resource Management.

According to PMI, Human Resource Management includes the processes that manage and organize the project team. Pretty simple huh? This is an interesting topic because we generally want agile teams to be self-managing and self-organizing. Do we throw this one out all together? Is there any way we'll be able to bridge the gap?

I've got to honest with you guys, I am not exactly sure where this one is going to end up. Let's jump in and see what we can do.

Human Resource Planning

PMI Definition: Identifying and documenting project roles, responsibilities, and reporting relationships, as well as creating the staffing management plan

Does a RACI diagram have any place on an agile team?

Agile tends to assume that you are staffing your team with specializing generalists. What is a specializing generalist you ask? These are people that may have specialization in a given area but are willing and able to operate outside their area of specialization.

Specialization is problematic because it leads to matrixed organizations. If a specialized skill set is required only part of the time, we need to find something else for that person to do with their downtime. Organizations end up filling that downtime with other project work. The problem here is that working on more than one project dilutes focus and creates artificial dependencies between projects. Real dependencies are one thing, self imposed dependencies are quite another.

Specializing generalists allow me to have a single person do more than one kind of work, eliminating constraints, and reducing the need to matrix people across multiple projects.

Teams work best when they stay together and are all focused on a common objective. They establish a stable throughput, they trust each other, they understand how to work together. Agile values continuity and it's part of what keeps agile teams fast and lightweight. This is a very difficult, if not impossible, to achieve in a matrixed organization.

That said, we still need to know overall what skills are required. We need to do the necessary due diligence to make sure that our team collectively has the competencies required to deliver. We need people that can potentially fill several roles on the team. If a RACI diagram helps you figure that out… go for it.

Acquire the Project Team

PMI Definition: Obtaining the human resources needed to complete the project

After giving this one some thought, I don't think agile has much to say here or much overlap with PMI. I'll just take this opportunity to restate the importance of building teams with specializing generalists. Getting the right people on the bus makes all the difference.

Develop the Project Team

PMI Definition: Improving the competencies and interaction of team members to enhance project performance

Agile teams improve competency through collaboration and teamwork.

How does collaboration and teamwork come into play on agile teams? Most teams will have a mix of senior people and junior people, people who are better in one are of the application than in another area of the application. Agile encourages close collaboration amongst team members, pair programming, and shared ownership. It gives everyone the opportunity to broaden their skillsets, learn new technologies, and become proficient in areas of the application they might not otherwise touch.

Daily standup meetings keep people involved and connected with each other. Retrospectives help the team learn from each other and decide how to work together more effectively. Creating this collaborative learning environment is one of the reasons that collocation is such an important aspect of building agile teams. Agile leaders value team building and collaboration so much, they tend to focus more energy on activities that give opportunity to develop closer interpersonal relationships.

If your team members lack a particular competency, and no one on the team has that skill, training one or more folks becomes a critical success factor. Make sure you have that time and money in your overall project plan for formal training.

Manage the Project Team

PMI Definition: Tracking team member performance, providing feedback, resolving issues, and coordinating changes to enhance project performance.

Ideally we want our teams to be self-managing and self-organizing. Give people the objective and get them the environment and the tools they need to deliver. The agile project manager can play a huge role in creating the kind of environment for this kind of behavior to emerge.

An agile PM needs to lay out the vision, make sure the team has the necessary skills to do the job, layout the initial planning structure, establish the metrics, and support the team by removing the things that get in their way. Part of establishing structure is keeping things visible and maintaining a culture of accountability. Iteration planning, daily stand-ups, product demos, and retrospectives help create this culture.

As an agile PM, I almost always track project burndown, iteration burndown, defect trends, and historical velocity. These metrics, in conjunction with the daily standup, usually give me a pretty good idea of how the team is doing. There have been times when I have needed to track individual hours and individual velocity but these cases should be the exception to the rule.

Agile definitely puts more emphasis on leading the team over managing the team. The reality is that sometimes your team is not healthy and mature or in a good place to manage themselves. A good manager, with a focus on servant leadership, can help create an environment where teams can thrive and people can learn what it means to take full ownership of project outcomes.

Now if we could just get PMI to stop calling our team members Human Resources!

Subscribe to this blog Subscribe to Leading Agile

PMI Agile Special Interest Group

The past few weeks I have been involved with a group of folks that are working to start up a special interest group within the PMI, specifically around agile methodologies. There are some pretty heavy hitters involved: Michele Sliger, Stacia Broderick, Mike Griffiths, Mitch Lacey, and Jesse Fewell amongst others.

As the PMI begins to accept some of the agile practices into the PMBOK, this group could be influential in helping to shape that content. There may be room for a domain specific addendum specifically addressing agile practices.

I am interested to know what you think. Is this a bad idea? Think it is a good idea and want to help out? Should APLN support this initiative? What are the risks? There are lots of questions to answer and I am really interested in your thoughts.

Please feel free to share your comments? If you want know more, take a look at the following FAQ for a little more information.

Subscribe to this blog Subscribe to Leading Agile

Refactor Your PMP: Quality Management

Okay… it has been a while since my last installment in this series. Aside from my general inability to stay focused on a single topic (what was I thinking committing to a nine part series) I got really swamped preparing for Agile 2008. I've got two talks coming up in November on this material, one of which has a presentation due in early September, so I guess it is time to get busy and get this series wrapped up.

Last time we covered Communications Management, in this post we'll discuss Quality Management.

As always, let's start with the PMI definition of Quality Management. According to PMI, Project Quality Management includes all the activities of the performing organization to determine quality policies, objectives, and responsibilities so that the project will satisfy the needs for which it was undertaken. There are three processes included in this knowledge area: quality planning, perform quality assurance, and perform quality control.

If you've been following this series, you'll know that my general approach with the PMI is to take guidance from the PMBOK and figure out how to satisfy the intent of the process with a more agile practice or principle. Agile is all over quality planning, quality assurance, and quality control but we often use different language to describe how we satisfy these objectives and we often plan for these activities in a pretty different way.

Let's see what we can do to bridge the gap...

Quality Planning

PMI Definition: Identifying which quality standards are relevant to the project and determining how to satisfy them

Quality planning is really about the initial set of assumptions (we make as an agile team) about how we are going to manage quality on our projects. As it relates to developing software, quality planning has mostly been done for us… it is implicit… it is understood by virtue of the fact that we are using an agile methodology.

When we have discussions about doing test driven development, pair programming, or continuous integration; we are making decisions about how we are going to handle quality. The decision to make use of acceptance criteria is simply a decision on how we will know we have met the requirements of our stakeholders.

Are we going to do unit testing? How about manual regression? Will we need to test for performance, scalability, or security? How will we know we have met any applicable regulatory or audit requirements? I would venture to say that most agile teams are having these conversations. Even if your team is not writing this stuff down or getting sign-off, you are implicitly developing your quality plan.

It is up to the team to balance how much of this needs to be documented. Ask yourself to what degree will a document facilitate understanding or help with stakeholder communication? Consider how much documentation is required by your organization. Keep things simple, minimally prescriptive, and make provisions to adapt your plan as you learn more about the emerging solution.

Perform Quality Assurance

PMI Definition: Applying the planned, systematic quality activities to ensure that the project employs all processes needed to meet the requirements

You've made some initial decisions about how your team will meet the quality expectations of the organization… now it is time to execute. Quality assurance is about making sure we are building the right product from the very beginning.

Early in the iteration, we meet as a team with our customers to define exactly what is to be built. Every role on the project has the opportunity and is encouraged to be involved. There are people looking at the requirements from every conceivable angle: system architecture, development, QA, analysis and design, and usability. We explore the problem from all perspectives, before we set off writing code, to ensure we are building a complete product.

Once we get started building out the features, we immediately execute our testing plans. At a minimum, agile teams are writing unit tests and doing continuous integration. We know at every moment of the project how well the code is performing against the requirements.

If your team has dedicated QA members, the QA folks are testing right along with the development team. Sometimes it is more exploratory and we are not looking for sign-off, we are really looking for feedback. Feedback from the QA team is essential to making sure that the product is evolving according to the quality standards we agreed to at the beginning of the iteration.

The team holds itself accountable by meeting in a daily standup. This allows the team to stay plugged in, assess progress, and identify impediments. In addition, the team has constant access to the product owners. This constant visibility allows the customer to fine tune the solution, as it is being built, to ensure that the product will meet market requirements.

Perform Quality Control

PMI Definition: Monitoring the specific project results to determine whether they comply with relevant quality standards and identifying ways to eliminate causes of unsatisfactory performance.

Even though quality is the focus from the very beginning in an agile project, we still seek to validate outcomes and formally track the quality of the product we are building.

The advantage of automated testing is that we know the health of the product in real time. We are able to measure and track defects and get them resolved as soon as they are introduced into the build. Manual testing, in parallel with the automated testing, gives a more intuitive way to exercise aspects of the code the are difficult to automate.

As a project manager I am constantly tracking burndown at the project level to see how well the team is doing against the backlog. Within the iteration, I am tracking task progress to make sure that we can deliver on our commitments. Agile teams also track defects, defect status, and test trends. All this gives the team a way to continuously control the project quality.

Agile teams don't wait until the end of the project to test, when we have the least amount of time to actually fix a problem, or respond to a change. We know at all times the health of the project, if the team is burning hot, if defects counts are trending up or down, how well we are resolving issues, and if those issues are becoming impediments to getting new product built.

Agile teams review features with their customer as they are completed. They do formal product demonstrations and retrospectives at the end of every iteration. These processes allow the team to control, not only the quality of the emerging product, but also of the processes we are using to deliver that product.

All of this feedback gets folded back into the plan, adjustments are made, and the team adapts based on what they have learned from regularly delivering code.

Next up… Procurement and Human Resources. We'll save Risk Management and Integration Management for last!

Subscribe to this blog Subscribe to Leading Agile

Refactor Your PMP: Communications Management

As promised… next up we're talking about Communications Management.

According to PMI, Project Communications Management employs the processes required to ensure timely and appropriate generation, collection, distribution, storage, retrieval, and ultimate disposition of project information. This knowledge area provides the critical links between people and information that are necessary for successful project communications.

There is a neat little book by Andy Crowe called "Alpha Project Managers: What the Top 2% Know That Everyone Else Does Not". This book surveyed over 5000 project managers to find out what the best project managers are doing differently. One of Andy's conclusions is that top project managers spend significantly more time communicating than their less successful brethren.

In some cases these top project managers spent up to 90% of their time communicating in one form or another. I have to say, that is certainly consistent with my personal experience. If something is going wrong on one of my projects, it is usually because people are not talking to each other.

But maybe I am taking a naïve view of what it means to communicate on a project? It seems to me that the PMI definition of Communications Management is a little broader than just making sure the team is talking to each other. Communications management deals with documents and plans and stakeholders. Communications management is really about managing the flow of information.

Since it's common knowledge that Agile teams don't do documents, I am guessing we have some work ahead of us to reconciling these points of view.

Okay… I was kidding with the Agile documentation comment. That said, there is clearly a difference in how these two project management perspectives treat the issue of documentation, reporting, and even interpersonal communication.

Both PMI and Agile have quite a bit to say about how to manage project communications so let's get started.

Communications Planning

PMI Definition: Determining the information and communication needs of the projects stakeholders

When Agile teams talk about communications, they are usually talking about communications within the team. Agile puts a great deal of emphasis on the free flow of information between team members, between team members and the product owner, and even between the team and the direct customer. In some ways, the Agile community has really abstracted the entire stakeholder community behind the role of Product Owner.

Communication between team members, and between the team and its customers, is essential but it is not the only component of communication that must be planned. Sometimes there are other stakeholders that we must take into consideration.

At the team level, we usually deal with team member communication through collocation, whiteboards, wikis, and other rich and collaborative workspaces. Agile teams trade a great deal of written documentation for these more osmotic forms of information exchange. On a small team with a single customer, it might be sufficient to suggest that customers get all the information they need from attending planning meetings, daily stand-ups, and iteration reviews.

When there is more than one stakeholder, or possibly a hierarchy of stakeholders , sometimes it is not sufficient to suggest that these stakeholders come down to the team room and check out the team's progress on the Kanban board. Sometimes we need to do some roll-up reporting across a portfolio of projects or even programs. Sometimes we need to report status at a much higher level of abstraction for a more senior audience.

The key to planning communications on an Agile project is to follow the principle of simplicity. Don't write documentation for the sake of documentation. Find out what your stakeholders really need and provide it as quickly and as simply as possible. Make use of natural information sources that the team is already producing (task boards, burndown charts, architectural representations) and create documentation that enables your business to make decisions.

Keep things light, go for face to face whenever possible, and when your stakeholders require more; make things as simple, clear, and accurate as possible.

Information Distribution

PMI Definition: Making needed information available to project stakeholders in a timely manner

At the team level, information distribution focuses on those rich channels of communication I mentioned in the last section. Agile teams keep their status up to date using large, visible information radiators that everyone in the team room has access to and can update themselves. These repositories of information are there for the team to know where it is at all times and so they can manage their work. The side effect of these radiators for the Project Manager is that you have instant access to real time information about the health of the project, release, or iteration.

Often, design and architecture will be worked out on whiteboards and then minimally documented on a Wiki or Sharepoint so they can be easily changed as we learn more about the evolving system. Agile teams lean toward lightweight artifacts and central, universally accessible document repositories. Agile teams recognize that the only truly accurate representation of the product is the code itself ; therefore documentation is kept light and at a pretty high level.

Sometimes a customer has a need for more detailed documentation to manage an external dependency or possibly an audit requirement. In these cases, that increased level of documentation is built into the estimate for the feature. Documentation is not free and it will slow down the creation of working software.

The key once again is to figure out what is the minimum amount of documentation needed to satisfy the requirement. Document systems at the highest level of abstraction you can get away with. Make sure you understand the information needs of the external stakeholder, make sure that work is represented in the backlog, and that it is prioritized to meet the needs of the organization.

Use the same collaborative techniques you would use to build features to create the documentation required by the business.

Performance Reporting

PMI Definition: Collecting and distributing performance information. This includes status reporting, progress measurement, and forecasting

Okay… so we've already talked about things like burndown charts and Kanban boards. These are tools that a team will use to organically manage their work and make sure they are on track. As an Agile project manager is your responsibility to help the team and encourage that these tools are kept up to date. For the most part, these are the only tools you will need to understand the health of your project, and you largely get them for free.

Performance on Agile projects is pretty simple. You know how big your backlog is and you know how much you are able to complete each iteration. Based on these two variables you are able to predict how many features you will be able to complete before the end of the project, release, or iteration. I personally like to keep a high level project roadmap that helps me understand where the project is expected to be at certain points as it progresses to completion. This is also useful for managing external dependencies.

These simple tools help you understand what progress you are making against expectations and if you'll need to extend the release, adjust scope, or request additional funding. Since you are an agile team, you'll more than likely be communicating how early you'll be, how much more you'll be able to do, and how much more value you've delivered to the organization.

Either way, you have a tremendous amount of information at your disposal to communicate project to the project stakeholders. Think EVM based on delivery of working product.

Manage Stakeholders

PMI Definition: Managing communications to satisfy the requirements and resolve issues with project stakeholders.

Managing stakeholders is really about managing the issues that come up during the life of the project. A significant benefit of Agile is that nothing is hidden. This level of visibility gives the project manager the information they need to resolve problems and remove impediments.

Issues can arise during iteration planning, execution, closedown, or just in the course of day to day work. Just like on any project, these need to get tracked and dealt with as soon as possible. Issues are reviewed during the daily stand-up meetings and retrospectives.

There are always going to be some issues that cannot be dealt with by the team. I typically hold a weekly or bi-weekly meeting with senior stakeholders where they get a distillation of significant impediments and what I need them to do to help me resolve the issue.

It is my opinion that stakeholders need to be managed and issues resolved no matter what your software development methodology.

I think that does it for this installment. That was much longer than I had expected. I figured communications management would be one of the easier topics to discuss. Maybe I just need to go home for the day.

Let see… next up… Quality Management.

Subscribe to this blog Subscribe to Leading Agile

Refactor Your PMP: Scope Management

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 Subscribe to Leading Agile

Refactor Your PMP: Cost Management

Next up is cost management. According to PMI, cost management includes the processes involved in planning, estimating, budgeting, and controlling costs so that the project can be completed within the approved budget. This knowledge area only includes three process, but as you might expect, we are going to put a little different spin on them and see what we can do to make them more agile.

Cost Estimating

PMI Definition: Developing an approximation of the costs of the resources needed to complete the project activities

We discussed in the last post that agile projects typically start with time and cost as the primary constraints and float scope through the life of the project. While this is true, there should always be some sort of assessment at the beginning of the project to determine what value the customer might expect at what level of investment.

The product owner might approach the team with a high level backlog of features that need to make the next release. The team would then estimate the backlog and calculate how many iterations they expect the work to take. There would be a negotiation of scope, team composition, and release duration as everyone comes to consensus around what is possible.

The cost of the project is then established as the product of team size and project duration.

Cost Budgeting

PMI Definition: Aggregating the estimated costs of individual activities or work packages to establish a cost baseline

Agile teams assess the relative size of each item in the backlog. Some teams also put a numeric value on the expected ROI of each feature in the backlog. In aggregate, the size of the backlog determines how many features can be delivered and thus the overall value of the release. Because costs are assumed to be a constraint, cost budgeting on an agile team is much more a statement of how much value can be delivered, over the life the project, for the approved budget.

The budgeted amount of value for the project is represented in the release backlog.

Cost Control

PMI Definition: Influencing the factors that create cost variances and controlling changes to the project budget

With the cost of the project now established as a project constraint, agile project are not nearly as concerned with controlling the costs and variances of individual work items. Agile teams are most concerned with how quickly the project begins delivering value and at what rate. We need to monitor how well we are delivering the anticipated features and if we have deviated from the rate we had originally expected.

If the project is not progressing as well as we might have hoped, we may need to remove less important features from the backlog. This will decrease the value to the customer and implicitly increase the cost per feature. If the product owner chooses to extend the duration of the project, to realize all of the anticipated value, this would increase the real costs to the project.

Delivered value is tracked primarily by measuring project burndown. Here we assess the total value of the release, what value the team had expected to deliver at the end of every iteration, and compare the actual value delivered against the ideal.

By monitoring project burndown the team can assess and control the cost impact to the overall project.

Next up... Scope Management

Subscribe to this blog Subscribe to Leading Agile

Refactor Your PMP: Time Management

The first knowledge area we are going to tackle is Time Management. According to PMI, time management involves those processes that contribute to the on-time completion of the project. This knowledge area includes six project management processes designed to accomplish this goal. We'll explore all six and see how we can adapt these processes to make them a little more Agile.

Activity Definition

PMI Definition: Identifying the specific schedule activities that need to be performed to produce the various project deliverables.

To make this process more agile, you first need to think in terms of defining the features of the system, not the activities. Up front we want to know how the system is going to behave. These feature specifications need to be small and independent of each other. Agile teams usually call these features a user story or a backlog item. Collectively the list of product features is called the product backlog. The backlog represents the scope of an agile project.

Activity Sequencing

PMI Definition: Identifying and documenting dependencies among schedule activities

While discussing activity definition, we stated that the backlog items need to be independent of each other. The reason they need to be independent is because we want to have the ability to change requirements as our understanding of the evolving system changes. By definition we are seeking to minimize the dependencies between the work items on our project. Sequencing on an agile project is based less on dependencies and more on risk and business value. We want to focus on sequencing based on which features are going to reduce the most risk and deliver the most value as early in the project as possible.

Activity Resource Estimating

PMI Definition: Estimating the type and quantities of resources required to perform each schedule activity.

In traditional project management approaches, we are usually trying to determine the type and quantities of resources when we know the least about what it is we are going to build. Spending time and money to get a better understanding of these variables is not going to yield a substantial return. Agile approaches use a technique of estimating that relies on the collective understanding of the team to determine a relative size estimate of the feature, often measured in units such as story points or ideal engineering hours. These units only asses the size of the feature relative to the other features in the backlog.

Activity Duration Estimating

PMI Definition: Estimating the number of work periods that will be needed to complete individual schedule activities

We've discussed that each feature in the backlog needs to be small. Our goal is to have every backlog item small enough that it can be delivered within a single iteration. Agile teams build in this constraint and then measure how many features they are able to complete in a given iteration. By measuring how many story points, or ideal hours, they are able to complete each iteration, the team can predict how many iterations it will take to complete the backlog.

Schedule Development

PMI Definition: Analyzing activity sequences, durations, resource requirements, and schedule constraints to create the project schedule

Typical agile projects begin with a time constraint, iterations are fixed periods of time and release schedules are usually established at some fixed interval. Each of these are set by the team and the product owner, but once set do not change. That language might sound a little strong but agile is about building trust with your customer. Good agile teams can always make their date, it is the scope that will vary.

Schedule Control

PMI Definition: Controlling changes to the project schedule

Because the iteration and release timeframes are fixed, it all comes down to a discussion around scope. These discussions are a constant collaborative effort between the product owner and the team. The product owner always has the option of adding additional iterations to include more features. Because the features are discrete, and the team is always working on the highest priority features first, the product owner also has the option of calling the project complete at the end of any iteration.

As always, if you think there is anything I left out, or should have dealt with in more detail, please let me know via response to this post. I speak on this subject quite a bit so anything you have to contribute to make this brief explanation more understandable would be really appreciated.

Next up we'll deal with cost management processes.

Here is a link to my post on Agile Chronicles:
http://blog.versionone.net/blog/2008/06/refactor-your-p.html

Subscribe to this blog Subscribe to Leading Agile

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:

Assumptions are Made to be Validated - Mike Cottmeyer

Inverting the Iron Triangle - Mike Cottmeyer

Calgary APLN Meeting Slides - Mike Griffiths

PMBOK 4, This Time It's Agile - Mike Griffiths

Herding Project Managers - Mike Cottmeyer

The Role of the Project Manager - Glen Alleman

Subscribe to this blog

Subscribe to Leading Agile

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

1. Validate the traditional project management processes
2. Explain why these processes break down in certain problem domain
3. Listen for objections and understand their point of view
4. Explain how agile project management solves some of these problems.

What do you think?

Subscribe to this blog

Subscribe to Leading Agile

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.

Subscribe to this blog

Subscribe to Leading Agile

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

Subscribe to Leading Agile