This presentation describes systematic, repeatable and co-ordinated approach to agile solution architecture and design. It is intended to describe a set of practical steps and activities embedded within a framework to allow an agile method to be adopted and used for solution design and delivery. This approach ensures consistency in the assessment of solution design options and in subsequent solution design and solution delivery activities. This process leads to the rapid design and delivery of realistic and achievable solutions that meet real solution consumer needs. The approach provides for effective solution decision-making. It generates options and results quickly and consistently. Implementing a framework such as this provides for the creation of a knowledgebase of previous solution design and delivery exercises that leads to an accumulated body of knowledge within the organisation.
Integrated Project and Solution Delivery And Business Engagement ModelAlan McSweeney
This document outlines an integrated project delivery and business engagement model. It discusses how projects have both IT and business dimensions and require an integrated approach across stages and functions. The model includes components like stages, artifacts, activities and gates. It presents the model's extended dimensions and integrated process with business engagement. The initial focus areas are business engagement and solution definition to establish a solid foundation before implementation. Key aspects include defining artifacts across stages, review gates, and taking an artifact-based approach to provide project status. Addressing business analysis and solution design weaknesses is seen as key to avoiding common causes of project failures.
Digital Transformation And Solution ArchitectureAlan McSweeney
Digital strategy is a statement about the organisation’s digital positioning, competitors and customer and collaborator needs and behaviour to achieve a direction for innovation, communication, transaction and promotion. Digital strategy needs to be defined in the same framework structure as the proposed digital architecture platform.
Achieving the target digital organisation means deploying solutions that enable the digital architecture. Solution architecture needs to design solutions that fit into the target digital architecture framework. This requires:
• Solution architecture team operating in an integrated manner designing solutions to a set of common standards and that run on the platform
• Solution architecture team leadership ensuring solutions conform to the common standards
• Solution architecture technical leadership to develop and maintain common solution design standards
• Solution architecture updates the digital reference architecture based on solution design experience
Digital solution design requires greater discipline to create an integrated set solutions that operate within the rigour of the digital architecture framework. The solution architecture function must interact with other IT architecture disciplines to ensure the set of solutions that implement the digital framework operate together. This requires greater solution architecture team leadership. This needs to be supplemented and supported by a well-defined set of digital solution design standards.
This follows-on from the previous presentation: Digital Transformation And Enterprise Architecture
https://www.slideshare.net/alanmcsweeney/digital-transformation-and-enterprise-architecture.
The Need For Effective Early Engagement In Solution Architecture And DesignAlan McSweeney
Early engagement in the solution delivery process needs to occur before any solution delivery project is initiated. Its objective is to understand the scope, requirements, objectives, approach, options and to get a high-level understanding of the likely resources, timescale and cost required before starting the project
Fundamentally, early engagement is about managing risk:
• Risk of doing the wrong thing
• Risk of doing it in the wrong way
• Risk of underestimating complexity and scope of work
• Risk of higher than expected cost of operation and maintenance
• Risk of underestimating organisation change impact and organisation resistance
• Risk through uncertainty
Early engagement is not a requirements gathering exercise. Traditional requirements gathering requires substantial initial effort, resources and cost and for the business to commit without doubts, uncertainties and ambiguities being known.
Early Engagement involves taking a not necessarily well-defined request from the business and creating an unambiguous set of solution options including their delivery and operation quickly and accurately
This paper describes an approach to early engagement in the solution definition process.
Incorporating A DesignOps Approach Into Solution ArchitectureAlan McSweeney
Solution architecture and design is concerned with designing new (IT) solutions to resolve problems or address opportunities . In order to solve a problem, you need sufficient information to understand the problem. If you do not understand the scope of the required solution you cannot understand the risks associated with the implementation approach.
Getting the solution wrong can be very expensive. The DesignOps approach is a unified end-to-end view of solution delivery from initial concept to steady state operations. It is a design-to-operations approach identifying all the solution design elements needed to ensure the delivery of a complete solution.
Solution architecture and design teams are becoming larger so more co-ordination, standardisation and management is required. The increasing focus on digital transformation increases the need for improved design as business applications are exposed outside the organisation. Solution complexity is increasing. The aim of the DesignOps approach is to improve solution design outcomes.
Structured Approach to Solution ArchitectureAlan McSweeney
The role of solution architecture is to identify answer to a business problem and set of solution options and their components. There will be many potential solutions to a problem with varying degrees of suitability to the underlying business need. Solution options are derived from a combination of Solution Architecture Dimensions/Views which describe characteristics, features, qualities, requirements and Solution Design Factors, Limitations And Boundaries which delineate limitations. Use of structured approach can assist with solution design to create consistency. The TOGAF approach to enterprise architecture can be adapted to perform some of the analysis and design for elements of Solution Architecture Dimensions/Views.
This document outlines RJS Software's solution design and business analysis process. It discusses conducting a solution design to comprehensively plan IT projects by analyzing business processes, identifying improvement areas, and establishing a project plan. It also describes how a business analysis can help optimize current software and systems. The six-step process involves: 1) understanding the problem, 2) identifying goals and requirements, 3) mapping the current process, 4) designing the solution, 5) calculating ROI, and 6) documenting and presenting the solution design. Conducting this analysis helps ensure stakeholders agree on objectives, requirements are defined, and surprises are avoided during implementation.
This presentation describes systematic, repeatable and co-ordinated approach to agile solution architecture and design. It is intended to describe a set of practical steps and activities embedded within a framework to allow an agile method to be adopted and used for solution design and delivery. This approach ensures consistency in the assessment of solution design options and in subsequent solution design and solution delivery activities. This process leads to the rapid design and delivery of realistic and achievable solutions that meet real solution consumer needs. The approach provides for effective solution decision-making. It generates options and results quickly and consistently. Implementing a framework such as this provides for the creation of a knowledgebase of previous solution design and delivery exercises that leads to an accumulated body of knowledge within the organisation.
Integrated Project and Solution Delivery And Business Engagement ModelAlan McSweeney
This document outlines an integrated project delivery and business engagement model. It discusses how projects have both IT and business dimensions and require an integrated approach across stages and functions. The model includes components like stages, artifacts, activities and gates. It presents the model's extended dimensions and integrated process with business engagement. The initial focus areas are business engagement and solution definition to establish a solid foundation before implementation. Key aspects include defining artifacts across stages, review gates, and taking an artifact-based approach to provide project status. Addressing business analysis and solution design weaknesses is seen as key to avoiding common causes of project failures.
Digital Transformation And Solution ArchitectureAlan McSweeney
Digital strategy is a statement about the organisation’s digital positioning, competitors and customer and collaborator needs and behaviour to achieve a direction for innovation, communication, transaction and promotion. Digital strategy needs to be defined in the same framework structure as the proposed digital architecture platform.
Achieving the target digital organisation means deploying solutions that enable the digital architecture. Solution architecture needs to design solutions that fit into the target digital architecture framework. This requires:
• Solution architecture team operating in an integrated manner designing solutions to a set of common standards and that run on the platform
• Solution architecture team leadership ensuring solutions conform to the common standards
• Solution architecture technical leadership to develop and maintain common solution design standards
• Solution architecture updates the digital reference architecture based on solution design experience
Digital solution design requires greater discipline to create an integrated set solutions that operate within the rigour of the digital architecture framework. The solution architecture function must interact with other IT architecture disciplines to ensure the set of solutions that implement the digital framework operate together. This requires greater solution architecture team leadership. This needs to be supplemented and supported by a well-defined set of digital solution design standards.
This follows-on from the previous presentation: Digital Transformation And Enterprise Architecture
https://www.slideshare.net/alanmcsweeney/digital-transformation-and-enterprise-architecture.
The Need For Effective Early Engagement In Solution Architecture And DesignAlan McSweeney
Early engagement in the solution delivery process needs to occur before any solution delivery project is initiated. Its objective is to understand the scope, requirements, objectives, approach, options and to get a high-level understanding of the likely resources, timescale and cost required before starting the project
Fundamentally, early engagement is about managing risk:
• Risk of doing the wrong thing
• Risk of doing it in the wrong way
• Risk of underestimating complexity and scope of work
• Risk of higher than expected cost of operation and maintenance
• Risk of underestimating organisation change impact and organisation resistance
• Risk through uncertainty
Early engagement is not a requirements gathering exercise. Traditional requirements gathering requires substantial initial effort, resources and cost and for the business to commit without doubts, uncertainties and ambiguities being known.
Early Engagement involves taking a not necessarily well-defined request from the business and creating an unambiguous set of solution options including their delivery and operation quickly and accurately
This paper describes an approach to early engagement in the solution definition process.
Incorporating A DesignOps Approach Into Solution ArchitectureAlan McSweeney
Solution architecture and design is concerned with designing new (IT) solutions to resolve problems or address opportunities . In order to solve a problem, you need sufficient information to understand the problem. If you do not understand the scope of the required solution you cannot understand the risks associated with the implementation approach.
Getting the solution wrong can be very expensive. The DesignOps approach is a unified end-to-end view of solution delivery from initial concept to steady state operations. It is a design-to-operations approach identifying all the solution design elements needed to ensure the delivery of a complete solution.
Solution architecture and design teams are becoming larger so more co-ordination, standardisation and management is required. The increasing focus on digital transformation increases the need for improved design as business applications are exposed outside the organisation. Solution complexity is increasing. The aim of the DesignOps approach is to improve solution design outcomes.
Structured Approach to Solution ArchitectureAlan McSweeney
The role of solution architecture is to identify answer to a business problem and set of solution options and their components. There will be many potential solutions to a problem with varying degrees of suitability to the underlying business need. Solution options are derived from a combination of Solution Architecture Dimensions/Views which describe characteristics, features, qualities, requirements and Solution Design Factors, Limitations And Boundaries which delineate limitations. Use of structured approach can assist with solution design to create consistency. The TOGAF approach to enterprise architecture can be adapted to perform some of the analysis and design for elements of Solution Architecture Dimensions/Views.
This document outlines RJS Software's solution design and business analysis process. It discusses conducting a solution design to comprehensively plan IT projects by analyzing business processes, identifying improvement areas, and establishing a project plan. It also describes how a business analysis can help optimize current software and systems. The six-step process involves: 1) understanding the problem, 2) identifying goals and requirements, 3) mapping the current process, 4) designing the solution, 5) calculating ROI, and 6) documenting and presenting the solution design. Conducting this analysis helps ensure stakeholders agree on objectives, requirements are defined, and surprises are avoided during implementation.
This document provides an overview of Phase E in the TOGAF Architecture Development Method. Phase E focuses on opportunities and solutions. It identifies parameters for change, major phases, work packages/projects to address gaps identified in previous phases, and new business opportunities. The key outputs are an implementation and migration strategy, transition architectures, and project charters. Phase E takes inputs from previous phases and the architecture repository. It involves consolidating gaps and dependencies, reviewing requirements, and formulating an implementation approach through activities like identifying work packages and transition architectures.
IT4IT and DevOps Tools Landscape (2020).Rob Akershoek
Complete overview of the IT management tooling landscape 2020. Key market players / vendors in the IT4IT and DevOps tooling ecosystem. Automate and streamline your end-to-end DevOps tool chain.
The document defines the roles of solution architect, enterprise architect, and technical architect. It states that a solution architect is responsible for converting business requirements into an architectural design and blueprint for a solution. The solution architect needs input from stakeholders and provides outputs like application, database, infrastructure, and implementation designs. It also outlines the differences between the roles, noting that an enterprise architect focuses on enterprise-wide strategy, a solution architect focuses on delivering a specific solution, and a technical architect specializes in particular technologies within a solution. Finally, it shows how a solution architect contributes throughout the total life cycle of a solution.
This document discusses applying agile principles and practices to TOGAF architecture projects. It outlines the goals of mapping agile approaches to the TOGAF Architecture Development Method (ADM). Key aspects covered include mapping agile values, principles, practices and roles to the TOGAF ADM phases. Specific techniques like story cards, planning boards and retrospectives are described. The workshop aims to provide guidance on an agile enterprise architecture approach and get feedback to inform future standards.
Solution Architecture And User And Customer ExperienceAlan McSweeney
User experience is the sum of experiences across all dimensions of all solutions and the user’s interaction with it including its functionality and quality attributes. It is the sum of all interactions with the solution and the results the solution provides. Solution usability is much, much more than a user interface
Users experience the complete operational solution across its entire scope and experience its functional and quality properties. The solution architect must be aware of the usability of designed solutions. Usability is not an afterthought: it must be embedded in the overall solution design from the start
The dimensions of solution usability are:
• Components of overall solution
• Functional components of solution
• Quality properties
The complete solution Is always much more than just a bunch of software. Implementing the end-to-end components of the solution positively impacts on solution usability and utility. Without the complete view there will be gaps in the usability of the solution.
Enterprise architecture needs to provide leadership in defining and implementing approach to measuring solution usability. Enterprise architecture needs to define standards and associated frameworks for
• Overall experience
• Solution usability
Each of these needs to include measurement and analysis framework. Solution architecture needs to incorporate these standards into solution designs. Individual solutions incorporate usability standards
Overall set of solutions comprise the experience.
Introduction to Business Architecture - Part 2Alan McSweeney
The first part is available at: https://www.slideshare.net/alanmcsweeney/introduction-to-business-architecture-part-1.
This material describes conducting a specific business architecture engagement. The engagement process is generic and needs to be adapted to each specific application and use. The engagement is a formal process for gathering information and creating a new business function model based on an analysis of that information.
The objective is to create a realistic and achievable target business architecture to achieve the desired business change.
Business architecture is a structured approach to analysing the operation of an existing business function or entire organisation with a view to improving its operations or developing a new business function, with a strong focus on processes and technology. Business architecture is not about business requirements – it is about business solutions and organisation changes to deliver business objectives.
IT Architecture’s Role In Solving Technical Debt.pdfAlan McSweeney
Technical debt is an overworked term without an effective and common agreed understanding of what exactly it is, what causes it, what are its consequences, how to assess it and what to do about it.
Technical debt is the sum of additional direct and indirect implementation and operational costs incurred and risks and vulnerabilities created because of sub-optimal solution design and delivery decisions.
Technical debt is the sum of all the consequences of all the circumventions, budget reduction, time pressure, lack of knowledge, manual workarounds, short-cuts, avoidance, poor design and delivery quality and decisions to remove elements from solution scope and failure to provide foundational and backbone solution infrastructure.
Technical debt leads to a negative feedback cycle with short solution lifespan, earlier solution replacement and short-term tactical remedial actions.
All the disciplines within IT architecture have a role to play in promoting an understanding of and in the identification of how to resolve technical debt. IT architecture can provide the leadership in both remediating existing technical debt and preventing future debt.
Failing to take a complete view of the technical debt within the organisation means problems and risks remained unrecognised and unaddressed. The real scope of the problem is substantially underestimated. Technical debt is always much more than poorly written software.
Technical debt can introduce security risks and vulnerabilities into the organisation’s solution landscape. Failure to address technical debt leaves exploitable security risks and vulnerabilities in place.
Shadow IT or ghost IT is a largely unrecognised source of technical debt including security risks and vulnerabilities. Shadow IT is the consequence of a set of reactions by business functions to an actual or perceived inability or unwillingness of the IT function to respond to business needs for IT solutions. Shadow IT is frequently needed to make up for gaps in core business solutions, supplementing incomplete solutions and providing omitted functionality.
Enterprise Business Analysis Capability - Strategic Asset for Business Alignm...Alan McSweeney
This document discusses the role and importance of enterprise business analysis as a strategic capability for achieving business and IT alignment and driving innovation. Some key points:
- Enterprise business analysis can help translate business strategy into objectives, ensure IT solution delivery is aligned to strategy/objectives, and contribute to solution delivery governance.
- It involves analyzing business requirements and processes associated with changes, defining business solutions to deliver requirements/processes, and rebuilding the conversation between business and IT.
- Multiple levels of business analysis (enterprise, functional, IT) are needed to effectively prevent fragmentation across the organization and deliver solutions in response to business needs from strategy through delivery.
- Without this capability, IT risks delivering solutions that are not
This document discusses IT architecture and architects. It begins by noting that the main purpose of architecture is to deal with the complexity of information systems. It then provides examples of how systems have become more complex over time. The document discusses different types of architectures, including software architecture, solution architecture, and enterprise architecture. It defines the roles of software architects, solution architects, and enterprise architects. It also discusses competencies for architects and typical architecture deliverables. The document aims to provide clarity on different architecture roles and contexts.
BIM process adoption for integrated design and constuctionReshma Philip
The document provides an overview of a BIM consultant's biography and experience, as well as a presentation on BIM and the design process. The consultant has over 20 years of experience implementing BIM and digital design systems. The presentation covers key topics like what BIM is, how it compares to traditional design processes, important terminology, software considerations, and examples of BIM implementation on government projects in KSA.
This document discusses the relationship between enterprise architecture (EA) and project and portfolio management (PPM). It argues that EA and PPM have different but complementary perspectives in helping an organization translate strategy into realized value through portfolios and projects. The document provides examples of how EA and PPM can collaborate more effectively by having EA guide the enterprise towards its target state while PPM drives the enterprise strategically forward. It also provides a sample collaboration model where EA and the project manager work together on project architecture.
How to Articulate the Value of Enterprise Architecturecccamericas
Ever struggled with the question, What is the Value of Enterprise Architecture? In this facilitated conversation, Michael Fulton will share his perspective on Enterprise Architecture and the value it provides to the CIO, to IT, and to the business.
Come ready to engage, because in the conversation we will discuss:
•The EA 7-year itch
•Several External Perspectives on EA Value
•The CC&C perspective on a simplified approach to EA Value
•Ensuring your perspective on EA Value is relevant for your stakeholders
At the end of this conversation, you should walk away with:
•A new perspective on the value of EA
•Tips and tricks on how to articulate and quantify EA Value for your key stakeholders.
Business Value Measurements and the Solution Design FrameworkLeo Barella
The presentation covers a process and artifacts to establish better communication between business and IT and improve the quality and consistency of solutions. It also includes a tool to measure business value of the solutions that are being proposed and allows the business audience to make educated choices based on overall IT Business impact.
This document provides an outline for a course on project scheduling and controls. The 3-day course will introduce key concepts in project scheduling including activity sequencing, developing project schedules, schedule updates and change control, and earned value management. Participants will learn to create effective project schedules, implement controls, evaluate metrics and prepare reports. The course aims to prepare attendees to sit for the PMI Scheduling Professional or AACE Project Scheduling Professional certifications. It will use exercises, workshops, and a case study to demonstrate scheduling skills across different project types.
After unnecessary complexity has been reduced from the problem being solved, the scope of the solution to the problem is governed by the complexity of the problem. Complexity is needed to handle and process complexity. Systems acquire or accrete unnecessary complexity over time as originally unforeseen exceptions or changes are incorporated. It may be possible to reduce complexity by collapsing/compressing/combining/consolidating elements and by removing non-value-adding, duplicate, redundant activities. When unnecessary or accreted complexity in the problem being solved has been removed, you are left with necessary complexity that must be incorporated into the solution. Simple problems do not have complex solutions. Complex problems do not have simple solutions. The complexity factor of the proposed solution must match the complexity factor of the problem being resolved. Many system implementation and operational failures arise because of failure to understand and address the core complexity of the problem.
#Fundamental understanding of agile - By SN PanigrahiSN Panigrahi, PMP
#Fundamental understanding of agile - By SN Panigrahi,
Essenpee Business Solutions,
What is Agile Methodology,
Project Life Cycle, Predictive Life Cycle, Iterative Life Cycle,
Incremental Life Cycle, Adaptive Life Cycle, Agile Life Cycle,
Waterfall Method, Sprint, Product Backlog, Sprint Planning, Sprint Backlog, User Stories, Daily Scrum, Sprint Review, Sprint Retrospective, Product Owner, Sprint Team, Scrum Master, Agile Scope, Agile Schedule, Burnt down Chart, Kanban, Lean, Ceremonies
ANIn Coimbatore Jan 2024 |Combining Agile Mindset and Design Thinking by Shan...AgileNetwork
1. The document discusses combining an agile mindset, design thinking, and the lean startup cycle to solve problems in an innovative way.
2. It provides an example of a manufacturing client who wanted to proactively detect and fix faults to improve customer satisfaction.
3. Using design thinking to understand the problem, an agile approach to build minimal viable products iteratively, and lean startup methodology of testing assumptions, the teams built 24 MVPs over 9 months which led to 6 successful production solutions that increased uptime and customer satisfaction.
This document provides an overview of Phase E in the TOGAF Architecture Development Method. Phase E focuses on opportunities and solutions. It identifies parameters for change, major phases, work packages/projects to address gaps identified in previous phases, and new business opportunities. The key outputs are an implementation and migration strategy, transition architectures, and project charters. Phase E takes inputs from previous phases and the architecture repository. It involves consolidating gaps and dependencies, reviewing requirements, and formulating an implementation approach through activities like identifying work packages and transition architectures.
IT4IT and DevOps Tools Landscape (2020).Rob Akershoek
Complete overview of the IT management tooling landscape 2020. Key market players / vendors in the IT4IT and DevOps tooling ecosystem. Automate and streamline your end-to-end DevOps tool chain.
The document defines the roles of solution architect, enterprise architect, and technical architect. It states that a solution architect is responsible for converting business requirements into an architectural design and blueprint for a solution. The solution architect needs input from stakeholders and provides outputs like application, database, infrastructure, and implementation designs. It also outlines the differences between the roles, noting that an enterprise architect focuses on enterprise-wide strategy, a solution architect focuses on delivering a specific solution, and a technical architect specializes in particular technologies within a solution. Finally, it shows how a solution architect contributes throughout the total life cycle of a solution.
This document discusses applying agile principles and practices to TOGAF architecture projects. It outlines the goals of mapping agile approaches to the TOGAF Architecture Development Method (ADM). Key aspects covered include mapping agile values, principles, practices and roles to the TOGAF ADM phases. Specific techniques like story cards, planning boards and retrospectives are described. The workshop aims to provide guidance on an agile enterprise architecture approach and get feedback to inform future standards.
Solution Architecture And User And Customer ExperienceAlan McSweeney
User experience is the sum of experiences across all dimensions of all solutions and the user’s interaction with it including its functionality and quality attributes. It is the sum of all interactions with the solution and the results the solution provides. Solution usability is much, much more than a user interface
Users experience the complete operational solution across its entire scope and experience its functional and quality properties. The solution architect must be aware of the usability of designed solutions. Usability is not an afterthought: it must be embedded in the overall solution design from the start
The dimensions of solution usability are:
• Components of overall solution
• Functional components of solution
• Quality properties
The complete solution Is always much more than just a bunch of software. Implementing the end-to-end components of the solution positively impacts on solution usability and utility. Without the complete view there will be gaps in the usability of the solution.
Enterprise architecture needs to provide leadership in defining and implementing approach to measuring solution usability. Enterprise architecture needs to define standards and associated frameworks for
• Overall experience
• Solution usability
Each of these needs to include measurement and analysis framework. Solution architecture needs to incorporate these standards into solution designs. Individual solutions incorporate usability standards
Overall set of solutions comprise the experience.
Introduction to Business Architecture - Part 2Alan McSweeney
The first part is available at: https://www.slideshare.net/alanmcsweeney/introduction-to-business-architecture-part-1.
This material describes conducting a specific business architecture engagement. The engagement process is generic and needs to be adapted to each specific application and use. The engagement is a formal process for gathering information and creating a new business function model based on an analysis of that information.
The objective is to create a realistic and achievable target business architecture to achieve the desired business change.
Business architecture is a structured approach to analysing the operation of an existing business function or entire organisation with a view to improving its operations or developing a new business function, with a strong focus on processes and technology. Business architecture is not about business requirements – it is about business solutions and organisation changes to deliver business objectives.
IT Architecture’s Role In Solving Technical Debt.pdfAlan McSweeney
Technical debt is an overworked term without an effective and common agreed understanding of what exactly it is, what causes it, what are its consequences, how to assess it and what to do about it.
Technical debt is the sum of additional direct and indirect implementation and operational costs incurred and risks and vulnerabilities created because of sub-optimal solution design and delivery decisions.
Technical debt is the sum of all the consequences of all the circumventions, budget reduction, time pressure, lack of knowledge, manual workarounds, short-cuts, avoidance, poor design and delivery quality and decisions to remove elements from solution scope and failure to provide foundational and backbone solution infrastructure.
Technical debt leads to a negative feedback cycle with short solution lifespan, earlier solution replacement and short-term tactical remedial actions.
All the disciplines within IT architecture have a role to play in promoting an understanding of and in the identification of how to resolve technical debt. IT architecture can provide the leadership in both remediating existing technical debt and preventing future debt.
Failing to take a complete view of the technical debt within the organisation means problems and risks remained unrecognised and unaddressed. The real scope of the problem is substantially underestimated. Technical debt is always much more than poorly written software.
Technical debt can introduce security risks and vulnerabilities into the organisation’s solution landscape. Failure to address technical debt leaves exploitable security risks and vulnerabilities in place.
Shadow IT or ghost IT is a largely unrecognised source of technical debt including security risks and vulnerabilities. Shadow IT is the consequence of a set of reactions by business functions to an actual or perceived inability or unwillingness of the IT function to respond to business needs for IT solutions. Shadow IT is frequently needed to make up for gaps in core business solutions, supplementing incomplete solutions and providing omitted functionality.
Enterprise Business Analysis Capability - Strategic Asset for Business Alignm...Alan McSweeney
This document discusses the role and importance of enterprise business analysis as a strategic capability for achieving business and IT alignment and driving innovation. Some key points:
- Enterprise business analysis can help translate business strategy into objectives, ensure IT solution delivery is aligned to strategy/objectives, and contribute to solution delivery governance.
- It involves analyzing business requirements and processes associated with changes, defining business solutions to deliver requirements/processes, and rebuilding the conversation between business and IT.
- Multiple levels of business analysis (enterprise, functional, IT) are needed to effectively prevent fragmentation across the organization and deliver solutions in response to business needs from strategy through delivery.
- Without this capability, IT risks delivering solutions that are not
This document discusses IT architecture and architects. It begins by noting that the main purpose of architecture is to deal with the complexity of information systems. It then provides examples of how systems have become more complex over time. The document discusses different types of architectures, including software architecture, solution architecture, and enterprise architecture. It defines the roles of software architects, solution architects, and enterprise architects. It also discusses competencies for architects and typical architecture deliverables. The document aims to provide clarity on different architecture roles and contexts.
BIM process adoption for integrated design and constuctionReshma Philip
The document provides an overview of a BIM consultant's biography and experience, as well as a presentation on BIM and the design process. The consultant has over 20 years of experience implementing BIM and digital design systems. The presentation covers key topics like what BIM is, how it compares to traditional design processes, important terminology, software considerations, and examples of BIM implementation on government projects in KSA.
This document discusses the relationship between enterprise architecture (EA) and project and portfolio management (PPM). It argues that EA and PPM have different but complementary perspectives in helping an organization translate strategy into realized value through portfolios and projects. The document provides examples of how EA and PPM can collaborate more effectively by having EA guide the enterprise towards its target state while PPM drives the enterprise strategically forward. It also provides a sample collaboration model where EA and the project manager work together on project architecture.
How to Articulate the Value of Enterprise Architecturecccamericas
Ever struggled with the question, What is the Value of Enterprise Architecture? In this facilitated conversation, Michael Fulton will share his perspective on Enterprise Architecture and the value it provides to the CIO, to IT, and to the business.
Come ready to engage, because in the conversation we will discuss:
•The EA 7-year itch
•Several External Perspectives on EA Value
•The CC&C perspective on a simplified approach to EA Value
•Ensuring your perspective on EA Value is relevant for your stakeholders
At the end of this conversation, you should walk away with:
•A new perspective on the value of EA
•Tips and tricks on how to articulate and quantify EA Value for your key stakeholders.
Business Value Measurements and the Solution Design FrameworkLeo Barella
The presentation covers a process and artifacts to establish better communication between business and IT and improve the quality and consistency of solutions. It also includes a tool to measure business value of the solutions that are being proposed and allows the business audience to make educated choices based on overall IT Business impact.
This document provides an outline for a course on project scheduling and controls. The 3-day course will introduce key concepts in project scheduling including activity sequencing, developing project schedules, schedule updates and change control, and earned value management. Participants will learn to create effective project schedules, implement controls, evaluate metrics and prepare reports. The course aims to prepare attendees to sit for the PMI Scheduling Professional or AACE Project Scheduling Professional certifications. It will use exercises, workshops, and a case study to demonstrate scheduling skills across different project types.
After unnecessary complexity has been reduced from the problem being solved, the scope of the solution to the problem is governed by the complexity of the problem. Complexity is needed to handle and process complexity. Systems acquire or accrete unnecessary complexity over time as originally unforeseen exceptions or changes are incorporated. It may be possible to reduce complexity by collapsing/compressing/combining/consolidating elements and by removing non-value-adding, duplicate, redundant activities. When unnecessary or accreted complexity in the problem being solved has been removed, you are left with necessary complexity that must be incorporated into the solution. Simple problems do not have complex solutions. Complex problems do not have simple solutions. The complexity factor of the proposed solution must match the complexity factor of the problem being resolved. Many system implementation and operational failures arise because of failure to understand and address the core complexity of the problem.
#Fundamental understanding of agile - By SN PanigrahiSN Panigrahi, PMP
#Fundamental understanding of agile - By SN Panigrahi,
Essenpee Business Solutions,
What is Agile Methodology,
Project Life Cycle, Predictive Life Cycle, Iterative Life Cycle,
Incremental Life Cycle, Adaptive Life Cycle, Agile Life Cycle,
Waterfall Method, Sprint, Product Backlog, Sprint Planning, Sprint Backlog, User Stories, Daily Scrum, Sprint Review, Sprint Retrospective, Product Owner, Sprint Team, Scrum Master, Agile Scope, Agile Schedule, Burnt down Chart, Kanban, Lean, Ceremonies
ANIn Coimbatore Jan 2024 |Combining Agile Mindset and Design Thinking by Shan...AgileNetwork
1. The document discusses combining an agile mindset, design thinking, and the lean startup cycle to solve problems in an innovative way.
2. It provides an example of a manufacturing client who wanted to proactively detect and fix faults to improve customer satisfaction.
3. Using design thinking to understand the problem, an agile approach to build minimal viable products iteratively, and lean startup methodology of testing assumptions, the teams built 24 MVPs over 9 months which led to 6 successful production solutions that increased uptime and customer satisfaction.
#Agile Methodology - Fundamental Principles & Basics - By SN PanigrahiSN Panigrahi, PMP
#Agile Methodology - Fundamental Principles & Basics - By SN Panigrahi,
Essenpee Business Solutions,
What is Agile Methodology,
Project Life Cycle, Predictive Life Cycle, Iterative Life Cycle,
Incremental Life Cycle, Adaptive Life Cycle, Agile Life Cycle,
Waterfall Method, Sprint, Product Backlog, Sprint Planning, Sprint Backlog, User Stories, Daily Scrum, Sprint Review, Sprint Retrospective, Product Owner, Sprint Team, Scrum Master, Agile Scope, Agile Schedule, Burnt down Chart, Kanban, Lean, Ceremonies
The document provides an overview of Agile Project Management (APM) according to the DSDM Atern framework. It discusses the fundamentals and philosophy of APM, which focuses on delivering business value iteratively within fixed timeboxes. It also outlines the key principles, roles, products, and techniques used in APM such as prioritization with MoSCoW, timeboxing, requirements management, and facilitated workshops. Measurement focuses on business value, quality, effort and delivery speed.
Integrating agile into sdlc presentation pmi v2pmimkecomm
The document discusses integrating Agile practices into a company's software development lifecycle (SDLC). It outlines key Agile concepts like product backlogs, sprints, and daily standups. It provides examples of how sprints can align with the SDLC and what deliverables each sprint produces. Critical success factors and potential adoption risks are also covered.
This document provides an introduction to Agile methodology. It discusses how Agile addresses problems in software development like lack of predictability, transparency, and responsiveness to change. It then defines what Agile is from a mindset, values, and principles perspective. It also outlines some popular Agile flavors like Scrum, Kanban, SAFe, and XP. Finally, it walks through what a day or sprint looks like for a Scrum team, including roles, artifacts, meetings, and how stories are planned and tracked on a Scrum board. The overall document serves to introduce the core concepts and promise of Agile software development.
Expectations from IT Team
Project Methodology - Why it is as important as the Technology for your Product
Gaps in Recent Graduates
How to bridge these gaps?
HanoiScrum: Agile co-exists with WaterfallVu Hung Nguyen
This document discusses the differences between Agile and Waterfall project management methodologies and whether they can be combined for large projects. It provides definitions and core principles of Agile, including an emphasis on adaptability, frequent delivery of working software, and collaboration between business and development teams. The document also outlines the traditional phases of the Waterfall model. It considers whether Agile and Waterfall can be mixed, with Agile used for scoping and design and Waterfall for implementation. Experts' opinions are presented that argue a hybrid approach can work if the proper criteria are used to determine when each methodology is applied.
About Agile & PMI Agile Certified Practitioner (PMI-ACP) OverviewAleem Khan
A properly implemented Agile method increases the speed of development, aligns individual and organization objectives, creates a culture driven by performance, supports shareholder value creation, achieves stable and consistent communication of performance at all levels, and enhances individual development and quality of life.
Intro agile development methodology abhilash chandranAbhilash Chandran
This document provides an overview of agile software development and the Scrum framework. It discusses the limitations of traditional waterfall models and how agile methods address these through iterative development, collaboration between cross-functional teams, and frequent delivery of working software. The key aspects of Scrum are described, including roles like the Product Owner and Scrum Master, meetings like Sprint Planning and Review, and artifacts like the Product Backlog and Sprint Task Board. Agile principles emphasize individuals and interactions, working software, customer collaboration, and responding to change.
This document outlines four levels of an agile transformation journey and provides examples from PayPal's agile transformation. It begins by identifying common stumbling blocks in enterprise agile transformations. It then describes four levels of an agile transformation journey, with each level focusing on optimizing value delivery. Key aspects of PayPal's transformation are highlighted, including training over 2000 employees, forming over 300 agile teams, and increasing agility maturity from 18% to 76% within nine months by launching all teams onto agile at once. The document emphasizes that PayPal's transformation was successful by understanding pain points, emphasizing customer-driven innovation, and having self-managed cross-functional teams.
Applying both of waterfall and iterative developmentDeny Prasetia
This document discusses applying both waterfall and iterative development models to a project to develop a tool with minimum functionality in a short time for an operating lease business. It identifies challenges of growing business needs, lack of standardized processes and manual data entry. An assessment is proposed to clarify requirements and scope. Both waterfall and iterative development models are described. The document recommends using iterative development within the waterfall model to allow for prototyping, user feedback and flexibility to changes. Key success factors include collaborative teams, monitoring progress daily, and continual improvement between iterations. Lessons focus on managing risks, quality processes and using story point estimation.
The document provides an overview of agile and how it relates to business intelligence. It discusses why agile adoption is rising, with 70% of BI solutions failing to meet expectations due to lack of business involvement. It then covers the agile mindset of emphasizing business participation, empiricism, building working software frequently, small team sizes, and transparency. The rest of the document details components of a successful agile execution including defining processes, technology practices, organizational change management, and managing interfaces between agile and non-agile teams.
This document provides an overview of project management fundamentals from Invensis Learning. It defines key concepts such as projects, programs, portfolios and their differences. It describes various project life cycles including predictive, iterative, adaptive and hybrid models. It also outlines topics that will be covered in the course, including project management concepts, influences, roles, processes and certifications. The document is copyrighted material from Invensis Learning.
Lean SAP Delivery - introducing the conceptMendel Koerts
Lean SAP Delivery is about applying the principles of production logistics onto the operating model for IT. Agile development, optimising bottlenecks, and prioritization based on business value will lead to significant time-to-market reduction for SAP projects, changes, as well as fixes, against lower cost.
The introduction of a project management framework will provide a structured and managed approach for projects within your company.
With the right framework in place it will allow projects of all sizes and priority to be planned effectively. This ensures that at all times the cost of the project is managed while delivering quality and the right level of performance and control across project management.
Agile Project Management explained and examined from several angles. Agile Software Development delivers better results when it is managed in an agile way.
Similar to Solution design & procurement approach v1 (20)
How to Implement a Strategy: Transform Your Strategy with BSC Designer's Comp...Aleksey Savkin
The Strategy Implementation System offers a structured approach to translating stakeholder needs into actionable strategies using high-level and low-level scorecards. It involves stakeholder analysis, strategy decomposition, adoption of strategic frameworks like Balanced Scorecard or OKR, and alignment of goals, initiatives, and KPIs.
Key Components:
- Stakeholder Analysis
- Strategy Decomposition
- Adoption of Business Frameworks
- Goal Setting
- Initiatives and Action Plans
- KPIs and Performance Metrics
- Learning and Adaptation
- Alignment and Cascading of Scorecards
Benefits:
- Systematic strategy formulation and execution.
- Framework flexibility and automation.
- Enhanced alignment and strategic focus across the organization.
How are Lilac French Bulldogs Beauty Charming the World and Capturing Hearts....Lacey Max
“After being the most listed dog breed in the United States for 31
years in a row, the Labrador Retriever has dropped to second place
in the American Kennel Club's annual survey of the country's most
popular canines. The French Bulldog is the new top dog in the
United States as of 2022. The stylish puppy has ascended the
rankings in rapid time despite having health concerns and limited
color choices.”
HOW TO START UP A COMPANY A STEP-BY-STEP GUIDE.pdf46adnanshahzad
How to Start Up a Company: A Step-by-Step Guide Starting a company is an exciting adventure that combines creativity, strategy, and hard work. It can seem overwhelming at first, but with the right guidance, anyone can transform a great idea into a successful business. Let's dive into how to start up a company, from the initial spark of an idea to securing funding and launching your startup.
Introduction
Have you ever dreamed of turning your innovative idea into a thriving business? Starting a company involves numerous steps and decisions, but don't worry—we're here to help. Whether you're exploring how to start a startup company or wondering how to start up a small business, this guide will walk you through the process, step by step.
Anny Serafina Love - Letter of Recommendation by Kellen Harkins, MS.AnnySerafinaLove
This letter, written by Kellen Harkins, Course Director at Full Sail University, commends Anny Love's exemplary performance in the Video Sharing Platforms class. It highlights her dedication, willingness to challenge herself, and exceptional skills in production, editing, and marketing across various video platforms like YouTube, TikTok, and Instagram.
Zodiac Signs and Food Preferences_ What Your Sign Says About Your Tastemy Pandit
Know what your zodiac sign says about your taste in food! Explore how the 12 zodiac signs influence your culinary preferences with insights from MyPandit. Dive into astrology and flavors!
B2B payments are rapidly changing. Find out the 5 key questions you need to be asking yourself to be sure you are mastering B2B payments today. Learn more at www.BlueSnap.com.
Discover timeless style with the 2022 Vintage Roman Numerals Men's Ring. Crafted from premium stainless steel, this 6mm wide ring embodies elegance and durability. Perfect as a gift, it seamlessly blends classic Roman numeral detailing with modern sophistication, making it an ideal accessory for any occasion.
https://rb.gy/usj1a2
Digital Marketing with a Focus on Sustainabilitysssourabhsharma
Digital Marketing best practices including influencer marketing, content creators, and omnichannel marketing for Sustainable Brands at the Sustainable Cosmetics Summit 2024 in New York
The Genesis of BriansClub.cm Famous Dark WEb PlatformSabaaSudozai
BriansClub.cm, a famous platform on the dark web, has become one of the most infamous carding marketplaces, specializing in the sale of stolen credit card data.
Company Valuation webinar series - Tuesday, 4 June 2024FelixPerez547899
This session provided an update as to the latest valuation data in the UK and then delved into a discussion on the upcoming election and the impacts on valuation. We finished, as always with a Q&A
[To download this presentation, visit:
https://www.oeconsulting.com.sg/training-presentations]
This PowerPoint compilation offers a comprehensive overview of 20 leading innovation management frameworks and methodologies, selected for their broad applicability across various industries and organizational contexts. These frameworks are valuable resources for a wide range of users, including business professionals, educators, and consultants.
Each framework is presented with visually engaging diagrams and templates, ensuring the content is both informative and appealing. While this compilation is thorough, please note that the slides are intended as supplementary resources and may not be sufficient for standalone instructional purposes.
This compilation is ideal for anyone looking to enhance their understanding of innovation management and drive meaningful change within their organization. Whether you aim to improve product development processes, enhance customer experiences, or drive digital transformation, these frameworks offer valuable insights and tools to help you achieve your goals.
INCLUDED FRAMEWORKS/MODELS:
1. Stanford’s Design Thinking
2. IDEO’s Human-Centered Design
3. Strategyzer’s Business Model Innovation
4. Lean Startup Methodology
5. Agile Innovation Framework
6. Doblin’s Ten Types of Innovation
7. McKinsey’s Three Horizons of Growth
8. Customer Journey Map
9. Christensen’s Disruptive Innovation Theory
10. Blue Ocean Strategy
11. Strategyn’s Jobs-To-Be-Done (JTBD) Framework with Job Map
12. Design Sprint Framework
13. The Double Diamond
14. Lean Six Sigma DMAIC
15. TRIZ Problem-Solving Framework
16. Edward de Bono’s Six Thinking Hats
17. Stage-Gate Model
18. Toyota’s Six Steps of Kaizen
19. Microsoft’s Digital Transformation Framework
20. Design for Six Sigma (DFSS)
To download this presentation, visit:
https://www.oeconsulting.com.sg/training-presentations
Event Report - SAP Sapphire 2024 Orlando - lots of innovation and old challengesHolger Mueller
Holger Mueller of Constellation Research shares his key takeaways from SAP's Sapphire confernece, held in Orlando, June 3rd till 5th 2024, in the Orange Convention Center.
Best practices for project execution and deliveryCLIVE MINCHIN
A select set of project management best practices to keep your project on-track, on-cost and aligned to scope. Many firms have don't have the necessary skills, diligence, methods and oversight of their projects; this leads to slippage, higher costs and longer timeframes. Often firms have a history of projects that simply failed to move the needle. These best practices will help your firm avoid these pitfalls but they require fortitude to apply.
❼❷⓿❺❻❷❽❷❼❽ Dpboss Matka Result Satta Matka Guessing Satta Fix jodi Kalyan Final ank Satta Matka Dpbos Final ank Satta Matta Matka 143 Kalyan Matka Guessing Final Matka Final ank Today Matka 420 Satta Batta Satta 143 Kalyan Chart Main Bazar Chart vip Matka Guessing Dpboss 143 Guessing Kalyan night
At Techbox Square, in Singapore, we're not just creative web designers and developers, we're the driving force behind your brand identity. Contact us today.
Taurus Zodiac Sign: Unveiling the Traits, Dates, and Horoscope Insights of th...my Pandit
Dive into the steadfast world of the Taurus Zodiac Sign. Discover the grounded, stable, and logical nature of Taurus individuals, and explore their key personality traits, important dates, and horoscope insights. Learn how the determination and patience of the Taurus sign make them the rock-steady achievers and anchors of the zodiac.
The 10 Most Influential Leaders Guiding Corporate Evolution, 2024.pdfthesiliconleaders
In the recent edition, The 10 Most Influential Leaders Guiding Corporate Evolution, 2024, The Silicon Leaders magazine gladly features Dejan Štancer, President of the Global Chamber of Business Leaders (GCBL), along with other leaders.
4. OperateShapeConcept
Problem Definition &
Impact Assessment
Feasibility
Assessment
High
Level
Design
Deliver
Detailed
Design Build Test
Implement Production Feedback
• UK Government and its suppliers has, in the past, built a whole industry around this Life Cycle,
typified by Prince II Project Management Methodology.
• It is a lifecycle that is very commonly implemented – its attraction is that this delineation of phasing
permits “checkpoints” at which a meaningful review and re-alignment (re-scoping or even
cancellation) can take place, thereby de-risking the process, something which is greatly-prized by
many stakeholders in solution life cycle process
The “Standard” Waterfall
Solution Lifecycle
4Solution Design & Procurement Approach01/04/2014
However:
• The “Checkpoint” approach creates a cottage industry of assurance – by people without the technical
skills to actually validate the solution, and thereby have to rely on documentation (creating its own
cottage industry) – ADDED COST
• Errors or incorrectly specified requirements found during the test or implement stages are extremely
costly to go back & correct – ADDED COST
• The process is invariably long-winded from beginning-to-end, which usually means that
requirements change during the life of the project,. Invoking expensive and time-consuming
Change Control. Worse, lengthy projects always experience personnel changes, with resultant
changes in thinking & approach – ADDED COST, RISK
5. SECTION 2
Solution Development Life Cycle – Motivation for (more-)Agile
Approaches
5Solution Design & Procurement Approach01/04/2014
6. Agile versus Waterfall
Agile Waterfall
Individuals & Interactions Processes & Tools
Working Software Comprehensive Documentation
Customer Collaboration Contract Negotiation
Responding to Change Following a Plan
6Solution Design & Procurement Approach01/04/2014
Quality
Features
CostTime
Quality
Features
CostTime
Principles
• Focus on the Business Need
• Deliver on Time
• Collaborate
• Never Compromise on Quality
• Build iteratively from firm foundations
• Deliver Iteratively
• Communicate continuously and
clearly
• Demonstrate control
Variable
Fixed
WaterfallAgile
7. Motivation for Agile Approach
Agile approaches are very suited to implementation of packaged software or
outsourced services. They are also used to a greater or lesser degree by
mature organisations in the development of software application components,
where it is felt that they can accept the Pareto Rule:
In an age where COTS software has become
highly-sophisticated through deployment and
experience in millions of Use Cases, the
hypothesis is that:
• 80% of the requirement can be satisfied with
20% of the total effort, and that
• common sense tells us we should quit there
while we are ahead.
The lingering doubt:
• Will the 80% work for us?
• Is the level of Risk acceptable?
8. SECTION 3
How do we Accommodate (more) Agile Approaches?
8Solution Design & Procurement Approach01/04/2014
9. OperateShapeConcept
Problem Definition &
Impact Assessment
Feasibility
Assessment
High
Level
Design
Deliver
Detailed
Design Build Test
Implement Production Feedback
• How do we accommodate “more-Agile” approaches to the Solution Development Life Cycle while
retaining Project Governance?
• However, there is a fundamental question which is not necessarily dependent upon the type of
“agile” that is adopted:
Does Agile “kick-in” at the start of requirements elaboration, or at the point where design
is stable?
• The next few slides elaborate some thoughts on this question
The Solution Lifecycle
9Solution Design & Procurement Approach01/04/2014
10. Iterative Build before Detailed
Design
0
OperateShapeConcept
Problem Definition &
Impact Assessment
Feasibility
Assessment
High
Level
Design
Deliver
Detailed
Design Build Test
Implement Production Feedback
1 2 4 5 6
Quality Gates
• In this case, iteration and parallel development by
teams working on different “sprints” takes place after
the HLD has been reviewed and agreed. Revisions to
design are accommodated during the sprint. This is
more clearly aligned with pure agile.
Update
Project
Plan
Tech
Design,
Specs
Create
Detailed
Test Cases
Develop &
Test
Demo &
Retrospec
tives
Refine
Reqs
10Solution Design & Procurement Approach01/04/2014
Full Business Case
Authorised or T&M
• If a Fixed Cost Business Case is agreed at this point,
the customer is exposed to the risk of incomplete
delivery or escalating change control. Depending
upon the rigour of the original specification, the
supplier may also be faced with an unacceptable
level of risk
• On the other hand most customers are reluctant to
agree to a T&M approach
11. Agile – Iterative Build after
Detailed Design
0
OperateShapeConcept
Problem Definition &
Impact Assessment
Feasibility
Assessment
High
Level
Design
Deliver
Detailed
Design Build Test
Implement Production Feedback
1 2 3 4 5 6
Quality Gates
Full Business Case
Authorised
Update
Project
Plan
Tech
Design,
Specs
Create
Detailed
Test Cases
Develop &
Test
Demo &
Retrospec
tives
Refine
Reqs
• In this case, iteration and parallel development by
teams working on different “sprints” takes place after
the LLD has been reviewed and agreed. Revisions to
design will only take place where detailed development
work reveals an error or a gap in the design
• This is not pure agile but rather a hybrid of waterfall
and agile.
• Clearly this allows the project to proceed with more
certainty but mitigates against one of the benefits of
agile – namely the feedback loop into design (and the
end product of the sprint) from detailed development
11Solution Design & Procurement Approach01/04/2014
15. Who – Multi-Disciplinary Team
Project Level Roles
Business Sponsor - owns and ensures ongoing viability of the
Business Case, & ready to pull the plug if necessary.
Responsible for obtain funding & other resources, oversees
decision making & escalation, responds rapidly to escalated
issues & delivers Business Benefits
Business Visionary - owns wider implications of business
change; define communicate and promote business vision;
contribute to key decisions, designs and review sessions,
monitor progress, approve changes to high-level requirements,
ensure collaboration & availability of internal SME resources,
act as final arbiter on business requirements
Project Manager - communicating with senior stakeholders
and responsible for project governance; high-level project
planning & scheduling; monitoring progress; managing risk;;
motivating the project teams; resourcing specialist roles;
managing problems & issues and escalating as required
Architect - to agree and control the Technical Architecture; to
identify and own technical risks, escalating to the PM as
appropriate; to advise on and coordinate technical activity; to
ensure non-functional requirements are achievable and
achieved; to ensure adherence to appropriate standards of
technical best practice; to control the technical configuration of
the solution; to manage technical aspects of the transition to
live use of the solution; to resolve technical differences
between team members
15Solution Design & Procurement Approach01/04/2014
16. Who – Multi-Disciplinary Team
Solution Level roles
Members of the team are empowered to make solution
decisions within an agreed terms of reference
Team leader - a leadership rather than management role. Can be
different team leader for different stages of project. Elected by
peers. Responsibilities - to work within the team to plan &
coordinate all aspects of product delivery, at a detailed level; to
ensure that the team operates as an entity and fulfils its
obligations; to report to the PM
Business Analyst - provides clear direction for the business
users; ensures business needs are analysed and reflected in
guidance for the project team; works alongside the business but
does not make decisions on its behalf, ensures no scope creep
and only low level details are added during the solution
development; manages requirements priority list
Business Specialist - role filled by someone with specific
knowledge relevant to some or all of the project - examples,
legal or finance or security expert
Technical Specialist - technical equivalent of Business Advisor -
examples, DB developer or Technical author
Solution Developer - technical skills (analyst / programmer) to
the fore, but good communicator and team player; must be
dedicated to the project because of the time-boxing approach
Business SME - very knowledgeable about business area and its
processes; links solution development team and the business;
the role provides business-related information from end-user's
perspective
16Solution Design & Procurement Approach01/04/2014
18. How - Workshop Approach
The workshops are structured to align with the new Target
Operating Model Business Capabilities that are in scope.
• Capabilities are de-composed into their constituent
processes – these represent the scope of individual
workshops
The workshops will address both To-be and As-is jointly in
workshops.
• We can identify anything that exists in the As-is that can
be reused for the To-be
• This is more efficient in terms of the use of BA & SME
resource
• It is also crucial to condense the e2e Requirements
Gathering into as short an elapsed period of time as
possible:
• Business context and therefore requirements change
quickly, so a lengthy process can become like painting
the San Francisco Bridge
• Continuity of personnel is also vital, so shortened
timescales mitigate the impact of personnel sickness,
holidays and turnover
18Solution Design & Procurement Approach01/04/2014
19. What - Design Approach
The workshops adopt a standard approach to analysis:
1. Quickly confirm the As-is process flows (with no
supporting Information Flows etc)
2. Identify the Outcomes mandated for a successful
implementation of the To-Be process
3. Map As-Is on to the To-Be model and identify any
gaps
4. Extract information from the documentation of
the individual workshops, such as Roles, Business
Rules, Candidate Services, User numbers etc and
lodge them in repositories so that they can be
“normalised.”
5. Perform a MoSCoW analysis to determine priority
19Solution Design & Procurement Approach01/04/2014
21. Why - Motivation for a
Managed Sandpit?
COTS Approach
• Speed to Market
• Lower cost
• Reduce Risk
– Will it work? Of course it will – COTS software has been deployed and exercised in millions of Use
Cases
– Will it work for us? The Key Question
Transformation Agenda
• Drive stakeholder thinking about “will it work for us?”
• Thereby inform RFP Requirements – “Outcomes focussed”
Capturing the outputs in the form of potential future questions and ultimately RFP Requirements
Experiencing a working relationship with bidders.
22. What is a Managed Sandpit?
Three Sandpit phases:
1. Convergence
2. Close-down
3. RFP Evaluation
A sandpit is an intensive, interactive and extended workshop where Examiner participants are encouraged
to delve deeply to explore the capabilities of bidder “vanilla” solutions.
Vanilla solution (configured to enable Examiner stakeholders to explore the scenario) which can be easily
created, “trashed” then easily resurrected.
Addresses the question “Will it work for us?” and starts Examiner thinking about:
• “Can we adapt our ways of working to adopt the vanilla solution and…”
• “What will we have to do to adopt the vanilla solution
22Solution Design & Procurement Approach01/04/2014
23. How - Process for a Managed
Sandpit?
The process can be broken down into:
• Define the scope of the issue (Scenario)
• Agree a common language and terminology amongst people from a diverse range of backgrounds and
disciplines.
• Share understanding of the problem domain
• Mix of “hands-on” elaboration of the Scenario and break-out sessions focused on the problem
domain, encouraging creative and innovative thinking within the framework of the initial scenario, and
each bidder’s “vanilla” solution
• Initial support for walkthrough of scenario (“Happy Path”) journey through the vanilla solution
• Ad hoc support for user queries:
– “How do I…?
– “How would you achieve this (outcome-focussed) requirement?
• Document outputs & further questions (we will maintain confidentiality of bidder IPR)
24. Who - Participants?
• It will typically involves 20-30 participants over time
– The Transformation Director (whose role is to define the topic and facilitate discussions at
sandpit events),
– Lead BA
– Solution Architect
– Subject Matter Experts (Bid team)
– Solution Experts (Bidder team)
• An essential element of a sandpit is a highly multidisciplinary mix of participants taking part, some
being programme stakeholders and some being users of programme outcomes, to drive lateral
thinking and radical approaches to addressing particular programme challenges.
24Solution Design & Procurement Approach01/04/2014
26. Sandpit Scenario – Students
entering the Exam
• 6 students enter for the F5 exam in the December exam session; Emma, Carol-Anne and
Andy are all from the UK and wish to sit at a Glasgow venue.
• Joyce and Nick live in the Caribbean and wish to sit at a Caribbean venue.
• Jasmine lives in Hong Kong and wishes to sit at a HK venue.
• All have decided to sit a computer-based exam, except for Carol-Anne who wishes to take a
paper-based exam.
• Each student logs into myAccount and navigates to exam entry. Once they have selected
their exam and the exam they wish to take and their eligibility is confirmed, they each select
the venue which is most convenient for them and choose an exam session from the available
dates and timeslots shown.
• As each of the students select an exam session and successfully completes payment, the
available capacity at their chosen venue is reduced accordingly. Upon successful acceptance
of their exam entries, students receive confirmation and full details of what to do next (e.g.
venue directions and any authentication details which they will need on the day of the exam).
26Solution Design & Procurement Approach01/04/2014
27. Sandpit Scenario – Students
sitting the Exam
• After having entered for the exam Andy moves to Hong Kong and needs to change his exam
booking from a Glasgow venue to Hong Kong. Again, this automatically updates the available
capacity at both Glasgow and Hong Kong.
• On the exam day, Emma arrives at her chosen venue and time slot (9am). The exam centre
authenticates her identity, checks her in and then shows her to her workstation.
• When instructed by the invigilator Emma enters her security credentials into the assessment
system and is presented with the correct exam version (as per her time zone) and begins her exam.
• The exam that she sits is the same version as that sat by Andy at 2pm local time in Hong Kong.
During the exam a fire alarm is activated and the exam centre is evacuated. Emma is allowed to
return to her workstation 20mins later and her exam is restarted where she left it with all previous
responses retained.
• When the exam is concluded all Emma’s responses and marks (where automatic marking has been
possible) are automatically stored and sent to the Examiner along with associated data for manual
marking (where auto marking has not been possible).
• The Examiner uses the information received to conduct statistical and process analysis on
automarked responses and sends written responses for expert marking. The Examiner processes
the final marks and sends results to its students.
27Solution Design & Procurement Approach01/04/2014
28. Sandpit Scenario – Exam Centre
set-up
• In advance of each exam session the exam centres enter their available capacity into the online
capacity management capability.
• For the December session the Glasgow venue has 4 seats available, Caribbean has 3 and Hong
Kong has 1.
• Throughout the exam entry period the Examiner monitors the consumption of the available
capacity via capacity management dashboards. It is noticed that the single Hong Kong seat is
booked and therefore an additional seat is sourced and made available.
28Solution Design & Procurement Approach01/04/2014
29. Sandpit Scenario – Exam
Production
• The December session will be the first time F5 is available in a CBE format. The Examiner monitors
the F5 item bank (showing “low stock”) and commissions approved Item Authors to write specific
items
• Sharon, an author who lives in India, accesses the secure authoring system from her home windows
PC, creating 2 different longer style questions using the template provided, includes the initial set of
question attributes (topic etc.) and submits to the Examiner.
• Sharon’s 2 questions are automatically routed to Catherine, who is the specialist reviewer for all
questions from this syllabus area. Like Sharon she is external to the Examiner and accesses the
reviewing system remotely from her home Apple Mac. The communication between Sharon and
Catherine’s devices and the authoring system is highly secure: their access to the system is subject to
robust authentication and their access is controlled and audited.
• Catherine reviews Sharon’s questions, edits them as necessary and adds comments; she marks it as
reviewed and the production system automatically adds it to the list of items to be reviewed at the
next relevant exam panel where it is reviewed, amended & accepted.
• A member of the Examiner exam production team changes the status of the questions to ready for
pre-test and they are banked ready for inclusion within a pre-test exam.
• A pre-test exam is generated and sat by a small number of students at an exam centre. During the
pre-test all responses and associated data are collected and submitted to Examiner (potentially along
with qualitative feedback).
• Examiner analyses the pre-test data and calibrates the questions.
• Throughout the author, review, acceptance and pre-test process, the system prevents any leakage of
content to the Internet or access by unauthorised persons.
29Solution Design & Procurement Approach01/04/2014
30. Sandpit Scenario – Exam
Production
• Following pre-testing a member of The Examiner exam production team changes the status of the
accepted questions and they are banked ready for inclusion within a live exam.
• In advance of the December exam session the F5 QTA (Qualifications Technical Advisor) requests
several auto generated F5 exam versions: one to be offered as the paper-based exam and the others
to be offered as computer-based exams. The system generates the draft exams using the F5
balancing rules. The F5 QTA and Examiner review the first exam version and decide that one of the
longer style questions should be changed. They search the question bank and select a different
question and edit the exam version. Once both the QTA and examiner are happy with the exam
version its status is changed to published. Throughout this process, access to the system by The
Examiner exam production team, QTA and Examiner is secured, authenticated, authorised and
audited.
• This exam versions is published both in a format suitable for offering as a Computer Based Exam as
well as in a format that can be sent to Examiner’s security printers for printing.
• Examiner’s Exam Production team regularly review the operational status of content production and
chase Authors which are behind with their commission, thereby ensuring that the overall exam
production schedule is followed.
30Solution Design & Procurement Approach01/04/2014
31. Sandpit Scenario – Exam
Centre/Invigilator
• In advance of the December exam session the Glasgow venue downloads all necessary software and
exam content. On the morning of the exam they perform a diagnostic test to ensure everything is
working as required to successfully complete the exams.
• During the exam the invigilator monitors each workstation within the room from their own
workstation. A fire alarm is activated, at which point the invigilator stops the exam and evacuates the
centre. After 20 minutes all candidates return to their desks and the invigilator restarts the exam.
• After the exam, the invigilator or centre administrator uploads student responses and any exam day
reports and ensures that student attendance information is correctly recorded. Exam day reports
include both details of the fire alarm incident as well as details of an incident where they noticed a
student attempting to cheat by copying responses from the student sat next to them.
• The centre administrator then validates that Examiner has received all the necessary response and
data files, before removing all exam content from the exam centre’s computers.
31Solution Design & Procurement Approach01/04/2014