PMcrunch

The term taxonomy refers to the categorization or breakdown to more clearly defined entities that can make an overall grouping of knowledge more understandable while there are many precise definitions for taxonomy, this should suffice for this particular discussion. The question is what taxonomy means to the project manager.Taxonomy often exists within the realm of database developers, database developers need to understand relationships among data elements and studying and defining the taxonomy of the particular subject data enables them to understand the whole much better by understanding the parts and how they relate to one another. 

Taxonomy is also a valuable tool in studying biology, where the multitudes of forms of life are broken down into a highly detailed classification scheme that constitutes taxonomy. 

So the question is what does taxonomy mean to a project manager? Why it is important? The answer is simply this, that one realm of knowledge can easily be applied to another realm of knowledge and as I give examples above of the application of taxonomy in other areas, I think that taxonomy is very important in helping (tag-tec)project managers(/tag-tec) with work break down schedules. “W B S” Work breakdown schedules constitute the unique taxonomy of the work on each and every unique project. 

We need to struggle oftentimes to clearly understand the relationships among the various work packages on a project. Struggling through this enables us to more clearly understand exactly what each work package consist of and also enables us to understand various types of dependencies between and among the various work packages. 

Just as there many types of relationships that can exist among data to a data base developer, there are a number of types of relationship that can exist between work packages. Here are a few: 

1. Time Dependencies - often one word package must be completed before another, this is a typical dependency on a project.

2. Skills - often the skills to do one package or similar to those to do another package and yet we have limited resources.

3. Critical Path Item - some work packages are on the critical path so they must be done according to schedule with those slack.

4. Priorities - some work packages involve priority features that stay colors either need or want to see within a certain time frame. It is important to be clear on what might be needed sooner rather than later from the point of view of stake holder priorities and preferences.

5. Risk - some work packages involve more project risk than others and we can potentially change the riskiness inherent in a work package by changing new order in which the work is performed.

There are surely are many more types of relationships among work packages that we could consider that might make up a sort of work breakdown schedule, or WBS, taxonomy to consider on our project, however the main thought for this post is that we can borrow ideas from the concept of taxonomy from other fields where the concept is well developed and apply them in project management. I think the best place to apply these is in the work breakdown schedule.

John Reiling, PMP
Project Management Training Online
Tech Training Online