PMBOK Archive

ACP Community Guide vs AgileBOK

– April 24, 2012Posted in: Agile, Application Development

The Community Guide of the PMI-ACP (login required) is an initiative of the PMI Agile Community of Practice to provide ongoing support for the PMI-ACP agile certification. PMI Today recently highlighted the importance of community volunteers to create the certification, so it only follows that our community be the ones to mature it into the future.

What about the AgileBOK?

There will be no Agile Body of Knowledge (AgileBOK) supported by PMI. PMI does not own, maintain, or support ANY web presence that lives outside of PMI.org. There is not, and never should be an authoritative standard for Agile. Having an AgileBOK would invite all PMI project managers to rigorously follow a standard and never adapt, tailor, or innovate their processes. This counters what we as Agilists stand and strive for.

How can you contribute to the Community Guide?

Team members will work as individual contributors within the Community Guide project. Their involvement may vary based on the nature of the work and their availability. If you are interested in creating or maintaining articles for the ‘Community Guide’, contact the current co-leaders of the ACP Support Team: Joeseph Flahiff and Derek Huether

Who is the Community Guide for?

The Community Guide is intended to be the authoritative source for all the stakeholders in the PMI-ACP ecosphere, including

• A study reference for those pursuing the PMI-ACP credential
• A training reference for REPs and trainers
• A technical reference for exam writers

What does the Community Guide cover?

The Community Guide is a unique community resource, offering you

• Links to relevant PMI documents regarding the certification
• The original intent of the PMI-ACP creators for each topic on the exam
• The current community consensus on how each topic works on “most agile projects, most of the time”

Image Source: Pictofigo

Popularity: 1%

Tags: ACP, Community Guide, PMBOK, PMI, PMI-ACP

Social Norms at Work

Derek Huether

– April 29, 2011Posted in: Agile, Project Management

I recently gave a talk in Michigan on the topic of servant-leadership. Unfortunately, servant-leadership is something that is painfully absent in so many organizations. Just a few years ago, it (servant-leadership) was not something I had even heard of. Going back and reviewing the PMBOK made me realize two glaring omissions. There is a lack of content on stakeholder or team engagement and there is a lack of content on leadership. Fortunately, in the last few years, I have enjoyed books by authors like Clay Shirky, Seth Godin, Dan Pink, and Dan Ariely. I’ve also met and interacted with some amazing people in the Agile community. I now interact differently with my peers, as a result of these experiences. I now apply my social norms at work. What are social norms? They are patterns of behavior in a particular group, community, or culture, accepted as normal and to which an individual is accepted to conform.

We all go to work and we all get paid to do it. Too many times, we take things for granted. We don’t question the things we do or the things that happen to us. I’m pretty sure this is based on conditioning over a long period of time. Perhaps we need to start treating those we work with more like those we socialize with. Next time you interact with a fellow employee, ask yourself if your behavior is socially acceptable.

Social Norms

Within an organization, where we are working with other people, things can get twisted. Some exhibit bad behavior and believe it’s somehow forgivable because we’re all getting paid. Well, I don’t think that’s acceptable. It’s very interesting to see the same people behave differently, when not in the office environment. Why is it some people forget basic manners or common courtesy, when in an office environment?

Case in point, I hold the door open for people, regardless if I know them or not. I see this as socially expected behavior. Socially, I expect a thank you. To say I expect it is a slight embellishment. Outside of the office, I still expect a thank you. Unfortunately, at the office, I’ve started to accept not getting any reciprocation. There are a few people in my building that I don’t personally know but I still hold the door for them. They won’t make eye contact with me and they won’t say thank you. When the situation is reversed, these same people do not hold the door for anyone. But, I refuse to accept their behavior.

We all need to strive to understand and empathize with others. People need to be accepted and recognized for their special and unique qualities. Assume the good intentions of your coworkers and don’t reject them as people, even while refusing to accept their behavior or performance.

Drawing: Pictofigo

HT: Business Dictionary

Zombie Procurement Strategy

Derek Huether

– January 21, 2011Posted in: Agile, Project Management

The last few weeks I have been advising a Federal Procurement team as they refine a Procurement Statement of Work (SOW). Unfortunately, I see the existing version as being very heavy and I want the final product to be much more lean. A perfect example is the current program has 29 documents that are contractually required to be delivered. Do these documents provide value? No, most of them to not.

Opportunity 1

Instead of writing the SOW with statements like “Contract holder will deliver this document” and not provide why or how it will help the customer accomplish their goals, I think we miss an opportunity. I believe we need to advance the conversation with the potential vendors, by structuring the future work as Epics. As long as the customer quantifies “reasonable”, we give the potential vendors an opportunity to think outside the box.

As the owner of the production system, I want to be able to know the average wait time when a customer calls, so I can ensure they are receiving a reasonable level of customer service.

Opportunity 2

Rather than using practical wisdom to create a new SOW, some would rather rely on past policy, procedures, and governance, regardless of current and future needs or if they ever made sense. I’ve challenged some by saying there are no procurement requirements stating that we must have these 29 documents. One Zombie response was ”I found management plans and documents referred to in the PMBOK. We should require the vendor to deliver all of them “.

Before I emptied a full can of Zombie Away on him, I said that wasn’t the most efficient approach. The PMBOK also says to use “expert judgement”. If you are not prepared to use expert judgement, a vendor is going to take your Zombie money and walk off with it. All you’ll be left with is an empty wallet and 29 documents.

I’m all for looking to the PMBOK for guidance. But remember, it is a guide, not commandments.

Like the image? Find it at Pictofigo

Popularity: 1%

Tags: Epic, PMBOK, Procurement, Zombies

Procurement Zombies

Derek Huether

– December 23, 2010Posted in: Project Management

I just finished reviewing a 42 page Statement of Work (SOW), which at some point will become the basis of dozens of (if not more) proposals, which will result in the award of a contract. If there was ever a time I would want to guard myself against zombie infiltration, the procurement cycle would be it. But at some point, zombies will get involved. In an attempt to be thorough (yet entertaining and brief) let’s focus on the Project Procurement Management processes: Planning, Conducting, Administering, and Closing.

Planning

The process of documenting project purchasing decisions, specifying the approach, and identifying potential sellers.

Conducting

The process of obtaining seller responses, selecting a seller, and awarding a contract

Administering

The process of managing procurement relationships, monitoring contract performance, and making changes or corrections as needed.

Closing

The process of completing each project procurement.

I pulled these from Chapter 12, Page 313 of the PMBOK Guide 4th Edition

For the sake of brevity, I am not going to tell you the right or wrong way to manage procurements. I’m not a procurement specialist. So instead, since it’s Festivus, I’m going to air grievances.

Procurements involve currency. That means that if it is your money being spent, you want to get as much value for your money as possible. It also means that if it is not your money being spent, zombies seem to be drawn to procurements more than brains. Don’t ask me to provide a metric for this. Just trust me.

In 15 years, I can not say I’ve witnessed any zombie activity at the planning stage. Then again, I’ve never seen a unicorn either but I’m not saying they don’t exist. Perhaps the zombies defer to the humans at this early stage. But the further along in the process, the more zombies seem to appear. If you really want to see a zombie swarm, add a purchasing card into the mix. Somehow, purchasing card usage can actually accelerate human-zombies transformations.

Opportunistic Procurement Zombie

Let’s say a zombie needs a new computer because its current one died. I know, ironic. The undead having something die. Anyway, it gets on the phone with someone willing to sell a new shiny computer. If the boss fails to establish a budget or specific specifications for the replacement device, there’s a pretty good chance the zombie is going to order much more than really needed. Good planning in this case, can cut down on zombie purchasing.

Entitled Procurement Zombie

Back in the day, working as a hardware consultant for a few federal programs, I witnessed a strange sense of entitlement. When it comes to zombie to human ratios, I’ve seen way more zombies on September 30th of each year than on any Halloween. These zombies, to ensure their program budgets will be equal or greater than the year before, go on a wild spending spree every September 30th (end of the fiscal year). I knew a colleague who worked for a zombie on a federal program. He was given a purchase card and instructed to contact Dell and order as many laptops as possible until he had spent “X” dollars. He was they instructed to ask them to not ship the laptops because the program had no need for them and nowhere to store them.

If you enjoyed the post great! If not, I will challenge you to a feat of strength.

Like the image? Find it at Pictofigo

Popularity: 1%

Tags: PMBOK, Procurement, Zombies

What’s in PMBOK 5?

Derek Huether

– November 5, 2010Posted in: Agile, Project Management

PMBOK 4th edition

PMBOK 5th edition

Though I know people are hard at work, deciding what will go into the Project Management Institute (PMI) Project Management Body of Knowledge (PMBOK) 5th edition, I can’t help but add my 2 cents.

We’re all armchair quarterbacks at one time or another so I’m rationalizing this post.

What is one of the biggest gaps in the current edition of the PMBOK, in my opinion? It’s the complete omission of (management) models or approaches. Agile, Scrum, Kanban, Spiral, Waterfall, and RUP should be defined in the PMBOK. It would be really nice if the PMBOK added an entire section dedicated to this, complete with diagrams and workflows. I think there is a problem, if you find yourself sending people to Wikipedia to find a list of the different software development processes. I completely understand there is more to the world of project management than just software development. But, I’m trying to make a point and provide an available resource for this post.

I’ve had people use the PMBOK as the excuse not to use Agile, saying it wan’t explicitly listed. I pointed out that neither was Waterfall. I wrote a post titled “Agile is in the PMBOK so it must be true” to make a point. If PMI wants the PMBOK to be used as the de facto standard for over 400,000 PMPs, they need to take a more iterative approach in releasing editions.

If anyone at PMI is listening, I would be more than happy to help.

Like the image? Find it at Pictofigo

Popularity: 7%

Tags: Agile, PMBOK, PMI, PMP