Both the IT community and the Federal Government often bemoan the fact that newspapers and media, in general, feast on failed technology programs and projects as their headline stories, while the successful projects are all but ignored. It is why the politicians and senior government executives have a long standing fear and largely prefer blind ignorance to the role technology can play in transforming and increasing productivity while they know it to be a truism. It’s why the Harper government, and frankly every government, effectively slows down or stops all IT projects in the months and sometimes year or two before elections to avoid potential embarrassments. We’re equally confident that although the media doesn’t report “Plane Lands Safely at Airport,” failed or over budget IT programs in the Federal Government tend to grab the headlines.
One needs only look at the incredible visibility the Phoenix pay system has garnered due to its glorious “failure”. This, of course, is the system that has resulted in 80,000 of 300,000 public servants not being paid correctly or in many cases at all. While it’s not ours to assign who, what or where all is to blame or at fault, let’s look at just some of the moving parts and complicating factors that have resulted in the new government fully engulfed in an IT Project mess that dominates the headlines. Unfortunately, many of these are characteristic and common to many projects and what therefore tend make it far more complicated than just the technology.
Processes. A long and convoluted procurement process that started in 2009 was awarded in 2011, and has now spanned two distinctly different governments. These procurements, although complex, tend to never envision total scope, underlying fundamental complexities already embedded, or difficulty to implement without a huge change management piece. For example, in this case, during the course of the software development work, it became clear that the myriad of union contracts in the Feds were being interpreted vastly differently by payroll specialists in the various regions and departments; furthermore, contract terms weren’t even clear. Re-configuring and “customizing” off-the-shelf software to handle many of the 80,000 pay rules and rates of the Feds is hopeful at best.
People. As always there is/was a huge people piece. The Phoenix implementation involved a government initiative that saw the Feds centralize and move its pay centre and all its pay specialists to Miramachi, New Brunswick; however, as is often the case, many of the experienced and tenured specialists chose not to move and a lot of knowledge capital went out the door (many have since been rehired and are located in Gatineau now). There has been a steep learning curve for many of the new hires as a result that resulted in a huge backlog of case files. Training and specifically training users was, and is, a vastly underestimated component
Specifications. It is now apparent that architects on the Feds initially vastly underestimated both data volumes and users for the new system, resulting in poor and sluggish performance of the system. Vendors and clients can certainly attest to so called post award “‘surprises” after what may have been a seemingly thorough RFI or RFP process. Who is to blame is always contentious but it is almost always real.
Finally there is always the unexpected, (somehow one thinks this should have been anticipated); however, in this case, the curve was the location of the Miramichi Pay Centre evidently had insufficient Internet bandwidth to handle the system load!
All to say that just as we know the hundreds of truly successful, on time and under budget IT projects will never be the lead story on the nightly news, we have to always remember every project is a complex amalgam of people, process, “stuff” and finally at the end, technology.