At ThoughtWorks technology briefings, Ross Petit and Jane Robarts gave a talk on governance. They start out by mentioning that governance appears to be there to prevent bad more than for actually doing good. It’s to make sure we don’t fail to meet expectations. Today projects have multiple vendors, stack, and stakeholders. Every project has an element of system integration. There is a lot of discovery and hundreds of decisions being taken. We need to make sure all these decisions are taken in a consistent manner and aligned with our goal. A study shows that well governed organizations outperformed poorly governed ones by 8.5 % annually. They face the same king of market and competitor risks as everybody else but the chance of an implosion by ineffective management is way less.
Next they describe IT governance and how it is usually put in terms of technology, assets, budgets, or planning. But it really comes down to behavior. IT is a people business, so governance should be about how people go about executing. We should answer 2 questions. Are we getting value for money and are we getting things in accordance with expectation (regulatory compliance, business control, security, performance, functionality, etc)
They then describe the dual role of the PMO. To delivery teams, the PMO represents the buyers and the funders. They are the buyer’s agent of an IT asset. To a buyer, the PMO represents delivery. They are underwriting the risk that the asset will be developed and complete. Most PMOs focus on one role, but not both.
Next they describe how businesses and IT are not known for good governance. Some examples in business are the A380, mortgage failures, and madoff ponzi scheme. IT examples include projects that are on time and on budget but do not meet client requirements, or there is a hidden system integration project inside an overall delivery project. To be better at governance, we need to be activist investors and not passive. We need to be aware that effort is not result, and the best time to scrutinize is before the wheels fall of. We need the right information and we need it in the right context. There is an asset context and people context. Then we create a lot of transparency and we can work on problems relentlessly.
They describe a continuous governance cycle of IT projects to answer the 2 governance questions: Are we getting value for our money and are we getting things according to expectation. 1st we get the information that we need, and then we can feed a continuous cycle of challenging what it is that we are doing and what it is that we are getting.
0. Step 0 is about fundamental data. Iterations and CI can give a lot of information and show us progress.
1. Step 1 is about project performance. It is more than just progress but also finding out what is being passed as progress. Find out things like is the environment ready, what data has been migrated, what is the re-open rate of defects?
2. Step 2 is about financial performance. We need some visibility into our rate of spend relative to the expectation we had as to how much something is going to cost. It is like a cash flow statement if we are able to deploy and monetize the benefits.
3. Step 3 is about business case compliance. We need a clear statement of purpose. A good business case is actionable and real, unambiguous, written in terms of the problem, not the technical merits of the solution, practical, with logical benefits and objective assessment of downside, risks, and uncertainties. We need to insure we are building the right stuff. Look at the project from the outside-in and see if the business environment has changed, see if the business case is still relevant or the goals still meaningful. From the inside-out, check if the scope has changed and if we are still satisfying the reason why we set out to do this in the first place. Do a story playback and challenge constantly why are we doing these stories in the context of the business case.
With the fundamental, performance, financial, and business case data we can find out if this is still a good investment. But this is not enough. We need to consume this data effectively. Some issues are that status reports are passively communicated, people understand the how but not why, there is too much data but not enough information, we are not following up on business cases to verify fulfillment.
They then explain that to find out if this is still a sound investment we need continuous assessment investment viability. This includes hard assessments like internally influenced project NPV, soft assessment like how much are we spending relative to the size problem that we are looking to solve. It also includes things like the current health of our funding sources, and do we meaningfully engage the investment committee. We can vary time, scope, quality, or cost. We can accelerate delivery and increase value of the investment, or check if the business assumption is still valid, or if the defects are proving to be too expensive. We can see the financial impact of technical debt to technical equity ratio (Asset gearing). If we take on technical debt, then maintenance cost will be higher and depress long term return on the investment. Technical debt is bad if we do not pay it down. But if this is a short shelf life solution, having technical debt might be ok.
They add that to find out if we have the right people we need continuous assessment of people. We need to focus half of our attention to people related issues. IT is a people business more than it is an asset or technology business. Resources have capacity, people have capability. We have to always ask, do we have the right people. Are they confusing effort for results. Managers tend to play the hand their dealt rather than asking for new cards. We have to look beyond the data to find out what going on. Are our people’s goal aligned with the project and vice versa.
Next, they describe the characteristic of highly effective steering committees:
· Encourage transparency and truth
· Make personnel decision capability-based and safe
· Set your diet of data, don’t accept only the data that is given
· Scrutinize past projects for systemic mistakes
· Committee members must have sufficient experience – and experienced mistakes
· Engage the delivery team in terms of success and not failure
· Challenge good news, bad news, and silence
Understand before making yourself understood
· The committee must function as a team
· See things from inside out
· Discipline and consistency.
Doing this gives effective governance and enables getting the data in the right context and can answer the 2 questions of getting value and accordance with expectation. It gives us the means to interrogate, question, and challenge. But to actually do it is up to the behavior of the committee.
Next they explain how this governance is real time because with each iteration we get the data in context and we can get the right people together to scrutinize the data and find out if this is still a good investment and do we have the right people. If we make a change, then in the next iteration we can follow up on the change.
They stress that governance is not about tools. It is about clearly defining the critical decision-making processes.
Next they cover maturing PMO and 4 dimensions.
· Project structure (zero state)
· Project execution (can we measure, what can we measure)
· Portfolio management (project vs. product, certify benefit realization)
· Business consumption (balancing risk vs. return, supporting business changes and prioritization)
A lot of organizations do well with project maturity. They start out with low repeatable process, move into repeatable, and bring in tools and refine that area. Start ups and product companies are great at portfolio management. They are great at making decisions that will improve their product, generate revenue and drive the market. With proper governance we can see maturity in both areas which leads to opportunity to grow and change the organization and make real decisions based on that.
They wrap up explaining that to initiate real time governance, align delivery operations by looking for the quality and consistency of the data that you can get. Get only the data you need when you need it and know that it is different depending on where you are in the delivery cycle. Contextualize the data and challenge and follow up on business impact.
This presentation is available on InfoQ at http://www.infoq.com/presentations/agile-pmo-governance
