Software Programme Management
In my linkedin blog article, Strategy, I looked at three models, one on business strategy, one on programme governance, and one on IT architecture pattern selection. This blog looks at the programme governance model. (It reuses some of the words too.)
The second model, aimed at the software portfolio governance was shown to me by Dan Remenyi, where one plots elements of the software portfolio as providing competitive advantage and the degree of dependence on the IT. The applications portfolio can be mapped onto these scales. Remenyi argues that the four quarters are families, which he names Strategy, Development, Support and Factory.
Each of these four classes of project drives the allocation of development funding, priority, maintenance funding, project risk appetite, people skills, project governance and sponsorship, software sourcing policy and today, hardware sourcing policies. What’s interesting about this technique is that it permits the management of software products to have different governance policies depending on the nature of the business; a professional services company will rely on its personnel systems, particularly its training acquisition, time management and skills databases, whereas organisations with more homogenous staffing requirements will place a different priority on their personnel systems and the required functionality.
This model allows, because of the competitive advantage dimension, the business strategy choices to be reflected in software management policies.
Competitive advantage varies over time, your portfolio depereciatrrres and competitors react to your competitive advantage. Companies may this need to refactor element of their software portfolio from unique to commodity as their competitors imitate or supersede once competitively advantageous processes. Also, nimble software users may transition software and business function from development to strategic, and then to factory!
A key insight is that a company should adopt different project management strategies depending on the classified role of the software system. The fact that different people’s skills also suit them to manage different types of project was also a relief and at the time something new to me. For instance a development project is likely to have a high or medium technical feasibility risk, and thus the project should be managed by someone with high technical skills, a strategic project the key risk is likely to be financial and/or one of deadlines and thus a more traditional set of project management skills should be used.
Another insight is that it one has to understand if the business process is unique or commodity, which will allow different cost management strategies to be applied. A unique business process is likely to require unique software, where functions deemed factory or support may be best suited to be delivered by off the shelf software. An additional dimension of Remenyi’s thinking is that while, if one requires unique function, software should be developed, if not, it should be bought and that the optimum process as defined by the software author should be adopted. You don’t want to be innovating your accounting software, at the least it makes audit costly and hard or your regulatory compliance software, which will be often given to you by the regulators but otherwise, cost is a key issue. In both cases a critical requirement is that the software keeps up with externally defined standards; as the law changes, the software will too. Bespoke amendments to a package will inhibit the speed and increase the cost of this mandatory maintenance activity.
A final comment is that I looked to make a consulting offering using this methodology and objectively measuring competitive advantage is very hard; I looked at investment i.e. stock evaluation techniques which would have taken us far outside the IT department who were the potentially obvious clients for such an offering, also the techniques themselves are controversial in their effectiveness. Net present value is also an unreliable indicator for software projects. The methodology requires senior business buy-in and a level of IT literacy at the executive committee level, a level often missing in many British companies and 3rd sector organisations, but particularly small and medium enterprises. That buy-in will only come if the tool is seen to be effective and deliver tangible benefits.
I think it’s very powerful, particularly in recognising that one size fits all decision rules and project management is not an appropriate approach.