questionsV2.json

{
  "automation" : {
    "overview" : "Agile business practices are key to remaining competitive. Automation includes looking at how you do software configuration management (SCM), test, deployment and release. Automation is a deciding factor in delivering more from less.",
    "qnum" : "1",
    "title" : "Automation",
    "features" : "<ul><li>Source control management</i><li>Test automation</li><li>Deployment</li><li>Release Management</li><li>Provisioning</li><li>Configuration</li></ul>",
    "1": "Many manual steps throughout the SDLC including testing, patching, configuration, release and deployment.",
    "1-summary" : "<ul><li>No clear definition of SDLC</li><li>Changes are applied directly in situ</li><li>Packages are built on individuals local machines</li><li>All tests are performed manually</li><li>Ad-hoc approach to provisioning runtime environments with lack of automation</li></ul>",
	 "1-details" : "<p>No clear definition of SDLC and no common understanding across teams involved throughout software delivery process.</p><p>  Changes are applied in situ and are not controlled by a version control system. </p><p> Distributable packages are created manually on users' personal devices.</p><p>  All tests are performed manually.</p><p>  Adhoc approach to provisioning runtime environments, with various levels of consistency and control, and a lack of automation.</p>",
    "2": "Overall processes manually coordinated, but with the emergence of scripting for simplifying repeated steps.",
	 "2-details" : "<p>Clear and common shared understanding of SDLC stages, manual steps employed to promote changes between stages</p><p> Code, configuration, and associated build and packaging instructions are version controlled</p><p> Automated build process from version controlled changes, but may be reliant on special environmental configuration and libraries</p><p>Some automated testing, but largely focused on application behaviour and function, and not extending to hosting environments, and real-life operational scenarios</p><p>All SDLC promotion steps are performed manually, for example, development to testing, or staging to production</p><p> There are a number of scripts used to support SDLC promotion steps, they are generally not reusable and only work for a specific application </p>",
    "2-summary" : "<ul><li>Shared understanding of SDLC stages, with manual promotion of code</li><li>Build artefacts are version controlled</li><li>Automated build process from version controlled changes</li><li>Some but limited automated testing</li><li>All SDLC promotion steps are performed manually</li></ul>",
    "3": "Automation coordinating the processes, with some automated testing, and the emergence of declarative configuration implementation. ",
    "3-summary" : "<ul><li>Emergent delivery pipeline automation but little reuse</li><li>Merging requires substantial effort and is typically difficult, requiring experienced team members</li><li>Build process can be run anywhere with access to resources</li><li>Emergence of automated testing of cross-cutting concerns - availability, performance, and security etc</li><li>Emergence of automated process for deployment but little or no reuse</li></ul>",
    "3-details" : "<p>Emergent delivery pipeline automation for specific applications, but no common tools or standards; approaches are siloed to specific teams, with little knowledge share or reuse</p><p>  Version controlled change management requires significant effort to merge for new release candidates; merges are difficult and require specialised and experienced team members to perform</p><p>Independent build process that can be run anywhere with access to declared dependencies and resources</p><p>Emergence of automated testing of cross-cutting concerns, such as availability, usability, resilience, performance, and security, applied inconsistently between application teams</p><p>Emergence of an overarching automated process for delivering new application versions through the SDLC, but created on an app-by-app basis, with little or no reuse</p><p> Declarative approach to configuration, with tools used to implement a desired state</p>",
    "4": "Significant reuse of delivery automation and automated testing now including operational concerns, but release frequency somewhat impeded by complexity of application code and configuration.",
    "4-summary" : "<ul><li>Centrally defined standard for pipelines that must be adhered to</li><li>Change merges may require significant coordination with external work streams</li><li>Packages are built only once, consistent versioning schema, managed build artefacts</li><li>Quality gateways and fast feedback loops</li><li>Standardised tooling used to promote applications to production</li></ul>",
	 "4-details" : "<p>Centrally defined standard for fully automated delivery pipelines to which all teams must adhere</p><p>Change merges are more straightforward, but may require high levels of coordination with external work streams, that on occasion delay releases</p><p> Packages are built once, and once only, with a commonly understood versioning schema, with controlled access to 3rd party build artefacts and dependencies</p><p> Common framework for quality gateways adopted by all application teams, and establishment of fast feedback loopsStandardised tooling used to promote applications through SDLC as part of releases, however, new deployments to production do not allow for incremental and controlled availability of new software versions</p>",
    "5": "Software deployed to production before a managed release, with production issues being resolved through a test driven approach.  Self service infrastructure with zero or little manual intervention required.",
    "5-summary" : "<ul><li>Common framework for automated delivery pipelines, allowing flexibility to individual teams customisations and adaptions</li><li>Change merges are compact, and incremental and not affected by other work streams</li><li>Packages include consistent trackable meta-data</li><li>Defects in production, are replicated via repeatable test, and added to pipeline</li><li>Release is now independent of deployment into production, allowing canary releases or blue green</li></ul>",
	 "5-details" : "<p>Common framework for automated delivery pipelines, allowing for individual team customisations and adaptions where appropriate</p><p> Code and configuration merges for upcoming releases are compact, and incremental</p><p> Changes can be performed by all appropriate team members without being blocked by other work streams</p><p>  Packages include consistent trackable meta-data, that can be use verify configuration state of a particular runtime environment</p><p>As a matter of course, any defect being discovered from development through to running in production, is replicated in a test, and incorporated into the delivery pipeline</p><p> Deployment and release are decoupled, with mechanisms allowing for the managed release of new software systems</p><p> Releases are independent to deployment of software systems into production, for example canary releases</p>",
    "workshops" : {
      "dev" : ["Automation Adoption Programme","CI/CD To Production","Container Adoption Programme","Automate App delivery","DevSecOps","Business Process Automation (RHBPM)"],
      "ops" : ["Automation Adoption Programme","CI/CD To Production","Container Adoption Programme","Standard Operating Environment Workshop","Adaptive SOE and Ansible Automation","Automate IT workflows","DevSecOps","IT Management","Cloud Management Discovery Session","Enable Agility with Cloud Infrastructure -  Discovery Session"]
    }
      },
  "wayOfWorking" : {
    "overview" : "In today’s market, organizations must rely on more than just technology and tools. In this section, Way of Working refers to the way in which you are running your IT projects.  Way of working looks across the whole Software Development Life Cycle (SDLC) including agile adoption, team composition, managing work in progress, process and governance and measures of software delivery performance. ",
    "qnum" : "2",
    "title" : "Way of working",
    "features" : "<ul><li>Agile adoption</li><li>Team composition</li><li>Managing Work in Progress</li><li>Processes and governance</li><li>Performance measures</li></ul>",
    "1": "Detailed designs before implementation, development and ops separated, long lead time to resources, change control not in place, or frequently subverted, no measurement of activity.",
    "1-summary" : "<ul><li>Sequential development and delivery processes - typified as waterfall</li><li>Hierarchies based on functional skills and capabilities</li><li> New work items tackled reactively</li><li> New changes introduced throughout SDLC</li><li> Software delivery performance is not habitually reported</li></ul>",
	 "1-details" : "<p>Sequential development and delivery processes, covering requirements gathering, analysis, design, implementation, and finally release</p><p> Organisational hierarchies based around functional skills and capabilities</p><p>New work items tackled somewhat reactively, with significant new work requiring project managers to negotiate and secure necessary resources and people</p><p> No commonly implemented change policy, new changes introduced throughout SDLC</p><p> Reports on software delivery performance are not habitually created, but instead generated through occasional auditing processes</p>",
    "2": "Emergent cross-functional teams, developing their own ways of working. Work in progress not clearly defined, or prioritised. SDLC covering multiple teams, visibility between teams low, and based on personal contacts and communications. Performance metrics are understood, but limited to specific aspects of SDLC.",
    "2-summary" : "<ul><li>Emergent cross functional teams, siloes manifested by handovers throughout the SDLC</li><li> Development team members are frequently assigned to production support issues</li><li>Occasions where change policy is bypassed, for expediency</li><li>Emergence of common metrics covering aspects of SDLC process,  not necessarily reported across teams</li></ul>",
	 "2-details" : "<p>Sequential development and delivery process governing SDLC, but with emerging interactive practices within specific teams</p><p>Emergent cross functional teams, developers and operations closely collaborating but with siloed functions such as Security, QA, Release</p><p> Distinct handovers throughout the SDLC</p><p> Individual teams operate their own prioritised product backlogs, task and issue tracking</p><p> Engineers are frequently assigned to production support issues</p><p> Multiple systems used to track software and production issues</p><p> Occasions where change policy is bypassed, for expediency or change seen as critical to success</p><p> Emergence of common metrics covering aspects of SDLC process and runtime software behaviour, generally reported within teams, but not necessarily reported across teams as a matter of course</p>",
    "3": "Emergent Agile practices, with cross functional teams. Some sequential delivery and hand-offs between SDLC stages.",
    "3-summary" : "<ul><li>Emergent iterative agile style</li><li> Siloed development and operations</li><li> Cross functional team now also includes other SDLC stakeholders, such a test / security</li><li>Application support roles now incorporated within development teams</li><li> Control processes have grown complex over time, no obvious owner</li><li>Metrics aggregated and used to report specific performance of SDLC stages</li></ul>",
	 "3-details" : "<p>Clearly defined emergent iterative agile style with a product backlog, definition of done, and retrospectives</p><p> A clearly defined Product owner role may not be fulfilled, or does not extend to production environments</p><p> Accountability is divided between siloed development and operations</p><p> Cross functional team now also includes other SDLC stakeholders, for example test engineers, and security</p><p>Application support roles now incorporated within development teams, and working from a shared backlog, and issue register</p><p> Planned development iterations frequently deliver fewer than expected changes, typically due to priority production issues taking focus</p><p> Control processes have developed over time, with additions to support new technologies and capabilities, but lack of ownership has led to complications, with low understanding of reasoning and business value</p><p>Common metrics aggregated and used to report specific performance of SDLC stages</p><p>Department understands the need for improving the people and process axis along with technology</p><p>  Team is still badly siloed or split based on geography, this makes it impossible for really close collaboration</p>",
    "4": "Closer collaboration and combined change control across SDLC with emergent measures tracking software delivery performance.",
    "4-summary" : "<ul><li>Business, development and delivery have aligned Agile practices</li><li>  Ownership of production within application team</li><li>Formal approval required for deployment to production</li><li>Backlog prioritisation does not always align with business expectations</li><li> Common approach for managing change accessible to all team members</li><li> Automatically measure software delivery performance, fully visible to all stakeholders</li></ul>",
	 "4-details" : "<p>Business, application development and delivery have aligned Agile practices</p><p>  Ownership of production is within cross functional application team</p><p>Cross functional teams now with representation for cross-cutting concerns, such as security or availability</p><p> Formal approval required for applications to be deployed to production, and released</p><p> Good adherence to backlog plans, and consistent SDLC throughput</p><p> Backlog prioritisation does not always align with business expectations</p><p> A common approach for managing change is shared across full SDLC with change items visible, communicated, and accessible to all team members</p><p> Automatically measure software delivery performance consistently across all applications teams, with full visibility to all stakeholders</p><p> Business tries to get people working in close proximity but change is driven largely top down - typified by call to action posters on the walls, but staff still behave the same as always</p><p> Consequently change is slow</p>",
    "5": "Singular iterative process managing work across the full SDLC, with appropriate measures to track software delivery performance over time. ",
    "5-summary" : "<ul><li>Agile process with quantifiable metrics, feedback loops, validating strategic goals</li><li>Team empowered to make delivery into production at will</li><li>Product owners have tight control over backlogs and effective prioritisation that aligns the business</li><li> Capable of running multiple service versions within production</li><li>Software delivery performance measures factored into continuous improvement</li></ul>",
	 "5-details" : "<p>Agile process with quantifiable metrics based on systems in production</p><p> Fast feedback loops, designed to verify and quantify strategic goals, and desired business outcomes</p><p>Fully cross functional team empowered to make delivery into production at will, with governance incorporated into automated pipeline</p><p>Product owners have tight control over backlogs and have an effective prioritisation and estimation mechanisms that directly aligns the business</p><p> All stakeholders accept that work in progress needs to be actively restricted to achieve quality</p><p> Features are now prioritised toward meeting strategic goals</p><p>Processes in place that allow measurement of the business value of multiple versions running simultaneously in production</p><p> Capabilities to make end of life decisions on specific versions within production Continuous tracking of software delivery performance measures factored into future planning, supporting continuous improvement</p>",
    "workshops" : {
      "dev" : ["DevSecOps","AppDev Design Sprint","Agile Development Workshop","Agile Ways of Working Assessment","DevOps Course (DO500)","Domain Driven Design","Open Innovation Labs","Container Adoption Program (CAP)","Transformation & Adoption Strategy Engagement"],
      "ops" : ["Automate IT workflows","DevSecOps","Security Compliance","DevOps Course (DO500)","Open Innovation Labs","IT Management","Container Platform","Cloud Management Discovery Session","Enable Agility with Cloud Infrastructure -  Discovery Session","Container Adoption Program (CAP)","Transformation & Adoption Strategy Engagement"]
    }
    },
  "architecture" : {
    "overview" : "Architecture includes looking at modularity, techical debt, observability and monitoring and user experience.",
    "qnum" : "3",
    "title" : "Architecture",
    "features" : "<ul><li>Modularity</li><li>Technical Debt</li><li>Observability and Monitoring</li><li>User Experience</li></ul>",
    "1": "Significant technical debt and tightly coupled applications, resume driven development, evolutionary architect, user interfaces reflect requirements of underlying data structures, with no common mechanism for runtime observability. ",
    "1-summary" : "<ul><li>Organsiation has limited visibility, or understanding, over significant aspects of production</li><li>High technical debt, little progress in reducing it</li><li>Ad-hoc logging/manual monitoring</li><li>UI reflects only the needs of the underlying datamodel / business process</li></ul>",
	 "1-details" : "<p>No clear definition of SDLC and no common understanding across teams involved throughout software delivery process</p><p>Changes are applied in situ and are not controlled by a version control system</p><p>Distributable packages are created manually on users' personal devices</p><p>All tests are performed manually</p><p>Adhoc approach to provisioning runtime environments, with various levels of consistency and control, and a lack of automation</p>",
    "2": "Layered architecture, but tightly coupled, with consideration for user experience. Tech debt recognised and considered as part of releases. Common approach observing application runtime behaviour. ",
    "2-summary" : "<ul><li>Applications separate concerns</li><li> Components exhibit tight coupling</li><li> Technical debt recognised, starting to manage</li><li>Standardising logging of common operational metrics</li><li>Consideration is given to user experience by a UI specialist developer</li></ul>",
	 "2-details" : "<p>Clear and common shared understanding of SDLC stages, manual steps employed to promote changes between stages</p><p> Code, configuration, and associated build and packaging instructions are version controlled</p><p> Automated build process from version controlled changes, but may be reliant on special environmental configuration and libraries</p><p>Some automated testing, but largely focused on application behaviour and function, and not extending to hosting environments, and real-life operational scenarios</p><p>All SDLC promotion steps are performed manually, for example, development to testing, or staging to production</p><p> There are a number of scripts used to support SDLC promotion steps, they are generally not reusable and only work for a specific application </p>",
    "3": "Feature prioritisation relies on expert knowledge. <br>Loosely coupled architecture with known and measured runtime characteristics. <br>Technical debt actively managed.",
    "3-summary" : "<ul><li>Applications are loosely coupled via APIs/messaging, or persistence schema</li><li>Technical debt being actively managed</li><li>Response to issues via predefined alerting thresholds</li><li>Product owner subjectively assume they know what experience and features the end users want</li></ul>",
	 "3-details" : "<p>Applications are loosely coupled via APIs or messaging, also loosely coupled around persistent data</p><p>Technical debt being actively managed</p><p>Reacting to isssues that are triggered by predefined alerting thresholds</p><p>Product owner subjectively assume they know what experience and features the end users want</p>",
    "4": "Research driven prioritisation. <br>Individual releasable components, but frequently blocked due to overall complexity.<br> Intrinsic recovery from failure. ",
    "4-summary" : "<ul><li>Components are now small enough to be individually releasable</li><li>Low technical debt but still preventing true agility</li><li>Core capabilities include adapt and recover from failure</li><li>Product owner performs user research to determine UX and features to build</li></ul>",
	 "4-details" : "<p>Clear and common shared understanding of SDLC stages, manual steps employed to promote changes between stages</p><p> Code, configuration, and associated build and packaging instructions are version controlled</p><p> Automated build process from version controlled changes, but may be reliant on special environmental configuration and libraries</p><p>Some automated testing, but largely focused on application behaviour and function, and not extending to hosting environments, and real-life operational scenarios</p><p>All SDLC promotion steps are performed manually, for example, development to testing, or staging to production</p><p> There are a number of scripts used to support SDLC promotion steps, they are generally not reusable and only work for a specific application </p>Emergent modular architectures - components are now small enough to be individually releasable allowing small batches of work.Low technical debt but enough to prevent true agility</p><p>Core capabilities of the solution are able to adapt and recover from failure</p><p>Product owner performs user research to determine UX and features to build.",
    "5": "Highly observable, modular architecture that supports frequent independent component deployment, with low risk to service quality.",
    "5-summary" : "<ul><li>Modular service architectures but with governance - lifecycle, security, orchestration and proliferation</li><li>True agility by aggressively removing technical debt</li><li>Pro-actively testing critical processes in production</li><li>Software is actively collecting usage data factored into continuous improvement</li></ul>",
	 "5-details" : "<p>Highly modular service architectures but with governance around lifecycle, security, orchestration and proliferation</p><p>Anything that interferes with agility is regarded as technical debt and actively removed as a matter of priority</p><p> Proactively testing in production including verifying potential failiure states</p><p>Software is actively collecting usage data and metrics which is being incorporated into future user experience </p>",
    "workshops" : {
        "dev" : ["Application Lifecycle Management","Red Hat Navigate","Microservices","APIs","Cloud Native Applications","Agile Integration"],
        "ops" : ["IT Management","Container Platform","Cloud Management Discovery Session","Enable Agility with Cloud Infrastructure -  Discovery Session","Infrastructure Migration Solution (IMS)","Red Hat Navigate","Modernize virtualization infrastructure","Software Defined Storage","SAP Migration"]
    }
  },
  "environment" : {
    "qnum" : "5",
    "title" : "Environment",
    "features" : "<ul><li>Collaboration</li><li>Creating empowered Teams</li><li>Personal Development</li><li>Staff Morale</li></ul>",
    "overview" : "In this section, environment includes looking at open source values (such as collaboration and transparency), team dynamics, empowered teams, personal development, training, skill level and moral.",
    "1": "Shared information and knowledge may be difficult to find, and individuals mostly work unilaterally to given assigned tasks.",
    "1-summary" : "<ul><li>Difficult to find information or necessary contacts within organisation</li><li>Tasks are generally worked on exclusively by individuals, and collaboration is generally low, or between team members fulfilling very similar roles</li><li> Personal career and learning paths not clear or well understoodCommon organisational, or team, goals not well understood or relatable to personal objectives</li></ul>",
	 "1-details" : "<p>Difficult to find information or necessary contacts within organisation</p><p>Tasks are generally worked on exclusively by individuals, and collaboration is generally low, or between team members fulfilling very similar roles</p><p> Personal career and learning paths not clear or well understood</p><p>Common organisational, or team, goals not well understood or relatable to personal objectives</p>",
    "2": "Good collaboration with peers, but examples of a lack of reuse across the organisation leading to cases of solution reinvention.",
    "2-summary" : "<ul><li>Knowledge sharing within teams is good, but low visibility of other areas of organisation, and a tendency to reinvent solutions to common problems</li><li> Siloed functions still evident, for example security, or QA</li><li> Learning opportunities rely on individuals requests and justifications</li><li> Organisational goals are well understood, but team members sometimes have difficulty relating these to assignments</li></ul>",
	 "2-details" : "<p>Knowledge sharing within teams is good, but low visibility of other areas of organisation, and a tendency to reinvent solutions to common problems</p><p> Learning opportunities rely on individuals' requests and justifications</p><p> Organisational goals are well understood, but team members sometimes have difficulty relating these to assignments</p>",
    "3": "Emergence of organisations strategies to support better knowledge sharing and transparency. Organisational goals clearly defined and understood, and relatable to specific teams and individuals. ",
    "3-summary" : "<ul><li>Although limited, a general willingness to cooperate across silos exists</li><li>Emergent cross-functional collaboration within teams</li><li>Somewhat reactive training provided; focused specifically on immediate business needs</li><li>Organisation tries to measure and actively foster positive workplace experience</li></ul>",
	 "3-details" : "<p>Although limited, a general willingness to cooperate across silos exists</p><p>Emergent cross-functional collaboration within teams</p><p>Somewhat reactive training provided; focused specifically on immediate business needs</p><p>Organisation tries to measure and actively foster positive workplace experience</p>",
    "4": "Cross-team collaboration and knowledge sharing, both managers and peers recognise other's efforts and achievements.",
    "4-summary" : "<ul><li>Emergence of collaboration, meritocracy, transparency, open exchange of ideas</li><li>Knowledge shared horizontally across teams</li><li>Training plan and up-skilling around wider business strategic needs</li><li>Individual contribution recognised by peers and wider organisation</li></ul>",
	 "4-details" : "<p>Emergence of collaboration, meritocracy, transparency and open exchange of ideas</p><p>Knowledge shared horizontally across teams</p><p>Permanent cross functional teams</p><p>Training plan and upskilling around wider business strategic needs</p><p> Individual contribution is recognised by peers and wider organisation</p>",
    "5": "Collaboration occurs not just across the organisation internally but also externally. Learning and training for individuals is a priority.",
    "5-summary" : "<ul><li>Organisation actively cultivates and encourages open exchange with external parties</li><li>Self directed and empowered cross functional teams</li><li>Sponsorship is given for wider training beyond obvious immediate need</li><li>Individuals derive personal esteem and fulfillment from the work that they do (self actualisation)</li></ul>",
	 "5-details" : "<p>Organisation actively cultivates and encourages collaboration, transparency, feedback, open exchange with external parties</p><p>Self directed and empowered cross functional teams</p><p>Sponsorship is given for wider training beyond obvious immediate need</p><p>Individuals derive personal esteem and fulfillment from the work that they do (self actualisation)</p>",
    "workshops" : {
      "dev" : ["DevOps Maturity Workshop","Strategy and Business Influence Workshop","Business Influence Mapping","Transformation & Adoption Strategy Engagement","Open Source Governance / Innovation","Open Source Strategy","Open Source Enablement Workshop","Developing CoPs","Open Organisation & Open Leadership","Red Hat Certification (RHCE)"],
      "ops" : ["DevOps Maturity Workshop","Strategy and Business Influence Workshop","Business Influence Mapping","Transformation & Adoption Strategy Engagement","Open Source Enablement Workshop","Developing CoPs","Open Organisation & Open Leadership","Red Hat Certification (RHCE)"]
    }
      },
  "visionLeadership" : {
    "qnum" : "4",
    "title" : "Vision and Leadership",
    "features" : "<ul><li>Strategic roadmaps</li><li>Business Value</li><li>Management style</li><li>Empowerment</li><li>Dealing with failure</li></ul>",
    "overview" : "Vision and Leadership includes product roadmap, business value, prevalent management style, empowerment and how failure is treated.",
    "1": "Decisions are being made that affect individuals, teams and the end customer but there is no clear or obvious way for others outside of the leadership team to provide input.",
    "1-summary" : "<ul><li>Product Roadmap driven by customer requirements with no consideration of market</li><li>Tasks given with explicit commands on how to achieve them</li><li>Attempts to learn lessons from setbacks are rare</li></ul>",
	 "1-details" : "<p>Product Roadmap driven purely by customer requirements with no wider consideration of market</p><p> Highly directive personal management tasks are given with explicit commands on how to achieve them</p><p>Attempts to learn lessons from setbacks are rare</p><p>Always a follower into a market and risk is low</p><p>Individuals may have awareness of organisational goals</p><p>Leaders maintain at least one clear direct channel for people to share opinions constructively on some matters relevant to their work or feel passionate about, but show passivity about understanding whether all people feel empowered and enabled to do so</p>",
    "2": "Leaders communicate organizational goals to the extent that individuals somewhat understand, but teams are unsure how they contribute to towards the goals.",
    "2-summary" : "<ul><li>Product roadmap driven by subjective view of market, tendency to implement individual non repeatable features</li><li>Directive management style</li><li>Failure may increase the level of team anxiety, and can distract from shared goals</li></ul>",
	 "2-details" : "<p>Told to do tasks but not directed in the detail</p><p>Failure may increase the level of team anxiety, and can distract from shared goals</p><p>Some, but not all, leaders are open to receiving feedback and creating an environment where people feel safe providing it, but often only after decisions have been made</p><p>Not unusual for leaders to frequently change priorities for individuals and teams</p>",
    "3": "Leaders help teams understand the organization's goals and how they can contribute to a collective effort in meaningful ways.",
    "3-summary" : "<ul><li>Prepared to risk new endeavour into a known space</li><li>Directed towards goals and trusted to deliver</li><li>Scheduled 'lessons learned' workshops are commonplace at the end of projects</li></ul>",
	 "3-details" : "<p>Directed towards goals and trusted to deliver</p><p>Scheduled 'lessons learned' workshops are commonplace at the end of projects</p><p>Prepared to risk new endeavour into a known space</p><p>Leaders link people both to each other and to some larger, shared picture</p><p> Leaders delegate and give individuals and teams clear priorities and space to concentrate on tasks (minimal context switching)</p><p>Leaders sensitive to the feelings, emotions, and passions of individuals</p>",
    "4": "Leaders set context to help everyone understand the whole mission, including vision, values & customer strategy, and how the work of individuals and teams contributes and impacts this.",
    "4-summary" : "<ul><li>Product Roadmap defined around a researched view of market needs</li><li>Collaborative relationship with leadership asking for opinions on setting goals</li><li>Failure leads to inquiry and attempted improvement</li></ul>",
	 "4-details" : "<p>Collaborative relationship, where leaders ask for opinions on setting goals</p><p>Failure leads to inquiry and attempted improvement</p><p>Leaders are transparent about goals and constraints, sharing data and resources as widely and thoroughly as possible</p><p> Leaders pro-actively create inclusive environments, drawing diverse disparate groups of stakeholders into productive conversations and establishing the conditions for pointed respectful dialogue</p><p>Leaders publicly give credit and recognition where due</p><p>Leaders encourage individuals to go out of their comfort zone, trusting them with delegated tasks and providing support</p>",
    "5": "Executing strategies to develop and disrupt new markets, short lead times in realising and evaluating new business opportunities. <br>Individuals given space to create, and solve problems, allowed to fail and incorporate and share learning.",
    "5-summary" : "<ul><li>Disrupting markets through innovation</li><li>Strategically aligned with shared goals and understanding</li><li>Fail fast, early and small is actively encouraged</li></ul>",
	 "5-details" : "<p>Strategically aligned with shared goals and understanding</p><p> Full trust in ability to deliver</p><p>Fail fast, early and small is actively encouraged</p><p>Shortened time market - leaders in market window</p><p>Opportunities and spaces for individuals to be creative / solve problems</p><p>Leaders are inspirational, where individuals feel a personal sense of purpose, acomplishment and commitment to organisational goals</p><p>Leaders value ideas over titles, proactiely seeking input from anyone in the organisation</p><p>Leaders act transparency, knowing not only what to share, but how to share it</p><p>Leaders have the confidence, humility and trust to give up the need to be in control, while inspiring commitment from people to accomplish goals</p><p>Leaders believe that teams will consistently outperform individuals working in isolation</p><p>Leaders trust teams to drive necessary change</p>",
    "workshops" : {
        "dev" : ["Strategy and Business Influence Workshop","Business Influence Mapping","Transformation & Adoption Strategy Engagement","Open Source Governance / Innovation","Open Source Strategy","Open Source Enablement Workshop"],
        "ops" : ["Strategy and Business Influence Workshop","Business Influence Mapping","Transformation & Adoption Strategy Engagement","Open Source Enablement Workshop"]
    }
      }
  }