Page 1: Create the perfect playing field
Page 2: Start with a clear understanding
Readers write back:
On Thursday, May 3, JM of Toronto wrote:
Well, it is next to impossible for a person to comment on government projects without having experienced them.
Following are the major reasons I would list, based on my government career so far:
1. Process Paralysis: Tons of processes to follow, without having the nature and size of the project in mind. Sometimes, process expenses are more than the actual IT application...
2. Security phobia: Over-architected solutions, expensive, un-matured security solution, signing/encryption requirements make system practically unusable.
3. Failure to retain talent: Lack of motivation, no or poor appreciation of efforts, bureaucracy, etc.
4. Poor knowledge transfer/staffing procedures
My 2 cents.
On Monday, May 15, Michael Toohey of Sydney, Australia, wrote:
Unfortunately big IT projects fail a lot both in the public and private sector. What is in common, what is different in either camp?
The complexity of public sector management poses challenges especially with stakeholder management. A fundamental for project governance is whether disaffected stakeholders effectively have the power of veto. People need to be brought along, but what happens when they are not? There is no simple answer to that, but it has to be considered for each major project.
So when should a big govt project be killed? How is that decision made?
My suggestion is that, politics aside, continuing with a project that is wobbly depends on an assessment of whether the benefits will be achieved and, if so, are we prepared to pay the new price. Do the benefits continue to outweigh the costs?
Benefits realisation can't be reduced to an article of faith - a post-implementation phenomenon that we hope to achieve. It has to be managed throughout implementation - so how can that be done?
This requires project governance to consider the role of the business case throughout the project. If the business case is, in practice, the bid for funds, then how do we act when a project is off the rails? Is a 20 per cent variance from workplan twice as bad as a 10 per cent variance? What are acceptable project budget variances?
The project management perspective of scope, workplan and budget is important but, in itself, is unlikely to indicate whether the project will deliver its benefits. Benefit realisation begins with tracking what has to be in place during implementation. Project sponsors and directors have to be able to be held to account on the business case. The business case has to set out what has to be tracked.
This approach leads to a different and more business-oriented assessment of project variances. Assuming affordability (a big assumption, I know), how does a project board assess a budget variance? Does it plug on regardless in the hope that the project will recover or does it assess the variance in terms of the probability of achieving the project benefits?
Finally, what is the capability and capacity of those charged with governance of these projects - both the project board / steering committee and the project management?
Would really like to hear the views of others on this.
Related content:
10 hot public sector IT trends for 2007
Why public sector IT projects fail
Take a business-centric view of IT projects, task force urges Ontario government
Big IT projects fumbled by feds, says Auditor General's report
Visit Vendor of Record, Canada's online procurement directory
icon.
