Through bureaucracy to "digital" or how to prepare for IT system development in the public sector

"I decide here!" said the department head of one of our clients during the meeting.

Two reworks, a doubling of the timeline, a 1.5x increase in budget after working through the process with the main specialist. And this was just one process.
In this article, we will share our experience and recommendations on how to minimize risks and improve the process of launching IT projects in the public sector.

Hello, I’m Maxim from Sailet. We specialize in custom development, have been working since 2017, completed many interesting projects, discuss automation, and are developing our own ECM (Enterprise Content Management) system.
We have developed several large public sector systems, and many more we haven’t developed exactly because of these reasons. Let’s get started!)

Problem 1:
Lack of Design

Design is a fundamental process that defines the structure and functionality of the future system. The lack of thorough planning during the design phase often leads to mistakes that are difficult and/or expensive to fix in the future. This is not a 150-page specification that states "the system must be functional and scalable." It is the creation of a detailed and specific outcome of the system's work, and ensuring that all participants in the process understand this outcome.

Why is this important:

• A clear understanding of all aspects of the project helps avoid unexpected issues during the development and implementation process.
• Allows to optimize costs and reduce development time by minimizing the need for changes after work has started.
• No false expectations are created at the start of the project, and unnecessary functionality is not developed that will later be reworked or excluded.

Bad example

The Healthcare.gov project, a federal website developed to implement the Affordable Care Act (ACA) in the United States, faced serious problems immediately after its launch in October 2013. Despite an initial budget of $93.7 million, costs had exceeded $200 million by the time of launch, and total expenses eventually reached approximately $1.7 billion.

The main problems of the project included:

1. The website was not adequately tested before launch, leading to numerous technical failures, including server overloads and software errors. At peak load, the website was unable to handle a large number of users, which became one of the reasons for its failure.
2. Healthcare.gov needed to integrate data from various federal databases, including databases from the IRS, SSA, and DHS. A lack of experience and poor project management led to this task being unsuccessful.
3. The project was characterized by frequent changes in requirements and specifications, which created additional difficulties in the development and implementation of the system.

Conclusion:

Many of the problems with Healthcare.gov could have been prevented if the basic principles of project management and technology development had been followed.

Divine Integration

The first step in proper development is getting a quality structure for your future project from top specialists (that’s us, by the way). So, fill out the form, get a free consultation, and vision for your future product. We don’t do it for everyone, only after qualification.

Real Statistics

According to research conducted by IBM, projects that lack proper design face serious issues 75% of the time at launch, including budget overruns and failure to meet stated requirements (Source: IBM Global Software Survey 2020). Another study by McKinsey showed that careful planning and design can reduce overall development costs by 20-30% (Source: McKinsey & Company report, "IT project failures: Lessons learned and best practices").

How to Prepare for Design:

• Thoroughly study the needs and requirements of all stakeholders.
• Identify the key processes that the system should improve.
• Include all functional and non-functional requirements in the TOR.
• Ensure that the document is clear and unambiguous for all project participants.
• Develop prototypes or models of the future system for better visualization and understanding of the tasks.
• Organize regular meetings with all project participants to discuss the design progress and make adjustments.

Of course, this is not an exhaustive list, but let's start with something at least.

Problem 2: Changing requirements and blurring of responsibilities

One of the most challenging tasks in project management is handling changes in requirements after development has started. In other words, there is often a complete lack of correlation between extended timelines, budgets, and "wish lists." At the same time, someone higher up always emerges with their own "this button needs to be removed, and this text should be bolded," until the process ultimately depends on a single specialist. This person is deeply immersed in the subject matter and is the only one who can truly determine what is necessary. However, they will, of course, avoid taking responsibility, knowing that tomorrow they might receive a reprimand, be fired, or face other consequences. It’s not wise to oppose superiors. As a result, it all turns into a kind of circus: first, it’s necessary to explain to every "most important" person why something is needed, defend it, and justify that this "button" is a core system function. Then comes explaining that every "I want" comes with a cost, and only after that can work resume.

An example from our practice

A project initially estimated to take 4 months of development and 1 month of implementation ended up taking 9 months and was only 40% complete compared to the original plan. That 40% essentially represented an MVP, which addressed the core process. Do you think we missed the mark with the estimate, wrote a poor TOR, gathered requirements inadequately, misidentified responsible parties, or simply didn't do enough? After all, it's rarely just one side's fault, right? Hand on heart, our primary mistake was starting too late to say no, revisiting the terms, and initiating termination.

In total, about 20 people in charge were replaced! Each came with their own "super solutions." "I make the decisions here!" declared the department head at a meeting. Two reworks, a timeline extension by 2x, and a budget increase by 1.5x followed after the process was refined with the lead specialist. And that was just for one process.

Solutions

• Establish a change management process with clear rules for introducing any adjustments to the project. All changes must go through a formal approval process.
• Implement a change tracking system to ensure every change is documented and justified.
• Conduct regular training sessions and workshops for all project stakeholders to ensure a unified understanding of goals and objectives.
• Conduct onboarding for new team members and ensure they fully understand the project before letting them contribute, to minimize risks associated with misunderstandings.
• Develop a comprehensive documentation system that includes the entire project history, from initial data to any changes made to the project.
• Use collaborative tools and platforms that allow all project participants to access up-to-date information in real time.

In one of the webinars "Where to Start Automation?", I explained that having a specific person responsible on the client’s side is a must for any project. On average, this person spends 10 to 20% of the contractor's time. They should manage the process on your side, taking into account all the "artifacts" needed for your business.

Problem 3: Vague requests and fixed budgets — different paths to project implementation

In Kazakhstan's public sector, as in many other countries, the procurement and evaluation process for IT project proposals often encounters fundamental challenges. These issues begin as early as the request for proposals stage, where tasks are vaguely defined, and budgets are fixed in advance without a thorough understanding of the actual complexity or scope of the required work.

— "Hello! We need a system for receiving applications from all over Kazakhstan. This is a national project. Please send a commercial proposal by 6:00 PM."

We periodically receive requests of this nature from various government agencies. Most often, the "girl" on the other side doesn’t even know the purpose of the future system.

It’s quite possible to estimate such a request, but usually, a range from ten million to ten billion satisfies no one.

Fixed budgets set in advance further complicate the situation. When a project’s budget is determined without considering a detailed analysis of tasks and requirements, IT companies are forced either to underestimate the scope of work to fit the budget (by "cutting" functionality) or to overspend resources to meet all the client’s demands.

Two main approaches to project implementation:

• Exploratory Approach

This approach is used when the task is new or lacks clear boundaries. Clients provide general input data and ask the contractor to study the problem and propose a solution. This approach allows for flexibility in defining requirements and developing the system, but it makes it difficult or impossible to plan an exact budget upfront.

• Approach with Fixed Requirements and Budget

In this case, the client provides a detailed TOR with clearly described tasks and functions the system must perform, along with a strictly defined budget. They also immerse the contractor in the REAL processes and context before receiving a REAL estimate. This approach requires the client to invest significant effort in preparing and thoroughly elaborating all aspects of the project in advance. While it helps reduce the risks of unforeseen expenses and delays, it demands exponentially greater effort during the initial stage of the project.

Recommendations

Government agencies need to focus on improving the quality of initial technical specifications, including conducting preliminary research and analytical work. Better yet, start by ordering analytics specifically. Analysis -> Optimization -> Automation. Developing a clear procedure for managing changes in project requirements will help minimize risks and avoid "blurring" of responsibility. Organizing training seminars and workshops for civil servants responsible for the preparation and implementation of IT projects will enhance their understanding of the processes and improve the quality of initial data for technical specifications.

Conclusion

Preparing for the implementation of IT projects in the public sector requires a comprehensive approach, including improving planning processes, clearly defining requirements and responsibilities, and leveraging best practices and international experience. Kazakhstan is one of the leaders in public sector digitalization, and we have indeed made tremendous progress in this area. We are simply trying to enhance these achievements further by highlighting key issues. I am confident that a realistic assessment of effectiveness will show that the resources invested in our "digital" initiatives could have supported a significantly larger number of high-quality systems. And to achieve this, all you need to do is order development from us!)