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.
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.