Ryan's Rules for Projects

I don't like meetings. I feel like meetings often fail to accomplish much beyond getting project team members into the same room once a week. We talk about the work we did the previous week, and we talk about the work we hope to do during the next week, but there are better ways to communicate that information.  I was thinking about this recently and became convinced there must be a better way to structure projects.

Just as Robert's Rules of Order are intended to facilitate debate and deliberation among a large group of participants, Ryan's Rules for Projects are intended to keep team projects moving quickly and  efficiently, and to give them the greatest chance for success.
Rule #1 - No more than 5 team members on any given project.
Too often we load up team members on projects in the mistaken belief that having more people involved will allow the team easy access to more information and allow more work to get done faster.  It doesn't work that way.  Think about it in terms of team sports. (Sports Metaphors: The last refuge of lazy writers.) In team sports, the speed of the action is negatively correlated to the size of the team.  American football can move quickly in short bursts, but the 11 players have to huddle, regroup, choose a new plan and start over in a new spot after every play.  The most surprising event in football is when a team actually marches down the field quickly to score.  European football or Soccer, also 11 players per team, is only slightly better.  They don't stop play every few seconds, but let's face it, 90 minutes of play and you're lucky if either team was able to score at all. Baseball, with 9 players (my personal favorite), has been described as "long periods of boredom, punctuated by moments of sheer terror."  Contrast hockey (6), basketball (5), and tennis (2) and you begin to see a pattern emerge.  Smaller teams can communicate easier, move more quickly, reorganize, and change priorities on the fly, while larger teams lumber on slowly toward a goal.

Rule #2 - Team members devote 20% of working time to this one project.
Ideally you should have 4 team members who are able to devote at least 20 percent of their working time to the project.  The fifth member should be an interested senior manager who keeps an eye on the progress of the team, but only gets involved in the event that the team has a 50/50 split on a decision and needs a tie breaker.  The 20 percent minimum ensures that no person is on more than a few projects at once, leaving the rest of their time available for miscellaneous working activities, like the rest of their job.
A smaller team devoting the same total number of man-hours to a project, will always outperform a larger team.
Rule #3 - Team members must collaborate regularly.
Collaboration time differs from "meeting time", in so far as it is time spent actually working together on a project.  Two or more team members may schedule time to collaborate, or they may spontaneously meet up, or call each other.  They may have a goal for their collaboration time, or a particular problem they wish to tackle, but they should never have an agenda of multiple items to be covered during a particular period.  Collaboration is directed, focused work, but it should be spontaneous, and never managed. During collaboration time, team members may work closely together on the same problem, or they may choose to tackle different problems in silence, together.  Being in proximity and thinking about the same project at the same time gives rise to serendipitous discoveries, and creative solutions, but it also ensures that team members stay focused on the project rather than being pulled away by other concerns.
Rule #4 - Meetings should be "nasty, brutish, and short."
Okay, I'll admit it, meetings are sometimes a necessary evil.  However, meetings should not be opportunities for the project team to communicate with each other, they are opportunities for the team to communicate with their fifth member, or with other senior management.  The team may call a meeting to get direction or a clarification of goals from management, to report progress, or to present new solutions and confirm they are on the right path.  Management may call a meeting to check in on the project, or to establish new goals or directives.   Meetings should be short, typically 15 minutes, and never more than 30.  They should be ad hoc, called only when necessary.  With fewer members devoting more time to the project, and meetings of shorter duration, ad hoc meetings should become fairly easy to schedule.  If you insist on holding regular meetings, they should be held at predetermined intervals along the project timeline, or when particular project milestones are achieved.

Why nasty and brutish? 
I really like the Hobbes quote, but it's also relevant. While office interactions should always be professional and genial, good people can, and often do, disagree, especially in the midst of collaboration.  Disagreement can be very healthy and creative. In my experience, many people hold back in meetings, afraid to express opinions for fear of looking foolish or damaging another team member's pride. Whether we enter meetings as C-level officers, plebeian peons, or something in between, we need to leave our egos, our job titles, and our inhibitions at the door.  For 15 minutes the meeting should be a free flow of brutally honest ideas and opinions. At the end of the meeting, managers give directions, team members return to their project, and, like Vegas, what happened in the meeting, stays in the meeting.
Rule #5 - Fail small, fail quickly, and fail often.
Back in February, I wrote an post titled "In Praise of Failure" where this final rule was the punchline.  As I said in that post, "Quick failures... are merely steps on the way to success."   Part of the reason we continue with  pointless meetings, accomplishing little, is because even though they bring us no closer to success, they also move us no closer to failure.  Meetings, as we currently practice them, are the equivalent of treading water.  We're not going anywhere, but we're not drowning either, and that's considered good enough.
Projects are inherently collaborative.  Collaboration is always messy.  Messy often leads to failure.  Failure with a little self-awareness gives rise to learning.  Learning creates new knowledge.  New knowledge is fed back into the project, and the process begins again.  Occasionally, "messy" takes a sharp left turn and leads to success, but only after several iterations of the process, and therefore, several failures.  Sadly, we are more afraid of failing, than we are driven to succeed, and we should be most afraid of standing still.
I have never had an opportunity to practice Ryan's Rules for Projects.  I have attempted to implement some of the rules into existing projects and I've been overruled or outvoted each time.  Maybe these rules are a recipe for failure, or maybe they're keys to success, but if you're tired of treading water, you could do a lot worse than trying it my way.

Jeffrey Brandt at PinHawk suggests a few more rules and I wholeheartedly agree.  My list was never intended to be definitive or comprehensive.  If you have further suggestions, please leave them in the comments.

Brandt's Addenda:  
Rule #6 - All team meetings must have an agenda. (ed. meetings not collaboration time)
Rule #7 - All projects must have a written definition of success.
Rule #8 - All projects must have links to one (or more) strategic business initiatives.

Bookmark and Share


Zena Applebaum said...

Best advice ever! I love it and can't wait to print it in a little blue book :)

Anonymous said...

Ryan, your ability to tell a story is wonderful. Your reference to sporting analogies is impressive and your style of humor is funny. Your understanding of how to run meetings efficiently is greatly lacking. I agree that many organizations don't run effective meetings and that teams should not be using weekly meetings to update project plans. But I don't agree that one came blame the project for an organizational problem. The problems you describe are organizational problems.


Ryan McClead said...

Thanks for the comments. I agree completely that these problems are organizational in nature, and I would love to hear your thoughts on which of these "rules" would be ineffective and why.


Steven B. Levy, author of Legal Project Management said...

I think there are some good points here. I had a blast (and was successful) on many projects with five or fewer team members, but I've also run successful projects with ten times that number and beyond. They were fun in a different way, but there is a certain project camaraderie that exists on tight-team projects that's hard to reproduce in larger environments.

I am not a big fan of the 20% guideline, however. I agree that for some kinds of projects, especially those strung out over time where there is much more calendar time than work to fill it and thus people are doing many projects at one time, trying to get serious focus (e.g., the 20% rule) is a good baseline. However, it's a better situation if people can work intensively on the project when they are available. Most of all, be careful not to allow the 20% to be performed in ten-minute increments. If it's two hours of a ten-hour day, it is best as two continuous hours, and so on.

Ryan McClead said...

Thank you Steven. The 5 team members rule is a response to what I believe is a tendency to err on the side of too many team members, but point taken that some projects simply require larger teams and they can be successful too. A very good point about allocating larger periods of working time, rather than lots of smaller increments. I'll definitely work that in.
Thank you,

Editorial comment: I confirmed that Steven Levy was not Steve from the second comment. But I'd still love to hear from Steve if he's out there.

Anonymous said...

I believe rules 1, 2, 4 and 5 are ineffective ways of looking at the situation. Meetings, done correctly, are opportunities for team members to understand not only their position in the process, but how the process benefits the enterprise. Without an understanding of the impact a project has on business goals, it is just work and will be treated as such by project members (and by extension their staff).

Rule 1 - no more than 5 members. Really, how in the world would you replace the Microsoft Office suite with a 5 member team? This coming from you (a person who preaches inclusion of more people in dialogues)? How would you ever communicate the goals, intentions and challenges of a project as large as that with a 5 member team?

Rule 2 - 20% allocation - I don't know about your organization, but the ones I'm familiar with have too many projects on the books and to few resources to handle them (in order to meet your 20% rule). Do you suggest the organization do fewer projects? I do agree with Steve Levy that the way in which we allocate our time needs to be more contiguous and that if you have too many projects this will be difficult to do.

Rule 4 - why should meetings be nasty, brutish and short? What is it you are trying to accomplish by inducing these attributes (other than shaking the nasty tree to see what falls out)? I agree, many meetings would benefit from direct and open dialogues, but that doesn't mean nasty, brutish or short. Assuming rule 3 is working (team members collaborate regularly) there should be few surprises in a meeting. You do not need to be nasty, brutish or short in order to engage in meaningful and spirited dialogues.

Rule 5 - fail . . . - Are you confusing an organization attempting to do something and failing (which would indicate a business decision that didn't work) or a project that failed because it was poorly run (which would indicate a lack of maturity in your PMO)? I completely agree with your post in praise of failure, but I do not believe that applies to project management. I do not believe you need to fail often in project management in order to improve process.


Ryan McClead said...

I’m so glad you came back to clarify your earlier comments. You are absolutely correct, “Meetings, done correctly, are opportunities for team members to understand not only their position in the process, but how the process benefits the enterprise.” This post is in many ways a reaction to meetings not done correctly, or at least to meetings that I feel don't perform that function. Those experiences coupled with my penchant for a bit of hyperbole, gave rise to these “rules” that could never and would never be followed religiously by any institution.

The intention of this post is to address the issues that I see continually plaguing project after project. I could have stated more succinctly that in my opinion, 1) Project teams are, in general, bigger than they should be; 2) Team members are pulled in too many other directions and projects suffer for it; 3) We don’t do enough real collaborating; 4) Meetings are too long, and many people don’t express themselves freely; and 5) Fear of failure leads to timid imaginations and a lack of creative exploration that sends too many projects down the “safe path” to mediocrity.

I could have said it that way, but it would have made for a pretty boring blog post.


Anonymous said...

I see, hyperbole over substance.

I get your point and I really find your writings to be very entertaining. I'm certainly not asking you to change your style. This topic, however, is one where you are blaming projects for dysfunction. That's like blaming cars for car accidents.

Stephano said...

I feel dumber for having read that last Anonymous comment.

Lilah said...

Love this and whole-heartedly agree that meetings should be nasty, brutish, and short. Ha ha.

Anonymous said...

I would agree that the problem with most meetings is that they are not conducted effectively. Unfortunately, too many people running meetings don't know how to run them. They let people ramble on, they don't when to stop and move on and they don't know how to deal with someone who wants to be in charge. Most meetings shouldn't take more than an hour and the leader of the meeting should have an idea of what they expect to accomplish and keep focused on that.

Anonymous said...

This is the most useful post I have read in a long time. I wish I could print, 3-hole punch, and binder it. Thanks for your succint and candid wisdom. The Addenda is not to be forgotten, thanks for including.

Rule #6 - All team meetings must have an agenda. (ed. meetings not collaboration time)
Rule #7 - All projects must have a written definition of success.
Rule #8 - All projects must have links to one (or more) strategic business initiatives.

-Shauna Wiest


© 2014, All Rights Reserved.