by Dianne Volek

In assessing potential technology projects, companies tend to focus on improving the frustrating internal processes or “digitizing” paper-based systems. 

Sometimes an IT project is grown around a specific software application – with management pressured at a user level to make a quick decision without considering other options. 

The benefit of a scientific and methodical “Prioritisation Process” is that it prevents a solution being found before the problem is recognized, acknowledged as a serious business issue and understood. 

Even the best prioritization process will not result in appropriate projects if the initial “brainstorming” of IT opportunities does not identify the correct focus areas or is limited to current frustrations. KD believes that many companies concentrate their IT efforts so intently on internal operations that they forget to take external environmental factors into account.

KD's strategy methodology takes a customer focus, assessing market trends, competitive advantage, core in-competence, and customer requirements and wishes. It is important that the Strategy design team understand that growth will come from satisfied customers and improved services and products, not from the IT systems themselves.

Once the team has identified a wide-range of business problems and business development opportunities, these are then analysed in more detail. Factors that are discussed include benefits of finding a solution, the risk of ignoring the problem, and if the solution is potentially cultural, procedural or technological. Many problems can be solved by IT, but are nevertheless not appropriately solved by IT.

The InterComm methodology is based on a simple matrix, which makes priorities clear. Team members know where each project fits, or accept that it was rejected for the right reasons.

• Quadrant 1 projects are easy, high benefit applications and are done first. 
• More difficult, high benefit project are done next, when confidence and experience has been gained. 
• Quadrant 3 project are easy (although lower benefit) to rebuild confidence after the difficult projects. 
• Difficult, low benefit applications are usually rejected either sooner or later. 

To get consensus about benefit and viability scores, team members decide jointly based on standard, logical criteria.

Benefit criteria include: 

• Accessibility of information 
• Speed of throughput 
• Volume of throughput 
• Impact on actual workload 
• Accuracy or completeness of information 
• Overhead and production costs 
• Is the problem a core “in-competence” 

Risk/viability criteria include: 

• Cost of software/implementation 
• Demand on internal staff 
• Probability and consequences of failure 
• Time taken to implement 
• Impact on day-to-day business functions 
• Technical difficulty 
• Previous experience (with IT projects) 
• Cultural readiness