What a concept! A Tax Technology project delivered without fault! Surely this is outside the field of reference for many; but for others, and hopefully you are one of them, it is at least in the realm of the (improbably) possible.
What do we mean by zero defect? As a minimum this is a project that goes live on time, within budget, meets 100% of expectations, and has no omissions or related errors in post-production. Ok, when put like that, it definitely sounds improbable.
Recently, we put our heads together and counted about 200 Tax Technology projects over the past two decades. Between us we had direct experience of around 80 of those and indirect (oversight) of the rest. After applying the criteria we arrived at a zero defect project count of 4. For discussion purposes we will bypass 3 of these because:
- Our experience of one of them was indirect, i.e. we did not participate ourselves
- We were bit part players in another, where despite increasing the major objectives from 1 to 8 in mid-project, this incredible global project was delivered on time and with no defects
- A small initiative predominantly delivered by a single person, so not a team effort.
So, just for fun, let’s call our remaining candidate Project Perfect!
Project Perfect was a significant enhancement to a VAT calculation and compliant invoicing solution covering many EMEA and APAC countries. We had 6 months, a 6 figure budget, a project manager and 3 core team members. It was completed flawlessly, including documentation, at the end of the 4th month, despite losing most of the first 3 months handling other priorities. So, what were the conditions that allowed a result of such quality?
We had some natural advantages. Besides solid skills, we knew the customer well and were intimately familiar with the requirements, the application (where we had performed earlier projects), and its component software and tools. Still, this alone would not have been enough. We gelled as a team and adopted a no-stone-unturned approach. The nub of the effort took place during one key 3 day huddle. User acceptance testing went without a hitch and took less than 2 hours. We were comfortably aligned with corporate goals and their IT prerequisites.
It takes many factors to create success (see How Tolstoy understood Tax Technology projects), but fundamental to this effort was familiarity with every technical configuration and line of code down to the lowest level. On many projects this is hard to achieve and perceived as complex, but it is only complex (and risky) until it is well understood, then it becomes simple. After that, from a project perspective, handling such detail is just a matter of due diligence.
Secondly, our project manager did little except run block for us like a 300 pound linebacker protecting his quarterback; he had trust and confidence in both the team and his laissez-faire management style. Granted, most project methodologies do not allow such freedom, and this is fine in itself, but adding too much structure will rule out delivery speed and accuracy of this magnitude.
So, what can we take away from the story of Project Perfect?
Way back in the 70’s, in the classic book The Mythical Man-Month, Fred Brookes suggests the difference between a good and a not-so-good IT project can be an order of magnitude [tenfold]. A later study by IBM suggests a factor of 25. Project Perfect, at least circumstantially, corroborates these numbers. In fact, as the power of Tax Technology software and tools increases so does the reach between the poles of success and disappointment.
However, in another sense, the example of Project Perfect has limited value. Amongst our sample of 200 there was a decent proportion of great projects that provided excellent value to the customer within more normal criteria. As with Project Perfect they tended to be characterized by skilled practitioners, light-touch management, and organizational alignment; but also critical were reasonable expectations and an understanding of both the capabilities and limitation of the technology in terms of delivering value to the indirect tax function. For most, these projects are a more useful study than Project Perfect, and more realistic as a target. In any case, once you have achieved a couple of these, Project Perfect may happen anyway without further assistance just because the planets of project foibles align magically and spontaneously.
Never-the-less, Project Perfect demonstrates the ubiquitous value of control over the technology. Control, in this context, has a pertinent and exhaustive quality about it and yet is achieved by the absence of intervention. This will be counterintuitive to many for whom control means (potentially) layer upon layer of external governance. Instead, the skills and experience of the project team take center stage, plus the stewardship that brings them to bear to the best advantage of the organization. Only when there is lack of confidence in the team or the general IT environment will a diligently implemented methodology likely yield better results.
In any case, more Project Perfects are always a possibility, but then so are highly frustrating projects irrespective of whether they were tightly controlled or not. Also, we are not advocating having no controls, because as a minimum excellent planning is always required. Still, it remains a curiosity and a wonder that the best way to achieve zero defect is in a shorter space of time than any planner could ever possibly imagine putting into a project timeline.
However, to further this discussion we would prefer experience well beyond our own. Please join and comment at our blog pawpawtaxology.com, where we lead an independent discussion on these matters as one more step towards the effective digital transformation of the Tax function at major corporations.