How a rules project is led has as much to do with its potential success as any other consideration. An effective leader can rally a team towards a series of major wins; an ineffective leader will leave a team scraping for minor victories. How you choose to lead your team can make all the difference.
Transparency and Context
A few years ago, I had lunch with a BRMS program manager at one of our client sites. I asked him what he believed were the best practices for a large project like ours. He said that a lot of project managers believe insulating the team helps with productivity, so they “block” and “gatekeep” others from interacting with the team. He immediately added, “We run open. Anyone can talk to anyone at any time. Ask questions, whatever. Why would I get in the way of others wanting to know what’s going on?” Turns out, a culture of transparency is exactly what rule projects need. If the rules make the logic more social, then why not take the practice through the whole team?
We often underestimate how many decisions each team member makes in a collaborative project. If they don’t have sufficient context to make effective decisions, we’re allowing those team members to fumble in the dark. At best, this creates bottlenecks in trying to get questions answered; at worst, this undermines the entire team’s ability to deliver value. A team member might be clear on what they are expected to do and still be unable to accomplish the task correctly, since they are missing details of the larger picture.
Team Ownership
I recently fell into a discussion with our Agile coach in the middle of planning a release. The discussion centered around the deeper meaning of assigning a task to a team member. Does it mean that the person doing the work is the “owner” of the task, or are they simply a delegate of the team which owns both the work product and outcome? As far as our Scrum practice is concerned, we both agreed that the ultimate interpretation is that assignments are not ownership. In the end, I think we both made a good case for assigning multiple people to a task and leave it up to them to figure out the work – even if they were not going to write the code together.
When we ask the same questions about rule projects, I land on some of the same Scrum practices for a rule project. The team owns the rules in the rule project. Anyone can be assigned at any time to write or modify the rule. Moreover, the team owns the outcome of the decision. Does the decision behave as expected? Does it have the right scope? Can we prove that it’s better than it was before? Does it deliver the value to the business? Is the team stuck? All of these questions underpin the accountability of the team and its ownership of the rule project.
Stakeholders and Accountability
There must be a group of people that care about the outcome of your project. If you are not giving regular playbacks to people who care, then you are missing out on some very productive feedback needed for success. Playback often and share what’s happing on the project. Show your rules, run your tests, and demonstrate how cool your vocabulary is for readability. Ideas will start to percolate in these sessions (get ready to start a backlog of capability!) and start prioritizing. Ultimately, playing back to your stakeholders is the best way to keep the visibility and importance of the project alive.
Coincidentally, the inverse of this is also true: Seeing a stakeholder be excited about a project can be highly motivating to team members!
Feedback
Taking feedback in the form of criticism can be hard at first. Your project needs this. Look for leadership and team members who accept feedback and convert it into creative action—even if it’s not quite what you expected. Your rule project is in a conversation with the business. Keep the channel open and continuously improve. Getting feedback is a privilege. Many experts agree that the lack of feedback is a dangerous sign that others have given up or the project might be off the rails. Schedule a playback and keep the team moving forward.
At some point, others might simply state that they don’t understand something enough to give feedback. Ask them to write some rules or give you some test data. Walk them through our lifecycle and invite them to help define a metric. Be quick to invite and follow-up. You will win over your detractors and further the cause with your supporters.
Please share your thoughts on this below (as a comment) or on LinkedIn. If you are in the early stages of project research, consider working with us. We offer workshops specifically designed for stakeholders chartered to solve tough strategic problems.
