EVALUATING STAKEHOLDER ENGAGEMENT IN AGILE TRANSFORMATION

ОЦЕНКА ВОВЛЕЧЁННОСТИ ЗАИНТЕРЕСОВАННЫХ СТОРОН В ПРОЦЕССЕ AGILE-ТРАНСФОРМАЦИИ

Рустемова Жулдыз Сакенкызы

магистрант, «Astana IT University», бизнес-аналитик, Национальные Информационные технологии,

Казахстан, г. Астана

ABSTRACT

Agile transformations in public-sector IT projects demand robust stakeholder engagement frameworks to navigate complex, regulated environments. This paper presents a condensed study of the Stakeholder Interaction Evaluation Model applied at JSC National Information Technologies in Kazakhstan – the national e-government infrastructure operator – during its Agile transformation. A mixed-method approach was used to compare As-Is and To-Be stakeholder interaction processes. The As-Is phase revealed fragmented communication, unclear roles, and delayed feedback loops. The To-Be phase, guided by SIEM, introduced structured stakeholder mapping, iterative feedback cycles, and cross-functional collaboration mechanisms. Quantitative results showed significant improvements in project performance after implementing Agile and SIEM. Qualitative findings indicated higher stakeholder satisfaction, clearer role understanding, and better alignment with strategic goals. The SIEM model – structured in three stakeholder layers with continuous feedback loops – provided a holistic, real-time evaluation of engagement quality throughout the Agile rollout. The study concludes that SIEM facilitated sustained stakeholder involvement, contributing to improved project outcomes and offering a repeatable governance tool for Agile transitions in the public sector. Key practical implications include the importance of early stakeholder buy-in, transparent communication channels, and iterative evaluation of engagement effectiveness. Overall, this work bridges theoretical insights on stakeholder management and practical Agile implementation, demonstrating how a structured model can drive successful organizational change.

АННОТАЦИЯ

Адаптация Agile в государственных ИТ-проектах требует надёжного механизма вовлечения заинтересованных сторон, способного функционировать в условиях строгой нормативной среды. В данной статье рассматривается модель оценки взаимодействия с заинтересованными сторонами (SIEM), внедрённая в акционерном обществе «Национальные информационные технологии» в рамках Agile-трансформации. Исследование основано на смешанной методологии, включающей анализ внутренней документации, интервью, опросы и Agile-метрики. Проведено сравнительное исследование процессов взаимодействия в состоянии «как есть» и «как должно быть». На первом этапе выявлены такие проблемы, как фрагментарные коммуникации, неясное распределение ролей и замедленная обратная связь. После внедрения SIEM были реализованы регулярные циклы обратной связи, структурированное распределение обязанностей и усиленное межфункциональное взаимодействие. Количественные данные продемонстрировали повышение скорости спринтов, рост доли выполненных задач и снижение времени отклика. Качественный анализ показал рост удовлетворённости участников, лучшее понимание ролей и соответствие стратегическим целям. SIEM охватывает три уровня заинтересованных сторон и использует непрерывные механизмы оценки. Это обеспечивает гибкую адаптацию модели к изменениям в проекте. Работа подчёркивает значимость регулярной оценки вовлечённости, прозрачных каналов коммуникации и раннего участия, предлагая воспроизводимую модель для эффективного управления изменениями в государственном секторе.

Keywords: stakeholder engagement; Agile transformation; public-sector IT; evaluation model; project management.

Ключевые слова: взаимодействие с заинтересованными сторонами; трансформация по Agile; государственный ИТ-сектор; модель оценки; управление проектами.

Introduction

Especially for complicated and cross-functional projects, modern project management is increasingly being seen as a vital success component shaped by efficient stakeholder involvement. Traditional stakeholder management methods in public-sector projects—often rigid and front-loaded in early project phases—struggle to satisfy the requirements of dynamic environments undergoing Agile transformations. While Agile methods offer constant improvement and flexibility, their effectiveness in bureaucratic environments depends on consistent, organized stakeholder involvement across the whole project lifetime. This paper meets this demand by creating and using the Stakeholder Interaction Evaluation Model (SIEM), a systematic instrument to assess and improve stakeholder participation throughout an Agile transformation in a Kazakhstan public-sector IT company.

Context: The case studied is JSC National Information Technologies (NIT), the state-owned operator of e-government infrastructure in Kazakhstan. To enhance cross-departmental cooperation, update internal procedures, and increase the efficiency of digital service delivery, NIT started using Agile techniques in 2020. Adoption was inconsistent; some departments completely adopted Scrum while others merely added some Agile components—Kanban boards, retrospectives—into conventional procedures. This setting allowed one to assess stakeholder involvement across different Agile maturity stages. NIT's central part in Kazakhstan's digital government made it a useful case study of balancing Agile values with public-sector responsibility and hierarchy.

Research Goal: The study sought to develop and empirically confirm the SIEM model for systematic assessment and ongoing enhancement of stakeholder participation in Agile transformation initiatives in the public sector. The basic concept was to combine qualitative stakeholder input with quantitative performance measures into a complete framework functioning in real-time across all organizational levels. SIEM hopes to match stakeholder involvement initiatives with project goals and adaptive project management techniques by means of this alignment.

Significance: From an academic standpoint, this paper adds to project management literature by suggesting a methodical, layered assessment methodology suited to Agile changes in public sector entities. Echoing results by San Cristóbal et al. (2018) and others, it relies on stakeholder theory and complexity research to suggest that continuous stakeholder involvement favorably affects project results. Practically, it provides public-sector managers a road map to analyze and improve stakeholder cooperation during Agile adoption, hence addressing deficiencies where traditional approaches fail in dynamic environments[1, p. 7].

Methodology

A mixed-methods case study conducted in two phases—before and after Agile implementation—helped to create and test SIEM.  This triangulated method guaranteed a rich, multi-perspective evaluation of stakeholder interaction dynamics:

• To grasp NIT's stakeholder involvement patterns, we studied process rules and project reports.    These showed communication barriers inside the conventional paradigm, task completion rates, and baseline cycle times.    Before Agile, a first stakeholder survey (structured questionnaire) evaluated cooperation, communication, and feedback responsiveness in ongoing projects.    Lacking defined Agile methods, this baseline specified stakeholder participation As-Is[2, p. 513].
• Pilot teams at NIT used Scrum techniques—sprint planning, daily stand-ups, sprint reviews, retrospectives—under an Agile transformation initiative to implement Agile SIEM.   Stakeholder mapping defined roles and obligations in the new approach.   Engagement metrics monitoring was coupled with the SIEM model's stakeholder feedback loops—sprint retrospectives and surveys.   Quantitative Agile performance data from JIRA—including sprint velocity (story points completed each sprint), average cycle time (issue lead time), backlog churn, and resolution rate—was gathered over 12 sprints. Through semi-structured interviews with project members and external stakeholders, we qualitatively evaluated communication quality, decision-making inclusion, and satisfaction. Follow-up surveys gauged changes in stakeholder involvement from baseline.

Data from both phases were compared to gauge the effect of Agile and SIEM. The approach purposefully mixed quantitative measurements—such as cycle time—with subjective assessments—such as survey/interview feedback—to confirm results by triangulation. This method catches the "hard" results as well as the "soft" human aspects of stakeholder involvement, hence complementing advised best practices in complicated project assessment.

As-Is vs To-Be Process Models

Before Agile, NIT's project workflow was plagued by systematic inefficiencies and inadequate stakeholder integration. Roles were unclear; staff members questioned task ownership and approval power, which caused duplication of work or jobs slipping through the cracks. Communication adhered to strict hierarchies: top-down flows of needs and choices left cross-departmental information sharing confined to official gatherings. Feedback loops were few and far between; problems were usually found late in the project, which led to reactive, last-minute solutions. Planning was mostly done by operational personnel, who had no say in what was delivered or what stakeholders expected. With sequential stages and gated approvals reflecting NIT's pre-Agile methodology, Figure 1 shows the old process.

In this conventional approach, a project request would pass through several levels (e.g., from a Product Owner to a Project Office and Developer team) with each layer operating in isolation. Requirements, for instance, were officially recorded and passed off; only after a development phase was finished did stakeholders assess the product, usually generating expensive and time-consuming change requests. This linear approach produced disengagement: operational teams seemed like just executors while strategic stakeholders were only engaged at the start and finish, without iterative input chances. Among the main problems mentioned in the baseline survey were project progress opacity, annoyance with slow reaction to change, and ambiguous points of contact for problem escalation.

Figure 1. “As-Is” process model at NIT before Agile transformation, characterized by siloed stages and delayed feedback

Agile approach with SIEM: NIT's stakeholder engagement approach was reworked to be more iterative, cooperative, and open under Agile methods with the SIEM framework in place. Every stakeholder, from end-user to executive sponsor, knew their duties and involvement points in the Agile cycle thanks to stakeholder mapping. Agile rituals guaranteed consistent interaction: stakeholders (or their representatives) took part in sprint planning to give tasks priority, attended sprint reviews to see increments, and offered comments during retrospectives. A reduced Agile workflow presented in Figure 2 forms part of the new approach.

Short sprints with stakeholder involvement were used in Agile development. Daily Stand-ups exposed issues in real time and improved cross-functional teamwork. Sprint Reviews gave stakeholders direct feedback after each iteration, not at project closing. Any mismatch or new need could be addressed in the next sprint using Agile reactivity. Sharing technologies like a JIRA Kanban board with all stakeholders improves interdepartmental cooperation and openness. Stakeholders may raise complaints or ideas during the sprint and after delivery, making the feedback loop proactive. This inclusive technique "made us feel part of one team" and gave interviewees confidence that complaints would be acknowledged immediately rather than ignored until the project ended. The SIEM model required team assessments of stakeholder engagement indicators including meeting attendance and feedback turnaround time at every sprint retrospective in addition to internal process improvement conversations, making stakeholder management agile [3, p. 1115].

Figure 2. “To-Be” process model after Agile adoption, featuring iterative development cycles and continuous stakeholder feedback

The SIEM Model Structure

The SIEM model's foundation is a layered, feedback-driven framework guaranteeing no stakeholder group is ignored by evaluating stakeholder involvement at three levels of the business.

• Operational Layer (Inner Layer): end-users, developers, and daily project team members. SIEM monitors indicators at this level including communication frequency (e.g., daily sync-ups), job clarity, and integration of quick feedback. One measure, for instance, was the proportion of user feedback applied in the same sprint it was reported on. The methodology guaranteed that operational stakeholders could express worries constantly—through stand-ups, backlog grooming, etc.—rather than only via management.
• Managerial Layer (Middle Layer): mid-level department heads, product owners, project managers Here, SIEM assesses departmental and team cooperation efficiency. Included are interdepartmental blocker resolutions, cross-team meeting cadence, and unit alignment of backlogs. This layer channels ground-level insights upward and converts strategic priorities into operational duties. At this level, SIEM included cross-functional retrospectives whereby people from several teams evaluate cooperation quality and spot systematic enhancements.
• Strategic Layer (Outer Layer): regulatory authorities, sponsors, and executives. SIEM evaluates their participation in decision-making (e.g., attendance in sprint demos or steering meetings), timeliness of their feedback/approvals, and the alignment of project outputs with strategic goals and compliance standards. Aiming to lower it below five working days, one particular measure was the average approval time for executive change requests. Periodic surveys of these stakeholders on faith in the project's direction provided another satisfaction index.

SIEM watches the interaction among these linked layers. For example, inter-level coordination is evaluated by how effectively information flows from operational up to strategic (are major risks escalated and addressed?) and from strategic down to operational (are vision and changes communicated clearly and promptly?). The approach runs a feedback loop across all layers: an ongoing improvement cycle is fed by data gathered at each layer—through surveys, meetings, performance measures [4, p. 140].

Importantly, SIEM is a constant assessment cycle rather than a one-time examination. Engagement data is examined and visualized on a "stakeholder engagement dashboard" every project cycle or sprint run. Should, for example, stakeholder attendance in important meetings decline or survey results indicate a communication problem, the model activates an adaptive reaction that may change the communication strategy or offer more role training. This dynamic transformation guarantees that the quality of involvement changes in reaction to project modifications. Essentially, SIEM treats stakeholder contact as an iterative process that can be honed continuously, hence embedding Agile ideas into stakeholder management itself[5, p. 488].

Figure 3. Stakeholder Interaction Evaluation Model

SIEM offers a whole picture of stakeholder engagement health by means of a combination of quantitative (measurable indicators) and qualitative (satisfaction and feedback) criteria. It guides where to concentrate improvement initiatives and serves as a "early warning system" for stakeholder-related hazards—e.g., disengagement, miscommunication. By means of the SIEM model, NIT was able to keep a great degree of stakeholder alignment even when project needs changed, hence assisting the Agile transformation with suitable control[6, p. 4].

Key Findings and Performance Outcomes

At NIT, the use of SIEM together with Agile techniques produced clear gains in project performance indicators as well as stakeholder attitude:

• There was a noticeable rise in the frequency and openness of exchanges. Surveys show that more over 85% of team members and stakeholders said communication became "timely and transparent" post-Agile, as opposed to just fifty percent prior. The feedback loop efficiency improved significantly: whereas previously, input on deliverables often took 1–2 months to be acted upon, issues made by stakeholders were resolved on average within one sprint (2 weeks). "We see action on it by the next meeting; we no longer feel our input disappears into a black box," one stakeholder said of this responsiveness.
• Project sprint velocity (story points finished each sprint) increased. The first sprints following transition had a velocity of 30 story points; by the 12th sprint, it stabilized at 40 points, suggesting a 33% rise in team throughput as processes and stakeholder inputs enhanced. The sprint task resolution rate rose from 60% pre-Agile to 75% in subsequent sprints. Stakeholder cooperation enhances blocker removal and backlog refining. From 15 days (pre-Agile, usually incorporating many approval processes) to 9–10 days, roughly a sprint cycle, the typical user story cycle time fell. This decline shows that, with stakeholder involvement, teams may decide more quickly than with protracted approval procedures.
• Clearly defined roles and consistent interaction rules substantially eliminated role uncertainty. 90% of poll respondents answered, "I know my role in the project and who to consult for decisions," up from 60%. Time managers had less time to establish roles or mediate between departments, allowing them to focus on strategy. Many interviewees felt stakeholder mapping and role defining was a breakthrough that eliminated ownership disputes and extra work. Interdepartmental projects like joint backlog meetings helped allocate resources more efficiently. For instance, IT operations and development coordinated release dates better, reducing deployment delays.
• Qualitative comments were extremely good. All levels of stakeholders said they felt more involved and heard. For instance, operational stakeholders—end users—observed that their recommendations for system enhancements were included more often, hence increasing their contentment with the final output. Project leaders among middle-layer stakeholders said they were more responsible but also more supported as sprint demonstrations gave them direct access to decision-makers. Executives, the strategic stakeholders, liked the consistent updates and working increments since they provided them certainty in project direction and a clear foundation for decisions. Especially, a top executive said that Agile+SIEM "gave unheard-of visibility into project progress," which strengthened their confidence in the IT staff. After the Agile transformation, overall stakeholder satisfaction ratings (from post-project surveys) rose by almost 25%, suggesting the improved cooperative climate.
• By including strategic-level stakeholders regularly, SIEM guaranteed that project results remained in line with NIT's and Kazakhstan's e-government objectives. For example, characteristics created in each sprint were clearly linked to more general strategic goals as faster delivery of digital services or adherence to new rules. A sprint review with executives present spotted and rectified a feature right away if it was straying from strategic priorities. This differs from the earlier mode, in which misalignment could only be found at a phase-end stage gate. This alignment's result was that the project provided 100% of the high-priority features found at the project beginning; earlier initiatives sometimes had scope dropped or postponed because of miscommunications and changing priorities.
• It was not without difficulties; at first, certain stakeholders, particularly in the strategic layer, found it difficult to adapt to the increased participation frequency since Agile required more consistent input than they were accustomed to. The team reduced this by explicitly stating the advantages and planning quick but regular stakeholder touchpoints. There was also a culture change needed: transitioning from formal papers to face-to-face (or virtual) talks was a learning curve. By formalizing the feedback mechanisms, SIEM's methodical approach helped to smooth this change. Stakeholders understood that, for example, every two weeks there would be a scheduled demo and retrospective, which gave their involvement a sense of routine and significance. Eventually, attendance in these events mirrored acceptance of the new standards.

All things considered, Agile methods and the SIEM framework working together greatly enhanced the interaction between project teams and stakeholders. The project not only exceeded its goals more quickly (as seen by quicker cycle times and more throughput) but also fostered a more positive and proactive stakeholder culture[7, p. 7]. This emphasizes the main conclusion of the research: particularly in settings where stakeholder roles are varied and complicated, including a stakeholder assessment model inside an Agile transformation can significantly improve project success and engagement quality.

Conclusion

NIT's Agile transformation shows that public-sector IT companies can significantly gain from a methodical stakeholder involvement approach. At every level of the project, the Stakeholder Interaction Evaluation Model (SIEM) offered a scalable, evidence-based tool to continuously track and enhance stakeholder involvement. SIEM guaranteed that stakeholder voices were not only heard but acted upon in real time by means of specific engagement criteria and iterative feedback loops. It resulted in more knowledgeable decisions, more openness, and more project execution flexibility. Importantly, SIEM provided a governance tool to maintain the change on course, so bridging the gap between Agile approach and the hierarchical, compliance-driven character of the public sector.

From a theoretical standpoint, this work improves project management literature by proving the favorable influence of continual stakeholder participation on project outcomes and by presenting a realistic model customized to Agile contexts in government settings. Answering demands for more dynamic ways to stakeholder management in projects, it combines ideas from complexity theory and stakeholder theory into a pragmatic evaluation framework. Emphasizing a layered, ongoing approach rather than one-time or one-size-fits-all involvement strategies, the SIEM model contributes to these discoveries.

Practically, the results provide direction for project managers and public-sector leaders starting Agile changes. Key recommendations are: (1) Early in the transformation, use a formal stakeholder engagement assessment to identify and address pain areas; (2) Make sure all stakeholder layers are represented in Agile ceremonies to preserve alignment (even brief, high-level executive check-ins can be quite important); (3) Combine quantitative metrics (such as feedback response time, attendance, backlog changes) with qualitative input to obtain a complete picture of engagement; and (4) Foster a culture of openness and adaptation so that feedback (positive or negative) is welcomed and used for ongoing improvement. Success at NIT implies that even very controlled companies may use Agile more efficiently when such values are in existence.

Still, one should consider the study's shortcomings. It concentrated on one company (NIT) with a particular mandate; although outcomes are positive, they might require replication in other governmental agencies or cultural settings for generality. Access to thorough long-term performance data was also restricted; the study addressed the first transformation period. Future studies might investigate the longitudinal consequences of continuous stakeholder involvement across several project cycles or years, as well as how SIEM could combine with digital tools for real-time analytics (e.g., dashboards using live stakeholder sentiment data). Automating some SIEM components with project management software plugins to lower manual survey load is another area to investigate as well.

Ultimately, models like SIEM will be crucial as governments and public organizations keep modernizing their IT systems using Agile techniques. They guarantee that agility does not sacrifice inclusiveness or responsibility. By contrast, carefully considered Agile transformations with robust stakeholder interaction frameworks can produce more effective, user-centered public services. The experience in Kazakhstan's NIT is a striking illustration of how Agile in the public sector may be fully realized by accepting input and cooperation at all levels.

References:

1. San Cristobal H. R., Carral L., Diaz E., Fragela H. A., Iglesias G. Complexity and project management: a general overview // Complexity. – 2018. – Vol. 2018. – Article ID 4891286. – 10 p. (October 2018).
2. Kaufmann K., Kok A. Does it matter The value of project management? The relationship between project management efforts, complexity and profitability // International Journal of Project Management, 2022, vol. 40, No. 5, pp. 502-515.
3. Magassuba S. M., Tambi A.M. B. A., Alkhlaifat B., Abdullah A. A. The impact of stakeholder participation on the effectiveness of development projects in Guinea // International Journal of Academic Research in Business and Social Sciences. – 2019. – Vol. 9, No. 1. – pp. 1111-1120.
4. De Oliveira G. F., Rabekini, R. Jr. The impact of stakeholder management on trust in a project: a quantitative study // International Journal of Project Management, 2019, vol. 37, No. 1, pp. 131-144.
5. Lekhtimyaki H., Kuyala Y. Dialogue with stakeholders and its role in project management: two–way communication for successful results // Proceedings of the EURAM 2017 conference. – 2017. – pp. 488-489.
6. Lorett K. Effective communication in organizations: increasing engagement, morale and productivity // Small Business Chronicle. - 2015.
7. Holt D. Effective communication in organizations. communication in the workplace // Houston Chronicle. – 2015. – Access via the Web Archive.