Share this
Mister Wong
Digg
Del.icio.us
Slashdot
Furl
Yahoo
Technorati
Newsvine
Googlize this
Blinklist
Facebook
Wikio
Hear this text
Export PDF
Print
E-mail
Tags
Reflections on the development of AuditSystem/2South African chartered accountant Trevor Stewart (pictured) recently sat down with The Project Manager in New York City to reflect on managing the development of AuditSystem/2, Deloitte’s integrated audit support system used by tens of thousands of professionals worldwide in serving the clients of the firm’s $12-billion audit practice.
Stewart kicked off his career with the Johannesburg audit practice of Deloitte, followed by a stint in London.
With a Mathematics degree from the University of Cape Town, he recalls gravitating toward using highly quantitative techniques on his audit engagements.
When the first personal computers came on the scene, Stewart says, “They were magic. The transformative potential of IT [information technology] dawned on me.
“I had seen it firsthand as a user, I became an evangelist, and I embarked on a path of learning as much as I could about applications and their development.”
Several years later, his passion and self-teaching paid off in the form of a transfer to Deloitte’s New York headquarters.
Tasked to lead the computerisation of the firm’s audit practice, Stewart set up an audit research and development facility in Princeton, New Jersey, an hour’s drive south of New York City, to develop AuditSystem/2.
After four years of initial development by a team of 50 or so software engineers and auditors, Version 1 was ready. That was the mid-1990s, and the system, now in Version 4, has been used continuously since then across the firm’s worldwide practice.
Reflecting on what contributed to its success, Stewart believes a key element was that everyone on the team understood the business needs being addressed and what was important to end users and the firm. “When that’s missing, developers often focus on the wrong things,” he plainly notes.
“It also helped that I and the two other partners leading the team combined audit experience with development know-how.
“Because AuditSystem/2 was critical for our audit practice,” notes Stewart, “we had the project team report to practice leadership rather than to the CIO [chief information officer].”
This somewhat unusual arrangement paid off by keeping the team closely focused on the needs of users – auditors in the field – and ensuring that they could draw on deep application expertise when required. Direct channels meant less opportunity for the miscommunication that plagues many developments.
Meanwhile, the team worked closely with the CIO on compatibility, infrastructure and support issues.
“At the start of the project, we spent a lot of time in the field meeting with end users and practice leaders to understand requirements,” says Stewart, when asked about the consultative demands required from a manager. “But if you are not careful, this process easily becomes unmanageable.”
The team found that users often expressed requirements in terms of specific feature sets with a particular user interface in mind. Says Stewart, “The architectural challenge was abstracting essential underlying requirements from users’ descriptions of their needs in an implementation-independent manner, while avoiding overloading the system with bells and whistles.”
When it comes to the creation of innovative, complex systems such as AuditSystem/2, designed to meet the needs of a diverse community of users, Stewart believes it is impossible to specify everything up front. Classic ‘waterfall’ project management, where complete and detailed functional specifications are handed over to systems analysts – who hand over detailed design specifications to programmers – does not work for this type of project. “I recently saw a comparable project fail catastrophically where this was not understood,” says Stewart.
“It is not feasible to specify in advance how every feature is going to work, or even what every feature is.”
Stewart and team started by building a ‘skeletal’ system that focused only on key architecturally significant features and then added layers of functionality, frequently circling back to users for feedback. “We built iteratively; and, while we had a master plan, it was not oppressively detailed or rigid,” he adds.
Organisationally, Stewart ensured that the project team was integrated, with users and software engineers working side by side so each would learn to understand and respect the perspectives and problems of the other. “I have seen many projects in which there is open warfare between users and developers. We worked hard to prevent that.”
The auditors who were brought in to work on the system came from all over the world, for limited time periods. “This not only created a healthy flow of fresh and diverse perspectives, but also resulted in planting knowledgeable users back in their home offices and countries where they were invaluable when it came to
deployment,” says Stewart.
Having a steering committee with clout and credibility in the organisation helped enormously. “They made sure that practice leaders understood the benefits and that the project was properly resourced,” he says.
To be effective, steering committees must be kept well informed. “This includes breaking bad news early and not waiting for miracles to bail you out.”
Getting good information from team members is essential. “When someone says they are ‘90% done’, it often means there’s a long way to go and you need to dig deeper,” adds Stewart.
Project plans need to be realistic. “Predicating a schedule on rosy, best-case scenarios is invariably a bad idea,” he warns.
When you are swept up in technical development, it is easy to defer deployment planning. That can be a mistake.
Says Stewart, “In a large firm like Deloitte, the global deployment of a significant new system is a logistical challenge involving communications, change management, infrastructure creation, training and support.
“There are many players involved and their activities must be planned, co-ordinated and budgeted well in advance,” he adds.
Deployment preparation should run parallel to software development and not be an afterthought.
Garreth Bloor
About Trevor Stewart
Having retired from Deloitte in June 2009 after a 38-year career with the firm – 31 years as a partner in numerous roles – Stewart is pursuing an academic and consulting second career in New York and completing a PhD at the Vrije Universiteit in Amsterdam.
Until recently, he was a member of the Tax eAudit Working Group at the Organisation for Economic Co-operation and Development and a vice president of the American Accounting Association.
He has spoken at numerous seminars internationally, authored dozens of technical papers and is a co-author – with Kenneth W. Stringer – of Statistical Techniques for Analytical Review in Auditing.
Stewart and his wife, Margaret, live in Manhattan.
