Agile Project Management for Government by Brian Wernham The indispensable guide to making your organization agile Publication

31st July 2012 Preat: Pre-order now at: www.maitland-andwww.maitland-and-strong.com maitland www.maitland nd-strong.com maitlandand www.maitland-and-strong.com.uk (powered by Amazon) Governments on both sides of the Atlantic have committed to introducing agile change management for faster results with cheaper implementation at lower risk. Agile Project Management for Government is the first hands-on guide designed to help public sector leaders reap the rewards of agile methods. Based on the latest national and international research, this ground-breaking book will show you how to achieve success in large-scale change initiatives. Highlights include: Analysis of government attempts to be agile around the world Reasons why many large change projects have failed and how to ensure yours doesnt How to adopt the 12 principles of agile The low-down on US and UK government rules, regulations and strategies Advice on how to make the most of best practice materials Advantages of Scrum versus DSDM/Atern and how to adapt both for the public sector Discussion of other major agile methods including Crystal, Adaptive Software Development, Evo, Spiral and Test Driven Development

Written by change management expert Brian Wernham, who has more than 30 years experience in adaptive project management, this guide is essential reading for leaders in central, federal and local government and for senior managers in companies with government clients.

Agile Project Management for Government Brian Wernham 2012 Selected extracts from Draft Galley Proof Maitland and Strong, London ISBN: 9780957223400 Planned Publication Date 31st July 2012

|i

Agile Project Government

Management

in

Contents
Introduction ......................................................................................................1

Part I ........................................................................................................ 7
Problems with Traditional Project Management Approaches and the Agile Solution .....................................................................................................................7 Chapter 1 ...............................................................................................................8 The Failure of Government Mega-Projects ......................................................8 Why not simply try to control mega-projects?...........................................10 The unnecessary risks created by big-bang delivery ............................12 Risks are unquantified ............................................................................14 Unrealistic expectations for certainty through detailed assurance and planning ..................................................................................................15 Solutions are over-specified before the problems are understood ........16 Overspecification can take three forms. .................................................17 The technology is divorced from the Stakeholders................................18 The role of feedback in ensuring that projects adapt to changing circumstances .............................................................................................19 What makes a Project Agile?.......................................................................21 Summary .....................................................................................................22 Discussion Questions ..................................................................................23

ii |

Chapter 2 .............................................................................................................24 The Lure of Big Design up Front (BDUF) ......................................................24 Using CASE Tools to Control the Problems of BDUF ................................29 Using Better Techniques to Solve the Problems of BDUF .........................30 Government Procurement Processes Prefer rigid approaches using BDUF, even when guidance materials advice otherwise .......................................31 Summary .....................................................................................................33 Discussion Questions ..................................................................................34 Chapter 3 .............................................................................................................35 The Promise of Agile .......................................................................................35 The Agile Manifesto.....................................................................................37 The Agile Manifesto in the Context of Government...................................39 Valuing individuals and interactions over processes and tools .............39 Valuing Working Software over Comprehensive Documentation.........41 Valuing Customer Collaboration over Contract Negotiation ................41 Valuing responding to change over following a plan .............................42 Summary .....................................................................................................43 Discussion Questions ..................................................................................44 Part II ..................................................................................................................45 Implementing the 12 Agile Principles in Government ..........................................45 Chapter 4 .............................................................................................................47 Implementing the Agile Approach..................................................................47 The apparent paradoxes of agile .................................................................48 Agile organizations .....................................................................................49 The Need for Tight-Loose Implementation of agile ...................................52 The ambivalence of Government towards appropriate looseness of control of project teams..............................................................................53

| iii

Chaos: the loose-loose model of control...............................................55 Inflexibility: the tight-tight model of control.......................................57 Inflexibility: the loose-tight model of control ......................................60 Agile: a tight-loose model of control ....................................................62 Summary .....................................................................................................63 Discussion Questions ..................................................................................64 Chapter 5 .............................................................................................................65 Why choose an Agile Method, and if so which one?.......................................65 What is the Scrum Method?......................................................................67 What are the Essential Features of the Atern Method?..............................67 Summary .....................................................................................................70 Discussion Questions ..................................................................................70 Chapter 6 .............................................................................................................71 Implementing Agile Principle 1 in Government Customer Satisfaction ...71 Suggested Extensions to Strategic and Tactical Guidance for the USA and UK to Support Agile Principle Number One ..............................................77 Summary .....................................................................................................81 Discussion Questions ..................................................................................81 Chapter 7 .............................................................................................................82 Implementing Agile Principle 2 in Government Harnessing Change ........82 Risk Aversion and Introversion ..................................................................86 The Agile Spectrum of Responses to Discovery and Change ...................86 Specification Prototyping ...........................................................................87 Skunkworks ...............................................................................................87 Iterative Delivery .........................................................................................88 Suggested Extensions to Strategic and Tactical Guidance for the USA and UK to Support Agile Principle Number Two ..............................................90

iv |

Summary .....................................................................................................94 Discussion Questions ..................................................................................95 Chapter 8 .............................................................................................................96 Implementing Agile Principle 3 in Government Iterative Implementation .........................................................................................................................96 Hierarchy of Delivery ................................................................................97 Level 1 delivery Specification Prototyping ............................................100 Level 2 Delivery Demonstration of an Emerging Solution...................101 Level 3 Delivery Having a Shippable Product Ready ...........................101 Level 4 Delivery Having a Consumable Product Ready.......................102 Level 5 Delivery Piloting the Solution ..................................................103 Level 6 Delivery Widespread Phased Roll-Out ......................................104 Planning for delivery.................................................................................104 Summary ...................................................................................................106 Discussion Questions ................................................................................107 Chapter 9 ...........................................................................................................108 Implementing Agile Principle 4 in Government Teamwork ....................108 Participatory Design .................................................................................109 Stakeholder Segmentation .......................................................................110 Stakeholder engagement in government .................................................111 Best Practice for Applying Stakeholder engagement in Government .....114 Modifications of Agile Methods for Government Projects .......................116 Summary ...................................................................................................118 Discussion Questions ................................................................................119 Chapter 10 .........................................................................................................120 Implementing Agile Principle 5 in Government Part I: Motivation and Trust through Leadership.............................................................................120

|v

Top Management Involvement .................................................................122 Governance of Project Management ........................................................131 Summary ...................................................................................................136 Discussion Questions ................................................................................137 Chapter 11 .........................................................................................................138 Implementing Agile Principle 5 in Government Part II: Motivation and Trust through Process ..................................................................................138 Project sponsorship...................................................................................141 Responsibility for decisions ..................................................................143 The Sponsor Acting as an Interface ......................................................144 Governance of an agile project .................................................................144 Using Agile methods (e.g. Scrum and Atern) to Motivate and Engender Trust ..........................................................................................................146

Contents continues in full version of text.

|1

Introduction

Much is made of the word agile in government today. "Government IT needs to be more agile, more responsive and more accountable to the citizens" says the US Government. 1 In the UK the government has vowed to be more agile, more fleetof-foot.2 So, is agile anything more than a nebulous concept? If government wants to be more agile what must it do? In technology the word refers to a way of running development projects so as to reduce the risk of late and over-budget delivery. In 2010 the USA Federal Government launched a plan calling for a modular approach to development using an iterative development process.3 In a nutshell this sums up the agile approach. Agile behaviors reduce the reliance on up-front and premature agreement of detail before development work commences. The proponents of this approach (often called agilists) argue that as development gets underway new requirements surface that stakeholders did not consider previously, and conversely the development teams discover problems (and opportunities) that can inform strategic decisions. On the face of it adopting this approach appears to be at odds with typical government bureaucratic approaches. However, in 2011, the UK government followed the US initiative by launching an ICT strategy with five out of the 14 points

11 0 2 d rad n atS gn in e vE no dn oL 01 02 a rdn uK

01 02 stne iZ ffe J

1 2 3

2|

in its action plan specifically relating to the adoption of agile approaches in development.4 This book is about the adoption of agile in government. About the history of agile methods, the problems of projects using traditional methods and the barriers to introduction of agile in government. Although it does focus on Central/Federal government projects, the application of this book is just as applicable to state and county levels. Some geographically local projects are of a staggering size. The Mayor of London, for example, spent 161.7m in setting up the London congestion charge scheme.5 Public bodies have planned significant technology projects. The National Digital Information Infrastructure and Preservation Program was allocated $100m in funding from Congress in 2000. The trans-Atlantic interaction between technology developers and project managers in the US and the UK is a central theme of the book. Not because experiences and ideas from elsewhere are not of value, and also not simply because of the size, and influence of these two geographies. There has been a continual, and fruitful interaction between the US and UK in the development of computers. The first electro-mechanical computer was built in the UK at Bletchley Park during the Second World War, and by under fascinating cross-Atlantic collaboration, the US Navy played a pivotal role in developing the next generation valve driven computer used at Bletchley Park to break encoded Nazi war messages.6 Although other authors have argued that agile processes should be scaled up to large projects,7 none have yet tackled the issue from a strategic leadership level especially in policy-led organizations. I ask the question: How do leaders in public sector bodies encourage and catalyze the power that agile methods promise to

re htO

e rofe b el ig a f o sruo va lf suo i ra v e ht fo li ate d eh t g ni s su c sid e mi t ri eh t f o t so m d nep s s ko ob yna M

d el ia te d n o se ga p yn am d n ep s 01 02 e dd oV ,n am raL d na 9 00 2 ed do V ,n am ra L sa h cu s , s ko ob

.a 70 02 ll ewg n iffe L ni n oi s su c sid p u-m o tto b a e lp ma xe r of ee S . pu m eh t g ni la c s g ni s su c sid

e gra l fo st ne me riu qe r eh t tn uo c ca o tn i g ni ka t t uo hti w sm ae t e gra l ot gn ila c s fo sn oi s su c sid

2 10 2 n o dn oL ro f tro p sn arT 89 91 .l a te rem aH . sn oi ta zi na gro

b 11 02 e ci ffO t en ib aC KU

4 5 6 7

|3

meet strategic goals? I ask how managers can change their behaviors and expectations to make room for and encourage agile behaviors at team level. This book takes an unusual approach. I do not see agile as an adversary to traditional techniques the new kid on the block trying to usurp the existing order of things. I see agile approaches and concepts as being complementary to existing approaches. There has been more continuity in the development of project management approaches and many (if not all) existing project management techniques can be applicable in an agile approach. It is the emphasis and strategic philosophy of top management that needs to evolve to encourage this. Unlike some authors8 I do not see this as a religious war between believers and un-believers. I argue that there is no case for a rear guard reaction against this new fad, or conversely a need for a storming of the barricades for revolutionary change. I argue the opposite: that agile technology development practices have been with us since the pyramids, and that the principles of agile thinking can inform the running of projects in even the largest, most bureaucratic organizations. From the start of my career as an engineering graduate with an MBA, I was determined not to become so focused on detail as to lose sight of the purpose of engineering solutions to make life smoother for the customer and save the organization time and money. I was keen be trained in business analysis techniques that brought business insight to drive technology development. I soon realized as I moved into roles that demanded effective, timely delivery that leadership and process must work together. This became especially important on large projects, such as the global dealer management initiative I implemented for a large car manufacturer. I had to lead a global team, distributed around the world. I flew from meetings with the technical architects and designers in Germany to lead the technical solution development in India and then on to Detroit to ensure smooth implementation. The experience of 24-hour management of a distributed team of over 200 people showed me the importance of communication and clear lines of responsibility, but also the power of choosing the right size for each incremental step forward in a project not too large to be risky, but not too small as to be inefficient.

b 3 00 2 g re bn e soR , sne hp etS : s e h cao rp pa el ig a t snia g a sn oit ca er fo selp m a xe rof gn iwo ll of eh t e eS 10 02 n iti kaR d na

4|

My experiences in public bodies have mirrored those in large corporates. Often I have had to work hard to make large, inflexible procurements more incremental and customer focused. Leadership of the internal team of supporting experts, such as lawyers and procurement executives often played a crucial role in steering the optimal course the environment often characterized by rigid process at junior levels and managed chaos at top management level. I have led many multi-year projects with team sizes of over 100 both in local and central government, and the leadership skills required have common attributes: good communication, and realistic goals for the team. Experiences leading large teams in the USA (in North Carolina and New York) and in Canada mirrored those in the UK and Europe I led the Rapid Application Development of the first automatic code generators for Windows based computers that replaced mainframe terminals at large public and private sector organizations. The key was flexibility in setting the team goals, and agreeing what the business was going to get by demonstrating working solutions at an early stage. Any seasoned project manager worth his salt will know that it is better to deliver an imperfect solution early, rather than wait forever for perfection. The trick is to know what level of imperfection can be handled by the business and traded off against the early realization of the benefits of the solution that the project is going to deliver. Bill Gates knew this when deciding on the right moment to release the replacement for Windows 3.1. He called it Windows 95. Officially, named for the year of its release (1995) but my sources at the time told me that it was named after the internal target of being released when 95% ready (not 100% perfect). Part I of this book traces the history of incremental and interactive development practices that form the backdrop to the recent interest in agile approaches. I trace the interweaving history of engineering approaches to development (that seek elegance and efficiency through architecture), with approaches that favor exploration through incremental design. In the 1980s, several trends occurred that appeared to marginalize incremental development. In response, proponents of iterative approaches from the US and UK met in Utah and agreed a manifesto for the agile brand.

|5

Part II considers the agile as a strategic management approach through the lens of this Agile Manifesto. Agile is usually explained in terms of the contrasting features of various competing flavors of agile as set out by pundits, trainers and consultants. Instead I take a step back and analyze what changes to thought processes and procedures public bodies should take to incorporate agile. Central government in particular is seen as important because of its leadership and enormous influence. Whether you are in in a federal country, such as the USA and Germany, or in a centralized country such as the UK or France, the 12 agile principles that support the manifesto apply. Part III considers the practical consequences of adopting agile approaches into organizations that have become used to very large procurements and very large projects. Two levels of change are perceived: strategic and tactical. At a strategic level I consider where guidance and norms in strategic management must allow and encourage the harnessing of the benefits of agile approaches. As examples, I present a series of extensions to national guidance which exist today in the USA and UK which I believe currently inhibit agile approaches. These extensions can be successfully applied and adopted elsewhere. In Commonwealth countries such as India, Canada and Australia, for example, many project management practices are based on processes born in the UK (for example Gate Review Processes), and also the US (for example CMMI process maturity). At a technical level I consider what changes are needed in the two most widespread agile methods in the US and UK: Scrum and DSDM/Atern. These two methods are interesting because they start from very different viewpoints, but aim to achieve similar results. Scrum takes a team-centric approach and Atern (originally called DSDM) takes a product-centric approach. In contrast to some authors I do not see these two approaches as antithetical. Because of their different focus I discuss why it could possibly be advantageous to use the two together on some projects. However with book This galley extract continues with selected pages from the book

|7

Part I

Problems with Traditional Project Management Approaches and the Agile Solution

Project management in public services has a checkered history. Some large projects succeed, but far too many are late, have massive cost overruns, and many are cancelled or produce no benefits. To understand why agile can help Government projects run more smoothly, I will first identify some case studies of success and failure. This is the topic of Chapter 1 which draws conclusions on the lessons learned. Chapter 2 sets out why many recent projects have failed, either to make the intended impact, and, in some notable cases, never even achieved basic delivery. The final chapter in this part presents an overview of how agile approaches may be a solution to such failures.

|9

Risk management often becomes a sanitized activity. It can get reduced to mere cutting and pasting of spreadsheets updated by specialist risk managers away from the governance structures and the key decision makers. Management must actively balance the benefits of scale against the risks that over-scaling creates. Figure 1.1 below illustrates how the chase for ultimate economy produces a drive for mega-project size.11

Figure 1 The impact of risk as scale of project increases

Firstly, there is the promise of savings from economies of scale. The cost for each unit of delivery reduces as the size of project being considered increases. Notice that these savings begin to tail off the costs of running mega-projects rise almost as fast as any savings are achieved through scale. Secondly, notice that the hidden costs of rising risk increase markedly past a certain point. This is because the importance of a risk depends on two components: the probability of it happening and the impact if it does happen.

th gim st ce jo rp T I ro f m 0 01 - m 05 fo e zi s a ne h t ,l ee t s d na et er cno c fo t so c e ht to n , k si r ot seta ler

t ah t n gi se d dn a gn in nal p fo tro ffe l au t cel let ni eh t fo eu la v e h t si t i t ah t e mu s sa e w fI

no it cu rt sno c rof nb 1 fo b mu h t fo e lu r a se su se i vaD

. 81 .p ,9 00 2 .la te sei va D ag em sa d et a cid ni eb

?t ce jo rp-a ge m a setu tit sn o c e zi s ta hW . st cej orp

11

| 13

Chapter 1

MegaThe Failure of Government MegaProjects

We know why projects fail, we know how to prevent their failure, so why do they still fail? Martin Cobb, Treasury Board of Canada Secretariat9 Government has a variable history of success in managing projects around the world. The sheer scale of some projects is staggering, as is the lack of information about spending on activities that often come to nothing. Some governments, such as those in the UK and France are highly centralized, carrying out many activities centrally, such as levying sales taxes or administering driving licenses. In other federated countries, such as the USA and Germany, substantially sized non-Federal authorities administer budgets for single massive projects. An examination of the top 10 IT projects in just one state in Australia in 2011 found that initial estimates of costs had risen from AU$1.3bn to AU$2.7bn.10 Centralization of administration through change projects promises the possibility of large economies of scale. The natural tendency is for large, monolithic projects to be initiated. Large, complex, bloated project structures often fail to identify the major risks to delivery. Even risks that are recognized are often not quantified or managed proactively.

1 10 2 n a m sdu b mO na iro t ciV UA

59 91 p uo rG h si dn atS

01

| 21

to the project, rather than to work with the project management to change the project approach to reduce the inherent risk itself. The US General Accounting Office (US GAO) does no better. Analysts such as Paul Strassman37 have noted that despite an accumulation of best practices and how-to guides, been laid at its door of over prescription of best practice checklists. Each item on such a checklist seems unobjectionable and logical, but often priorities between these mandatory commandments may be conflicting. As each set of best practices is expanded and made more detailed, it adds to the enormous number of rules and stipulations that should be adhered to. Strassman points out that as these rules have expanded, the number of GAO reports detailing information management failures have also expanded: What GAO misses is exactly what has been at fault with the (US Federal) government's information management practices. The increasing volumes of congressional diktats, legislative directives, Inspector General guidelines, General Services Administration rules, and departmental standards manuals have not improved performance as systems complexity keeps increasing. GAO has worked the problem from the wrong end. They have tried to induce excellence by adding to an already unmanageable volume of requirements that define best practice and methods ... they over define inputs instead of allowing agencies to commit to performance objectives that deliver measurable end-results.38

Solutions are over-specified before the problems are understood

Project managers often make an attempt to head off the twin threats of unknown risks and over-assurance by trying to tie down the requirements to early and in too much detail.

44 1 24 1 .pp , 79 91 nn a m s sartS

79 91 nn a m s sartS

73 83

| 27

smell the aroma coming from a caf. It is the natural way that we run our lives, and is also the optimum way to run a project: in short iterations that give feedback. In short, in everyday life we use feedback and empirical experience to adapt to changing circumstances. We also minimize the cost of failure with an iterative approach: the cost of failure is limited to merely the last iteration of work. And the smaller the iterations are, then the smaller the cost of potential failure becomes. If the project is high risk, then this theory of Empirical Process Control suggests an iteration length as short as possible. The main determining factor for optimum iteration length is how much it costs to close out each iteration. If regular implementation of the output is not onerous, then very short iterations are preferable (See Figure 2).
Figure 2: Iteration Reduces Costs of Failure

Summary
The decisions on size and delivery strategies are the most important that can be made when setting up a project. All too often it is enticing to solve all the

| 35

Chapter 3

The Promise of Agile

There are all sorts of jokes about what RAD (Rapid Application Development) really stands for, such as Really Awful Design and Rapidly Accumulating Defects. tongue in cheek comment on perceptions of RAD in 1998 by Jennifer Stapleton, Technical Director, DSDM (Atern) Consortium,82 As we have seen in Part I, as software development matured in the 1980s the approaches with the most attention and influence were top-down, waterfall, and BDUF methods. The proponents of more diverse methods became marginalized, and lost their influence on mainstream development practice. Craig Larman lamented: Even though the value of iterative and incremental development (IID) is well known among literate, experienced software engineers, some commercial organizations, consulting companies, and standards bodies still promote a document- driven single-pass sequential life cycle as the ideal.83 Stapleton has joked that Rapid Application Development (RAD) had not gained traction and was in danger of being perceived as simply delivering Really Awful Design or Rapidly Accumulating Defects.

55 .p ,3 00 2 ili sa B , na m raL

89 91 no te lp atS

28 38

| 151

balance between formal channels of communication and control, and the delegation of decision-making and flattening of layers of hierarchy. Governance at the project level is a factor that, when done well, can really motivate a team, and needs to meld together sponsor level leadership with realistic processes for steering the teams direction, reporting progress and for making decisions.

Using Agile methods (e.g. Scrum and Atern) to Motivate and Engender Trust
One of the attractive aspects of agile for team members is that they get to make their own decisions on matters that they are best placed to do so. These are typically: Deciding on the optimum technical solution Prioritizing delivery in chunks to gain the greatest benefit in the shortest time Exploration the interactions between requirements and possible solutions the art of the possible Quickly responding and adapting to new external factors, whether these are changes in policy/business environment, or new technical solutions that become available during the project Agile methods are, by their nature, process focused, and although leadership must play a part in their implementation and usage, they are framed in terms of process and roles. In effect, they are an activity based solution to the requirements that the 12 agile principles require each agile method presents a set of methods and processes that support and amplify the general agile principles.

152| 152|

Try these leadership tips now! Identify the main drivers for chaos outside your team and talk with your co-workers and team members about ways of managing these drivers Identify the expertise in your team and propose ways in which decisions related to these areas can be most effectively delegated to those with this expertise For your next meeting draw up an agenda of decisions that need to be made and categorize them into: o Those that an immediate decision is vital o Those where further investigation is necessary o Those where there appears to be only one viable solution, but it does not yet need to be committed to Concentrate your attention on the third: help the meeting to come to a common agreement as to the optimum time to make the decision so as to allow any factors that are unknown at present to surface, but not too late as to impact on success. This is not delay or indecision it is making the decision at the last responsible moment. Review the process for managing issues is it: o Light? o Effective? o Good at allowing issues to be resolved at the lowest level possible? Suggest an Failure Mode Evaluation Analysis workshop to ensure that your risks are not just managed in a bottom-up, bureaucratic manner If there is an existing risk register, get together with several of your peers to turn it upside down try combining together several low impact risks in series to see if their combined potential impact becomes high

148 |

Galley Proof Partial Sample Index to page 149 of the 377 pages
12 agile principles, 5, 46, 48, 146 24-hour management, 3 Agile approaches, 94, 118 Agile behaviors, 1 Agile organizations, 49 Agilists, 58 Apple, 24 Atern, 5, 6, 35, 52, 67, 68, 69, 81, 86, 88, 94, 97, 98, 99, 100, 104, 105, 106, 117, 133, 142, 146 Australian, 125, 126 Authoritarian project management, 50 Behavioral change, 45 Benington, 25, 26 Business case, 134 C3, 36, 37, 81 Canada, 4, 5, 8, 56, 125, 132 Case, 6, 71, 80, 93, 105, 144 Central government, 5 Commonwealth countries, 5 Crosby, 57 Crystal, 37, 52 De-emphasis on documentation, 49 Deming, 20, 57, 140, 141 Detroit, 3 Extreme programming, 48 Federal government projects, 2 Firecontrol, 11, 12, 18, 19, 112 Fowler, 38, 65, 96 France, 5, 8, 27 Gane, 27 Gates 2, 56 Gateway, 11, 140 Germany, 3, 5, 8 Governance, 131, 132, 133, 136, 144, 145, 146 India, 3, 5, 13 Informal communication across disciplines and organizational units, 49 Lack of written process within the team, 49 London congestion charge scheme, 2 Loose control of detail, 49 Merise, 27 Microsoft, 24, 40, 140, 141 Omaha, 37 Parliament, 123, 124 Policy decisions, 18 Portfolio management, 145 Project managers, 16 Project sponsor, 141 Project sponsorship, 141 Risk management, 9, 122, 125 Sarson, 27 Scrum, 5, 6, 45, 67, 71, 80, 88, 94, 97, 98, 99, 104, 106, 116, 126, 133, 139, 142, 146 Shewing, 19 Stakeholders, 12, 18, 19, 20, 58, 93, 104, 114 Top management, 45, 46, 118, 133, 134, 136 Top management involvement, 136 Utah, 4, 37 Valuing individuals and interactions, 39 Valuing responding to change, 42 Waterfall, 24, 26, 74 Windows 3.1, 4 Windows 95, 4 Yourdon, 27

Publication bibliography
Census shows decline in NHS staffing numbers. http://www.nhsemployers.org/Aboutus/latestnews/Pages/CensusshowsdeclineinNHSstaffingnumbers.aspx. The limits of Agile: Emergn CEO on Universal Credit - Public Sector IT. http://www.computerweekly.com/blogs/public-sector/2011/10/the-limits-of-agileemergn-ceo.html. DOD-STD-2167, Military Standard: Defense System Software development [superseding DOD-STD-1679A (Navy) and MIL-STD-1644B (TD)] (1985). In : [[United States Department of Defense]]. http://www.everyspec.com/DoD/DoDSTD/DOD-STD-2167_278/. DOD-STD-2167A, MILITARY STANDARD: DEFENSE SYSTEM SOFTWARE DEVELOPMENT] (1988). In : [[United States Department of Defense]]. Skunk Works Lessons Learned (1997). AGARD Conference Proceedings: Strategic Management of the Cost Problem of Future Weapon Systems. Drammen, Norway, 22-25 September 1997, 16/02/2012. Manifesto for Agile Software Development (2001). http://agilemanifesto.org/, updated on 28/12/2011. What price a PFI project? - Telegraph (2002). In Uk Daily Telegraph, 16/06/2002. http://www.telegraph.co.uk/finance/2765424/What-price-a-PFI-project.html, 17/02/2012. Enterprise risk management. Integrated framework : Executive Summary Framework : September 2004 (2004). New York: Committee of Sponsoring Organizations of the Treadway Commission. National Audit Office report (HC 33-I 2006-07): Delivering successful IT-enabled business change (2006), updated on 14/11/2006. Federal Enterprise Architecture Consolidated Reference Model Document. v 2.7 (2007). http://www.whitehouse.gov/sites/default/files/omb/assets/fea_docs/FEA_CRM_v23_F inal_Oct_2007_Revised.pdf, updated on 23/01/2009. IT Modernization Vision & Strategy (2007), 29/03/2012. NAO Report (HC 930 2007-08): HM Revenue & Customs transformation programme (2008). http://www.cag.gov.in/html/LB/Kr/LB_05_CHAPTER_I.pdf, updated on 15/07/2008.

150 |

ISO 31000 Risk management - principles and guidelines (2009). 1st ed.: 2009-11-15. Geneva: ISO. "No stone unturned" - Francis Maude unveils millions in efficiency savings | Cabinet Office (2010). http://www.cabinetoffice.gov.uk/news/no-stone-unturned-francismaude-unveils-millions-efficiency-savings, updated on 18/10/2010. Public Administration Select Committee PASC Good Governance: the Effective Use of IT (Wednesday 2011). http://www.publications.parliament.uk/pa/cm201011/cmselect/cmpubadm/uc715v/uc71501.htm. History: The Agile Manifesto (2012). http://www.agilemanifesto.org/history.html, updated on 8/07/2007. Campaign4Change | Breaking down barriers to change (2012). http://ukcampaign4change.com/, updated on 3/01/2012. Futurist pledges $50m in matched funding - University of Oxford (2012). http://www.ox.ac.uk/media/news_stories/2009/090412.html, updated on 18/01/2012. James Martin - About James Martin - Books Written (2012). http://www.jamesmartin.com/about/books_written.cfm, updated on 18/01/2012. The $100m man: Why philanthropist James Martin gave away his fortune (2012). In The Independent (UK) Profiles - People, 18/01/2012. http://www.independent.co.uk/news/people/profiles/the-100-man-whyphilanthropist-james-martin-gave-away-his-fortune-2182882.html, 18/01/2012. ADoole (2012): Reponse to FOIA Request. CASE REFERENCE IR 678713. UK Information Commissioner's Office. http://www.whatdotheyknow.com/request/105200/response/267421/attach/3/A%20C hesters%20IR%20678713%2023.03.2012%20final.pdf, updated on 22/03/2012. Agile Scout (2012): DSDM is Agiles Best Kept Secret? http://agilescout.com/dsdmis-agiles-best-kept-secret/, updated on 20/02/2012. Albert L. Lederer, Vijay Sethi (2002): The Implementation of Strategic Information Systems Planning Methodologies. http://zulsidi.tripod.com/pdf/sisp2.pdf, updated on 5/03/2002. Anderson, D.J (2005): Stretching agile to fit CMMI level 3 - the story of creating MSF for CMMI reg; process improvement at Microsoft corporation. In : Agile Conference, 2005. Proceedings, pp. 193201. Arisholm, Erik; Briand, Lionel C.; Member, Senior; Hove, Siw Elisabeth; Labiche, Yvan (2006): The Impact of UML Documentation on Software Maintenance: An

Experimental Evaluation. In IEEE Transactions on Software Engineering 32, p. 2006. Association for Project Management (2006): APM body of knowledge. 5th ed. High Wycombe: Association for Project Management. AU Victorian Ombudsman (2011): Own motion investigation into ICT-enabled projects. http://www.ombudsman.vic.gov.au/resources/documents/Investigation_into_ICT_e nabled_projects_Nov_2011.pdf, updated on 21/11/2011. August, Judy H. (1991): Joint application design. The group session approach to system design / Judy H. August. Englewood Cliffs, N.J: Yourdon Press; London : Prentice-Hall International (UK) (Yourdon Press computing series). Aviation Week (2011): Last Raptor Rolls Off Lockheed Martin Line. http://www.aviationweek.com/aw/generic/story_channel.jsp?channel=defense&id=n ews/awst/2011/12/19/AW_12_19_2011_p61406508.xml&headline=Last%20Raptor%20Rolls%20Off%20Lockheed%20Martin% 20Line. Avison, David E.; Fitzgerald, Guy (2003): Where now for development methodologies? In Commun. ACM 46, pp. 7882. Barry Boehm (2000): Requirements that Handle IKIWISI, COTS, and Rapid Change. In Computer 33, pp. 99102. Barry Boehm; Prasanta Bose (1994): A Collaborative Spiral Software Process Model Based on Theory W. In : Proceedings, 3rd International Conference on the software process. Applying the software process: IEEE, pp. 5968. Beath, Cynthia Mathis; Orlikowski, Wanda J. (1994): The Contradictory Structure of Systems Development Methodologies: Deconstructing the IS-User Relationship in Information Engineering. In Information Systems Research 5 (4), pp. 350377. http://search.ebscohost.com/login.aspx?direct=true&AuthType=ip,cookie,url,uid&d b=bch&AN=4430779&site=ehost-live&user=ns004994&password=RFq52nap. Beck, Kent (1999): eXtreme programming eXplained. Embrace change / Kent Beck. Reading, MA: Addison-Wesley. Berry, John (2011): Competancy Model For IT Program Management. US OPM. http://www.chcoc.gov/transmittals/TransmittalDetails.aspx?TransmittalID=4058. Boehm, Barry (2002): Get ready for agile methods, with care. In Computer 35 (1), pp. 6469. http://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=976920.

152 |

Boehm, Barry; R. Ross (1989): Theory-W Software Project Management Principles and Examples. In IEEE Transactions on Software Engineering 15, pp. 902916. Canada, Government of; Treasury Board of Canada; Secretariat (2009): Policy on the Management of Projects. Canadian Treasury Board. http://www.tbssct.gc.ca/pol/doc-eng.aspx?id=18229&section=text. Canada, Government of; Treasury Board of Canada; Secretariat (2010): Framework for the Management of Risk. CA TBC. http://www.tbs-sct.gc.ca/pol/doceng.aspx?id=19422&section=text. Carmel, Erran; Whitaker, Randall D.; George, Joey F. (1993): PD and joint application design: a transatlantic comparison. In Commun. ACM 36, pp. 4048. Clark, L. (1992): IE and the IEF versus RAD and FOCUS. Naval Postgraduate School, Monterey. http://www.dtic.mil/cgibin/GetTRDoc?AD=ADA257297&Location=U2&doc=GetTRDoc.pdf. CMMI Product Team (2011): CMMI for Development, Version 1.3 CMMI-DEV, V1.3. http://www.sei.cmu.edu/reports/10tr033.pdf, updated on 9/01/2011. Coad, Peter; Yourdon, Edward (1990): Object-oriented analysis. Englewood Cliffs, N.J. ; London: Yourdon Press (Yourdon Press computing series). Comptroller and Auditor General (India) (2004): Audit Report - LSGIs for the year ended 31 March 2004 - CHAPTER I. http://www.cag.gov.in/html/LB/Kr/LB_05_CHAPTER_I.pdf, updated on 8/04/2005. Conservative Home (2012): Not exactly clear support for Lansley from Cameron at PMQs. http://conservativehome.blogs.com/thetorydiary/2012/02/cameron-queenslaughter-front-line-police-officers-amess-maldives-c-burble-m-quite-a-big-cheerqueen-nhs-we-are.html. Cooper, R. G. (1994): Third Generation New Product Processes. In Journal of Product Innovation Management 11, pp. 314. http://processprotocol.com/pdf/pdt98.pdf, 16/02/2012. D.J. Tudor, I.J Tudor (2010): Dsdm atern student workbook. A guide to the definitive agile framework. [S.l.]: Galatea Training Services. Davies, Andrew; Dodgson, Mark; Gann, David (2009): From iconic design to lost luggage: Innovation at Heathrow Terminal 5. Copenhagen Business School: DRUID. Davies, Andrew; Gray, Ian (2011): Learning Legacy. Lessons learned from the London 2012 Olympic and Paralympic Games construction programme. London Olympic Delivery Authority.

http://learninglegacy.london2012.com/documents/pdfs/programme-organisationand-project-management/425009-234-innovation-aw.pdf, updated on 10/12/2011. Deming, W. Edwards (1986): Out of the crisis. Quality, productivity and competitive position / W. Edwards Deming. Cambridge: Cambridge University Press. DKBald00 (2007): IRS Risk Management Insights. http://poole.ncsu.edu/erm/documents/Hesspresentation04.27.07.pdf, updated on 21/06/2007. Doran, George T. (1981): There's a S.M.A.R.T. way to write managements's goals and objectives. In Management Review 70 (11), p. 35. http://search.ebscohost.com/login.aspx?direct=true&AuthType=ip,cookie,url,uid&d b=bch&AN=6043491&site=ehost-live&user=ns004994&password=RFq52nap. Drummond, Helga (1996): Escalation in decision-making. The tragedy of Taurus. Oxford [England] ;, New York: Oxford University Press. DSDM Consortium (2008a): DSDM Atern The Handbook. v4.2. DSDM Consortium (2008b): DSDM/Atern - The Handbook. DWP Department for Work and Pensions (2011): Department for Work and Pensions Annual Report and Accounts 2010-2011. http://www.dwp.gov.uk/docs/dwpannual-report-and-accounts-2010-2011.pdf, updated on 15/07/2011. Dyb\aa, Tore; Dingsyr, Torgeir (2008): Empirical studies of agile software development: A systematic review. In Inf. Softw. Technol 50, pp. 833859. http://dl.acm.org/citation.cfm?id=1379905.1379989. Dzidek, Wojciech J.; Arisholm, Erik; Briand, Lionel C. (2008): A Realistic Empirical Evaluation of the Costs and Benefits of UML in Software Maintenance. In IEEE Trans. Softw. Eng 34, pp. 407432. http://dl.acm.org/citation.cfm?id=1383055.1383295. East, Robyn (2012): IRS CADE2 Investment Dashboard. http://www.itdashboard.gov/investment?buscid=506. Ewell, Rowe (2006): CAPITAL PROGRAMMING GUIDE (PART 7). US OMB. http://www.whitehouse.gov/sites/default/files/omb/circulars/a11/current_year/part7. pdf, updated on 27/06/2006. Finkelstein, Anthony (1992): A software process immaturity model. In SIGSOFT Softw. Eng. Notes 17, pp. 2223. Finlay, Paul N.; Mitchell, Andrew C. (1994): Perceptions of the Benefits From the Introduction of CASE: An Empirical Study. In MIS Quarterly 18 (4), pp. 353370.

154 |

http://search.ebscohost.com/login.aspx?direct=true&AuthType=ip,cookie,url,uid&d b=bch&AN=9504033450&site=ehost-live&user=ns004994&password=RFq52nap. Fitzgerald, B. (1998): An empirical investigation into the adoption of systems development methodologies. In Fitzgerald,B. (1998) 'An Empirical Investigation into the Adoption of Systems Development Methodologies', Information & Management, 34(6), p. 317-328. Flyvbjerg, Bent; Bruzelius, Nils; Rothengatter, Werner (2002): Megaprojects and risk. An anatomy of ambition / Bent Flyvbjerg, Nils Bruzelius and Werner Rothengatter. Cambridge: Cambridge University Press. Flyvbjerg, Bent; Budzier, Alexander (2011): Why Your IT Project May Be Riskier Than You Think. In Harvard Business Review 89 (9), pp. 2325. http://search.ebscohost.com/login.aspx?direct=true&AuthType=ip,cookie,url,uid&d b=bch&AN=64493053&site=ehost-live&user=ns004994&password=RFq52nap. Fowler, Martin (1999): Refactoring. Improving the design of existing code / Martin Fowler. Reading, MA: Addison-Wesley (The Addison-Wesley object technology series). Fowler, Martin (2012): Writing The Agile Manifesto. http://martinfowler.com/articles/agileStory.html, updated on 17/01/2012. Francis Rose: GAO highlights 9 critical success factors for IT projects FederalNewsRadio.com. Interview with Director US GAO David Posner. FRC, U. K. (2005): Revised Turnbull Guidance. http://www.frc.org.uk/documents/pagemanager/frc/Revised%20Turnbull%20Guidan ce%20October%202005.pdf, updated on 10/12/2005. Fruhling, Ann; Vreede, Gert-Jan de (2006): Field Experiences with eXtreme Programming: Developing an Emergency Response System. In Journal of Management Information Systems 22 (4), pp. 3968. http://search.ebscohost.com/login.aspx?direct=true&AuthType=ip,cookie,url,uid&d b=bch&AN=20597992&site=ehost-live&user=ns004994&password=RFq52nap. Gane, C.; Sarson, T. (1977): Structured Systems Analysis. Tools and Techniques. N Y: Improved Systems Technologies. Giotis, Theofanis (2003): UK Government Gateway Project and Microsoft MSF. http://www.concept.ntnu.no/attachments/058_2006_samset_paper_euram_v4.pdf. Glass, R.L (2001): Extreme programming: the good, the bad, and the bottom line. In IEEE Software 18 (6), pp. 112111. http://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=965816.

Gomaa, Hassan; Scott, Douglas B.H (1981): Prototyping as a tool in the specification of user requirements. In : Proceedings of the 5th international conference on Software engineering. Piscataway, NJ, USA: IEEE Press (ICSE 81), pp. 333342. http://dl.acm.org/citation.cfm?id=800078.802546. Great Britain. Her Majesty's Stationery Office (1997): Appraisal and evaluation in central government. Treasury guidance. 2nd ed. Great Britain. Treasury (2003): The Green Book. Appraisal and evaluation in central government. [New ed.]. London: TSO. H.D. Benington (1987): Production of large computer programs. In : Proceedings. 9th International Conference on Software Engineering, March 30-April 2, 1987, Monterey, California, USA. Washington, D.C, Baltimore, MD: IEEE Computer Society Press; ACM Order Dept., p. 299. http://sunset.usc.edu/csse/TECHRPTS/1983/usccse83-501/usccse83-501.pdf. Hamer, David H.; Sullivan, Geoff; Weierud, Frode (1998): Enigma variations: an extended family of machines. In Cryptologia 22, pp. 211229. http://dl.acm.org/citation.cfm?id=295513.295518. Haungs, Jim (2001): Pair Programming on the C3 Project. In Computer 34, pp. 118119. http://dl.acm.org/citation.cfm?id=619060.621660. HM Treasury (2004): THE ORANGE BOOK 2004.pdf. UK HM Treasury. http://www.hm-treasury.gov.uk/d/orange_book.pdf, updated on 11/02/2004. HM Treasury and Cabinet Office (2011): Major project approvals and assurance guidance. http://www.cabinetoffice.gov.uk/sites/default/files/resources/majorproject-approvals-assurance-guidance.pdf, updated on 4/01/2011. Imai, M. (1991): Kaizen. (ky'zen). The key to Japan's competitive success: Compaa Editorial Continental. http://books.google.de/books?id=XsAkgTGo5ncC. IRM, AIRMIC ALARM (2002): A Risk Management Standard. IRM. http://www.theirm.org/publications/documents/Risk_Management_Standard_03082 0.pdf, updated on 6/02/2003. Jeff Zients, Deputy Director for Management US OMB (2010): OMB plans 25-point IT reform - FederalNewsRadio.com. Federal News Radio. http://www.federalnewsradio.com/?nid=697&sid=2194228. Joe Organ (2003): eGov monitor Feature: Government IT in the 1980s: The CCTA, Privatisation and Project Failures. eGov Monitor. http://www.egovmonitor.com/features/jorgan04.html, updated on 19/12/2011.

156 |

Kessler, Carl; Sweitzer, John (2007): Outside-in software development: a practical approach to building successful stakeholder-based products. First: IBM Press. Kimble, Chris (2008): SDM - Session 5, Semi-Formal Methods. http://www.chriskimble.com/Courses/sdm/Session_5.html, updated on 13/10/2008. Kundra, Vivek (2010): 25 point implementation plan to reform federal information technology management. Washington [D.C.]: The White House, [Chief Information Officers Council. http://www.cio.gov/documents/25-point-implementation-plan-toreform-federal%20it.pdf. Larman, Craig (2006): Agile and iterative development. A manager's guide. 8th ed. Boston [u.a.]: Addison-Wesley. Larman, Craig; Basili, Victor R. (2003): Iterative and Incremental Development: A Brief History. In Computer 36, pp. 4756. http://dl.acm.org/citation.cfm?id=972210.972226. Larman, Craig; Vodde, Bas (2009): Scaling lean & agile development. Thinking and organizational tools for large-scale Scrum / Craig Larman, Bas Vodde. Boston, Mass. ; London: Addison-Wesley. Larman, Craig; Vodde, Bas (2010): Practices for scaling lean & agile development. Large, multisite, and offshore product development with large-scale Scrum / Craig Larman, Bas Vodde. Upper Saddle River, NJ: Addison-Wesley. Leffingwell, Dean (2007a): Scaling software agility. Best practices for large enterprises / Dean Leffingwell. Upper Saddle River ; London: Addison-Wesley (The Agile software development series). Leffingwell, Dean (2007b): Scaling software agility. Best practices for large enterprises / Dean Leffingwell. Upper Saddle River ; London: Addison-Wesley (The Agile software development series). http://www.infoq.com/resource/articles/scalingsoftware-agility/en/resources/ch02.pdf. Lilley, Roy (Ed.) (2010): Health-Bill-Transition-Risk-Register-NC-15-Oct-10-DeptBd-Version-v1.1.xlsx. http://origin.library.constantcontact.com/download/get/file/1102665899193912/Health-Bill-Transition-Risk-Register-NC-15-Oct-10-Dept-Bd-Version-v1.pdf, updated on 26/03/2012. London Evening Standard (2011): Francis Maude insists that the days of "archaic" Whitehall benefits are numbered | News. http://www.thisislondon.co.uk/standard/article-23956158-francis-maude-insiststhat-the-days-of-archaic-whitehall-benefits-are-numbered.do.

Longworth, G.; Nicholls, Derek (1986): SSADM manual. Version 3 / Gordon Longworth and Derek Nicholls. Manchester: NCC Publications. Martin, James (1983): Information Systems Manifesto. Martin, James (1989-90): Information engineering. Englewood Cliffs, N.J: Prentice Hall (James Martin books on information systems). Martin, James (1991): Rapid application development. New York: Macmillan. Martin, James; McClure, Carma L. (1985): Action diagrams. Clearly structured program design / James Martin, Carma McClure. Englewood Cliffs, NJ: PrenticeHall. Martin, James; Odell, James J. (1992): Object-oriented analysis and design. Mary Poppendieck, Tom Poppendieck (2003): Addison Wesley - Lean Software Development: An Agile Toolkit. http://bib.tiera.ru/dvd47/Poppendieck%20M.,%20Poppendieck%20T.,%20Schwaber %20K.%20%20Lean%20Software%20Development.%20An%20Agile%20Toolkit%20(The%20A gile%20Software%20Development%20Series)(2003)(203).pdf, updated on 11/08/2003. McDonald, C. (2010): From Art Form to Engineering Discipline? A History of US Military Software Development Standards, 1974-1998. In IEEE Annals of the History of Computing 32 (4), pp. 3247. Mercurio et al (1990): AD/Cycle strategy and architecture. In IBM Systems Journal 29 (2), p. 172. Millington, Don; Stapleton, Jennifer (1995): Developing A RAD Standard. In IEEE Softw 12, pp. 5455. http://dl.acm.org/citation.cfm?id=624609.625511. Morgan, D. (2009): Covert Agile: Development at the Speed of Government. In : Agile Conference, 2009. AGILE 09, pp. 7983. Naur, P.; Randell, B. (1969): Software Engineering: Report of a conference sponsored by the NATO Science Committee, Garmisch, Germany, 7-11 Oct. 1968. Brssel: Scientific Affairs Division, NATO. http://homepages.cs.ncl.ac.uk/brian.randell/NATO/nato1968.PDF. Nerur, Sridhar; Mahapatra, RadhaKanta; Mangalaraj, George (2005): Challenges of migrating to agile methodologies (5). http://delivery.acm.org/10.1145/1070000/1060712/p72nerur.pdf?ip=94.173.41.31&acc=ACTIVE%20SERVICE&CFID=64122449&CFTOKE N=73662186&__acm__=1327924198_7e54abe1cc2cb3e10f879c81a22958d9.

158 |

North Carolina State College of Management (2007): The Opera Enterprise Risk Initiative. http://www.poole.ncsu.edu/erm/index.php/articles/entry/chris-hessroundtable/, updated on 29/03/2012. Nuseibeh, B. (2001): Weaving together requirements and architectures. In IEEE Computer 34 (3), pp. 115119. citeulike-article-id:776563. OGC (2011): Managing successful programmes. 2011st ed. [London]: Stationery Office. OMB (2003): Implementing the President's Management Agenda for E-Government. http://www.cio.gov/documents/2003egov_strat.pdf, updated on 18/04/2003. Peter Middleton (1994): Euromethod: The lessons from SSADM. In Walter Baets (Ed.): Proceedings of the Second European Conference on Information Systems, ECIS 1994, Nijenrode University, The Netherlands, 1994: Nijenrode University Press, pp. 359368. http://is2.lse.ac.uk/asp/aspecis/19940039.pdf. Project Management Institute (2008): A guide to the project management body of knowledge. (PMBOK guide). 4th ed. Newton Square, Pa: Project Management Institute. Public Accounts Committee (2/08/2012): Oral evidence taken before the Public Accounts Committee - The Introduction of the Work Programme - HC 1802-i. Interview with Robert Devereux. UK HOUSE OF COMMONS. Purvis, Russell (2000): The extent of CASE technology use within systems development projects. In Int. J. Comput. Appl. Technol 13, pp. 151158. http://dl.acm.org/citation.cfm?id=1356633.1356641. Rakitin, S. (2001): Manifesto Elicits Cynicism. In Computer, p. 4. http://sunset.usc.edu/events/2002/arr/letters.pdf, 30/01/2012. Rumbaugh, James (1991): Object-oriented modeling and design. Englewood Cliffs: Prentice Hall International Inc.; London : Prentice Hall International Ltd. Rumbaugh, James; Jacobson, Ivar; Booch, Grady (1999): The unified modeling language reference manual. Reading, Mass. ; Harlow: Addison-Wesley (The Addison-Wesley object technology series). Samset, Knut; Berg, Peder; Klakegg, Ole Jonny (2006): Front end Governance of Major Public Projects. http://www.concept.ntnu.no/attachments/058_2006_samset_paper_euram_v4.pdf, updated on 29/05/2006. Schwaber, Ken (2004): Agile project management with Scrum. Redmond, Wash: Microsoft Press.

Schwaber, Ken (2010): Scrum Basics. http://www.agileleantraining.com/download/Scrum-Guide-1.pdf, updated on 25/03/2010. Schwaber, Ken (2011a): The Scrum Guide. http://www.scrum.org/storage/scrumguides/Scrum%20Guide%20-%202011.pdf, updated on 22/08/2011. Schwaber, Ken (2011b): The Scrum Guide. http://www.scrum.org/storage/scrumguides/Scrum_Guide.pdf, updated on 18/10/2011. Shewhart, W.A (1931): Economic control of quality of manufactured product: American Society for Quality Control. http://books.google.de/books?id=EoynRAl0Po4C. Standish Group (1995): Unfinished Voyages. http://www.standishgroup.com/sample_research/unfinished_voyages_1.php. Stapleton, Jennifer (1998): Giving RAD a good name. In ITNOW 40 (6), pp. 2829. http://search.ebscohost.com/login.aspx?direct=true&AuthType=ip,cookie,url,uid&d b=iih&AN=44397333&site=ehost-live&user=ns004994&password=RFq52nap. Stephens, Matt; Rosenberg, Doug (2003a): Extreme programming refactored. The case against XP / D. Rosenberg, M. Stephens. Berkeley, Calif: Apress; Berlin : Springer. Stephens, Matt; Rosenberg, Doug (2003b): Extreme programming refactored. The case against XP / D. Rosenberg, M. Stephens. Berkeley, Calif: Apress; Berlin : Springer. Stevens, Matt (2003): Extreme Programming explained: What we really think of XP. http://www.softwarereality.com/lifecycle/xp/safety_net.jsp, updated on 17/11/2011. Strassmann, Paul A. (1997): The squandered computer. Evaluating the business alignment of information technologies / Paul A. Strassmann. New Canaan, Conn: Information Economics Press. Sutherland, Jeff; Schwaber, Ken (2007): The Scrum Papers. http://www.crisp.se/scrum/books/ScrumPapers20070424.pdf, updated on 22/04/2007. The Guardian (2011): Second thoughts about the City's Big Bang. http://www.guardian.co.uk/business/blog/2011/oct/26/big-bang-city-secondthoughts.

160 |

Thomas, David: PragDave: Some Agile History. http://pragdave.pragprog.com/pragdave/2007/02/some_agile_hist.html. Thomas, Elizabeth Scanlon (2011): Breaking the addiction to process. An introduction to Agile project management. Ely: IT Governance Pub. TIGTA: The Customer Account Data Engine 2 Program Management Office Implemented Systems Development Guidelines; However, Process Improvements Are Needed to Address Inconsistencies, 29/03/2012. Transport for London (2012): Congestion Charge Scheme - CChargeLondon.co.uk Information, Payment, Technology, Effect on Traffic, Businesses & Environment. http://www.cchargelondon.co.uk/history.html, updated on 2/09/2012. Treasury Board of Canada Secretariat (2010): A Guide to Project Gating for ITEnabled Projects. http://www.tbs-sct.gc.ca/itp-pti/pog-spg/irp-gpgitep/irp-gpgitepeng.pdf, updated on 18/08/2010. Treasury, H. M. (2005): Managing Public Money. http://www.hmtreasury.gov.uk/d/mpm_whole.pdf, updated on 11/01/2005. Turner, Richard; Jain, Apurva (2002): Agile Meets CMMI: Culture Clash or Common Cause? In : Extreme Programming and Agile Methods XP/Agile Universe 2002, pp. 153165. citeulike-article-id:6527920. U.S. Government Accountability Office, http://www.gao.gov (2007a): GAO-07-36 National Nuclear Security Administration: Additional Actions Needed to Improve Management of the Nation's Nuclear Programs. US GAO. http://www.gao.gov/assets/260/255316.pdf, updated on 19/01/2007. U.S. Government Accountability Office, http://www.gao.gov (2007b): GAO-07-518 Department of Energy: Consistent Application of Requirements Needed to Improve Project Management. US GAO. http://www.gao.gov/new.items/d07518.pdf, updated on 5/11/2007. U.S. Government Accountability Office, http://www.gao.gov (2011): GAO-12-26 Business Systems Modernization: Internal Revenue Service's Fiscal Year 2011 Expenditure Plan. US GAO. http://www.gao.gov/assets/590/585642.pdf, updated on 10/06/2011. UK Association for Project Management (2007): Co-Directing Change A guide to the governance of multi-owned projects, 16/01/2012. UK Association for Project Management (2011): Directing Change (2nd Edition), 05/01/2012.

UK Cabinet Office: Major Projects Authority - Assurance Toolkit. http://www.cabinetoffice.gov.uk/resource-library/major-projects-authorityassurance-toolkit. UK Cabinet Office (2009): PRINCE2 - Glossary of Terms v1.0, updated on 24/06/2009. UK Cabinet Office (2010): Management of risk. Guidance for practitioners. 3rd ed. London: TSO. UK Cabinet Office (2011a): Best Management Practice (BMP) Portfolio. http://www.cabinetoffice.gov.uk/resource-library/best-management-practice-bmpportfolio, updated on 12/06/2011. UK Cabinet Office (2011b): Government ICT Strategy, updated on 29/03/2011. UK Cabinet Office (2011c): Managing Change Maximising Value for Money in Major Projects. http://www.publicserviceevents.co.uk/ppt/MC11_SteveMitchell.pdf, updated on 12/08/2011. UK Cabinet Office (2011d): Starting Gate: MPA Guidance for Departments. https://update.cabinetoffice.gov.uk/sites/default/files/resources/MPA%20Starting%2 0Gate%20guidance%20for%20Depts%20September%202011.pdf, updated on 9/06/2011. UK Cabinet Office (2011e): Overview of the Major Projects Authority. http://www.cabinetoffice.gov.uk/sites/default/files/resources/mpa-overview_0.pdf, updated on 31/03/2011. UK HM Treasury (1991): Economic appraisal in central government (The Green Book). A technical guide for government departments. http://books.google.co.uk/books?id=HOSzAAAAIAAJ&q=treasury+green+book&dq= treasury+green+book&hl=en&sa=X&ei=hT0T6zROsf38QOAnJCbCA&ved=0CD8Q6AEwATgK. UK HM Treasury (2011): Major project approvals and assurance guidance. http://www.hmtreasury.gov.uk/d/major_projects_approvals_assurance_guidance.PDF, updated on 4/01/2011. UK HMRC (2011): Annual Report and Resource Accounts 2010-11. http://www.hmrc.gov.uk/about/annual-report-accounts-1011.pdf, updated on 14/07/2011. UK NAO: The failure of the FiReControl project - National Audit Office. http://www.nao.org.uk/publications/1012/failure_of_firecontrol.aspx.

162 |

UK NAO (2003): Recommendations Database. http://www.nao.org.uk/recommendation/report.asp?repId=423, updated on 17/02/2012. UK NAO (2004): National Audit Office Report (HC 877, 2003-2004): Improving IT procurement: The impact of the Office of Government Commerce s initiatives on departments and suppliers in the delivery of major IT-enabled projects (Full Report), updated on 11/02/2004. UK NAO (2010a): The Statement on Internal Control: A guide for audit committees, updated on 1/07/2010. UK NAO (2010b): NAO report (HC 21 2010-2011): Department for Work and Pensions: Support to incapacity benefits claimants through Pathways to Work (full report), updated on 27/05/2010. UK NAO (2011a): A snapshot of the Governments ICT profession in 2011. http://www.nao.org.uk/publications/1012/government_ict_profession.aspx. UK NAO (2011b): NAO Report (HC 708 2010-2011): National Health Service Landscape Review, updated on 19/01/2011. UK NAO (2011c): National Audit Office Report (HC 1272 2010-2012): The failure of the FiReControl project (full report), updated on 30/06/2011. UK NAO (2011d): The expansion of online filing of tax returns HC 1457, Session 2010-2012. http://www.officialdocuments.gov.uk/document/hc1012/hc14/1457/1457.pdf, updated on 11/09/2011. UK NAO (2012a): NAO Report (HC 1701 2010-2012): The introduction of the Work Programme, updated on 23/01/2012. UK NAO (2012b): National Audit Office Report (HC 1793 2010-2012): Child Maintenance and Enforcement Commission: Cost Reduction (full report), updated on 28/02/2012. Uk Parliamentary Office of Science and Technology (2003): POSTNOTE Government IT projects, updated on 24/07/2003. US DOD (2003): The Program Managers Guide to the Integrated Baseline Review Process. https://acc.dau.mil/adl/enUS/37635/file/9126/Program%20Managers%27%20Guide%20to%20the%20Integrat ed%20Baseline%20Review%20Process.pdf, updated on 6/04/2003. US GAO (2003): GAO-03-645T Best Practices: Better Acquisition Outcomes Are Possible If DOD Can Apply Lessons from F/A-22 Program. Testimony Before the Subcommittee on National Security, Emerging Threats, and International

Relations, Government Reform Committee, House of Representatives. http://www.gao.gov/new.items/d03645t.pdf, updated on 4/11/2003. US GAO (2005): GAO-05-276 Information Technology: OMB Can Make More Effective Use of Its Investment Reviews. http://www.gao.gov/new.items/d05276.pdf, updated on 15/04/2005. US GAO (2007): GAO-07-736 2010 Census: Census Bureau Has Improved the Local Update of Census Addresses Program, but Challenges Remain. http://www.gao.gov/new.items/d07736.pdf, updated on 14/06/2007. US GAO (2008a): GAO-08-1051T Information Technology: OMB and Agencies Need to Improve Planning, Management, and Oversight of Projects Totaling Billions of Dollars. http://www.gao.gov/assets/130/120968.pdf, updated on 31/07/2008. US GAO (2008b): GAO-09-45 Tax Administration: IRS Needs to Strengthen Its Approach for Evaluating the SRFMI Data-Sharing Pilot Program. http://www.gao.gov/assets/290/283133.pdf, updated on 11/07/2008. US GAO (2009a): GAO-09-1002T Homeland Security: Despite Progress, DHS Continues to Be Challenged in Managing Its Multi-Billion Dollar Annual Investment in Large-Scale Information Technology Systems. US GAO. http://www.gao.gov/assets/130/123290.pdf, updated on 15/09/2009. US GAO (2009b): GAO-09-543T Defense Acquisitions: Measuring the Value of DOD's Weapon Programs Requires Starting with Realistic Baselines. http://www.gao.gov/assets/130/122182.pdf, updated on 4/01/2009. US GAO (2010): GAO-10-227SP NASA: Assessments of Selected Large-Scale Projects. http://www.gao.gov/new.items/d10227sp.pdf, updated on 2/01/2010. US GAO (2011a): GAO-11-297 FEMA: Action Needed to Improve Administration of the National Flood Insurance Program. http://www.gao.gov/assets/320/319467.pdf, updated on 6/09/2011. US GAO (2011b): GAO-11-383 Catastrophic Planning: States Participating in FEMA's Pilot Program Made Progress, but Better Guidance Could Enhance Future Pilot Programs. http://www.gao.gov/new.items/d11383.pdf, updated on 4/08/2011. US GAO (2011c): GAO-11-873 Quadrennial Homeland Security Review: Enhanced Stakeholder Consultation and Use of Risk Information Could Strengthen Future Reviews. http://www.gao.gov/assets/590/585314.pdf, updated on 15/09/2011. US GAO (2011d): GAO-12-7 Information Technology: Critical Factors Underlying Successful Major Acquisitions. http://www.gao.gov/new.items/d127.pdf, updated on 21/10/2011.

164 |

USD(AT&L) (2008): DoD Directive 5000.01, May 12, 2003; Certified Current as of November 20, 2007 -- POSTED JANUARY 24, 2008. http://www.dtic.mil/whs/directives/corres/pdf/500001p.pdf, updated on 24/01/2008. VA Office of Inspector General (2011): Department of Veterans Affairs Office of Inspector General Audit of the Project Management Accountability System Implementation; Rpt #10-03162-262. http://www.va.gov/oig/52/reports/2011/VAOIG-10-03162-262.pdf, updated on 25/08/2011. Vijayasarathy, Leo R.; Turk, Dan (2008): Agile Software Development: A Survey of Early Adopters. In Journal of Information Technology Management. Vogt, Christian (2002): Intractable ERP: a comprehensive analysis of failed enterprise-resource-planning projects. In SIGSOFT Softw. Eng. Notes 27, pp. 6268. Wang; Xiaofeng; O'Conchuir; Eoin; Vidgen; Richard: A Paradoxical Perspective on Contradictions in Agile Software Development. http://aran.library.nuigalway.ie/xmlui/handle/10379/1582. Williams, Laurie (2012): What agile teams think of agile principles. In Commun. ACM 55 (4), pp. 7176. Winston W Royce (1970): Managing the Development of Large Software Systems. In : Proceedings, IEEE WESCON, pp. 19. http://www.cs.umd.edu/class/spring2003/cmsc838p/Process/waterfall.pdf. Work and Pensions Committee (2010): The Child Maintenance and Enforcement Commission and the Child Support Agencys Operational Improvement Plan. Report, together with formal minutes, oral and written evidence. UK House of Commons. http://www.publications.parliament.uk/pa/cm200910/cmselect/cmworpen/118/118.p df, updated on 23/02/2010.