Reeling in IT Programming and Development Costs

Spend Matters welcomes this guest post from Raphael Demmer of GEP.

IT category managers and buyers know that development and programming services are particularly difficult to manage from a procurement perspective. This is true even for seasoned professionals with a deep understanding of programming. As it so often is, the main challenge is that procurement relies on exact specs. However, IT requirements, more than any other category, are dynamic and fast-moving. Even veteran IT project managers struggle to define exact milestones, work plans and deliverables when new ground is constantly being broken on untested IT requirements in their firms.

As we are quickly approaching the end of the year and are inevitably inundated with requests for open-ended IT consulting, programming or support engagements, let us have a look at some levers we can apply to try to control costs and arrive at last-minute savings.

Skills benchmarking

A perpetual hurdle to cost control in IT projects is the incomparability of resources. A senior developer at Infosys might have the same amount of experience as an analyst at CSC. Titles, unfortunately, are too eclectic to make an accurate cost assessment. In IT, years of experience is no longer a sufficient benchmark. Financial services IT is different from marketing IT, just as manufacturing IT is different from logistics IT and so on. Furthermore, because of the nature and culture of the industry, actual work experience matters less and less, and “geeky,” innovative upstarts may be more proficient than college grads at a multi-service firm. This is notwithstanding that multi-service firms of the caliber of Wipro or even Zensar Technologies may be more inclined to offer commercial benefits for resource utilization at the end of year. To most firms, a developer on a project is always preferable to a developer creating capability marketing materials.

To get around many of these complications, I propose taking inventory of the actual skills necessary for required work streams. More importantly, rate cards should be segmented according to skills instead of resources. In my experience, while most suppliers might push back forcefully, this has led to some success. If we require someone with two years of systems administration to do a job, that is what we should be paying for, even if the person actually carrying out the work technically has more experience.

Controls and a competitive process at every step of the project

Many IT projects suffer from needless dependency on one key supplier throughout the lifecycle of the project. Too often this is due to the fact that the understanding of the actual project and output is minimal at the outset. However, even if that is the case, there are proven controls that can be put in place to lower dependency and ensure success without cost overages. Although they may sound standard, it is critical to push for them if the wider project plan is not set in stone:

  • A non-conformity clause, stipulating that deliverables or any output should be redone, free of charge, if the client in its reasonable opinion believes the results are insufficient or defective
  • A robust reporting process including clear escalation stages should the project be forecast to run over budget. Or if it just hit the budget in the latter case, why was it not fixed-cost to begin with?
  • A sign-off and handover process that extends beyond the project manager, particularly if the project manager is an external expert
  • While these projects may start with an agile approach at the end of every project phase, the supplier should be challenged to deliver a full project plan for the next phase that is transferrable to another team

Even if there is no time for a competitive tender, if there is an existing supplier pool, it is highly advisable to consider others from the existing supplier pool at every project stage. There are typically better fits available for the type of work required, and this also has commercial ramifications. If there is apprehension in switching suppliers throughout a long-term project, most suppliers are open to hybrid staffing and collaboration with others. The following should be considered at every IT project phase:

  • Feasibility/gap analysis: At this stage we want a supplier that has a broad understanding of different markets, IT trends and requirements. The big four (particularly Deloitte and PwC) are typically best placed to make dynamic, adaptable and tailored recommendations, while taking a pragmatic approach. They are also more trustworthy, as long-term projects are not their preferred modus operandi and they have little interest in proprietary solution on-sell.
  • Systems analysis and system design: IT-focused providers with broad capabilities (Accenture, Infosys, Capgemini) should deliver at best overall value here. It is key, however, to have the above mentioned controls in place.
  • Development and implementation: In the development and implementation stages, we should be looking at suppliers whose key competitive edge is their teams’ actual crunchy programming capability (Wipro, Zensar, Genpact, Tata).
  • Maintenance: Unfortunately, due to insufficient control, enablement and knowledge transfer, this phase is too often overlooked in terms of cost. However, it is frequently appropriate to attempt an in-house maintenance solution, and business stakeholders should be challenged accordingly. If continuous small change looks necessary, it may be worthwhile to question the results of the previous phases.

Share on Procurious

Discuss this:

Your email address will not be published. Required fields are marked *