Showing posts with label governance. Show all posts
Showing posts with label governance. Show all posts

Tuesday, November 10, 2015

To Be A Great Leader, You Have to Eat Your Own Dog Food

A common occurrence these days is to implement processes, procedures, rules, and regulations to protect organizations or improve the business.  The worst thing a leader can do is to implement something that they do not follow.  Your employees, team members, and associates will see right through that.  I have been witness to many organizations and leaders circumvent something that they put in place.  What is the point in that?  If you believe in something, then do it!

I have some real life examples of this. An IT organization puts in place that you must have a functional and technical specification approved before you can implement new technology.  This makes sense.  The organization wants to make sure everything is thought out before implementation to alleviate risk.  They are so stringent in this request that they will delay the number one corporate initiative for the year to ensure that the process is followed.  They continually force the consultant and the project team to utilize the process and meticulously check the boxes.  Meanwhile, they get an initiative for the same type of technology.  In the time that the project team is filling out all of the required paperwork, IT implements their solution.  When asked, the IT team did not have any of the required documents that the project team was required to do.  This screams of hypocrisy.  If the process is stringent, both projects must follow it!

Another example is when the Sponsor states that the company will be regimented in their delivery process.  All requirements are documented, go through a system, coded, and validated.  If it is not in the system, it is not a requirement.  Except for when they tell the consultant requirements outside of the system.  The miscommunication from this activity can result in rework, missed functionality, and budget over-runs.

Another organization is frustrated with new technology coming in that disrupts other technology already deployed.  In this case, they implement a technology review.  This review is to look at the technology, establish risk, and test it with corporate standards to ensure compliance.  Every project is forced through this council that determines the viability.  Unfortunately, they did not convey this to all users, so it is being implemented on some projects, but not others.  Then, due to the amount of requests, they bottleneck the environment to go to a Technology Steering Committee meeting that is limited in time and every 2 weeks.  This can delay projects 4-6 weeks depending on the agenda.  In this example, the division followed every process requested and the council ended up denying the use of a new technology even with overwhelming savings to the organization should the technology pass.  The division objected and in the end, could not use the new technology.  Three months later, the project manager read the meeting notes from the council and saw that the very same technology had been approved for IT’s use without having to follow the process.  The division requested again to go forward with a crucial cost savings project that was again denied without reason.

The last example is where a large organization had implemented a governance process.  They asked for a study on how the process was doing and then wanted automation of the process.  It was found that the process cost roughly $35M to operate and there were no true savings that could be attributed to the process.  As part of the governance meetings, no project was truly course corrected, cancelled, or accelerated as a result of the process.  Therefore, the process could not be attributed to any cost savings.  The consultants requested that the process be eliminated and a new governance process be created that delivered the value of the time being spent.  In the end, the owner of the process deleted the bad portions of the report and published the findings to seemingly approve of the existing process.

These are real examples of things that I have witnessed.  I am not saying that any of these processes are bad.  I am not saying we shouldn’t have key processes in place.  What we need to determine is if the process is worth doing, then everyone does the process.  Also, the process has to deliver value to the organization!  Else, why do it?  Why implement a PMO that then says none of the project managers report to the PMO manager?  Why establish a governance process if it isn’t going to determine the fate of the project?  Why implement technology restrictions only to allow a select few the ability to circumvent them?  It is amazing how much waste of effort and cost can be applied to processes that do not deliver on the value promise.

To be a leader, ensure that there is a driven value out of a process.  Know what that value is and how to measure it before implementing it.  Then run the metrics to see if the process is living up to the metrics.  If not, kill it.  If so, then there is a definitive value that you can state you brought the organization.  Also, if the process exists, you must follow it just like everyone else!  That is leading.  Believe me, when you as a leader are circumventing the process, your people will know it.  Then they begin to question the leadership value that you provide.  Think about it.  Have you ever really followed and respected a leader who implements one thing and then does another?

No Day But Today,