Normalization

Not sure how far I will get with explaining idea..but for some time I've been thinking about database normalization and how THAT type of approach can be applied to project management. DB normalization is usually held as a standard to how well structured a database is.

From programming 101 I learned that Relational Database Management Systems were based on set theory and defined by a mathematician - E. Codd. There are 6 or 7 or 5 1/2 and one more Normalized Forms (depending on what you read, I always remember it being more then 1 and less then 11). These normalized forms are used to describe how the physical database structure is implemented and used as a bench mark. It's amazing how a few sentences can have such a deep impact (lesson to self - the more I yap the less I really know). SO - the question I've been tossing around is, can PM - or someone for PM - define a simple set of rules that can be used to define how to approach PM and how to judge a well laid out plan? Probably not since people make $ from selling a lot of books and if a person could define PM with more then 1 or less then 11 well defined rules then the entire PM industry might close shop. But let's see if we can tackle at least one.

First normal form (1NF) is a normal form used in database normalization. First normal form excludes the possibility of repeating groups by requiring that each field in a database hold an atomic value, and that records be defined in such a way as to be uniquely identifiable by means of a primary key.

WOW - this might be tougher then I thought. Let's see: Each table has a primary key, not so bad. So for every task, risk, change request, etc., there is a unique identifier that you can reference each entry by. For instance, a task as a Task ID that within the project can not be repeated - NOT SO BAD!

Eliminate repeating groups? What's that mean?? Let's use tasks to define: A single tasks can not have a field (task name, start/end dates, resources, etc.) that repeat. So, for example:
Task ID: 1
Start Date: Jan 1, 2007
End Date: Jan 3, 2006
Task Name: Buy some Jelly
Resources: Meade

would be valid, but

Task ID: 1
Start Date: Jan 1, 2007 and Jan 8, 2007
End Date: Jan 3, 2006 and Jan 11, 2007
Task Name: Buy some Jelly
Resources: Meade

would not be, since the start/end dates have more then one entry - not bad. What about resources? I could take my dog shopping - but that would be okay as long as for the entire task duration it's me and my dog and not for part me and then another part my dog assigned to the task (if so then it should be broken into sub-tasks such as 1.1 drive to store and 1.2 buy the Jelly where the dog would drive and I would buy the jelly) - WOW - not bad again.

I think we can get around the atomicity like more then one resource - as long as we consider all the resources listed as being a single unit needed to complete the task (Am I stretching it here?) Enough thinking for one day - I'll need to sleep and think about the Second Normal form.