Three months ago, the Agency for Digital Government completed an extensive revision of the governmental IT-project model. Now a record of the initial experiences with the model has been made available.
In terms of content, several document templates have been simplified. The acquisition- and implementation phase have been combined into one, which among other things creates more opportunities for completing agile projects. This has meant that governmental organizations now have more freedom to organize their own IT-projects.
The largest change many agencies have experienced, has been that risk assessment of projects now takes place at an earlier stage in the process, meaning that a risk assessment is already available at the beginning of the analysis phase.
The steering committee should be under control
A steering committee agreement has to be signed quickly. The agreement should contain a detailed description of the steering committee’s working methods; an agreement that is binding for steering group members when filled out with name and signature.
The new model contributes to benefits and risks becoming the focal point for the planning and completion of projects. The fundamental idea is that instead of focusing on detail specification, goals and resources should be in focus and sorted out before the start of the project.
The analysis phase of the project is crucial. It has now become a requirement, that the risk assessment takes place no later than three months before the analysis phase of the project. The basic implications of this are that governmental agencies now have something entirely new to tackle, when devising the steering documents to be submitted for risk assessment.
Steering documents must contain the following:
- A project foundation, that replaces the previous PID and describes overall goals, benefits, risks, solution, delivery and the plan for the analysis phase.
- A steering committee agreement that gives reasons for the composition of the steering committee and documents the individual principal of the steering committee members.
The change means, that instead of tinkering with a project for six months or a whole year before everything is internally aligned and controlled, governmental agencies now have to share their project thoughts and ambitions with the IT Project Council at a much earlier stage.
Time is a key factor in the government’s revised IT-project model
The opportunity for advice from the IT Council is an important starting-point. Over the course of maximum three months the agency needs to describe goal, benefits, risks, solution, delivery and a plan for the analysis phase. This plan needs to describe how a thorough and detailed analysis of the project benefits and solution will be carried out. In order to devise this plan and deliver an effective analysis effort, it is crucial that the project has identified “sore spots”, so the plan can contain a break-down of how these “sore spots” will be dealt with.
In most cases the approach and methods are familiar, but getting started can still prove difficult, especially if the organization is not ready yet.
Overall experiences from the first couple of months with the revised governmental IT project model:
- The three months leading up to the risk assessment go by quickly – plan the process and get off to a good start.
- Prepare the steering committee, so the member understands “the game” and their responsibility in completing the process. Include the steering committee at an early stage, as it can take longer than expected to get the documents filled out and signed.
- Do not be afraid of your surroundings, but instead utilize advise from the IT council and have dialogue with your stakeholders.
- Manage zero-error culture and be open about the fact that a project can change in the analysis phase. First, the general project foundation is described to the Agency for Governmental IT Services and subsequently a thorough and detailed analysis is carried out.
- Use well-known and tested project methods, host benefit-workshops, risk-workshops, product decompositions, apply estimation methods and draw on experiences.
- Engage internal and external professional competencies early on. Good business analysts, IT-architects et cetera, can help create an understanding of the task at hand, contribute with estimates and plan the analysis phase.
- Kill your darlings; be open to different options and critical when it comes to “unchangeable truths”. Overly optimistic expectations of unmarketable or unrealistically priced solutions, always become a problem for the project later on.
