Enforcing Governance

Rules of the Road

I was on my way into the office the other day at 5am.  Being it takes about two hours, a lot can happen.  For about 15 minutes, I noticed a driver tailgating me on a winding country road.  When they had an opportunity to pass, they took it, though we were in a no passing zone.  It was a reckless act.  I then watched the driver tailgate the car in front of me.  Within five minutes, they passed that car though we were still in a no passing zone.  Off they drove, into the dark.  I thought there were three very clear possibilities that would happen.  First, this person was going to skid off the road or hit a deer. Second, a Police officer would pull them over and cite them for reckless driving. Three, nothing would happen and they would continue to drive recklessly.

Governance in our Organizations

Now, let's consider a similar situation in an organization.  You have clearly defined rules of the road, known as your organizational governance or framework.  You use this governance to ensure the different types of teams deliver on the organizational goals and that there is a shared understanding of what not to do.  The bigger and complex the organization, the greater need for the governance.

You have a team who is not following the organizational governance.  Though they are able to reach their goals, they put everyone else at risk.  What do you think would be the best course of action?

1. Should we monitor them and see if they negatively impact other teams and the organization?
2. Should we enforce the governance?
3. Should we do nothing?

Seeing Value From The Customer Perspective

I recently sat in a meeting between a vendor and client, where the client was attempting to communicate their need to route new work deliverables to an existing Change Control Board (CCB). The contractor came back and said they believed the CCB in this case would not provide value and perhaps it should be bypassed.

Note to all vendors: Just because a process does not appear valuable to you, it does not mean the process does not provide value. The use of the CCB provides a (formal) control point helping to prevent unauthorized work and cost overruns. This goes further then just having a client billed for unauthorized work. Any work done without prior authorization has a risk of negatively impacting project schedule, cost, or quality. The mere act of doing unauthorized work impacts the scope.

I don't care if you're using Agile, Waterfall, or other methods to deliver value.  What is important is you understand your process and what mechanisms provide the greatest value to the customer.

If you think you need to deviate from a documented or understood process, rewrite your process to account for the deviations. If you are unwilling to change your documented process, the deviation is unworthy of being done.

I created the Visio diagram (above) a few months back to help both the customer and vendor visualize what we were trying to accomplish.  The challenge was implementing Scrum in a very formal and controlled environment.

I certainly recognize many don't have such a formal process.  Instead of CCBs, you may call them Product Backlog Review Meetings.  Counter to this, you may have a very fluid and simple software development life cycle (SDLC).  If so, you still need to understand your process and you still need to communicate with your customer.  Understand what their highest priorities are and deliver.