Of course, software practice has been continually improved. Yet, C-suite’s biggest issue has not gone away: technology’s poor contribution to organizational strategic agenda. Why? A simple reason: we made strategy-related improvements in governance, but failed to make strategy-related improvements in practice.
We thought that strategic business outcomes is almost entirely an IT governance issue. So, we attempted improvements in IT governance. For example, we tried changing the CIO’s reporting, role, and responsibilities.
Another example: we tried using frameworks that make recommendations on what should be done to achieve strategic alignment. “Fix cross-discipline disharmony” is a typical recommendation. There is in-fighting between IT and business professionals due to differences in disciplines, objectives, culture, language, and incentives. So the framework recommendation would include efforts to establish trust between the two groups, a mechanism for consensus decision-making, getting IT folks to sit closer to business folks in the office, and getting IT folks to talk the language of business folks.
While these two changes are certainly helpful, some of the other improvements are debatable: creating a so-called “Strategic IT Portfolio” and picking a software from this pre-determined list, for example. Anyway, fixing IT governance alone did not fix the strategic alignment issue.
We’re grateful to software practice innovators, who have given us a steady stream of improvements.
- We have a strong technology focus
- We pay attention to human factors while designing software user interfaces
- We’ve also improved our project management capability.
Which is all necessary. But wait a second. In essence, these improvements have been aimed at achieving software quality, faster development, and reduced project risks, right? If so, where are the practice improvements that could help deliver strategic business outcomes? Well, some experts have tried to improve the requirements process, but then you could still ask a very fundamental question: how do we even know that we’re not wasting money gathering requirements for a wrong (unaligned or poorly-aligned) software? Another very fundamental question you could ask: do we have a method to integrally design software and business change from a strategy standpoint?
What we need: a strong business phase in software practice
Software practice must improve.
As the technical, human, and project management factors dominate software practice, the business factor receives very little attention. Look at the business phase in conventional practice. This phase has just one business-specific activity: the requirements process. Can such a business phase help translate an organization’s strategic agenda? A software team that merely has access to the agenda will still deliver unaligned or poorly-aligned software.
We need a clearly-defined strategy translation activity in the business phase. What tasks should this activity comprise? Who should perform the tasks? These are the two broad questions we must find answers for in order to create a strong business phase.