Archives for the month of: June, 2009
« Older Entries

Project Rhythm

June 30, 09 //
6

This is a guest post by Andrew Sparks. Find out more about Andrew at the end of this post.

What does a well-run project sound like?

Generically we speak of successful, high-performance projects (or factories or other team operations) as “humming” or “ticking like a Swiss watch”.

Every successful project I have ever seen has had its own pace and rhythm.
When problems occur, they do not knock the project out of balance. Problems are just grist to the mill and the project team cranks through anything that crops up during the normal weekly schedule of meetings, discussions and decisions.

rythm Project Rhythm
Image by phylevn.

Conversely, poorly performing projects seem to lurch from crisis to crisis, buffeted and knocked off balance by almost every single thing that crops up.

My karate teacher used to say that essence of combat is imposing your rhythm on your opponent.

In a sense this is also what is happening in a well executed project.

The team is able to impose their rhythm on the status quo to achieve their project objectives.

All very well – but what are some practical pointers for a PM wishing to improve their performance in this area?

First off set clear expectations with your project team about the weekly rhythm of work. Publish the schedule of meetings and project communications, then stick to it.

I don’t buy in to the school of thought that only says only schedule meetings on an as-needed basis.

I advocate fixing the meeting schedule in advance and then cancel the meetings if there is nothing to process.

All part of building up the weekly rhythm of work for the team.

I don’t buy into “stand-up meetings” either.

You have a meeting with recorded notes & actions and good time-management, or you don’t (and it’s just an informal conversation – watercooler optional).

Some things need to be formally managed in projects that are generally informally managed just about everywhere else. Properly managing the meeting and comms schedules is one aspect of this.

Set the pace of work within the team appropriately. Sometime we have to push, and push hard indeed, to get the project tasks/deliverables/(you know what I mean) ready for a milestone.

Some PMs unfortunately interpret this as having the team work 18 hour days from the very start. I have seen a few PMs burn their teams out for no reason trying to prove what hard workers they are and how urgent it all is. You need to start with the end in mind and set the pace (and resources) appropriately.

Understand that pace and rhythm are different from volume or style (just pushing the musical analogy a little further). The team can be working at a high medium or low tempo (or flexing to demand). This says nothing about their style of working.

Loud & noisy or quite and controlled. It’s all good.

About the author: Andrew Sparks is a Senior Practice Director, working for Oracle EMEA. He runs the EMEA International Projects practice. Here he is seeing the wood for the trees. Andrew is also the author of the Project Lifestyle blog.

The views expressed in this article are the authors’ own and do not necessarily reflect the views of Oracle.

Other people who liked this article liked these too
  • No related posts

Systems View – Final Analysis

June 26, 09 //
0

This is the final post in my series about using systems thinking for analyzing problems in projects.

1. Systems Thinking: A Technique To Find Project Problems
2. Systems Thinking: Looking For Causal Loops
3. Shifting The Burden And Fixes That Backfire – Archetypes Part 1
4. Limits To Growth And Tragedy Of The Commons – Archetypes Part 2

I started this topic to be able to analyze problematic situations in projects. You will need to try this technique a few times before you really get the hang of it.

To be a good project manager you have to “see” potential problems. Literature provides us with large lists of potential problems in projects. You could look at all those lists to see if your problem is on it somewhere. But wouldn’t it be great to be able to look at problems in your project on a more fundamental level? That would be the best thing that can happen to you, and the techniques discussed in this series, will help you just with that!

Start running small workshops where you discuss the variables you chose (like budget overrun, number of bugs).

  • If this variable is going up or down with ever increased speed you have to look for a reinforcing loop;
  • If the variable is moving towards a threshold, and either stays on this threshold or starts oscillating around it, you have a balancing loop;
  • When a problem symptom alternately improves (the variable goes down) and deteriorates (problem goes up worse than before) you might have a “Fixes That Backfire” on your hands;
  • There is growth (sometimes explosive) leveling off or failing into decline, you might start looking for “Limits To Growth”.

Getting familiar with the archetypes helps you looking for the right loops and links.

And there is an additional bonus: when discussing and talking about the problems in this way, the solutions just “pop up” as you are addressing the fundamental causes.

Other people who liked this article liked these too

Elements Of Project Leadership

June 25, 09 //
4

As a Project leader you are dumped in an organization you have never seen before. You get people assigned you don’t know. The organization prescribes methods and tools you don’t like. And of course, there are a gazillion of unwritten rules.

Welcome to your project life.

You run on partial Information, partial Influence and partial capability.

But how do you actually run a project under these circumstances?

projectleadership Elements Of Project Leadership

Answer: Project Leadership.

The elements of (my version of) Project Leadership are:

  • Goals and Means on individual, project and organizational level
  • Alignment of goals and means on all levels by communication

Goals

A project has a goal, an objective. This is part of the larger context of the goals of the organization.

Individuals have goals, ambitions, interests. If peoples goals are met, they work happy; if not, they don’t.

Job for the Project leader is to align the goals on all levels. Keep on tweaking and adjusting. Make sure everyone understands. Make sure they are all in balance.

Means

Means are the strategies to reach the goal. This is the set of rituals, artifacts and values shared among the group, the organization and individual. The culture.

The culture can be used to create a strong group; it can be in conflict with the dominant structure.

Job for the Project leader is to align the means on all levels for maximal effectiveness. Balancing deviance with compliance. Making sure there are rules of engagement the entire team uses.

Communication

You think that if you are dropped into foreign territory like this, you would get a lot of equipment.

Sorry.

You get your Swiss Army knife: communication.

But in the end, that was all MacGyver needed.

Other people who liked this article liked these too

Be The Change You Wish To See

June 24, 09 //
0

How do you get your team to do the right thing? To adopt agile practices? To go the extra mile? To be on time for meetings? To produce polished products?

You can be on the lookout for the latest techniques. You can put your hopes in the most hyped up tools.

null

You can always search for great excuses: I don’t have authority. Not the right people.

But you’re running a project. You just get people assigned. You never have enough, clearly defined authority.

Deal with it.

So, how do you get your team to do the right thing?

Show them. Do the right thing yourself.

Be on time. Be friendly. Be interested. Be happy. Produce great stuff. Go the extra ten miles. Show up. Always.

If you want to see some fabulous behavior in your team, behave fabulous first.

Be the change you wish to see.

Other people who liked this article liked these too

Limits To Growth And Tragedy Of The Commons – Archetypes Part 2

June 23, 09 //
2

This is the fourth post in my series about using systems thinking for analyzing problems in projects. I recommend you read the previous posts before diving head first into this post.

Archetypes can be considered as stereotypes of problematic situations. When analyzing a situation they are the standard patterns you look for.

In this post I will describe two archetypes:

  • Limits To Growth
  • Tragedy Of The Commons

limgr Limits To Growth And Tragedy Of The Commons Archetypes Part 2
Image by laurenatclemson.

Limits To Growth

In this case two processes are intervening with each other: a process that indicates growth, and a process that puts limits to this growth (with a delay). If you think about project management a classical sample of this type is the addition of members to a team to increase the total productivity of this team.

limitsgrowth Limits To Growth And Tragedy Of The Commons Archetypes Part 2

Example

To increase productivity of a team new fresh employees are added to the team. However, people need time to learn the ropes within the teams working environment, and with extra members to total communication overhead increases.

Within small teams this may not have a large impact on the productivity of the individual team members, but as more and more new members are put to a team, the productivity gain will drop. It will probably plateau at a given moment, or, when teams are getting too large, too much new members are added simultaneously, etc. it may even drop.

If you have a variable that is increasing and all of a sudden you hit a plateau or it even collapses, you might look for a “Limits To Growth” situation.

Tragedy Of The Commons

The Fifth Discipline archetypes I discussed until know can be considered as relatively simple. Just a view loops that are interacting. Reality will be more complex where multiple archetypes are interacting with each other. The next archetype is such a situation: Tragedy of The Commons.

With Tragedy of The Commons you have multiple Limits To Growth that are interacting with each other. To be more precise, they are interacting on the same limiting process or constraint. The symptoms are identical to a single Limits To Growth, but with increased speed, and not transparent.

tragedy Limits To Growth And Tragedy Of The Commons Archetypes Part 2

Example

Consider the situation where you have two projects (A and B) that are both in testing phase. The growing process is finding new bugs by the test team. The overall performance per project is the number of bugs at a given moment. This will not be increasing forever as the bugfix team will resolve the bugs with some delay. However, the speed of fixing is limited by the capacity of the team.

Now consider the situation where the fix team within a company is shared. So project B will use the same capacity of the fix team. The two processes are interacting on a common resource.

Normally the capacity is calculated for such situations. But what happens: project A sees that by giving bugs a high priority, the time they get their fix speeds up. Project B concludes the same thing, and does this also. And although the capacity is calculated to handle two projects (but only when using the “real” priorities of bugs) the overall performance drops like a fly.

Next time:

Final analysis.

This a post in my series about using systems thinking for analyzing problems in projects.

1. Systems Thinking: A Technique To Find Project Problems
2. Systems Thinking: Looking For Causal Loops
3. Shifting The Burden And Fixes That Backfire – Archetypes Part 1
4. Limits To Growth And Tragedy Of The Commons – Archetypes Part 2
5. Systems View – Final Analysis

Other people who liked this article liked these too
« Older Entries