Implement EXPILCIT Governance

  • Article

While speaking at the Dr. Dobbs' Architect and Design World conference last week Scott Ambler said "Like it or not you are governed!"  Genius in its directness and simplicity and extremely relevant for recovery projects.

Many a challenged project struggles against the unstated and frequently invisible reins of governance.  Traditional definitions of governance speak to " … the leadership and organizational structures and processes that ensure that the organisation’s IT sustains and extends the organisation’s strategies and objectives .   Recovery needs to take a more simplified, pragmatic approach.  Governance equals constraints.  The projects budget, the schedule, the network, the hardware, other applications, legacy systems, current staff, tools, and oversight are all governance.  These are the concrete manifestations of the organizations decisions ... be they intentional or coincidental.  They are real and the recovery is defined by them .

The trick is to expose the governance.  Bring it into the open for discussion and ... here is the important part ... change.  I know governance comes down from the business to IT.  I know it represents what the business wants, needs, and desires.  And I know the specific implementation of those wants, needs, and desires are negotiable.  Everything is negotiable. 

Just for fun, take a few minutes and write down all the rules and constraints from your current project.  Here are a few to get you going;

  • There's no more money for people or equipment
  • We must have a delivery before the next <fill in the blank> meeting
  • We have committed to this tool and simply can't replace it.
  • The new solution must improve <pick a metric> 200%
  • The new solution must reduce operational costs X% year over year

No matter what the business states as constraints they need to be paired with some truths associated with software development.  I like to refer to these as the physics that controls the process.  Like gravity, it's not just important ... it's the law;

  • A team has a maximum product development velocity.  No amount of "managing" will increase their output.
  • Build completely and Test completely.  If you don't do it now you will do it later.
  • The right tool in the wrong hands is no better than the wrong tool in the right hands although both are marginally better than the wrong tools in the wrong hands.
  • All projects have some amount of pain to be endured.  You can accept it in small amounts throughout the project or you can put it off until the end game.  It's a bit like conservation of energy, project pain can not be created or destroyed, it can only be changed from one form to another or transferred from one body to another, but the total amount of pain remains constant (the same).
  • The right thing, as in do the right thing, isn't malleable.  If you think you can fix doing the wrong thing now later in the lifecycle you will be punished by the lifecycle.
  • Achieving specific business goals cost real money.  Finding a cheap solution with massive return on investment is just like hitting the lottery but less likely.

Having frank, open, and frequent discussions about the governance and goals related to a project creates an opportunity for all involved to redefine success in such a way as to make it possible.  The resulting explicit governance need not lower the business goals, but you will need to help all involved understand what they can REALISTICALLY do within the agreed upon limits of governance.