Home » Communication » Your Project Needs Business Rules, Not Meetings

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 Project Management Meetings Are EffectiveNot 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!

Project Management Tool Business Rules Provide GuidanceUsing 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.

Project Management Meetings Not Always EfficientGetting 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.

Thank you for sharing!

10 thoughts on “Your Project Needs Business Rules, Not Meetings

  1. Bruce Benson says:

    More comments from around the web:

    J Tito Coronado
    IT Manager | Operations Network & Infrastructure | BPM


    Thank you for the link to the article “Your Project Needs Business Rules, Not Meetings
    ” (http://bit.ly/1aKMCVf) about a meeting-less way to get things done. It provides a clear counter-meeting approach to getting work done. Having worked in an organization where not only everything required a meeting, but everyone needed to be invited, this is a refreshing idea.

    The respondents to this thread have provided a lot of wisdom. Many good arguments have been made for and against the need for meetings. Considering that the business meeting is just a tool it makes sense that there are effective uses for, as well as ineffective uses of, meetings. That being said is it possible for this group to come up with a “business rule” to be applied to help decide if a certain type of action requires a meeting or some other form of business activity to accomplish the task or decision?

    Proposed: Meeting-less experiment
    Goal: establish an agreed upon set of business rules that will help anyone make better decisions about when to use a meeting versus other forms of business activity?

    Anyone interested?

  2. Leonard says:

    Hi Bruce,

    From the background information you have given, it seems to me that three things were misfiring.

    Firstly, the assumption to get everybody together to “talk” about each defect in order to “drive the folks to higher degrees of awareness and productivity” is futile and just waste everybody’s time, especially when you get a high number of defects coming down the line. The only benefit of having such big meetings is to convey specific information about a tricky process, it is basically intense training where something is discussed in detail.
    Secondly, if you have meetings to make decisions, you should only have the real decision makers present, others are just spectators and you waste their time. Most of the time the assumption is that if the managers wants to discuss something, they will do so but want the experts present in case there is a more technical question. In such cases, rather teleconference the expert in if so required, or call him in at the time he is needed, do not for example have 4 experts sit and wait through a long discussion where their input is never asked for.

    Lastly, the escalation chain of defects were to long, and you fixed it very nicely by implementing business rules to throw it back to the people that matters. If all defects has to go right up the chain to the top, it just implies a) poor management or b) distrust in the the lower/mid level employees. So called Total Control doesn’t really help much, better to let the people run with most of the stuff, and only get involved where they get stuck or the decision level is high.

    Last comment, many big companies have what I like to call “paper drag”. Basically, as you discovered, middle management has to complete ridiculous amounts of paper work that add no real value, but make upper management feel like there is good governance on the projects. And beware the person who doesn’t have all his paper work in place, then you go to paper hell.

    1. Bruce Benson says:


      All excellent points. When an organization resorts to these kind of meetings to make decisions, there are indeed usually multiple problems present.

      The use of business rules allowed us to peel back part of the problem in this case and to eliminate what had been considered an essential reoccurring project meeting. This streamlined what had been a vary labor and time intensive process. The project completed on time and with good quality (a rarity). The team got recognition (cash award) for its management and analysis of the change process.

      Thanks for the comment


  3. tom says:

    Why did you not have the client use the back log? The iteration meeting could have been used to manage the priority of features and defects.

    1. Bruce Benson says:


      Generally speaking you are absolutely correct. In this case it was a consumer product with a large, complex and embedded software system (operating system, applications, etc.). The vast majority of “changes” were not really changes that a customer would recognize or be able to make any informed decision on. They were primarily internal engineering “changes” – think of them as design and infrastructure issues (it would be like asking the customer if refactoring was OK). For the issue that were “let’s do it differently” and visible to the end user, the customer – which was the marketing/account team – did in fact do exactly that with this approach.

      In a sense, we took an incremental process and made it a bit more agile by moving all change decisions from a central point and giving the ones that were appropriate to engineering back to engineering and the ones appropriate to the customer back to the customer. The remaining “decision function” was more like a Scrummaster where I focused on reinforcing the process and making sure everything worked as expected.

      Using this approach, of looking at your meetings and decision patterns and making changes, usually uncovers misused meetings and often, as it did here, provides rationale for getting back to doing things in a known logical and sensible manner (e.g. agile methods).

      Good question and observation.

Comments are closed.