This is a blog about way cool Project Management. This post explains its purpose and serves as an introduction.

We are currently in the era of agile methodologies. Before that we had our plan driven approaches. Software development had its structured design and its object oriented design. I am not suggesting that they are all the identical, this is not an post about how we recycle the same ideas again and again in different packages. I am not even saying that they are all bad, or even all good. As our profession progresses and matures we can just add more tools to our project management toolbox for software development and implementations. We are all waiting for what the next big thing will be.

In the meantime struggling within the project trenches PMs are wondering which approaches to apply. What solution will bring salvation to their current project hazzard? For inexperienced Project Managers it can be hard to assess a situation, they have learned some "knowledge areas", they have some checklist printed out on their desk, but are they going to calm down the Team Lead that just went out of his mind? For some experienced colleagues assessing the situation comes more naturally. They have seen it before, made some bad mistakes before and can shoot from the hip just by having the problem in sight. But can they step outside their previous experiences? Can they see the more fundamental problems that occur in their project? Are they aware of all the techniques that are available to help them out?

Of course, these are hypothetical questions. These questions address some of the more fundamental issues hitting the Project Management profession. And not only in software projects. But I think I have found a way out. A way that can survive, or more correctly absorb, the arrival and departure of PM and software development methods, and help new and senior Project Managers with the questions raised above. I don't have a final solution yet, but on this blog I am dedicated to get to the bottom of this.

The solution to the problem lies in the fact that most problems within projects are people problems and not technical in nature. Or as DeMarco and Lister put it (1999):

"The major problems of our work are not as much technological as sociological in nature."

In a project, it's the people that are the main cause of problems. Time schedules, financial projections, and software goals may be abstractions, but it's the flesh-and-blood people whose work determines your project's status. It's the programmer that misses a deadline and holds up everyone else, it's the financial manager that goes berserk if you can't produce some good budgetary indications, and it's the key user that doesn't give a darn but didn't tell you about his dismal lack of motivation; these are the folks who can cause serious trouble.

Our main focus of attention should be on why and how individuals behave within projects, and how people interact with each other within this context. This socio stuff might not be the most popular subject among software technocrats, but it will provide us better answers, and even better, be more stable in the long run; the behavior of people doesn't change as fast as our technology. So, our first stop would be to create a model, or mental image if you want, on how individuals behave and interact within projects.

I use the phrase "Project Sociology" “If you look on Wikipedia you will find the following definition:

"Sociology is the study of the social lives of humans, groups, and societies, sometimes defined as the study of social interactions."

That should do it. And never underestimate the power of proper theoretic foundation. People that are new to the profession should be first introduced to these concepts, instead of providing them with a list of hundred separate techniques. They can remember the model more easily, and deduct solutions from them more efficiently then browsing through their papers.

By looking at projects as social interactions we can make use of psychology to cover why individuals interact in a certain way (seeing people as separate entities), look at sociology to explain the interactions seen from a group point of view, and complexity to look at the result of all interactions.

This should explain why I am searching for a proper "whole" for PM. Why I am looking for a true Project Management Body Of Knowledge, one that is based on psychology, sociology, organizational behavior, complex adaptive systems, and whatever might help us out. One that is based upon the fact that projects are nothing more than humans working together. One that can deal with the funkiness that humans possess.

Oh yeah, and perhaps I don't always ask, but feel free to help out. It is a challenging task, and I can use all the help I can get