There are as many suggestions about what makes a good or bad IT project as there are projects themselves . . . or, at least as there are commentators to pick holes in them.
Aside from external issues, such as the trustworthiness and proficiency of vendors, and the stability of the environment and marketplace, experts say there are a number of internal factors that you should have a handle on before you undertake any major project.
The common threads, regardless of who you talk to - consultant, vendor, business manager or IT manager - are executive sponsorship, people, communications and planning. Handle them well, and you are almost guaranteed success. Handle them badly and you are heading for an inevitable fall.
Look to the Top
Bill Gibson, CIO of the Australian Taxation Office, reckons executive sponsorship of major projects is the absolute, no-question-about-it, number one critical success factor. "Unless you have that, and it's there for the duration, you are already going to put the project at risk."At the ATO that level of commitment is best exemplified by the ongoing "ATO Change" program. The organization's most senior managers - Commissioner Michael Carmody, and Senior Commissioners D'Ascenzo, Granger and Farr - spend two to three hours together at a meeting every fortnight reviewing progress and assessing deviations. According to Gibson, they expect to be informed against a set of eight specified outcomes, and any significant deviation must be approved by them.
Currently into the second year of a four-year schedule, Gibson expects the commissioners' active involvement in ATO Change to continue for at least the next 12 months. Not quite the duration, but nonetheless a significant indicator of executive interest. "I don't see many other organizations making that sort of commitment," Gibson says.
This is not exactly a new concept, however. In 2002, Olin Thompson published an article titled "Who to Blame for Project Failure" on the technologyevaluation.com Web site, in which he said that "for most failures, we need to look up within the organization".
"Enthusiasm and commitment for a project does not 'trickle up' through an organization, it 'trickles down'. Only the person at the top can set the tone, have enough power to enforce decisions, allocate the resources, resolve conflicts and give direction to others, whether explicit or implicit. Only the person at the top can create enthusiasm and commitment," Thompson wrote.
Look to the People
Of course, enthusiasm and commitment alone, while admirable, will not ensure successful completion of a project. No one yet has created the self-raising project, so you need people to start, manage and complete it. And they need to be the right people.Getting the right or the best people can be a challenge from the outset. Demand for the time and skills of the best will inevitably be high, even without the extra burdens of a special project. It is a lot easier to get the people no one wants. But settling for less than the best can cause problems beyond simply the inevitable stuff-ups.
Mike Smith, executive director for EDS Australia's government group, says that during the "whole-of-government" outsourcing projects, disgruntled people were an issue. These could be people who philosophically objected to government outsourcing, or those who felt that their once-colleagues who moved across to the private sector outsourcing supplier were traitors to the system. He cites examples of sabotage ranging from pulling connections out of the wall to moving equipment or breaking pieces of equipment to threats of violence (although he stresses that he knows of no cases where this was taken to actual assault). And this last example of people against those who were once their friends and workmates.
Smith says it is important not just to have the right people, but also the right blend of people: "There are some who enjoy building things, and some who enjoy fixing things. You need the right skills and the right mix."
Jonathan Palmer, CIO of the Australian Bureau of Statistics, also considers people - or specifically the wrong people - to be a major pitfall of projects, and that includes not only the people actually working on the project, but those who are impacted by the project. "Poor assumptions made about how users will operate are often the result of lack of communication or wishful thinking."
He says the impact of major projects on organizational culture and the requirements to change behaviour implicit in project outcomes are often overlooked. Not only are these effects difficult to predict and manage, none of the budget ever goes into making those predictions or managing that change. Palmer cites knowledge management projects as classic cases where typically little thought is given to assessing how and even whether the users will ever use a new system.
Meanwhile Ron Posselt, Lake Macquarie City Council's group manager for operations, suggests that there is one user result that you can predict, and that is that the project will never be entirely right. "People have expectations that things will be 100 percent, but they never are. If it's 95 percent there, users often focus on the 5 percent shortfall," Posselt says.
Despite the fact that this 5 percent can often be resolved later and that normally it represents the trivial or "nice to have" aspects of a project, he says, users do not allow for the complexity of a project, nor for the inevitable compromises that are made along the way.
Get the Message Across
This raises the issue of communicating what you are doing and why, something that Posselt reckons cannot be overemphasized. Communicate across the board he says, between all involved, including vendors and suppliers. Good communication means good documentation, clear service level agreements (SLAs) and the determined avoidance of the "gentlemen's agreement" that leads inevitably to misunderstanding, failure and recrimination.The ATO's Gibson warns that IT can be guilty at times of not seeking enough clarification from customers, often reverting to the whine that "the customer could have been more precise".
Communicating clearly works both ways, of course, which at times includes standing up for your convictions. "IT needs to stand its ground and explain," Gibson says, "as opposed to those who feel they always have to say 'yes'. Good project managers are able to remain reasonably firm without being seen to be obstructionist. It's a poor project manager who recognizes the risk but doesn't enunciate the issues. You've got to be prepared to have fierce - frank and honest - conversations." The trick is to avoid letting that fierceness lead to confrontation.
Palmer says the best projects are synergies between IT people who understand the business and businesspeople with enough IT to understand why they need it. It is a partnership, he says.
Andrew Johnstone-Burt, COO and head of public sector for Capgemini, agrees, going further to suggest that not having one team with a single mission or objective is a major issue and cause of project failure. He adds that the "one team" has to comprise agency, consultants and vendors. "Sub-vendors are often not asked to contribute when they very well might have a solution."
Basic Problems
When projects fail, was the root cause lack of communication? Poor vendor choice? Scope creep? Lack of experienced personnel? Or is it because no one knows how to spell Al Qaeda? This last point - the Al Qaeda issue - offers a dramatic example of the dangers of incomplete communication.
George Kondrach, executive vice-president of Innodata Isogen, a New Jersey-based supplier of content supply chain solutions, says the difficulties in large-scale intelligence agency computer projects is not always based on technical difficulties but cultural behaviours and the way in which information is shared.
"Some of the problems in sharing information are quite basic," Kondrach says. "For example, one well-known terrorist organization has two different spellings. One intelligence agency [Kondrach does not say so, but it is the CIA] spells it as 'Al Qaeda', while another spells it 'Al Qa'ida' [FBI]. A collective search of their databases would yield incomplete results." To confuse the issue even more, the FBI spells Osama bin Laden as "Usama bin Laden" while the CIA sometimes uses the spelling "bin Ladin" - and "Al-Qa'ida".
While this level of semantic interest may seem trivial, the implications of not being able (let alone willing) to properly share information could have dire consequences for the intelligence community and the communities they ostensibly protect. Okay, not all IT projects have terrorist activity as the possible result of a stuff-up or difference of attitude, but the implications are the same: unless you are on the same page, with a clear appreciation of how the project will impact on all players and be integrated into the organization, you have little chance of reaching a shared goal.
Of course, sometimes communication can backfire by setting expectations that are too high. But Posselt reckons you can address this beforehand: communicate realistically at the outset.
"There is a propensity [by people with an interest in technology] to over-boost tech solutions. Therefore it's critical to have businesspeople on hand to lessen this." He warns that "a lot of IT people have a problem with being realistic" - which means that you need to communicate, and do it clearly, realistically and regularly, and it is best if you start the communication process as early as possible. That way, at least you will know that your spelling is consistent.
Plan . . . from the Beginning
A communications policy should be part of your project plan, and that plan should likewise be tied down before you take your first step.Gibson says that "projects start with a customer saying 'I have a business problem'", but that problem might be very loosely defined, and those involved in the project need to get closure and lock down their plan of action with sufficient time allocated and clear definitions in place. He says that the situation at the ATO is improving. "We work in a very constructive and collaborative way and getting clarity is easier and more timely, more predictable. It's still not 100 percent but it's better."
Capgemini's Johnstone-Burt says that a lot of plans do not take a "whole-of-system life" view. Plans should look at both the life cycle of the program and "through-life" support. There is often a focus on the go-live and not enough (if any) on afterwards. "You need to look at end-user acceptance, skills level required and the impact of the change in processes."
But even the best laid plans . . .
Constant Change
The thread within all of these threads is the inevitability of change. While it is a cliche that change is the only constant, it is an aspect that needs to be taken into consideration with any project, but particularly with large ones. "Scale and time make change inevitable," ABS's Palmer says.Posselt agrees, in principle, but says that you need to look at how important is the change you want to make or have been asked to make in the overall concept of the project. "If it is not important, then put it aside for later. Like when you're building a house, if you kept incorporating changes it would never get finished. You can come back and look at it later, and with IT projects this is not too difficult to do."
EDS Australia's Smith feels that the hardest part about any project is dealing with reality. "What you're about to experience is a very approximate view of what you've planned. You need to recognize the uncertainty of the future. The map will change."
That map includes changes to project personnel and executive sponsorship, changes to objectives, changes to technology (is the project still relevant or now obsolete?) and changes to the environment (speaking of terrorism, Smith quotes September 11 as bringing massive changes to security projects, and the viruses of 2001-02 causing significant impact on Internet projects).
"It's not always easy to understand when a change is happening, so you need an appropriate change control mechanism, with appropriate reporting and control," Smith says.
But can change be planned for?
Gibson does not think so. "All projects are discoveries, and you'd never have a 100 percent precise definition of what you want and that it will never change. Those who say that everything can be planned out and that it will always be okay - I have to disagree. Looking through rose-coloured glasses will inevitably lead to huge disappointments, or worse."
There are such things as unsalvageable projects, Gibson says, when it is recognized that a project is going to cost too much, take too long and/or not deliver on expected functionality. "But 'unsalvageable' should be recognized and acted upon earlier than when the cost overruns," he says. "It might be that you've found an alternative. But unplanned aspects can totally undermine a project.
"When you pull the plug three-quarters of the way through, there's great disappointment. Senior execs can most easily walk away, but middle managers and those actively involved in the project need greater explanation and management. This sort of decision [to walk away] needs to be made from outside the project; still in the business line, but not by those actively or emotionally involved."
Ultimately, Posselt says, if you say you do not have the resources to manage change, and to communicate the full implications of all that the changes entail, then "you do so at your peril".
The Fundamental Issue
However, the people, executive sponsorship, communications and planning aside, there is a more fundamental issue to be considered, and that is whether to have major IT projects at all.
Palmer says this is an issue on two grounds: "major" and "IT". For a start, he believes that it is a pitfall to regard such activities as "IT projects" rather than as "business projects". A lot of projects fail, he says, because the business is not engaged, and that it is seen as technology for its own sake. A disengaged client puts the risk onto the IT manager, often with the suggestion that "IT forced this upon me".
"Technology may be the trigger for a project, but the responsibility must lie with the business," he says, adding that "the only IT projects are projects done by IT for the IT department's own needs".
On the issue of "major", Palmer says that large projects are a danger in themselves, as scale delivers all sorts of problems not encountered on smaller projects. "Over the years, we've done a good job of having as few large projects as possible."
This includes the current National Data Network, a project in which the ABS is playing a principal role and which is designed to link databases of information sources relevant to policy analysis and research, particularly key administrative and survey data sets held by state and federal government agencies. While large in concept and implication, Palmer says it is not that large a project. It currently has fewer than 10 people working on it, and the budget this financial year is $500,000. Palmer admits the project has limited funds, but says it was a conscious decision to keep it "not too big".
The really big project will be the e-Census. Although the next census is due this year, Palmer expects only about 10 percent of people to lodge their information online. But come 2011 . . . That is when all of the major project issues will come to a head. And the use of the best people, the best planning, the best communications and the best executive sponsorship will show their true worth.
SIDEBAR:Major Project Critical Success Factors
1. Build one team with A players.
2. Establish periodic "stage-gates" (not to be confused with milestones), as "in so far" and "no further without good reason":
• stage-gates offer an opportunity to appraise/reappraise
• they stop inevitable momentum/inertia of major programs
• you need to be able to walk away/pull the plug or change direction.
3. Visible executive leadership:
• not an inspector/monitor role (management by walking around)
• need to be "I'm in this with you and I'm leading".
4. Continuous management of external and internal stakeholders:
• emphasis on continuous
• lack of information breeds the worst.
5. Effective program management:
• costs, resourcing, etc.
6. Rigorous benefits realization regime/framework:
• emphasis on rigorous
• must have integrity.
Source: Andrew Johnstone-Burt, Capgemini
Join the CIO Australia group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.