IT Cost Drivers

Tips to Reduce the IT Costs for Programs / Projects

The following is a list of a number of things which can be cost drivers for IT projects:

  • The number of systems touched
  • Quality of Requirements Documentation
  • Requirements Capture and Solution Design process
  • Document review process
  • Extensive use of vendor resources
  • Fear culture causing risk averse behaviour
  • Engaging with different business models
  • Approach to package implementations
  • No re-use of Testing IP (scripts etc)

The number of systems touched

  1. Makes Design more complex and expensive
  2. Makes Development more difficult and expensive
  3. Makes organisation rely heavily on experts
  4. Makes Testing more complex and expensive

Solution

  1. Implement strategy to reduce number of systems – NOTE  – this is beyond the control of individual projects or programs but may be addressed as a strategic driver for the organisation

 Quality of Requirements Documentation

  1. Text based requirement too easily misinterpreted (by users and developers)
  2. Not based on data dictionary – ambiguous
  3. Result is requirements are not locked down until far too late with major scope management issues late in projects when burn-rate is highest

Solution

  1. Screen and Report mock-ups included in requirements
  2. Use of Requirements Management Tools eg., Telelogic DOORS

 Requirements Capture and Solution Design process

  • Common approach is to produce a 2 pass approach – a signed-off High Level document followed by a Detailed document
  • Sometimes only a High Level document is produced

Solution

  1. Need detailed Requirements Capture to be very unambiguous and succinct
  2. Need detailed Requirements to be documented as quickly as possible
  3. Need to map Solution Design to the Requirements document at individual requirement and component levels to ensure optimal design and development effort
  4. Use of Prototyping to capture requirements and solution – this allows users to get an early view of proposed solution and maximises their engagement

 Document review process

  • Common approach is to have a sign-off process which involves multiple reviews / iterations

Solution

  1. Work-shopping is recommended wherever possible as it:
    1. allows reviewers to interact and share knowledge
    2. minimises iterations
    3. reduces time and cost of review process

 Extensive use of vendor resources

  • Usually, vendor resources are more expensive than internal resources
  • Vendors retain a significant part of IP making it difficult to negotiate contracts
  • There is a significant administrative overhead with using vendors because of the contract management issues

SolutioN

  1. In-source
  2. internal resources are cheaper
  3. this  also retains IP within the company so that future development is also cheaper
  4. Negotiate better deals by proposing larger deals for each project  if necessary outsourcing the whole project to vendors
  5. Negotiate larger organisation-wide outsource model – this is not something that can be managed by the project  but can be addressed as an organisation strategy

Fear Culture Causes Risk Adverse Behavior

  • Fear of failure and the adverse reaction to failure causes people to choose safe options which may not be best for the organisation in the long-term

  • Projects which should be stopped are sometimes continued because of the repercussions associated with stopping them

Solution

  1. Change the culture – there is much to be learnt from mistakes – ensure the learnings are banked

  2. Reward people who propose that non-viable projects be stopped in the same way successful projects are rewarded

 Engaging with different business models

  • There is a cost in having multiple engagement models with various business units
  • There should be a generic business engagement for IT / project resources to ensure that there is one set of processes
  • Multiple engagement models make training and re-deployment of staff very difficult

Solution

  1. Develop a standard engagement model with all business units – this is not something that an individual project can implement but is an IT-wide strategic change

 Approach to package solutions

  • The common approach is to start with a ‘blue-sky’ or wish-list requirements
  • This approach means there is an expectation management issue when package is reviewed
  • Usually many modifications are proposed
  • Changing packages is a very substantial decision with often very serious ramifications to not only the project concerned but can cause ongoing issues with all future upgrades and interfaces to the package

Solution

  1. Use a gap-analysis approach whereby the package is reviewed and a gap analysis is documented
  2. The potential gaps then need to be investigated to determine if work-arounds can be found by changing or adapting current business process
  3. Packages should only be modified as a last resort  

 No re-use of Testing IP (scripts etc)

  • The development of test scripts and test environments on a project by project basis
  • This approach means there is no leverage on previously developed testing scripts
  • There is a significant cost and lead time in setting up test environments

Solution

  1. Develop a test centre approach able to utilise previously developed knowledge and test processes, scripts and environments

 The following is a list of the possible outcomes of proposed changes:

  1.  Reduced re-work caused by scope change
  2. Reduced costs for Testing
  3. Reduced costs for Development
  4. Reduced project delivery times
  5. Improved perception of IT delivery
  6. Reduced expectation management and scope management issues