Navigating bureaucracy towards digital transformation: preparing for IT system development in the public sector

Hello, I’m Maxim from Sailet. We specialize in custom software development, have been operating since 2017, completed numerous interesting projects, talk about automation, and are developing our own Enterprise Content Management (ECM) system.

We’ve developed several major government systems, and even more were not developed precisely because of these reasons. Let’s dive in!)

Design is a fundamental process that determines the structure and functionality of a future system. Lack of thorough preparation at the design stage often leads to errors that are difficult and/or expensive to fix in the future. It’s not a 150-page specification that simply states, "the system must be functional and scalable." Instead, it involves creating a detailed and specific outcome for the system and ensuring everyone involved understands it.

Why is this important?

• Clearly understanding all aspects of the project helps prevent unexpected issues during development and implementation.
• Allows optimization of costs and reduction of development time by minimizing the need for changes once work has begun.
• Eliminates false expectations at the outset of the project and prevents unnecessary features from being developed, which might later be redesigned or discarded.

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

Key challenges included:
1. The site was inadequately tested prior to launch, leading to numerous technical glitches, including server overloads and software bugs. At peak loads, the site couldn't handle the high user traffic, contributing to its failure.
2. Healthcare.gov needed to integrate data from various federal databases, including those of the IRS, SSA, and DHS. Lack of experience and poor project management resulted in this task being poorly executed.
3. The project experienced frequent changes in requirements and specifications, complicating both development and implementation.

Conclusion:
Many of Healthcare.gov's problems could have been avoided if basic project management and technological development principles had been followed.

A bad example

The first step towards successful development is obtaining a solid project structure from top-notch experts (that's us, by the way). So, fill out the form, receive a free consultation, and gain insights into your future product. We don't work with just anyone—only after qualification.

Divine Integration

According to studies conducted by IBM, projects that lack proper design face serious issues at launch in 75% of cases, including budget overruns and failure to meet stated requirements (Source: IBM Global Software Survey 2020). Another study by McKinsey revealed that meticulous planning and design can reduce overall development costs by 20–30% (Source: McKinsey & Company report, "IT Project Failures: Lessons Learned and Best Practices").

Real statistics

How to prepare for the design:

• Thoroughly analyze the needs and requirements of all stakeholders.
• Identify the core processes that the system should enhance.
• Include all functional and non-functional requirements in the specification document.
• 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.
• Organize regular meetings with all project members to discuss progress and make adjustments.

Of course, this isn't an exhaustive list, but let's start somewhere.

One of the most challenging aspects of project management is handling changes in requirements after development begins. In other words, there's often little correlation between extending deadlines and budgets and sudden "wants" from stakeholders. Someone always comes along with their own ideas, like "we need to remove this button" or "make this text bold," until finally, the only expert who truly understands the subject matter arrives. Only they can determine what's actually necessary. However, they usually won't take responsibility because they fear reprimands, dismissal, or worse. After all, it's not wise to contradict one's superiors. As a result, the whole process turns into a circus: first, you have to explain to each "most important person" why certain elements are critical, defend your decisions, and clarify that each "want" comes with a price tag, before you can proceed with the actual work.

A project initially estimated to take four months for development and one month for implementation took nine months to complete, reaching only 40% of the original plan. That 40%, essentially an MVP, managed to address the primary process. Do you think we miscalculated, poorly drafted the specs, gathered inaccurate requirements, incorrectly identified responsibilities, or failed to deliver? In reality, it's rarely the fault of just one side, right? Honestly, our biggest mistake was waiting too long to say no, reassess conditions, and initiate termination.

Overall, nearly 20 individuals rotated through the role of project manager, each bringing their own "superior" solutions. "I decide here!" declared the department head at a meeting. Two revisions, a doubling of the timeline, and a 1.5x budget increase ensued after collaborating with the chief specialist—all for just one process.


Solutions:

• Establish a change management process with clear guidelines for any modifications to the project. All changes must undergo formal approval procedures.
• Implement a change tracking system to document and justify each alteration.
• Regularly conduct training sessions and seminars for all project stakeholders to ensure a unified understanding of goals and tasks.
• Onboard new team members and ensure they fully comprehend the project before allowing them to contribute, thereby mitigating risks associated with misunderstandings.
• Create comprehensive documentation encompassing the project's history, from inception to any subsequent changes.
• Leverage collaborative tools and platforms that grant all project participants access to real-time updates.

During one of my webinars titled "Where to Start with Automation?", I emphasized the importance of having a dedicated point person on the client's side for any project. Typically, this individual spends 10-20% of their time guiding the process while considering all relevant business factors.

An example from our practice

In Kazakhstan's public sector, as in many other countries, the procurement and evaluation process for commercial proposals in IT projects frequently encounters fundamental difficulties. These issues begin at the proposal request stage, where tasks are often vaguely formulated, and budgets are fixed beforehand without a deep understanding of the actual complexity or scope of the required work.

— "Hello! We need a system for receiving applications from across Kazakhstan. This is a national project. Please send your commercial proposal by 18:00."

Requests similar to this occasionally come from various government entities. More often than not, the person on the other end doesn’t even know the purpose of the future system.

Evaluating such requests is possible, but the usual range from ten million to ten billion tends to satisfy no one.

Predetermined fixed budgets further complicate matters. When a project's budget is established without considering the detailed elaboration of tasks and needs, IT companies are forced either to underestimate the workload to fit within the budget ("cutting" functionality) or to overspend resources to fulfill all the customer's requirements.

• Research-Based Approach

Used when the task is new or lacks clear boundaries. Clients provide general background information and ask the contractor to investigate the issue and propose a solution. This approach allows flexibility in defining requirements and developing the system, although accurately estimating the budget initially can be difficult or impossible.

• Fixed Requirements and Budget Approach

In this case, the client provides a detailed specification with clearly described tasks and functions the system must perform, as well as a strictly defined budget. They also immerse the contractor in REAL processes and context, only then receiving a REALISTIC estimate. This requires the client to prepare more thoroughly and detail all aspects of the project in advance. While this can reduce the risk of unexpected expenses and delays, it demands significantly more effort at the early stages of the project.

Two main approaches to project implementation:

Recommendations