Project Potion. Meshing Up Projects.

Don’t you hate a 3000 page method description with in the footnote:

“Oh yeah, by the way, you need to tailor this to the situation. You don’t need everything. Sort of. Kinda. We guess.”

Hate it. Hate it.

People put labels on methods. They give it a name. We need to categorize everything just to make sense of the world.

If you call things Agile, Lean, Traditional, 1.0, 2.0, 3.0, 54.8, ISO77658, your audience already has a lot of assumptions. Even without knowing the background, the problems addressed and the circumstances for its use.

That’s cool. That’s natural.

Descriptions and labels make it difficult to know what a method or technique is about. Let alone being able to use it with the right intent.

This becomes obviously hard when you try to mix and match approaches. You need to find essences and compare stuff.

It sounds like fun.

At least, that is what Dave Prior and I thought.

So, we started a new podcast, called Project Potion. Meshing Up Projects.

We talk about different approaches, topics and techniques, put them in a blender and see what comes out.

We never know.

But we learn. A lot.

We hope you do to.

Twitter Digg Delicious Stumbleupon Technorati Facebook Email

No Responses to “Project Potion. Meshing Up Projects.”

  1. Great podcast! I think we’ve been mixing & matching all along, and never thought twice about it. I do think however, we need the glossary, so we share a common language. Although, we’ll probably end up like the US & the UK, two countries separated by a common language. In my situation, we don’t do agile, we do iterative or incremental development. Similarly, while we officially follow the PMI’s PMBOK, in reality, we always do what is absolutely necessary & only what is absolutely necessary to accomplish our goals. I don’t care what it’s called, as long as at the end, the concept can be introduced into conversation without having to explain it to everyone over & over again.

  2. Hi Ray, thanks for your comment and glad you liked it. Still experimenting though.

    You are right about common language. In the end, everybody in the project must use the same approach, so it must be simple and identifiable.

    I wrote earlier this year about the rules for the rules of engagement:

    http://www.basdebaar.com/the-rules-for-the-rules-of-engagement-1813.html

    Just to make sure that “I don’t care what it’s called, as long as at the end, the concept can be introduced into conversation without having to explain it to everyone over & over again.” :)

  3. For the largest US defense program on the planet a 3,000 page process description would be completely insane!!

    Run away as fast as you can.

  4. Glen, that’s the only thing a PM can do :)

    but it still amazes me people create these huge binder. And with websites/wikis it takes you longer to find out the size of descriptions.