3 Leadership ↑
No. 22 – Govern Wisely
Even if your software development team is self-organizing, it is not self-governing. Someone needs to point it at a worthy goal. Even the best software developers won’t experience success if they spend their time developing something of little or no value.
Your software development projects need to be in alignment with your organizational strategy. If you don’t know what that strategy is, or if your project is not contributing to it in some way, then it’s not likely to be a rousing success.
In general, you should only be developing new software in areas that provide your organization with some degree of competitive differentiation.
You also need to pick projects that have reasonable chances of success. Many projects are doomed from the start, either because they are too large, because stakeholder expectations are unrealistic, because the chosen technology is too immature, because organizational politics present insurmountable problems, because you are automating a fundamentally poor process, or for a whole host of other reasons. These projects generally proceed, not because these problems are unknown, or their impact is underestimated, but because people are afraid to speak up, or are not listened to when they do.
If stakeholder expectations are unrealistic, then now is the time to confront that reality, rather than launching into development hoping that things will work themselves out later. If time, money and patience are likely to run out before you reach key objectives, then better to adjust expectations now – or cancel the project outright – rather than launch out on a death march.
You could do worse than to emulate Steve Jobs. When he returned to Apple in 1997, he commented that the company had lots of great engineers, but was suffering from poor management, and immediately began to cancel several large projects, such as OpenDoc.
If your organization has many different software development efforts, and if you are having a hard time carving out dollars for new development, then it may be time to adopt a Plan-Build-Run (PBR) model. In such a model, the Plan function is responsible for identifying, prioritizing and funding new projects, the Build function is responsible for software development, and the Run function is responsible for keeping existing systems operational. This is a drastic measure, and can negatively impact synergy between these three different functions for a single product tower, but the benefits may be worth it, if you need to squeeze dollars out of maintenance functions and achieve greater strategic focus in your development efforts.
Many IT governance functions operate like bankers: they look at the estimated investment requirements, the anticipated returns, and the resulting hockey stick chart, and decide to fund or not to fund – as if these were the only relevant factors.
However it may be time for IT governance bodies to start acting more like venture capitalists. Everyone in the industry has been moaning for decades now about the high failure rates for IT projects (usually in order to sell us some new panacea that seems to help for a while, but does little in the long run to move the needle). But IT projects – like entrepreneurial startups – are inherently risky investments. And so perhaps the job of an IT governance body should be to look for projects where the high opportunities for return outweigh the risks of failure – just as a venture capitalist does when evaluating potential investment opportunities.
If our corporate IT investment boards started operating more like Shark Tank – taking risk factors like the ones above into account – then perhaps we would see better overall returns on our software development investments.
Another important governance function is to ensure that initial project estimates for cost and schedule are reasonable. if your project has to accomplish certain long-term objectives in order to be successful, then you will need to do some level of estimating for the overall project, and will need to make sure you can secure funding to complete the entire job.
Of course, at this point, you will be doing Rough Order-of-Magnitude (ROM) estimates, so you will want to make sure you have some reasonable amount of management reserve – in terms of both budget and schedule – available to cover risks that cannot be completely known to the project at this early stage of the game. You should also make sure you have a way of defending that reserve so that it is not squandered on non-essential items.
Another important function of governance is to select and implement appropriate progress measures for each project. How will you know if the project is on track to meet its key milestones? A formal Earned Value Management system won’t always be necessary, but some equivalent will be needed. For more on this topic, see the Pagan Tuna post, “EVM for Mere Mortals.”
Words from Others on this Topic
The Repeatable Process has one important strength that the Initial Process does not: It provides control over the way the organization establishes its plans and commitments.
There’s an old Wayne Gretzky quote that I love. ‘I skate to where the puck is going to be, not where it has been.’ And we’ve always tried to do that at Apple. Since the very very beginning. And we always will.
– Steve Jobs, “Macworld Keynote”, 2007