Elaboration and Design

Upon completion of the solution analysis and planning phase, there should be a foundational understanding of the goals, scope and vision of the proposed solution. The elaboration and design phase expands upon prior work by delving deeper into identifying and documenting the business and technical requirements. The goal of the phase is to derive a target solution architecture, technical design and implementation plan. This phase has a typical duration of two-to-six weeks depending on the size of the project.

The major activities within the elaboration and design phase are:

Discover Business and Functional Requirements

This cycle works towards an in-depth understanding of the business and functional requirements that must be achieved by the solution. These discussions are usually led by business analysts (BAs) with participation from the implementation lead and should focus on identifying and reaching an agreement on the following:

  • The details of the business process(es)
    • Steps per process
    • Participants/routing logic per step
    • Actions needed to be performed for each step
    • Decision points
    • Data needs
    • Expected volumes
  • Reporting
    • Reporting requirements
  • Integrations
    • Which systems are to be integrated

It is very common for this phase to trigger significant internal discussion amongst the business and operational teams, as a business process automation project forces all parties to come to an agreement on standard operating procedures. It is extremely important to have business decision makers involved within the conversations to make sure decisions are made. Failure to have clearly-articulated business processes often has downstream impacts that result in reworking of developed components, as these requirements conversations usually re-appear during user testing if they have not been standardized early in the project life cycle.

There are a number of techniques to run such discovery workshops and gather requirements. For example, the business process model and notation (BPMN) standard is commonly used to document business process requirements for K2 solutions. Full details and guidance on how to gather and document requirements is beyond the scope of this site; however K2 does offer additional insight and assistance in this area through a training course designed for business analysts. If there is interest in preparing BAs to better understand how to refine their discovery and documentation skills within the context of K2 solutions, it is recommended that they attend this course.

We offer templates that are immediately usable by individuals tasked with documenting requirements, both for those new to working with K2 and for those who have previously rolled out K2 solutions. These templates allow for information to be captured in such a way that they will better translate to K2 design constructs when handed to the technical team in the following steps.

Common roles that participate within this phase are outlined below.

ROLE
DESCRIPTION
Technical stakeholder/sponsor
Owner of the IT implementation initiative – typically a manager/executive.
Business stakeholder/sponsor
Owner of the delivered solution – typically a manager/executive.
Business analyst/SME
Individual(s) familiar with the functional needs of the targeted solution.
Implementation lead/solution architect
Implementation lead/solution architect Individual(s) tasked with formulating the initial solution vision and architecture. Will drive this initiative through discovery, designing and planning phases.

Supporting content for this phase:

Supporting Content
DESCRIPTION
This template is useful for anyone tasked with gathering requirements for a K2 solution that is not familiar with the K2 tools and nomenclature. The verbiage in this document is not K2 specific, but will map to K2 functionality when provided to a knowledgeable K2 resource. The resource using this should also be familiar with gathering requirements for non-K2 elements such as forms and reports.
This template is formulated with more K2-specific nomenclature for those familiar with K2 tooling.

Evaluate Infrastructure and Integration Needs

Common areas of discussion in this phase include:

  • How many environments are needed for this new solution? (E.g., development, test, production and disaster recovery (DR))
  • What are the solution-level service level agreements (SLAs) needed for this new solution?
    • Recovery point objective (RPO) is the amount of data at risk, determined by the amount of time between data protection events and reflects the amount of data that potentially could be lost during a disaster recovery. This metric is an indication of the amount of data at risk of being lost.
    • Recovery time objective (RTO) equates to downtime. This metric refers to the amount of time it takes to recover from a data loss event and how long it takes to return to service. RTO refers to the amount of time the system's data is unavailable or inaccessible preventing normal service.
  • Are there any existing K2 environments?
    • If so:
      • Can these existing environments be leveraged for this new solution?
        • Do the versions in place support the required functionality for this new solution?
        • Do they have similar DR SLAs?
  • What non-K2 systems will need to be integrated into the solution?
  • What are the authentication and authorization needs of the end-to-end solution? With the above items well defined, the appropriate infrastructure can be proposed in the next phase. Common roles that participate within this phase are outlined below.
Role
DESCRIPTION
Implementation lead/solution architect
Individual(s) tasked with formulating the initial solution vision and architecture. Will drive this initiative through discovery, designing and planning phases.
Business analyst (BA)
Individual(s) that can speak to the business SLAs that need to be supported (especially around DR).
Various systems administrators (e.g., SharePoint, SQL Server, Active Directory)
As-needed administrators of various dependant systems to help ascertain integration and authorization considerations.

Supporting content for this phase:

Supporting Content
Description
K2 getting started guides
K2 product documentation that provides insight into how K2 blackpearl and K2’s SmartForms can be configured.

Create Functional and Technical Designs

The goal of this phase is to document the functional needs of the solution and the technical design to support that functionality.

The purpose of the functional design is to outline what needs to be accomplished by the solution to achieve the stated business requirements. This often involves a wireframe to review the user interface (UI) and Visio diagram to review the actual process workflow.

A functional design is targeted at an audience that may not have deep technical skills but must be able to evaluate the design goals and comment/assess validity of the proposed direction.

The purpose of the technical design is to articulate how to implement the concepts in the functional design. Specifically, the technical design lays out the details for what needs to be built.

The target audience for the technical design document are those with technical experience that have the capability to understand the technologies being discussed. The technical design document is often reviewed by various technical leads to sign off on the implementation architecture before being provided to the designers/developers on the implementation team.

Depending on the size and complexity of a project, the functional design and technical design may be one single document or separate documents.

It is important to note that this phase often leverages rapid application prototyping. This involves using K2 tooling to quickly mock up workflows, forms and system interactions in order to confirm functional needs as well as assess technical implications. These rapid prototyping sessions can be extremely valuable to ensure all parties have the ability to visualize what may be possible and react accordingly, instead of having to rely solely on conversations and documents. Upon completion of a prototype, the decisions associated with it should be factored into the functional and technical designs.

Role
DESCRIPTION
Implementation lead/solution architect
Individual(s) tasked with formulating the initial solution vision and architecture. Will drive this initiative through discovery, designing and planning phases.
Business analyst (BA)
Individual(s) that can speak to the business requirements, should any additional points of clarification be needed.
Various component design leads (e.g., SharePoint, UI, reporting, database)
As-needed resources tasked with leading the design and implementations of the various technologies within the solution.

Supporting content for this phase:

Supporting Content
Description
An example document that describes solution functionality. The intent is to permit a non-technical user to understand the look, feel and operations of the proposed solution and either sign off of intended functionality or provided feedback.
An example of a document that is at sufficient technical depth that should enable the implementation team to build the solution.

Develop Detailed Project Estimates

During this cycle, the various component leads (e.g., user interface, reporting, SharePoint, database) review the technical design document and formulate their respective work breakdown structures and estimate the level of effort to implement each. Considering the level of discovery and design work performed prior to this point, it is expected that this estimate be more detailed and refined than the earlier one done during the solutions, analysis and planning. It is the implementation lead’s responsibility to combine various estimates into a single solution estimate and provide to the project manager.

Common roles that participate within this phase are outlined below.

Role
DESCRIPTION
Implementation lead/solution architect
Individual(s) responsible for overall technical delivery that will work with the various sub-component (UI, database, SharePoint, workflow) architects to construct an estimate.
Various component design leads (e.g., SharePoint, UI, reporting, database)
As-needed resources tasked with leading the design and implementations of the various technologies within the solution.

Below outlines available supporting content for this section:

Supporting Content
Description
Provides a structured approach to a detailed estimate. This requires a thorough understanding of the technical design from which the estimate calculation can be executed.

Identify Milestones and Versions

This sub-phase focuses on reviewing the design and detailed estimates, and determining a phased-implementation approach that permits for sharing progress early and often. Additionally, this phase focuses on enabling structured change through the overall solution lifecycle.

The phased implementation approach is based upon tangible shorter term goals called milestones. Project milestones are based upon a achieving a discrete set of functional requirements, including build, test and review cycles.

Multiple milestones can be grouped together into a version. A version is what may ultimately be deployed to production. The main participants within this phase are the project manager, implementation lead and business stakeholders, who work in conjunction to determine the proper balance of business value and technical foundation when determining the milestones and versions.

In addition to quicker visibility into progress, the milestone-based approach uses smaller deliverable sets to enable more granular test cycles and the ability gather feedback sooner. This is much more efficient than a “big bang” delivery type, which tries to fit most, if not all, functionality into a single deployment.

The purpose of this planning sub-phase is to review the work breakdown structure and identify milestones, slot milestones into deployable versions, and then formulate the project roadmap. Milestones can be of varying length, but it is common for them to be anywhere from two-to-four weeks in duration. Versions usually include multiple milestones. The key to scoping a version is to identify a combination of milestones that will can be deployed as a discrete unit that provides business value.

Common roles that participate within this phase are outlined below.

Role
DESCRIPTION
Business stakeholder/sponsor
Owner of the delivered solution – typically a manager/executive.
Business analyst / SME
Individual(s) familiar with the functional needs of the targeted solution.
Implementation lead/solution architect
Individual that is responsible for all elements of the technical solution architecture.
Project manager
Individual that aligns various perspectives to formulate the milestone and version roadmap

Formulate Project Plan and Resourcing

Upon completion of milestone and version planning, a project plan will be developed that outlines the delivery schedule for all milestones and versions. With a project plan in place, resourcing can then be determined.

For additional considerations around potential project roles, please refer to the project resource planning document.

Below outlines available supporting content for this section:

Supporting Content
DESCRIPTION
This is an example of a K2 project plan that can be used to understand common tasks and resource assignments. This is a reference only and should not be considered a statement of potential durations and resourcing needs for a specific project.
A resource capability plan that covers the roles involved in typical K2 projects. Each role has a list of typical areas of responsibility, skills required, and levels of expertise for each skill.

Upon completion of all of these steps, the implementation phase is ready to begin.

Initial Discovery

This phase focuses on understanding the high level goals, needs and timelines for the potential project. This is typically a one-to-four hour meeting in which the key stakeholders of the solution, such as business subject matter experts (SMEs), technical leads and/or project manager(s) have a discovery conversation with the leads from the potential implementation team (referred to as business architect and technical architect).

Solution Analysis and Planning

The solution analysis and planning phase is the entry point into solution functional scoping and project planning. The goals of this phase are to identify project critical success factors, as well as discover initial functional scope/business requirements and technical drivers and integrations. This phase is typically lead by the business architect and the technical architects leveraged during the initial discovery phase.

Implementation

Milestones are best implemented by following a build, test and review cycle. This section goes into detail on who should be involved and best practices to follow.

Roll Out

The roll out phase occurs when a version is deployed to the production environment and becomes operational within the business unit. Learn how to coordinate a roll out across multiple stakeholder groups.