History and spread of Agile project management in the public sector of Lithuania; Basic principles of legalizing the Agile in the public procurement; Practical recommendations for Agile IT procurement

1. www.agile.lt
www.agileturas.lt
www.valstybe.agile.lt
Agile + Public Sector = ?
Alexey Kovaliov
2021.09.15

2. www.linkedin.com/in/aleksejkovaliov
• Scaled Agile Program Manager
• Consultant
• Lector
• Father

3. Theme
▪ History and spread of Agile project management in
the public sector of Lithuania
▪ Basic principles of legalizing the Agile in the public
procurement
▪ Practical recommendations for Agile IT procurement
▪ Summary

4. History and spread of
Agile project
management in the
public sector of Lithuania

5. Key Influencers to Project Management in
Lithuanian Public Sector
▪ Government Office (GO)
▪ Public Procurement Office (PPO)
▪ Information Society Development Committee
(ISDC)
▪ Under Economy and Innovation Ministry
▪ Previously under Ministry of Transport and
Communications

6. 2021
Today
2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021
ISDC: Life Cycle Methodology updated
2/25/2014
ISDC: Usability Methodology
5/5/2015
ISDC: Recommendations for IT Project
Governance Services Procurement
11/12/2017
GO: Government PMO & Project
Management Standard (PMI based)
10/6/2018 PPO: Recommendations
for IT Procurement
(unofficial)
10/5/2020
1/1/2010
Waterfall Life Cycle of the State Information Systems Methodology
1/2/2014
6/1/2013 9/1/2021
Public Sector Influencers cooperation with Agile Lietuva
2/1/2014 9/1/2021
Agile Life Cycle of the State Information Systems Methodology
2/1/2017
Agile IT Projects Governance Recommendations
9/1/2021
10/2/2020
Agile IT Procurement
Recommendations
9/1/2021
History

7. Proof Links
ISDC, 2014: „LIFE CYCLE of the STATE INFORMATION SYSTEMS MANAGEMENT
METHODOLOGY“
ISDC, 2014: „USABILITY METHODOLOGICAL RECOMMENDATIONS“
ISDC, 2015: „E-SERVICES METHODOLOGICAL RECOMMENDATIONS“
ISDC, 2017: “IT PROJECTS GOVERNANCE METHODOLOGICAL RECOMMENDATIONS"
GO, 2018-2019: State Project Management Standard
PPO + Agile Lietuva + Infobalt, 2020: Public presentation of the Recommendations for IT
Procurement

8. What is recommended?
2014: „ STATE INFORMATION SYSTEMS LIFE CYCLE MANAGEMENT METHODOLOGY “
2017: “IT PROJECTS GOVERNANCE METHODOLOGICAL RECOMMENDATIONS"
Life Cycle of the State Information System
System Initiation Implementation Operations Modernization Termination

9. What is recommended?
2014: „ STATE INFORMATION SYSTEMS LIFE CYCLE MANAGEMENT METHODOLOGY “
2017: “IT PROJECTS GOVERNANCE METHODOLOGICAL RECOMMENDATIONS"
Choosing an Implementation Approach for the State Information System
Is Scope “Big”?
Is Scope “Modular”
Apply
“Modular”
Apply “Iterative-
Incremental” -
Agile
Is Scope “Well
Defined”?
Apply
“Waterfall”
Apply “Iterative-
Incremental” -
Agile

10. Approaches Comparison Agile Lietuva © ☺
▪ by activities sequencing

11. Approaches Comparison Agile Lietuva © ☺
▪ by usability of the intermediate results

12. Approaches Comparison Agile Lietuva © ☺
▪ by readiness for changes

13. Approaches Comparison Agile Lietuva © ☺
▪ by documentation artefacts

14. ISDC stats 2018
24
7 6
0
5
10
15
20
25
30
Waterfall Modular Agile
Waterfall Modular Agile
State Information Systems and Registers 2014 - 2018
Just 6 Agile level projects
in 4 years of legal Agile 

15. ISDC stats 2019
1
8
10
20
0
5
10
15
20
25
Waterfall Modular Agile Unspecified
Waterfall Modular Agile Unspecified
State Information Systems and Registers 2018 - 2019
10 projects in just 1 year ☺

16. ISDC stats 2021
State Information Systems and Registers 2019 - 2021
TBD

17. Key Challenges for Agile spread in Public Sector
▪ Legalized and Recommended, but not Mandatory
▪ Controlling Authorities are not always Agile-friendly
▪ High level of Transparency and Control force to
take care about “paper” safety first vs project
efficiency
▪ Lack of clear Agile IT Procurement
recommendations / guidelines at the start
▪ Vendors are not always Agile-friendly due to
economical reasons
▪ Lack of knowledge and practice
▪ Lack of Project Management as a Discipline and
Process in Public Sector

18. Basic principles of
legalizing the Agile in the
public procurement

19. Agile Project is Project first, Agile second
▪ Agile project also may have and must have Fixed Term, Scope and
Budget
▪ Agile project must have proper Governance and Control
▪ Agile project produces usable Intermediate Results, which may or
may not GO LIVE
▪ Key benefit of Agile project – better Risk and Change Management
▪ Practical assessment of intermediate progress
▪ Easier introduction of change
▪ Closer involvement of stakeholders and users in collaborative mode

20. Agile suits Complex Programs
▪ Program is cascaded to a set of Projects/Streams
▪ Every Project may have iterative-incremental delivery phases (Agile)
▪ Additional benefit of Agile – early validation of inter-stream dependencies

21. Planning
Scrum of
Scrums
Stream
Corrective
Actions
Program
Corrective
Actions
Risk &
Change
Management
Complex Agile Program = Scaled Agile
Workstream 1, Team 1 Workstream 1, Team 2 Workstream 2

22. Agile “Undercover”1
Traditional Project Contract
x x x x x x x
Contract Signed
Detail
Requirements
Approved
Technical Design
Approved
System
Deployed
Users Trained
UAT/Trial Usage
Accepted
Project Sign off

23. Traditional Project Contract
x x x x x x x
Contract Signed
Detail
Requirements
Approved
Technical Design
Approved
System
Deployed
Users Trained
UAT/Trial Usage
Accepted
Project Sign off
Backlog Preparation
& Refinement Backlog Preparation & Refinement
Environments,
Designs,
Tech Enablers
Prototype
Development Design Adjustments & Development
Adjustments based on demonstrations feedback
“Undone”
catch up &
Stabilization
Release Plan &
Initial Backlog
presentation
Release
ALPHA1
Release
ALPHA2
Release
BETA1
Release
BETA2
Release
BETA3
Release
Version
Agile “Undercover”2

24. How to make Public Sector Agile?
▪ Make Public Sector skilled in Project Management
▪ Identify Influencers and potential Owners of the Project Management discipline in
Public Sector
▪ Establish collaboration with Project Management and Agile communities of practice
▪ Establish official methodologies, standards, guidelines for Project Management in
Public Sector
▪ Run training programs for key Public Sector organizations
▪ Link / expand Public Sector Project Management methodologies to
Agile
▪ Establish deeper collaboration with Agile communities of practice
▪ Adjust official Project Management methodologies with recommendations for Agile
approach
▪ Establish Public Procurement recommendations for Agile projects
▪ Run pilot projects and crease success case studies
▪ Run training programs for key Public Sector organizations
▪ Key factors of success
▪ Strong support from Government Office or other responsible Authorities
▪ Alignment with Control Authorities including Public Procurement Office
▪ Transparency and collaboration with market players and communities of practice
▪ Success Case Studies from key Ministries or Government Office

25. Practical
recommendations for
Agile IT procurement

26. What is Agile IT Procurement?
▪ Procurement Object definition
▪ Ensuring the space for deviations
▪ Contract Characteristics
▪ Phased delivery by small cadencies (iterations)
▪ Requirements to produce intermediate working / usable solution after each
cadence
▪ Phase delivery for Operations (releases)
▪ Client participation and collaboration rights and liabilities on cadence level
▪ Vendor transparency assurance on cadence level
▪ Teams structure and capacity
▪ Plans and Progress
▪ Impediments
▪ Change management process, incl. rules for setting the priorities and detail
scope, on cadence level
▪ Project control points aligned with cadencies
▪ Rules for cross-stream alignment and dependency management in case of
Complex Program/Scaled Agile
26

27. IT Procurement Categories1
▪ Communication Services
▪ Cloud / Hosting Services
▪ Hardware
▪ Software licenses, license upgrade or manufacturer support
▪ Projects to implement new or essentially modernize Information
Systems
▪ Information Systems’ Support and Extension Services
▪ Specific IT SMEs Services
▪ Typical / Packaged Projects (e.g. Security testing/audit)

28. IT Procurement Categories2
▪ Communication Services
▪ Cloud / Hosting Services
▪ Hardware
▪ Software licenses, license upgrade or manufacturer support
▪ Projects to implement new or essentially modernize Information
Systems
▪ Information Systems’ Support and Extension Services
▪ Specific IT SMEs Services
▪ Typical / Packaged Projects (e.g. Security testing/audit)
Regular procurement of “goods” or
standard services
Lowest price wins
Regular procurement of “goods” or
standard services
Lowest price wins
Subjects for Agile IT Procurement

29. Decision Making about the Procurement Category1
Procurement of
IT Projects
Typical /
Repetitive
project
Unique Project
Small Project
Big Project
Services
Support and/or
Extensions
Time &
Material/Skills
“Big Project” Procurement
Support & Extension
Procurement
“Goods” procurement
“Goods” procurement
- Agile

30. Decision Making about the Procurement Category2
Do we know
WHAT to do?
Do we know
HOW to do it?
Can we MANAGE
it all?
Time &
Material/Skills
Support &
Extensions
Big Project
Procurement
Buy Consultants
to define WHAT
& HOW

31. „Big Project “ Procurement

32. „Big Project “ Procurement
▪ Vendor Qualification requirements
▪ Economic Efficiency evaluation
▪ Procurement Object structure (3 parts)
▪ Technical Specification / Statement of Work guidelines
▪ Implementation / Releases phases
▪ RFP Task for Vendor
▪ Support and Extensions Services

33. Vendor Qualification requirements
▪ Depends on Public Procurement Office rules,
recommendations and practices
▪ General recommendations
▪ Ensure competition
▪ Let small and medium businesses to participate
▪ Demand proven record for no more than 0.3-0.5 of target budget
▪ Do not overdemand SMEs certificates
▪ Do not overdemand ISO or similar company level certificates
▪ Demand contingency of teams and vendor ability to ensure
replacements
▪ Demand dedicated SMEs
▪ If possible – demand recommendations or Proof of Concept
▪ If possible – demand Teams’ screening

34. Economic Efficiency
▪ Price 30% / Criteria 70%
▪ E.g. 70% =
 20% - Solution Vision and Quality Assurance approach
 Functional and Non-functional requirements satisfaction and add-ons
 Delivery plan logic and rationale, delivery phases optimization
 40% - Solution Architecture Efficiency and Openess
 Architecture compliance to Client’s existing assets, policies, investments,
competencies
 Licensing efficiency
 Total Cost of Ownership in 3-5 years perspective
 10% - Added Value
 Additional functional/non-functional capabilities, which are not mandatory by
Technical Specification
 Additional strategic value, not defined in Technical Specification, but reasonably
justified by Vendor
▪ There is no single template for Economic Efficiency criteria
definition
▪ It should be aligned with Project Goals and Environment

35. Procurement Object Parts
Procurement Object Price Procurement
Liability
Payment
Information System
implementation and
deployment
Fixed price 100% Staged, based on defined
“release” cadencies /
Program Increments
Additional Services
(Extensions, Changes)
Total price for N
hours
X% By mutually agreed Work
Orders and based on Work
Order acceptance fact
Support Services Total prices for M
months
Y% Fixed monthly “insurance”
fee, starting after first GO
LIVE release.
In case first GO LIVE happens
before Implementation is
finished, smaller monthly fee
should be applied

36. Technical Specification / Statement of Work1
• Procurement Goals and Strategic Priorities
• Business processes and models
• User Personas/Rroles, amounts
• Key Data Objects/Entities and Sizing (low-high, peaks, flow)
• Existing related IT assets description
• Functional requirements
• Non-functional requirements
• Compliance with existing IT policies and investments
• Performance, security, resilience etc
• Integration requirements
• Data Analytics requirements
• Deployment architecture requirements
• Requirements for Services
• Implementation Approach requirements, Phases and intermediate/final results
• Extensions and Change Services
• Support Services

37. TS / SoW2: Try to stay on Business process level
▪ Do not overdo with Technical Requirements or
Solution Architecture
▪ Unlock Vendors’ creativity and evaluation
alternatives
▪ Evaluate best Architecture proposals by Economic
Efficiency points

38. TS / SoW2: Describe what you most want to
miss
▪ Existing related or modernized IT assets description, incl.
legacy systems, to-be-replaced systems
▪ All what is needed for migration and/or integration
▪ Future Deployment Architecture and IT Operations
▪ Incl. where will Solution be deployed, do you have infrastructure
already, who will be responsible for IT Operations etc.
▪ Data Analytics / Business Intelligence requirements
▪ Existing or desired reports templates
▪ Logical dimensions and metrics
▪ Integration requirements:
▪ All integrated systems, their owners and state
▪ in / out flows, sizing, sync/async mode
▪ To-be systems’ integration capabilities (protocols, formats, APIs)
▪ Mention integrated systems in Business processes

39. Implementation Phases
Phase Duration Payment Results Acceptance for
Operations (Start of Support
Services)
Initiation 1-2 weeks % of Fixed Price -
Feature Validation / Detail
Analysis
2 weeks– 1
month
- -
Implementation 1:
Processes ABC
2 - 3 mons. % of Fixed Price Trial Operations
Implementation 2:
Processes DEF
2 - 3 mons. % of Fixed Price
[+ Extensions and Change
Services Work Orders]
Trial Operations
Implementation 3:
Processes GHI
2 - 3 mons. % of Fixed Price
[+ Work Orders]
[+ Support Fee]
Go Live / Production
Operations
... ... ... ...
Final Implementation &
Stabilization
1 - 2 mons. % of Fixed Price
[+ Work Orders]
[+ Support Fee]
Go Live / Production
Operations
Closure and Switch to
Support
1 – 2 weeks. % of Fixed Price
[+ Work Orders]
[+ Support Fee]
Go Live / Production
Operations

40. Implementation Phase are not only about Implementation
▪ Deployment in different environments (Testing, Training,
Production),
▪ Business/User Acceptance testing
▪ Technical Acceptance for IT Operations
▪ Support and Extensions/Change Services needs
evaluation
▪ Security Testing or other kind of Audit
▪ Other Project control activities

42. RFP Task for Vendor
▪ Proposed Plan with Phases, Cadences, Streams
▪ Proposed Delivery approach methodology, governance
adjustments
▪ Proposed Support procedures
▪ Proposed Solution Technological Architecture
▪ Proposed Solution minimal requirements for Deployment
Environments (“IT Shopping List”, “Bill of Material”)
▪ Total Cost of Ownership projection 3-5 years
 Vendor Support Services (based on proposed Support Services fee)
 Software licensing models and prices (with manufacturer’s proof)
 Deployment and IT infrastructure expansion costs
(distributors/manufacturer’s proof)
 New skills acquiring costs for Client IT Operations
▪ Technical Specification / Statement of Work requirements
compliance statement

43. Support & Extensions Services Procurement
43

44. Palaikymas
Support &
Extensions
Extensions
Work Orders
Support
Implementation
phase
Production
phase
Implementation
phase
Production
phase

45. Support
▪ Define in Procurement TS / SoW:
▪ Regular maintenance work
▪ Incident classification
▪ Reaction and resolution time constraints
▪ Services provision schedule, communication channels
▪ Access to supported environments
▪ Hotfixes/Changes delivery policy, incl. acceptance and documentation
renewal
▪ Potential penalties for SLA violation (penalties can be deducted from
monthly fee)
▪ Service Level Agreement reporting and monitoring
▪ Timeline and phases of Support Services
▪ Separate Support Services during Project Implementation Phases and post-
Implementation
▪ Recommended to apply fixed monthly fee, covering
▪ Regular maintenance work
▪ Defects resolution and SLA assurance
▪ Recommended penalties to be applied to monthly fee
▪ In case of SLA violations

46. Extensions Services
▪ Define in Procurement TS / SoW:
▪ Work Orders life cycle and rules
▪ Work Orders categories
▪ Work Order provision authorities, formats
▪ Work Order preliminary analysis, evaluation and confirmation
rules
▪ Work Order implementation rules, control points, intermediate
results supply and acceptance (Agile !)
▪ Work Order final delivery rules and acceptance)
▪ Separate Services during Project Implementation Phases and post-
Implementation
▪ Recommended to pay by Work Order acceptance fact within +/-
X% delta of the initial evaluation
▪ Recommended to apply penalties for Work Order evaluation or
implementation delays
▪ Post-Work Order defects should be resolved in terms of Support
Services

47. Wrap Up
Q & A