velocity research: k2 solution delivery methodology · requirements are not clear or to explain...

VELOCITY RESEARCH:

K2 SOLUTION DELIVERY

METHODOLOGY Published: 07 December 2015

© 2015 Velocity IT Ltd. All Rights Reserved. Reproduction and distribution of this document in any form without prior written permission is forbidden.

Velocity disclaims all warranties as to the accuracy, completeness or adequacy of such information. Velocity shall have no liability for errors, omissions or inadequacies in the information contained herein or for interpretations thereof. The opinions expressed herein are subject to change without notice.

Introduction

K2 Solution Delivery Methodology

Requirements Analysis

Initial Solution Design

Solution Design Review

Functional Specification

High Level Project Estimate

Functional Specification Sign-off

Detailed Project Estimate and Project Plan

Detailed Technical Specification and Architectural Specification Document

Solution Build

More information

2 © 2015 Velocity IT Ltd. All Rights Reserved. Reproduction and distribution of this document in any form without prior written permission is forbidden

Table of Contents

________________________________________________________________3

_______________________________________________3

_______________________________________________________4

________________________________________________________5

______________________________________________________6

______________________________________________________7

__________________________________________________8

_______________________________________________9

_______________________________________10

______________11

______________________________________________________________12

___________________________________________________________13

www.velocity-it.com

INTRODUCTION

This paper provides a baseline K2 solution delivery methodology. It is based on K2 solution

development best practices and lessons learned working with K2 customers over a 15 year

period.

K2 SOLUTION DELIVERY METHODOLOGY

The primary drivers for adopting the K2 technology is the rapid application and workflow

capabilities it provides customers.

This plays out well when using an agile methodology, but a degree of initial discovery, functional

analysis and solution design provides a solid foundation later for the build phase. This does not

replace the processes of the Scrum delivery framework, but enriches it by providing key pre-build

phase deliverables.

The sections below provide a K2 solution delivery methodology based on an enterprise K2

project with a 100-day build period. This provides a reference for business stakeholders,

solutions architects, project management and K2 developers to gauge the effort required for each

of the activities.

3 © 2015 Velocity IT Ltd. All Rights Reserved. Reproduction and distribution of this document in any form without prior written permission is forbiddenwww.velocity-it.com

REQUIREMENTS ANALYSIS Step 1

Aim Perform user requirements analysis.This is done in a workshop setting.

Participating Stakeholders

• Process owners and champion end users

• Solution Architect

• Business Analyst

• Product owners

Goals Classify scope correctly as: • immediate requirement • future requirement • far future requirement, relevant to programme success.

ROLES AND RESPONSIBILITIES:

Solution Architect Key driver of the requirements analysis session. The SA asks the correct questions and mentally shapes an initial solution design as the analysis session progresses. The SA uses simple techniques (i.e. whiteboard drawings) to re-articulate user requirements in context with a very high level solution that might fulfil this. No technical terms used.

Business AnalystSupports the SA and provides answers that facilitates solution design formulation. Key link between the process owners/users and SA when requirements are not clear or to explain business context.

Process and product owners Provide elaboration on requirements based on SA and BA questions

Key Outcomes

Solution Architect • Thorough understanding of the user requirements. Understanding of business concepts that are otherwise hard to interpret from user

stories only.• Enough information to draw up a solution design and correlate solution features with user requirements.• Understanding of the rough order of scope for developing a solution for immediate, future and far future requirements. • Be able to call out the complexity of solution elements and the potential risks associated including it in the solution.

Business Analyst • Owns a backlog of requirements that need further clarification and analysis. This should be kept to <=10% of overall requirements.

Outcomes fed back to the SA to incorporate into solution design. • Should easily understand SA’s explanation of proposed system solutions for the user requirements.

Process and product owners • Have an initial idea of a high level solution to their problem. • Have a common understanding of the requirements as a whole. • Have a feeling of “everybody on the same page” post-requirements analysis.

There should be a sense positivity, team cohesion and excitement after the analysis workshop.

Issues Avoided

• Under-analysis of requirements leading to bigger gaps later in the project. Avoid the technical team getting involved in gap analysis discussions; keep them focused on development.

• Over-analysis of simple requirements that are otherwise hard to understand later without business context provided by Process Owners and the Business Analyst.

• Mismatch in business terminology and vocabulary.

• Mismatch in data dictionary (names of business entities and attributes).

• Understanding impacts of de-scoping solution elements without jeopardising long term usefulness of the proposed solution.

• Understanding impacts to the project and delivery effort when introducing additional solution elements.

• Context for discussing issues otherwise hard to understand without.

• Exclusion of key stakeholders in the analysis process leading to gaps in the solution.

• Out of control scope creep. Workshop sessions duration is a function of the number of requirements that can be analysed, hence creep is easily “felt” by all involved

• Unknown issues that wouldn’t otherwise have surfaced if not for this context-rich setting.

Estimated effort

5-7 days

www.velocity-it.com 4 © 2015 Velocity IT Ltd. All Rights Reserved. Reproduction and distribution of this document in any form without prior written permission is forbidden

INITIAL SOLUTION DESIGNStep 2

Aim Create an initial Solution Design.


Solution Architect

Support from: • Business Analyst • Process Owner • Product Owner • Technical Team Leads (UX and Development)

Goals • Produce a formal solution design that showcases the proposed solution for the business problem.

• Implementation technology (i.e. K2 solution constructs) should feature strongly in the design.

• Correlate requirements with solution elements.

• Review the solution design before the solution presentation and review meeting with the Process Owners and Product Owner.

• Have an updatable solution design should requirements change or change requests raised.

• This design needs to be maintained throughout the project lifetime.

Key Outcomes

A firm solution design containing:

• Processes to be automated (Swim lane diagrams; close as possible to K2 process maps to be implemented).

• Wireframes of solution’s user interface (SmartForm constructs to be used extensively).

• Wireframes of the solution’s reports (SSRS/Tableau constructs if these are the reporting technologies).

• A model that easily articulates the data domain and relationships/multiplicity between business entities.

• Solution data sources.

• Input for draft architectural specification document to be done by the system architect.

Issues Avoided

• Mismatch between process requirements and available technology tooling for implementing it (i.e. K2 process designer).

• Mismatch between user interface requirements and available technology tooling for implementing it (i.e. K2 SmartForms).

• Complex UX/UI design promised to users, but difficult to implement in an economical way.

• Avoids otherwise easily overlooked solutions for reporting and information that generally only gets looked at later in the process.

• Avoids a data schema that wrongly describes the solution domain. Also avoids uncertainty of data sources.

• Avoids an architectural design kick-off without a target solution to set basis for the design.

Estimated effort

10 days


SOLUTION DESIGN REVIEWStep 3

Aim Review the solution design.

This is done in a workshop setting.





• Product owners

Goals • An agreement between stakeholders that the requirements are fulfilled by the proposed solution design. If not, additional analysis required.

• Agreement on scope and prioritisation of solution elements.

ROLES AND RESPONSIBILITIES:

Solution ArchitectKey driver of the solution review session. Run through the solution design and correlate functional requirements with solution features. Refine where needed. This should be small tweaks.

Business AnalystSupports the SA and provides answers that facilitates easy solution review. Assist in refinement and clarifications.

Process and product owners Provide feedback on proposed solution design and confirmation it solves the business problem Provide input based on SA and BA review and refinement questions.

Key Outcomes

• Firm solution to the business problem.

• Firm idea on scope and prioritisation of solution elements.

• Solution architect has an accurate idea of the rough order of magnitude the solution build will take (architecture still needs to be factored in).

• Business expectations set and clear.

• Informal acceptance of the solution.

Issues Avoided

• Misaligned views of business expectations of the solution.

• Gaps in the solution design.

• Avoid users having a clear view what to expect in terms of a solution deliverable and help them to formulate additional outputs (start with training programme development, help creation, etc.).

• Incorrect feasibility analysis outputs as a result of uncertainties brought about unanalysed requirements.

• Expensive scope exclusions after development started.

Estimated effort

1-2 days


FUNCTIONAL SPECIFICATIONStep 4

Aim Create a functional specification.



Support from :• Business Analyst

Goals • Captures the firm functional specification in a document that is signed off between the business users and the technical team.

• References the solution design outputs to keep this document short (i.e. diagrams, models, etc.).

• The document always reflects the latest functional specification and should be kept in line with the solution design. This document needs to be maintained throughout the project lifetime.

Key Outcomes

Firm specification on “what” is to be delivered, and a trace back to the requirement it is fulfilling.

Issues Avoided

Avoids stakeholders misaligned on what is to be delivered and how it will functionally behave.

Estimated effort

5 days


HIGH-LEVEL PROJECT ESTIMATEStep 5

Aim Create high level project estimate.


Solution Architect

Support from: • Technical Architect• Test Lead

Goals Captures the high level task breakdown required to create the solution and timescales against each item.

Also factor in rough order or magnitude for:• Solution Architecture and Design • Infrastructure design and provisioning • Project management • Development contingency • Deployments • Testing • Defect fixes • Production rollout tasks• Production support tasks • Overall contingency (% of total effort)

Having a means to trim scope if over budget.

Key Outcomes

Rough order of magnitude of the project implementation effort (days).

Issues Avoided

Under or overestimation of the project delivery timescales.

Estimated effort

1 day


FUNCTIONAL SPECIFICATION SIGN-OFFStep 6

Aim Sign-off functional specification.





• Product owners

Goals A final review of the system functionality and a signoff between business users and technical team.

Key Outcomes

• Firm formal agreement on deliverables and functionality to be delivered.

• A signed-off functional specification. A change request can be raised against this and the process of analysis/design should be familiar now and changes easy incorporate into this specification as updates.

Issues Avoided

Under or overestimation of the project delivery timescales.

Estimated effort

1 -2 days


DETAILED PROJECT ESTIMATE AND PROJECT PLANStep 7

Aim Detailed project estimate and Project Plan.



• Technical Architect

• Senior Technical Developer Leads

• UX/UI Design Lead

• Test Lead

• Project Manager

Goals Refine estimate based on detailed functional specification.

Key Outcomes

Firm estimate of project cost with minimum margin of error.

Issues Avoided

Project time and cost overrun.

Estimated effort

2 days


DETAILED TECHNICAL SPECIFICATION ANDStep 8

Aim Create a technical specification and architectural specification document.


• Technical Architect • Solution Architect • UX/UI Design Lead

Goals Captures the firm technical architecture and design specification that describes the low level details of the design.

The goal is to have it as detailed as possible within the constraints of project timescales.

Have firm documentation where the technical design and architecture are specified and described. These need to be maintained throughout the project lifetime.

Key Outcomes

An initial technical design and architectural document.

Issues Avoided

Fundamental physical design issues including:

• Platform and infrastructure

• Security

• Sub-system Interoperability

• Data sources and access

Estimated effort

10 days initially. Ever evolving.

11 © 2015 Velocity IT Ltd. All Rights Reserved. Reproduction and distribution of this document in any form without prior written permission is forbidden

ARCHITECTURAL SPECIFICATION DOCUMENT

www.velocity-it.com

SOLUTION BUILDStep 9

Aim Solution build


• Scrum master • Senior Technical Developer Leads • Technical Developers • Solution Architect • Test team

Support from: Technical Architect, UX/UI Designers, Business Analysts

Goals • Follow Scrum to build the solution in an iterative fashion. • The firm outputs from the pre-build phase ensures a smooth build process and exceptions can be dealt with easily. • Ability to be agile in the development process, but understanding that the solution is built on a firm design. • Being effective and efficient. • Outsource development effort to the strongest player for the job.

Key Outcomes

• A high quality solution based on firm inputs from business and technical stakeholders. • Successful deployment and utilisation of the solution. • Solution justifies the business case for it. • Makes business team efficient.

Issues Avoided

Project failure

Estimated effort

80-100 days (build only) Excluding theme, API, encapsulation service, platform configuration.


© 2015 Velocity IT Ltd. All Rights Reserved. Reproduction and distribution of this document in any form without prior written permission is forbidden. Velocity disclaims all warranties as to the

accuracy, completeness or adequacy of such information. Velocity shall have no liability for errors, omissions or inadequacies in the information contained herein or for interpretations thereof. The opinions expressed herein are subject to change without notice.

MORE INFORMATION

For more information on the contents of this paper, K2 solution delivery or customer requests for free

document templates referred to in this paper, please email [email protected]

www.velocity-it.com

velocity research: k2 solution delivery methodology · requirements are not clear or to explain...

Documents