The book Agile Project Management for Government is structured in three parts. The first part presents some case studies of Agile success in public administrations. The second part discusses the principles of the Agile Manifesto in the context of government software development. The final part identifies six barriers to Agile success and suggests how you can overcome these barriers.
The book is well written with a good balance between presentation of examples and discussion of concepts. At the end of each chapter you will find some conclusions that summarize its content and questions that allow thinking further from what you have just read. There are also “Agile Leadership Exercises” that aim at putting the chapter knowledge in your own context.
Although the book is clearly focused on software development projects in a government context, I think that it can have a wider appeal, because some of the dysfunctional behaviors of some government organization can also be observed in private (especially large) corporation where the importance on control processes and the dispersion of responsibilities exist.
Reference: “Agile Project Management for Government”, Brian Wernham, Maitland & Strong, 289 pages, IBSN 978-0-957223400
The New Zealand government instituted a disaster compensation system within three days of the Christchurch earthquake. The team responsible for the software used an agile approach to visually track their work on a continual basis. Releases of working software were scheduled on a half daily and sometimes even hourly basis. The system paid more than AU$200m […]
A rigid and hierarchical project reporting structure called a Project Management Office (PMO) had been setup. It was large, unwieldy, and exhibited a huge optimism bias in its status reporting. Its bloated $120m budget was spent on inexperienced project managers with general government administration backgrounds. They had received basic training but had little or no background in technology development. Throughout the project, the reports produced by this PMO, despite being detailed and full of statistics, never reported even one sub-project as being in trouble, even as the project was obviously out of control.
Many projects produce business cases that are so detailed that they become an albatross around the project manager’s neck. Changing even minor details of a project’s objectives can be fraught with difficulty when faced with the need to keep an overcomplicated business case in line with latest thinking.