Yes, it is that time of the year. Well, almost. I want to start early this year with my "Best of 2007″ series… I hope I am the first… my Top 5 Project Management Blogs. The ranking is based upon the 5 blogs I shared or starred the most in my RSS reader. The blogs I thought were most worth sharing with others. Here is my list for 2007…

1. Raven's Brain
2. Better Projects
3. Undocumented features
4. Collaborative Thinking
5. Pawel Brodzinski

Thank you all, and hope to read more from y'all next year

Its difficult to really put your finger on the subject of stakeholder interests. It is more a guessing game than a science, so we need to make as much sense of the topic as we can. I conducted a small study on visitors to my website who work on software projects, in an effort to gain some insight into what actually drives project people. From the results, I came up with five aspects that affected almost 80% of the responses. Read them, and when analyzing a particular stakeholder, try to see in what way each of these aspects affects that person.

The five aspects that drive project people are:

1. Process versus. Content
2. Reference Group
3. Change versus. Status Quo
4. Defined versus Creative
5. Group versus Individual

1. Process versus Content

A big difference among stakeholders involved in your project is their preference for either the process or the content. Taking this distinction to its extreme, consider a senior manager who gets his thrills by changing the entire organization, and then think about the programmer who lights up when discussing network protocols. Process fetishists can generally be found working at higher levels of the organization. They are into the game of projects, and its the journey that they most enjoy. Content lovers, on the other hand, can be found at the more operational levels, most of the time constituting the people actually in your project team. Its not as much the journey as the destination they get their kicks from. Project managers tend to have a mix of both flavors, but of course this is a generalization.

Knowing what tendency people have towards either process or content provides you with some great leads on how to motivate them. For example, a strong preference for content makes it important to know the goals of the project. What will be the end result, and why? Simply letting project team members in on these questions has an amazing effect on their motivation.

2. Reference Group

Another aspect to consider is the group of people the stakeholders measure themselves against, or their reference group. Software engineers tend to compare themselves with other software engineers, not only within their own company but also in a wider range, even internationally. Management members mostly compare themselves with other people within their companies hierarchies. Stakeholders use the reference group to formulate their own interests: I want to earn as much as Big Shot Shirley. I want to be as good as Leisure Suit Lenny. I want to have more power than Head Honcho Harry. If you know with whom stakeholders compare themselves, you have an important piece of information to build incentives or at least to know what drives the stakeholders.

3. Change versus Status Quo

Projects are always about change, and the real project die hards embrace ever-changing environments. If you operate in larger companies, however, you will most likely have members on your project team that are not change lovers” people who feel more secure with the things they know, with things just as they are now.

4. Defined versus Creative

How many times did you think that you had everything covered by putting a perfect procedure into place, only to find out that you were the only one sticking to the procedure? Putting a structure into place may be a good thing for one person but a real motivation-killer for another. This rigid structure is ruining my creativity! You must have heard that one before. You should steer with the right amount of defined processes. Stuffing a large binder with procedures, committees, and formats to follow is definitely a sure way to make some good people very unhappy. And then there are the guys and gals that love a fixed plan. Most of the time, they are also the ones who dislike change.

5. Group versus Individual

Consider the lone wolf that hacks away at programming code in the dead of night. Put him in a nine-to-five regimen in an exposed office environment and watch his productivity plummet. The other way around, put me all by myself without any social contacts, and you can see me dying a slow and lonely death. If people love to operate alone, dont force them to be social just for the sake of team spirit. Preference for working in a group or working as an individual is an important factor that a project manager can use to motivate the project people.

If your project team is spread all over the globe, you will sometimes scare yourself with the amount of prejudice you have when dealing with people from different cultures. I know I do. Humans have a tendency to categorize everything, including people. Stereotyping can be dangerous, because it tries to say something about an entire group of people, and leaves individual differences out in the cold.

But it is quite convenient to believe that Hispanics always have a siesta, Chinese people always answer yes to every question, and Americans already start their day in a hurry. And then we have the French¦ ah, dont get me started about the French.

You know I am kidding, dont you?

Stereotyping is just to darn convenient¦ Let me provide you the following quote from Agile Software Development by Alistair Cockburn to show you what I mean:

"My early experience was with a consulting company in England, where the manager had set the project up single-handedly, developing the scope, objectives, strategy, plan, etc., and then get a team together and present the project to the team.

I tried to do this as a project manager in Italy. At the team briefing the message I got was: "That is your plan; you work to it. If you want us to work together, we plan together." Powerful message. Then I went to Australia, where the prevailing corporate culture is that the managers make all the mistakes and everybody else just does as they are told.

I set up my first project the Italian way. I called the team together in a room with clean whiteboards, described the scope and objectives, and said, "Now let's work out together how we are going to do this."The response was: "You are the manager. You work it out, and we'll just do whatever you say."

These stories exists because they have some truth in them. Different cultures result in different behaviors of people. But before you try to draw conclusions about an entire continent, why not just start with the individual project team member instead. Take a mental spin, take a leap, perform a 360, try to assess a situation in a different cultural reference frame.

Here are six cultural assumptions you might give a flip (based upon this posting), and yes, they are written down as stereotypes:

1. Future “ Present “ Past Orientation

For some cultures history will determine the future, so the past is very important. Others, mainly South-American cultures, believe the past cannot be changed, the future cannot be predicted, only the present can be influenced. And then there are the Western cultures who believe that with hard planning, proper preparation and thorough analysis the future can be captured.

2. Time-Plentiful vs Time-Is-Money

There is a huge difference in life if you believe that time is an unlimited resource; the sun sets and will rise again, always, over and over again. Time is plentiful. Tomorrow the same amount of time is left as today. If you put this world view in contrast with the idea that time is passing and will never come back, you might see how the concept of deadlines can be confusing between some cultures.

3. Respect For The Man

In The Netherlands we have a problem with authority. We like to see our bosses as equals, and tend to treat them as such. Respect is something that should be earned, and hierarchy and upbringing has nothing to do with that. And even with respect, that doesnt mean I have to treat someone differently. That is at least the opinion of the majority of the Dutch people.

In other parts of our planet, upbringing and hierarchy have a lot to do with getting respect. And disagreement with a respected person is unthinkable. This is the widely known yes from Indian people (yes, I know, the whole continent :)) that is misunderstood by their western colleagues.

4. Me vs Us

There is a world of difference if you behave from the idea that you operate as an individual or that you operate as a small part of a collective.

A market research firm conducted a survey of tourist agencies around the world. The questionnaires came back from most countries in less than a month. But the agencies in the asian countries took months to do it. After many telexes, it was finally done. The reason was that, for example, American tourist agencies assigned the work to one person, while the Filipinos delegated the work to the entire department, which took longer. The researchers also noticed that the telexes from the Philippines always came from a different person. (from AnalyticTech.com)

5. Spelling Everything Out vs Its Only Natural

Even I learn something everyday. When researching for this post, I learned this difference: in some cultures it is normal that everything is expressed in detail, information is explicitly provided, everything is spelled out for you. And then there are the countries where they assume that you have some shared knowledge, some intelligence and a mind of your own. For this latter culture it is almost insulting to get everything spelled out like that.

6. Doing Everything At Once Or One Thing After The Other

This not entirely the old discussion that women are better in multi-tasking than men. This is about the fact that some cultures doing more than one thing at a time is just, well, normal. So if you are talking with someone and he is taking also phone calls at the same time, it might be insulting in one culture, but it can also be just plain normal behavior in another.

It is difficult to discuss cultural differences without stereotyping, as you might have noticed. Stereotypes are just easier in communication. When dealing with individuals, make up your mind based upon only the individual, and not his or her entire race.

Every element of a project method has a reason. If you know the reason, you know when to apply or use this method component. To explain this, I created a small sample using Scrum, and I turn to some global observations about it. I use the word global as I will not go into every little detail, but use the information that is available on the fabulous site ControlChaos.com.

Taken from that site:

Scrums Three Tools:

1. Backlog: Overall, by product line, by product, and by system an organization identifies all outstanding work and prioritizes it. This prioritized backlog list changes continuously and is updated and reprioritized continuously.

2. Sprints: Work increments where a team works on completing an identified, self-contained group of prioritized work. During the sprint, the work is not changed from outside the sprint, although as work occurs in the sprint, additional work may be uncovered.

3. Scrums: Daily meetings where a Sprint team meets to identify what work was just done, what work will be done next, and what is impeding work.

Here are some of my observations to add to the information given above:

1. Backlog: This list is the general planning tool. This is needed to provide feedback to the team members on what should be done, feedback to the users on what will be happening with their requirements, and feedback to management on progress and need for interventions/decisions. As only the items are planned for the current and/or next sprint (iteration), it can cause a problem with management that wants to have some statement about the long-term planning and cost. On the other hand, the underlying idea behind Scrum is that with unknown requirements (see 2. Sprints), every statement about the long term is almost useless. Only based upon the real speed of the team are time frames determined, and only for the foreseeable future. So the question is: Can you convince management that it is better to stay in reality and get involved in the process, or do they want to work with statements based upon feelings and hunches and have a false sense of security (some people prefer the latter)?

2. Sprints: Scrum uses an incremental approach to provide early feedback of some end result. The underlying risk that is covered here is uncertainties in requirements. By providing feedback in a working version as early as possible, this system allows the end users to view if the requirements are properly addressed. Also, a close involvement of end users within the Scrum team covers this risk. However, to be able to determine if the requirements are properly addressed, users will have to look to at least some version of the system that satisfies a certain business goal in its whole. As certain sets of requirements are dependent on each other, a real opinion can only be formed when a major part of the requirements are addressed.

If you look further in the sprint definition, you will find that it has to satisfy a sprint goal, which should be some business goal. So Scrum doesnt promote iterations just for the sake of iterations. The idea is to provide feedback, and if that is not possible in a good way, the increments dont make any sense.

3. Scrums: The Daily Scrums last no more than fifteen minutes. During the meeting, everyone on the team answers three questions:

1. What have you done since the last Daily Scrum?
2. What will you do between now and the next Daily Scrum?
3. Whats getting in the way of your doing your work?

This is to provide daily feedback to each other (including management) on the current state of the work and to address issues that need to be taken care of. Actually, these are just rules for an efficient meeting. Other methods also provide this, but the aggressiveness of the name Scrum has strong appeal.

From this short sample you can see that feedback on product and process are used to either reduce risks or satisfy the needs of stakeholders. You can also use the backlog technique in approaches other than Scrum. Heck, priority lists of requirements and risks can be found in other methods also. However, calling it a backlog is an in-your-face name, calling it exactly what it is. There are more methods that take an incremental or iterative approach, but always remember what it is you are trying to address, why you go incremental. Without having the sprint goal, the sprints would be useless.

Or "Yes, You Can Mix and Match"

Just to reassure you: yes, you can use different techniques together. I will take as an example the usage of burn-down charts as described for Crystal Clear. However, this technique can also be found elsewhere, as in Scrum and Extreme Programming. A burn-down chart is a chart that reflects the progress made on development. It will list the number of features on the y-axis and the time on the x-axis. As time progresses, the line should go down.

In more plan-driven methods, an updated Gantt chart can be used to indicate the progress. However, I like the simplicity and effectiveness in communication of this style of chart. In one clear image it says it all about the progress of development. Another nifty thing is that you can indicate scope increase in a clear manner (second chart in the figure). If you are on a tight deadline but users keep on adding requirements (scope increase), you can just up the line for the number of features left to complete and draw a new estimate line. By leaving the original line in the chart, you
make it very clear to the sponsors that you are running late because of the increase in scope.

Regardless of which method you use, even if plandriven like PMP and Prince 2, you can use this method of communication.

Earlier this year I experimented with a small video about the importance of project goals. Quality and content were not great, but heck, it was an experiment.

I uploaded it again… enjoy!

BTW I have some great new videos lined up for you… all I need is time