<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<dokAAPp xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="../../../../../../prj/bin/GuidICS/dokAAPp.xsd">
    <author>
        <individual>
            <ind firstName="Paweł" ini="pb" org="NIK" role="drafting coordination" surName="Banaś"/>
        </individual>
        <organization>
            <org kraj="Netherlands" nm="Algemene Rekenkamer" skr="NCA" www="www.rekenkamer.nl"/>
        </organization>
    </author>
    <about caseNumber="11" file="GovICTprojects-lessonsLearned" folder="C:\pb\Algorytm\SAI_robo\NL\2007\GovICTprojects-lessonsLearned" id="NL2007GovICTprojects-lessonsLearned" issueYear="2007" waga="11">
        <tyt>
            <tx file="GovICTprojects-lessonsLearned.pdf" l="en" nm="Lessons Learned from Government ICT Projects - Part A" typDok="authorized_translation"/>
            <tx file="GovICTprojects-lessonsLearned_NL.pdf" l="nl" nm="Lessen uit ICT-projecten bij de overheid - Deel A" typDok="original_document"/>
        </tyt>
        <portfolio>
            <pfl zn="keyInvestment"/>
            <pfl zn="measurementOfProjectSuccess"/>
        </portfolio>
        <ver put="202609201811" stage="final"/>
    </about>
    <part id="lead">
        <tyt>
            <tx l="en" nm="The spiral nobody has an interest in stopping"/>
        </tyt>
        <narrative>
            <narr l="en">
                <ak nr="1">In 2007 Dutch newspapers reported that the government was wasting four to five billion euros a year on failed ICT projects. The House of Representatives asked the audit office to explain why, and gave it five months. The answer, published in November 2007, is that nobody involved is behaving badly: the House wants big problems solved quickly, ministers want to look decisive, suppliers need large contracts, and all three legitimate interests pull the same way. What follows is what that produces, traced through audits of projects running from the late 1990s to 2007 - deadlines set by the political calendar, goals too vague to test, systems wired to systems nobody had checked them against, and progress reports the House asked for and did not get.</ak>
            </narr>
        </narrative>
    </part>
    <part id="background" v="01">
        <tyt>
            <tx l="en" nm="Background"/>
        </tyt>
        <part id="scale">
            <tyt>
                <tx l="en" nm="Scale"/>
            </tyt>
            <narrative>
                <narr l="en">
                    <ak tp="li">The audit was triggered by press reports in 2007 that central government wasted between four and five billion euros a year on failed ICT projects; the audit office found the figure rested on total Dutch ICT spending of 18.5 billion euros, where the statistics office put national ICT investment at 12.6 billion, of which 2.1 billion was public sector and 0.5 billion central government.</ak>
                    <ak tp="li">The report rests on no new fieldwork: seven earlier audits of named ICT projects, the regularity audits carried out since 2000, national and international literature, and interviews with outside specialists, over roughly five months.</ak>
                    <ak tp="li">It answers three of the four questions the House of Representatives put on 9 July 2007; the fourth - avoidable costs and delays in central government ICT projects since 2000 - was deferred to a part B published in July 2008.</ak>
                </narr>
            </narrative>
        </part>
        <part id="compliance">
            <tyt>
                <tx l="en" nm="Compliance"/>
            </tyt>
            <narrative>
                <narr l="en">
                    <ak tp="li">A parliamentary regulation on large projects obliges ministers to report periodically on projects meeting certain criteria, and many ICT projects share those characteristics without ever being classified as large projects.</ak>
                    <ak tp="li">Ministerial responsibility to the House frames the whole report: a minister answers for steering and executing a project as well as for the political decision, and for protecting the public interest even where an autonomous administrative body is the client.</ak>
                    <ak tp="li">The report points to American federal legislation of 1996 requiring budget holders to take a portfolio approach to IT investment and to have a statutory chief information officer approve an investment report, and recommends finding out how that has worked.</ak>
                </narr>
            </narrative>
        </part>
        <part id="perfromance">
            <tyt>
                <tx l="en" nm="Performance"/>
            </tyt>
            <part id="economy">
                <tyt>
                    <tx l="en" nm="Economy"/>
                </tyt>
                <narrative>
                    <narr l="en">
                        <ak tp="li">Projects are routinely far more expensive than budgeted; an earlier audit of the national emergency communications network found the project budget to be of poor quality, with costs left out of the estimates altogether.</ak>
                        <ak tp="li">Decision-makers overestimate what the technology can do and underestimate the money, time and people that implementation needs.</ak>
                        <ak tp="li">Investment decisions are taken project by project rather than against the organisation as a whole, so a new system is never judged for its fit with the existing ICT portfolio.</ak>
                    </narr>
                </narrative>
            </part>
            <part id="efficiency">
                <tyt>
                    <tx l="en" nm="Efficiency"/>
                </tyt>
                <narrative>
                    <narr l="en">
                        <ak tp="li">Projects take longer than planned; one transfer of tasks between government services forced a six-month postponement as soon as the receiving service examined what its information systems would actually have to do.</ak>
                        <ak tp="li">Decisions are taken in a single block rather than in phases, with no decision points built into implementation and no exit strategy to fall back on.</ak>
                        <ak tp="li">About 80 percent of the work of building an application goes into the last 20 percent of its functionality, and exception rules are programmed that could be handled by manual procedures.</ak>
                    </narr>
                </narrative>
            </part>
            <part id="effectiveness">
                <tyt>
                    <tx l="en" nm="Effectiveness"/>
                </tyt>
                <narrative>
                    <narr l="en">
                        <ak tp="li">Projects deliver less than intended, and goals stated as "full integration of ICT in education" or "preparing children and young people for the knowledge-based society" cannot be tested against anything.</ak>
                        <ak tp="li">Information reaching the House failed two thirds of the checkpoints on one project, was withheld on a second and was too optimistic on a third.</ak>
                        <ak tp="li">Where a programme runs across several bodies the chain has no shared goals, and participants pursue their own interests, which need not be contrary to the minister but need not serve them either.</ak>
                    </narr>
                </narrative>
            </part>
        </part>
    </part>
    <part id="cases" v="01">
        <tyt>
            <tx l="en" nm="Cases"/>
        </tyt>
        <ctsy>
            <gr gn="area">
                <cts id="computerisation"/>
                <cts id="public-administration"/>
                <cts id="public-finance"/>
                <cts id="public-procurement"/>
            </gr>
            <gr gn="ins">
                <cts id="central-government"/>
                <cts id="cabinet"/>
                <cts id="ministry"/>
                <cts id="government-agency"/>
                <cts id="supplier-organisation"/>
                <cts id="municipality"/>
            </gr>
            <gr gn="control">
                <cts id="goalsetting"/>
                <cts id="targetTerm"/>
                <cts id="guidance"/>
                <cts id="design"/>
                <cts id="processPlanning"/>
                <cts id="businessProcessEngineering"/>
                <cts id="coordination"/>
                <cts id="responsibility"/>
                <cts id="accountabilityTerm"/>
                <cts id="strategicDirection"/>
                <cts id="change"/>
                <cts id="organizationalDevelopment"/>
                <cts id="results_review"/>
                <cts id="feedbackTerm"/>
                <cts id="contingencyPlanning"/>
                <cts id="monitoring"/>
                <cts id="reporting"/>
                <cts id="managementReports"/>
                <cts id="documentation"/>
                <cts id="analysis"/>
                <cts id="dataIntegration"/>
                <cts id="dataQualityManagement"/>
                <cts id="testing"/>
                <cts id="benefit"/>
            </gr>
            <gr gn="value">
                <cts id="domain_knowledge"/>
                <cts id="regulatory_system"/>
                <cts id="finance"/>
                <cts id="community"/>
                <cts id="human_capital"/>
                <cts id="asset"/>
            </gr>
            <gr gn="fun">
                <cts id="IT"/>
                <cts id="governance"/>
                <cts id="planning"/>
                <cts id="strategy"/>
                <cts id="finance"/>
                <cts id="regulations"/>
                <cts id="infrastructure"/>
                <cts id="projectMethodology"/>
                <cts id="productServicePurchase"/>
                <cts id="organizationalDesign"/>
                <cts id="workProcessDesign"/>
            </gr>
            <gr gn="quality">
                <cts id="clearObjectives"/>
                <cts id="reliableInformationBase"/>
                <cts id="functioningOversight"/>
                <cts id="soundRiskManagement"/>
                <cts id="costControlValueForMoney"/>
                <cts id="adequateResourcesCompetences"/>
                <cts id="appropriateUseOfTechnology"/>
                <cts id="interoperabilityForUsers"/>
                <cts id="userCenteredDesign"/>
                <cts id="streamlinedProcesses"/>
            </gr>
            <gr gn="sta">
                <cts id="lawmaker"/>
                <cts id="policy-setter"/>
                <cts id="mandating-authority"/>
                <cts id="management"/>
                <cts id="oversight-role"/>
                <cts id="delivery-partner"/>
                <cts id="supplier"/>
                <cts id="operator"/>
                <cts id="user"/>
                <cts id="media"/>
            </gr>
        </ctsy>
        <part id="technologyTakenCurePeople">
            <tyt>
                <tx l="en" nm="Technology taken for a cure, by people who do not know what it cannot do"/>
            </tyt>
            <narrative>
                <narr l="en">
                    <ak nr="2" ref="draft draft" tp="xm" zn="NL2007GovICTprojects-lessonsLearned">The first force pushing projects past what they can carry is enthusiasm. 'Political decision-makers tend to believe in ICT as a miracle cure for all manner of policy issues: the ideal solution to any problem. Yet managers often do not fully understand what ICT can do and, more important, what it cannot' (p.14). The consequence runs in two directions at once: they overestimate the technical capabilities and underestimate the time, money and people implementation will take. If the minister then decides without adequate advice, the project becomes organisationally and technically unfeasible and its goals stop being specific, measurable, agreed, realistic, time-bound and consistent - 'without a realistic business case, the project can be a source of great disappointment'. Nor is the enthusiasm corrected from outside: vendors 'for commercial reasons tend not to be overly critical', and because they deal directly with political managers, 'the latter quickly come to think that an ICT solution is within reach'.</ak>
                </narr>
            </narrative>
            <ctsy>
                <gr gn="control">
                    <cts id="goalsetting"/>
                    <cts id="guidance"/>
                </gr>
                <gr gn="value">
                    <cts id="domain_knowledge"/>
                </gr>
                <gr gn="fun">
                    <cts id="IT"/>
                    <cts id="strategy"/>
                </gr>
                <gr gn="quality">
                    <cts id="adequateResourcesCompetences"/>
                    <cts id="appropriateUseOfTechnology"/>
                </gr>
                <gr gn="sta">
                    <cts id="policy-setter"/>
                    <cts id="supplier"/>
                </gr>
            </ctsy>
        </part>
        <part id="deadlinesComeElectoralCalendar">
            <tyt>
                <tx l="en" nm="Deadlines that come from the electoral calendar, not from a plan"/>
            </tyt>
            <narrative>
                <narr l="en">
                    <ak nr="3" ref="draft draft" tp="xm" zn="NL2007GovICTprojects-lessonsLearned">'Deadlines are often the outcome not of reasoned and realistic plans but of political considerations' (p.14). The House expects quick solutions to urgent problems; ministers time delivery to their own term of office. When other conditions are fixed in advance too - how many organisations take part, what functionality is required - the project becomes incapable of being completed on time. The report's illustration is the capacity-for-work legislation: the implementing bill went to the Council of State for advice at the end of March 2005 with introduction proposed for 1 January 2006, and the implementing bodies said they could manage it only if the bill passed unamended, with systems operational by 1 September 2005 at the latest. At that point nobody knew when the bill would become law. The second half of the finding is quieter and just as damaging: under time pressure, 'there is also a risk of not enough time being taken to define the project's goals and requirements'.</ak>
                </narr>
            </narrative>
            <ctsy>
                <gr gn="control">
                    <cts id="goalsetting"/>
                    <cts id="processPlanning"/>
                </gr>
                <gr gn="value">
                    <cts id="regulatory_system"/>
                </gr>
                <gr gn="fun">
                    <cts id="planning"/>
                    <cts id="governance"/>
                </gr>
                <gr gn="quality">
                    <cts id="clearObjectives"/>
                    <cts id="soundRiskManagement"/>
                </gr>
                <gr gn="sta">
                    <cts id="lawmaker"/>
                    <cts id="policy-setter"/>
                </gr>
            </ctsy>
        </part>
        <part id="nothingReconsideredOnceDecided">
            <tyt>
                <tx l="en" nm="Nothing is reconsidered once decided, and nothing has a way out"/>
            </tyt>
            <narrative>
                <narr l="en">
                    <ak nr="4" ref="draft draft" tp="xm" zn="NL2007GovICTprojects-lessonsLearned">Changes to a project's terms of reference should prompt a re-examination of the assumptions under it. 'This, however, is more the exception than the rule. As a result, the original development path becomes entrenched and project management considerably more complex' (p.15). The same is true when warning signs appear in planning, staffing, budget or required functionality: it rarely happens, 'chiefly because political decisions are difficult to reverse once they have been taken' - and because 'the individual signs are too small to be worth considering whereas all the signs together are not'. The audit office's illustration is a shared service centre for personnel administration, where a second-opinion committee made several critical comments, concrete action was taken on one of them, and the action plan was never taken up again in subsequent meetings. The chapter closes on the difference from private business: 'a project muddles on instead of being stopped when it should be. The private sector must obey the rules of the market.'</ak>
                </narr>
            </narrative>
            <ctsy>
                <gr gn="control">
                    <cts id="results_review"/>
                    <cts id="contingencyPlanning"/>
                    <cts id="feedbackTerm"/>
                </gr>
                <gr gn="value">
                    <cts id="finance"/>
                </gr>
                <gr gn="fun">
                    <cts id="projectMethodology"/>
                    <cts id="governance"/>
                </gr>
                <gr gn="quality">
                    <cts id="soundRiskManagement"/>
                    <cts id="costControlValueForMoney"/>
                </gr>
                <gr gn="sta">
                    <cts id="management"/>
                    <cts id="oversight-role"/>
                </gr>
            </ctsy>
        </part>
        <part id="severalOrganisationsChainGoal">
            <tyt>
                <tx l="en" nm="Several organisations in a chain, and no goal any of them shares"/>
            </tyt>
            <narrative>
                <narr l="en">
                    <ak nr="5" ref="draft draft" tp="xm" zn="NL2007GovICTprojects-lessonsLearned">'Government ICT projects are often organisationally complex because they involve several organisations. The autonomy enjoyed by the organisations means there is little if any central steering or commitment' (p.16). And below the structural point sits a behavioural one: 'in practice, organisations act primarily in their own interests. Their contribution to and acceptance of ICT solutions often depend on the extent to which the solutions serve their own interests or solve their own problems.' The illustration is a residence-permit programme launched in September 2002 by three ministers, implemented jointly by a chain that included the foreign ministry, the police, the border service, the immigration service and the municipalities, each responsible for its own project. An audit in 2005 found 'the chain did not have any shared goals. The individual organisations pursued their own interests' - not necessarily contrary to the responsible minister's goals, but not serving them either - and that the participants 'did not always look upon each other as partners, did not always think they were appreciated as partners and did not always accept directions'.</ak>
                </narr>
            </narrative>
            <ctsy>
                <gr gn="control">
                    <cts id="coordination"/>
                    <cts id="responsibility"/>
                </gr>
                <gr gn="value">
                    <cts id="community"/>
                </gr>
                <gr gn="fun">
                    <cts id="governance"/>
                    <cts id="organizationalDesign"/>
                </gr>
                <gr gn="quality">
                    <cts id="clearObjectives"/>
                    <cts id="streamlinedProcesses"/>
                </gr>
                <gr gn="sta">
                    <cts id="delivery-partner"/>
                    <cts id="mandating-authority"/>
                </gr>
            </ctsy>
        </part>
        <part id="organisationalChangeSystemsPull">
            <tyt>
                <tx l="en" nm="Organisational change and the systems pull on each other, and the pull is underestimated both ways"/>
            </tyt>
            <narrative>
                <narr l="en">
                    <ak nr="6" ref="draft draft" tp="xm" zn="NL2007GovICTprojects-lessonsLearned">'ICT projects generally lead to organisational change and, conversely, organisational change can have a significant impact on the ICT infrastructure. The pursuit of a political goal often overlooks the relationship between ICT and the organisation' (p.17). Transferring tasks from one body to another changes business processes, and because processes and systems are tightly bound, a change in one has serious consequences for the other - 'the impact that this can have is frequently underestimated'. The illustration: preparations to move tasks from one service to the immigration service began in 2002, and once it became clear new systems would be needed the service studied what would have to change; it found the planned completion date unrealistic and the implementation date had to be put back six months. The reverse direction is the same failure seen from the other side: 'ICT systems are frequently developed without considering the consequences for the organisations that have to use them', with the system operating sub-optimally because it does not fit working practices or because users were inadequately prepared and trained.</ak>
                </narr>
            </narrative>
            <ctsy>
                <gr gn="control">
                    <cts id="change"/>
                    <cts id="organizationalDevelopment"/>
                    <cts id="businessProcessEngineering"/>
                </gr>
                <gr gn="value">
                    <cts id="human_capital"/>
                </gr>
                <gr gn="fun">
                    <cts id="organizationalDesign"/>
                    <cts id="workProcessDesign"/>
                </gr>
                <gr gn="quality">
                    <cts id="userCenteredDesign"/>
                    <cts id="streamlinedProcesses"/>
                </gr>
                <gr gn="sta">
                    <cts id="user"/>
                    <cts id="management"/>
                </gr>
            </ctsy>
        </part>
        <part id="softwareRigidWherePolitics">
            <tyt>
                <tx l="en" nm="Software is rigid where politics is fluid, so the requirements have to be settled first"/>
            </tyt>
            <narrative>
                <narr l="en">
                    <ak nr="7" ref="draft draft" tp="xm" zn="NL2007GovICTprojects-lessonsLearned">'ICT projects are different from other projects because ICT systems are relatively inflexible. Many political and organisational processes, however, are dynamic and flexible' (p.18). Development benefits from a stable environment and from early, precise definition of goals and requirements; without them 'the requirements the system must satisfy will not be known', and where an external provider builds it, 'there is then a significant risk of it delivering something the government did not intend', because the provider 'forms an incomplete and possibly incorrect picture of what the client expects'. The subsequent changes then cost time and money. The illustration inverts the proper order entirely: under great time pressure in 2003, the immigration service had to develop new systems while some of its processes were still undefined - 'the process designers were only one step ahead of the system designers. At one point the ICT department was actually leading the development of the business processes.'</ak>
                </narr>
            </narrative>
            <ctsy>
                <gr gn="control">
                    <cts id="design"/>
                    <cts id="processPlanning"/>
                </gr>
                <gr gn="value">
                    <cts id="domain_knowledge"/>
                </gr>
                <gr gn="fun">
                    <cts id="IT"/>
                    <cts id="productServicePurchase"/>
                </gr>
                <gr gn="quality">
                    <cts id="clearObjectives"/>
                    <cts id="adequateResourcesCompetences"/>
                </gr>
                <gr gn="sta">
                    <cts id="supplier"/>
                    <cts id="mandating-authority"/>
                </gr>
            </ctsy>
        </part>
        <part id="newSystemsTalkOld">
            <tyt>
                <tx l="en" nm="New systems have to talk to old ones, and nobody checks whether they can"/>
            </tyt>
            <narrative>
                <narr l="en">
                    <ak nr="8" ref="draft draft" tp="xm" zn="NL2007GovICTprojects-lessonsLearned">'A complicating factor in the development of ICT systems is that the systems themselves often do not work in isolation but have to be connected to other systems already in operation' (p.19). Compatibility inside one organisation is already demanding; across several there are further organisational and technical complications, and data from two bodies 'must be collated even if they do not agree with each other'. The illustration is a stock-records audit: in 2004 there was a 17 percent variation between recorded and actual stock at one military logistics centre and 28 percent at the clothing and equipment agency, the warehouse records at both being unreliable. The causes are named exactly - 'old and polluted systems being connected to each other', and old batch-processing systems connected to modern real-time systems, 'which created discrepancies in the files'. The audit office concluded that reliable stock records would remain a problem for as long as the old systems were running. The chapter adds a third technical factor: ICT advances so quickly that expertise and know-how become obsolete during the build.</ak>
                </narr>
            </narrative>
            <ctsy>
                <gr gn="control">
                    <cts id="dataIntegration"/>
                    <cts id="dataQualityManagement"/>
                    <cts id="testing"/>
                </gr>
                <gr gn="value">
                    <cts id="asset"/>
                </gr>
                <gr gn="fun">
                    <cts id="IT"/>
                    <cts id="infrastructure"/>
                </gr>
                <gr gn="quality">
                    <cts id="interoperabilityForUsers"/>
                    <cts id="reliableInformationBase"/>
                </gr>
                <gr gn="sta">
                    <cts id="operator"/>
                    <cts id="management"/>
                </gr>
            </ctsy>
        </part>
        <part id="remediesSimpleWellKnown">
            <tyt>
                <tx l="en" nm="The remedies are simple, well known, and not used - which is the real finding"/>
            </tyt>
            <narrative>
                <narr l="en">
                    <ak nr="9" ref="draft draft" tp="xm" zn="NL2007GovICTprojects-lessonsLearned">The report states its own central conclusion twice, and the second time it explains itself. The remedies are not obscure: 'the motto is: start small and proceed in small steps', limit the number of organisations, choose standard software, split the project into controllable parts, and where complexity is genuinely unavoidable adapt the completion time instead. 'All the recipes given above are known. But they are often not applied even though those involved know that projects are doomed to failure if they are too ambitious or too complex. Why is this so?' (p.20). The answer is that three parties each have a legitimate reason to want the project big. The House 'expects the government to solve complex problems, preferably as quickly as possible'. Ministers 'like to show they are decisive', and 'announcing a feasibility study or a small-scale pilot scheme is not usually seen as decisive action'. Providers 'need contracts, preferably big ones'. None of them checks the others: 'the parties entrap each other in the spiral and inevitably agree upon a project that is too complex but has the status of political fact from which there is no elegant way back.'</ak>
                </narr>
            </narrative>
            <ctsy>
                <gr gn="control">
                    <cts id="responsibility"/>
                    <cts id="accountabilityTerm"/>
                    <cts id="strategicDirection"/>
                </gr>
                <gr gn="value">
                    <cts id="community"/>
                    <cts id="regulatory_system"/>
                </gr>
                <gr gn="fun">
                    <cts id="governance"/>
                    <cts id="strategy"/>
                </gr>
                <gr gn="quality">
                    <cts id="costControlValueForMoney"/>
                    <cts id="functioningOversight"/>
                </gr>
                <gr gn="sta">
                    <cts id="lawmaker"/>
                    <cts id="policy-setter"/>
                    <cts id="supplier"/>
                </gr>
            </ctsy>
        </part>
        <part id="goalsWrittenSoOne">
            <tyt>
                <tx l="en" nm="Goals written so that no one can ever say whether they were met"/>
            </tyt>
            <narrative>
                <narr l="en">
                    <ak nr="10" ref="draft draft" tp="xm" zn="NL2007GovICTprojects-lessonsLearned">Without accurately formulated goals, 'it will not be possible during implementation to determine whether the project is still on course and the minister will subsequently not know whether he has achieved his goals and whether the money was spent as agreed' (p.22). The illustration runs the length of a decade. Neither the House nor the ministry doubted that something had to be done about computers in schools, and from the late 1990s a policy was built covering infrastructure, equipment, teacher training and digital teaching aids. 'At the beginning of the project, the House repeatedly requested operationalised policy goals, but never received them.' What it got instead were formulations the report quotes without comment: 'taking an integrated approach to embed the use of ICT into education', 'taking a lead on neighbouring countries in the effective use of ICT', 'full integration of ICT in education', 'preparing children and young people for the knowledge-based society'. None of them can be failed.</ak>
                </narr>
            </narrative>
            <ctsy>
                <gr gn="control">
                    <cts id="goalsetting"/>
                    <cts id="targetTerm"/>
                    <cts id="monitoring"/>
                </gr>
                <gr gn="value">
                    <cts id="domain_knowledge"/>
                </gr>
                <gr gn="fun">
                    <cts id="planning"/>
                </gr>
                <gr gn="quality">
                    <cts id="clearObjectives"/>
                    <cts id="reliableInformationBase"/>
                </gr>
                <gr gn="sta">
                    <cts id="lawmaker"/>
                    <cts id="policy-setter"/>
                </gr>
            </ctsy>
        </part>
        <part id="progressReportsOwedOne">
            <tyt>
                <tx l="en" nm="Progress reports that were owed, and in one case simply never came"/>
            </tyt>
            <narrative>
                <narr l="en">
                    <ak nr="11" ref="draft draft" tp="xm" zn="NL2007GovICTprojects-lessonsLearned">Many ICT projects carry the characteristics that make a project 'large' under the parliamentary regulation - non-routine, large-scale, new technology, organisationally complex implementation - and so should be reported on periodically whether or not they are formally classified as such (p.23). Two failures are set out. In 2000 a parliamentary motion asked for a single police information system and for annual progress reports; in 2003 the audit office found the second half of the motion had simply not been acted on, and the minister then undertook to report annually from 2004 - four years late. And on the emergency communications network, the audit office concluded in June 2003 that 'on two thirds of the checkpoints, information did not satisfy the requirements of the Large Projects Procedural Regulations. Some information, including information on delays, was available at the ministry but was not provided to the House. Other information, for example financial information, was not available to the state secretary.' Over the six years to February 2003 the House 'was unable to form a reliable picture of the financial, substantive and planning aspects' of that project.</ak>
                </narr>
            </narrative>
            <ctsy>
                <gr gn="control">
                    <cts id="reporting"/>
                    <cts id="managementReports"/>
                    <cts id="monitoring"/>
                </gr>
                <gr gn="value">
                    <cts id="regulatory_system"/>
                </gr>
                <gr gn="fun">
                    <cts id="governance"/>
                    <cts id="regulations"/>
                </gr>
                <gr gn="quality">
                    <cts id="functioningOversight"/>
                    <cts id="reliableInformationBase"/>
                </gr>
                <gr gn="sta">
                    <cts id="lawmaker"/>
                    <cts id="oversight-role"/>
                </gr>
            </ctsy>
        </part>
        <part id="momentDecisionHouseTold">
            <tyt>
                <tx l="en" nm="At the moment of decision, the House was told the optimistic version"/>
            </tyt>
            <narrative>
                <narr l="en">
                    <ak nr="12" ref="draft draft" tp="xm" zn="NL2007GovICTprojects-lessonsLearned">Information can be delivered on time and still leave the reader worse informed. On the shared service centre for personnel administration, the information given to the House until mid-2005 'was at times too optimistic and unclear' (p.25). The specific instance is a progress report of 30 June 2004 which 'did not clearly state that the government's approval of the report would in effect be a government decision to go ahead with the implementation'. Conditions had been set for that approval; the minister knew when the decision was taken that there were risks and that the conditions might not be met; and 'the picture the minister presented to the House on 30 June 2004 did not clarify these risks and shortcomings. The House had to suffice with comments made by the Second Opinion Committee in an appendix.' On the same project the minister was later reluctant to report operational disagreements while there was still hope of success, arguing that commercial interests had to be respected - to which the audit office answered that the House could have been informed in confidence.</ak>
                </narr>
            </narrative>
            <ctsy>
                <gr gn="control">
                    <cts id="reporting"/>
                    <cts id="documentation"/>
                    <cts id="responsibility"/>
                </gr>
                <gr gn="value">
                    <cts id="finance"/>
                </gr>
                <gr gn="fun">
                    <cts id="governance"/>
                </gr>
                <gr gn="quality">
                    <cts id="reliableInformationBase"/>
                    <cts id="functioningOversight"/>
                </gr>
                <gr gn="sta">
                    <cts id="lawmaker"/>
                    <cts id="management"/>
                </gr>
            </ctsy>
        </part>
    </part>
</dokAAPp>
