Tagged with: andrew sparks • conversations • expectations • guest post • improvement • meetings • oracle • performance • rhythm • schedule • stand-up meetings • Teams
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.
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.
Great post! Yes rhythm is very important to keep our project teams focused on the project.
I disagree. I used standups very effectively with my team. In fact, strict agilists would say that nothing needs to be written in meetings as long as everyone is on the same page at the end.
Hi all,
Glen Alleman posted a follow up article with the same name at
http://herdingcats.typepad.com/my_weblog/2009/06/project-rhythm.html
Check it out.
Great post – Yes, It is very importent to have planned meetings with MOM artifact. But sometime in case of fire or to discuss point with small group standing meetings are also good way.
Diwant’s statement, “In fact, strict agilists would say that nothing needs to be written in meetings as long as everyone is on the same page at the end,” is not accurate. The daily stand-up is a particular “agile” ceremony that has a specific purpose. All meetings are not stand-up meetings. The statement that “agilists” think nothing needs to be written in (any) meeting reflects a poor understanding of agile methods.
@Dave Thanks for the response. I was referring to one of the four ‘commandments’ in the agile manifesto, “software over documentation”. You are absolutely correct that certain agile ceremonies require documentation. For example, we used to maintain a product backlog which was a simple excel. Look at user stories as well. Those are written on note cards. So yes, there can be documentation in agile. My point was that since agile supports “software over documentation”, if the documentation can be avoided entirely then a strict agilist would do so. Teams of three people may do with zero documentation whatsoever! It’s a beautiful thing when it works, although it is only for teams that work well together.