Thank you, Madam Chair.
There are two questions: what has changed, and what are we doing differently going forward?
First, in terms of what has changed, Secure Channel was originally conceived as a project going back to roughly 1999-2000. Nine years later, 2009, many things have indeed changed, both on the technology front and the experience front, in terms of understanding of the broad IM/IT community in Canada, and in fact worldwide, in terms of IM/IT, cyber security, and so on. Within government, certainly our policies, management frameworks, and oversight have also changed.
First of all, let me say from a policy perspective that in 2007 we came out with the enhanced project management framework policy, which I think is a key step in equipping the government going forward to be more effective and a better manager of large and complex IT projects--and IT projects across government are bound to be large.
I mentioned a couple of strategies in my opening remarks, but I would stress them again. Whereas Secure Channel was targeted as one large project, going forward in our new project management framework we are stressing the segmentation of large projects into what we call a program of discrete and independent projects that can be launched, followed, and monitored independently. They can individually contribute benefits that can be followed, if successful, by different projects that can continue to build on their initial success and continue to refine, expand, or roll out the solution further. So that's an important step forward.
Over the last 10 years, I think projects have become very large for many reasons, and this is true with my experience in the private sector as well in government. The demand for IM/IT is quite strong. Departments, in fact all organizations, rely on services, so there is always a requirement for more automated support. Nevertheless, it is the challenge of the IM/IT organizations across government, and Treasury Board is working actively with them to properly segment these programs into manageable projects. Each one will come up with a business case that will allow for the evaluation of success. Clear project charters on these individual projects will indicate roles, responsibilities, and the governance that the departments and their deputies are going to exercise. As well, project gating stages at regular intervals will report on status, success, or any issues that might arise and allow for corrective action, including such things as bringing in independent project reviewers to get a different heads-up and so on.
The project management framework has gone a long way to help, and I think will, over the next number of years, contribute significantly to improving project outcomes. That is the number one element that we are proposing to do differently.
In terms of general guidance to the community of CIOs that I have provided and will continue to provide going forward, we are being very careful not to be too ambitious with unproven approaches. We are pushing the community to work initially with smaller projects that can pilot outcomes. Once these approaches are tested, then we can build sound business cases that reflect better cost because a pilot has come back with some results, and we can better plan for future rollouts given that it's not as abstract a problem.
Certainly our guidance is to decompose programs into projects, pilot approaches, to conduct rigorous business cases, monitor a lot more closely and regularly, and in this way improve outcomes.