It is a big deal today. Project management tools to get people together. Crowd source. Wisdom of the crowds. Even in the Agile Manifesto: “individuals and interactions over processes and tools.” Hogwash!

OK, seriously, I just want to suggest that there are other project management tools, other ways to optimize, that do not require regular or ad hoc meetings. This is to complement all those people gatherings that we do need to get the job done. You may even be able to eliminate some meetings.

Not All Meetings Are Effective

I was managing defects. Hundreds of defects were already reported with hundreds coming in weekly. It was a huge job (see Project Management Meeting Madness). The popular notion was that we needed to have meetings and have everyone talk about each and every defect. This common belief was that this would drive the folks to higher degrees of awareness and productivity. It didn’t. In fact it never did and the data showed it quite clearly over the years. But that was the belief and the practice.

We wanted to improve on time delivery of our products. We formed an “experts” board to review all the product project plans. The senior managers on this board would even receive extra pay for this extra duty. This board of experts would regularly review project progress, in addition to the normal product reviews that were required and ongoing. As a product integration manager I had to put together or update dozens of slides every few weeks to present to this group. Over time, the main emphasis was to “appease” these folks — do whatever they asked us to do — so they would only speak good words about our project. Based upon on time delivery metrics these reviews made no difference. They did not, amazingly, slow things down nor did they suddenly result in product on time delivery (but see how we did it in Get The Project Management Schedule Right).

The quality and test teams didn’t think the product and development teams were taking all their defect reports seriously. They formed a daily meeting to review the “severities” that were being assigned to each defect that had been reported. The team’s purpose was to “catch” defects that had been mis-categorized. The often stated belief was that the development and product teams were understating the severity of the problems to make the quality look better than it was. The other notion was that a higher severity level resulted in a faster defect repair. The defect trends showed that these meeting made no difference to the overall speed of fixing defects, including those that had their severity adjusted. In fact, the data showed that by the time the team reviewed a days worth of defects (which could take days before they could get to them and days to review them) and adjusted severities, most had already been resolved by the development team.

The point here is that if our meetings don’t seem to accomplish what we want them to accomplish, consider either doing away with them or try another, non meeting, approach. Too many meetings are called out of habit or emotional reaction or because “we have to do something!” rather than because they are effective. One of my bosses admitted that a few meetings he called were to “punish” the development team managers by requiring excruciating detail!

Using Business Rules Can Reduce The Need For Meetings

I committed meeting heresy. We had started a new product project. The requests for changes and additional features started to trickle in. The conventional approach was to have a regular weekly “configuration control board” meeting. This is where we would look at each and every item and decide to approve it or not.

My job would be to set up the time and place of the meeting. Instead, as the requests came in I looked at each and every one. I sent the requests out to those same people who would be on the control board and got their inputs. I also pre-screened them and made my own recommendation on their disposition before I sent them out.

After a few dozen requests, a pattern formed. Most of the requests were of the form “oops, we missed something when scoping the feature — we also need X to make approved feature Y work.” For these, I made a business rule that these can be approved within the development team. This rule would hold until we got closer to launching the product.

The second most prevalent request was “it would be better if we did it a different way.” These impacted what the customer and what marketing requested. I made another business rule that these would be automatically approved if reviewed and agreed to by the account teams and development could deliver them by the deadline.

On it went. No more than a half dozen rules presented themselves. I then published these rules back to the development teams sending in the requests. I got a few inquiries from team leads as this was an unusual approach, but they liked it because they had a clear path for the vast majority of requests they had. There was no meeting or committee set up to review the requests. There was no request format nor background information web form that had to be filled out. I was copied on everything approved internally by development (with a reference to the applicable business rule), but they could proceed without waiting for any further approvals. All I did was scan the requests to see if the rules seemed to be working and asked questions periodically.

The development team seemed delighted that we were doing it this way. No other product team took this approach. Eventually, development standardized on our business rules and the other products on our software line started to use the same rules (but didn’t always do away with the meetings). Now, we were the lead product, so we had a bit more say on how things were to go, but this approach worked in large part because it allowed decisions to be made rapidly based upon agreed upon rules. It also emphasized that the product management team trusted the decision making ability of the development team.

Getting People Together Is Not Always The Most Efficient Approach

Many chairpersons of meetings have tried to accomplish this same thing, use business rules, within a traditional meeting structure. My main observation here is that when we have multiple personalities in the room, often just accepting that a rule applies and deferring ones own input (and influence) is hard for many people to do. I had one meeting member bluntly admit as much asking “Why are we here if not to actively discuss and decide things?”

We were able to implement this business rule approach with defect reviews, feature reviews and to a limited extend — quality reviews. This streamlined the decision making and removed the impediments of unneeded meetings and approvals. This was one of many internal efficiencies that led us to consistent on time with good quality product deliveries.

Meetings are necessary for getting people together to share information, to make decisions and to build focused teams. Not every “decision function” needs a meeting however. Agreed upon business rules can be employed to help push out decisions to the appropriate teams, while still providing overall guidance. Take a look at your meeting’s regular decisions and if there are consistent patterns, consider turning those into business rules that allow decisions to be made without a meeting. Your teams will be more productive and agile in their decision making.