In Part I of this two-part series, we talked about why governments should go agile. But, going agile is not as simple as switching over to another project management tool or having daily stand-up meetings. Agile is a cultural change that needs to be included from the moment governments start thinking about undertaking a technology project.
Drawing from our experience of working with a premier government agency in India, we’ll outline a few steps (or share a blueprint) to ensure project success.
To put it simply, in an agile project one feels like they are creating something as against monitoring something. And, when a bottleneck is encountered, the teams come together to make way.
This helped further the cultural and process change that the project needed. In fact, the project’s CEO also played a huge role in this manner. He set priorities, convened weekly catch ups and motivated the team to move fast. He happened to be a keen listener who took a genuine interest in the technical vision and scalability of the solution.
The focus tends to be on minimizing cost and ensuring compliance. Procurement is often approached from a position of safeguarding interests rather than towards a successful outcome. As the project progresses, its scope and eventual solution usually evolve beyond the outlines of the RFP, needing governments to be flexible. However, the rigid contract-level scope comes in the way of direction changes.
To go agile, governments need to transition towards purchasing skill rather than purchasing scope. This is a fundamental change in how they view their projects and therefore, not easy. In a one-off engagement with a government agency, we identified a peaceful mid-point where the contract essentially purchases skills. These skills were then overlaid on the scope template. This allowed us to adapt to environmental demands and make changes within the same contract.
Another unique feature (wide-range impact of) government-related metrics is explained with this example - almost overnight, India revoked Pakistan’s status as Most Favoured Nation (MFN) in early 2019. Implementing this change on the ground calls for updates to many systems across departments. Who would think that such a declaration would affect import duties—but it did.
When the objective is to provide the best possible experience for an expansive user group, a tech-forward approach is necessary. Instead of working back from an existing problem, governments need to work forward towards possibilities. The Indian Space Research Organization’s (ISRO) ambitious projects, for instance, fall under this category. The commitment to new technology, new processes and new thinking needs to be cultivated regularly without getting held back by RoI conversations.
These could range from adoption of non-fossil energy and water conservation to sophisticated defense and space technologies. Let’s look at an example of 5G adoption - this tech can help governments seamlessly reach every citizen of a country and provide them with customized digitally rich information as well as allow them to access essential services. Governments also need to be savvy about this given that they will have to cross swords with several sophisticated adversaries (hackers) who could often use bleeding edge technologies to serve their wrongfully-motivated purposes.
For instance, the words ‘pilot project’ might give the impression that there is an option to go back. Instead, leadership should use words such as ‘early adopters’ to describe projects that are adopting agile principles.
In one of our high-impact engagements with a government agency, we built the capability to provide Over The Air (OTA) update for an application that runs on several thousand machines used by agents. This feature was conceived and suggested by our team and duly supported by the government agency leadership. It took several months for us to implement the system. Once it was released, other features followed, riding on top of the new capability.
For the first time, over the entire lifetime of the organization, one could make daily releases if required. The agile approach makes small changes in increments. The sponsors at the government agency took to the new normal, and started asking for additional features to be sent out on a regular basis.
What a long way we had come from where we were just two months ago!
Being agile helps governments deliver on their promises in a speedy, flexible and thoughtful manner. Governments need to be ever ready in a future where digital technologies become the backbone of public service delivery. This includes being proactive when it comes to adopting the world’s best processes and methodologies. Technological strengths of a country will soon define its abilities. Ambitious governments will have no choice but to go agile - in thought and in practice.
A version of this article was published in the eGov magazine.
Drawing from our experience of working with a premier government agency in India, we’ll outline a few steps (or share a blueprint) to ensure project success.
Governments need to strategically map out their digitization journey
Usher in positive accountability
Most government contracts, by their very nature, impose contrived accountability. Contrived accountability works through negative reinforcement, outlining who is responsible if something does not happen. Agile is a stark cultural change, pushing for co-creation. This approach creates greater accountability, and in a healthier way by driving commitment and conviction. Given the need for business and technology teams to work closely in agile projects, government agencies will, in fact, also have a greater sense of control.To put it simply, in an agile project one feels like they are creating something as against monitoring something. And, when a bottleneck is encountered, the teams come together to make way.
Champion change
As with all change management initiatives, governments also need internal champions who can drive change. These internal champions need to have the authority and influence to bring about said change. The premier Indian government agency that we worked with had several IT industry veterans as part of the project. These were people who had spent a significant number of years in the technology sector, and had served as CTOs of various companies. They brought relevant knowledge, technical thinking and pertinent industry contacts, to the table.This helped further the cultural and process change that the project needed. In fact, the project’s CEO also played a huge role in this manner. He set priorities, convened weekly catch ups and motivated the team to move fast. He happened to be a keen listener who took a genuine interest in the technical vision and scalability of the solution.
Buy skill not scope
Typically, government procurement processes are as follows - they float a Request For Proposal (RFP), created in consultation with experts. This will include the scope of the project and require vendors to mention their price, location, compliance, processes, the size of the organization etc. What it often doesn’t include is the vendor’s technology strengths and methodology.The focus tends to be on minimizing cost and ensuring compliance. Procurement is often approached from a position of safeguarding interests rather than towards a successful outcome. As the project progresses, its scope and eventual solution usually evolve beyond the outlines of the RFP, needing governments to be flexible. However, the rigid contract-level scope comes in the way of direction changes.
To go agile, governments need to transition towards purchasing skill rather than purchasing scope. This is a fundamental change in how they view their projects and therefore, not easy. In a one-off engagement with a government agency, we identified a peaceful mid-point where the contract essentially purchases skills. These skills were then overlaid on the scope template. This allowed us to adapt to environmental demands and make changes within the same contract.
Clarify metrics
When profit-making is not the ultimate goal, it’s tougher to identify the metrics. Today, governments need to be responsive, preemptive and proactive, and these characteristics will empower faster releases and quicker responses to functional changes.Another unique feature (wide-range impact of) government-related metrics is explained with this example - almost overnight, India revoked Pakistan’s status as Most Favoured Nation (MFN) in early 2019. Implementing this change on the ground calls for updates to many systems across departments. Who would think that such a declaration would affect import duties—but it did.
Think tech-forward
Traditionally, Return On Investment (RoI) used to be calculated in terms of payback over a period of time. But the rapid explosion of technologies has made traditional approaches to ROI calculations irrelevant. This traditional business-backward approach also falls short in the context of government projects.When the objective is to provide the best possible experience for an expansive user group, a tech-forward approach is necessary. Instead of working back from an existing problem, governments need to work forward towards possibilities. The Indian Space Research Organization’s (ISRO) ambitious projects, for instance, fall under this category. The commitment to new technology, new processes and new thinking needs to be cultivated regularly without getting held back by RoI conversations.
These could range from adoption of non-fossil energy and water conservation to sophisticated defense and space technologies. Let’s look at an example of 5G adoption - this tech can help governments seamlessly reach every citizen of a country and provide them with customized digitally rich information as well as allow them to access essential services. Governments also need to be savvy about this given that they will have to cross swords with several sophisticated adversaries (hackers) who could often use bleeding edge technologies to serve their wrongfully-motivated purposes.
Stay the course
We have established that transitioning to agile is nothing less than a change-management program. It could take several years for the change to take effect. Which is also why it’s important to stay the course and display conviction through words and action.For instance, the words ‘pilot project’ might give the impression that there is an option to go back. Instead, leadership should use words such as ‘early adopters’ to describe projects that are adopting agile principles.
Be conscious of change
While going agile, organizations must remember to savour achievements, however big or small. It is this consciousness that makes leaders committed to going agile and encourages them to stay the course.In one of our high-impact engagements with a government agency, we built the capability to provide Over The Air (OTA) update for an application that runs on several thousand machines used by agents. This feature was conceived and suggested by our team and duly supported by the government agency leadership. It took several months for us to implement the system. Once it was released, other features followed, riding on top of the new capability.
For the first time, over the entire lifetime of the organization, one could make daily releases if required. The agile approach makes small changes in increments. The sponsors at the government agency took to the new normal, and started asking for additional features to be sent out on a regular basis.
What a long way we had come from where we were just two months ago!
Being agile helps governments deliver on their promises in a speedy, flexible and thoughtful manner. Governments need to be ever ready in a future where digital technologies become the backbone of public service delivery. This includes being proactive when it comes to adopting the world’s best processes and methodologies. Technological strengths of a country will soon define its abilities. Ambitious governments will have no choice but to go agile - in thought and in practice.
A version of this article was published in the eGov magazine.
Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.
