A one vendor fail or a multi-vendor fight?

A one vendor fail or a multi-vendor fight?

Summary: I found the advice from the inspector-general of taxation, that the Australian Taxation Office (ATO) should avoid long, fixed-cost projects where one vendor has the reins, to be a bit short-sighted.


I found the advice from the inspector-general of taxation, that the Australian Taxation Office (ATO) should avoid long, fixed-cost projects where one vendor has the reins, to be a bit short-sighted.

The argument was that with a fixed-cost and single vendor, there was a risk that scope would change and as timelines began to slip, the vendor would drop the quality of the end-result so that it could finish at an acceptable cost.

Therefore, projects should be passed out in modules, smaller bite-sized chunks that would have lower risks of expanding in scope.

Talking to IBRS analyst Jorn Bettin about this concept, he believed that its success would depend on how the responsibilities were divided amongst vendors. There can be a lot of finger pointing going on when multiple vendors are working on projects that dovetail together. That's why companies often like "one throat to choke".

Bettin thinks that to have multiple vendors working on small modules for an overarching program, their work should be divided by competencies.

But that causes its own issues, according to Bettin, because it's difficult for the government to truly understand what big vendors' competencies are. Meanwhile, small vendors, which may have well-defined competencies, are passed over because of their risk profile. If something goes wrong, will they be able to make it right or pay to fill the gap?

My biggest issue with having multiple vendors is that even if work is split into competencies, it requires the government to be a real leader, guiding the vendors into their individual berths like a harbour master. Past experience has shown that government project management and IT governance leaves much to be desired, and I could see such projects ending in absolute shambles.

So I'm afraid, in this case, it's probably damned if you do and damned if you don't.

Topics: Government, Government AU, Outsourcing

Suzanne Tindal

About Suzanne Tindal

Suzanne Tindal cut her teeth at ZDNet.com.au as the site's telecommunications reporter, a role that saw her break some of the biggest stories associated with the National Broadband Network process. She then turned her attention to all matters in government and corporate ICT circles. Now she's taking on the whole gamut as news editor for the site.

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • Governments simply don't know how to run projects. Nor do, it seems large Australia corporations. In both, Prince2 rules supreme as some kind of panacea PM methodology which quickly turns most projects into treacle.
    Give me a good PM with battle scars and PMBOK any day of the week.
    • I have only experienced Prince2 externally. The customer used it to 'manage' the process whilst 'we' (the supplier) just did our best to meet the contractual obligations.

      So here was one side using Prince2 and the other side just using 'what we thought worked'. The end result was a 4 year program taking 8 to *successfully* deliver what was required.

      Prince2 (and other magical management processes) can help reduce risk, however it will add enormously to the project schedule and drive people mad with it's frustratingly complex requirements.
      Scott W-ef9ad
  • I agree. Its more about project governance and the ability to control scope than anything to do with the fact that it was a single vendor. Introducing more vendors simply introduces more complexity - so I'm not sure how they think that is going to help deliver on time and on budget. Switching to a more agile approach may reduce the risks but can be difficult with complex, far reaching changes. As per the previous post, a good battle scarred PM, with executive support(!) is what I'd be choosing.
  • Where most projects fail is the recognition that less is more. Projects always suffer scope creep with the idea that 'with a little extension so much more could be achieved'. Add a complex management process and you get 'minutae fixation' that dooms projects to failure.

    Using this ATO project as an example, of the 170 applications to overhaul probably only a few were critical path. Source vendor(s) to resolve the critical path first, one step at a time. Then you can tender for other vendors to resolve the outlying apps over an extended period of time (multiple mini-projects).

    This would have resulted in:

    1. Critical path resolved up front. Immediate benefits to be gained.
    2. Non-critical apps resolved in phases. Incremental gains, with smaller risks should one or two app integrations fail.
    3. These outlying apps are most likely departmental. Smaller vendors working directly with each department, under an overarching program administration, will likely yeild better results than a lowest common denominator mega-app.
    Scott W-ef9ad