Elaboration and Design

Upon completion of the SA&P phase there should be a foundational understanding of the goals, scope and vision of the proposed solution. The Elaboration and Design phase expands the prior work by delving deeper into identifying and documenting the business and technical requirements in order to drive to derive at a target solution architecture, technical design and implementation plan. This phase can be of a short duration depending on the size of the project.

The major activities within the Elaboration and Design phase are:

Discover Business & 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 Analysis (BA) with participation from the Implementation Lead. These conversations should focus on identifying and coming to an agreement on the following:

  • The details of the business processes
    • Steps per process
    • Participants and routing logic per step
    • Actions needed to be performed for each step
    • Escalation points
    • Decision points
    • Data needs
    • Expected volumes
  • Reporting
    • What reports are needed and details around composition?
  • Integrations
    • What systems are to be integrated?

It is very common for this phase to trigger 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 important to have business decision makers involved within the conversations to make sure decisions are made. Failure to have clearly articulated business decisions will surface during testing or demo’s and will have downstream impacts that may result in reworking of developed components.

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 document; 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.

K2 does have templates that are immediately usable by resources tasked with documenting requirements. 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.

Note: Keep in mind that exact roles can change based upon specific project needs. Additionally, it is common for individual people to be responsible for more than one role.

ROLE
DESCRIPTION
Technical Stakeholder / Sponsor
Person who will own the IT implementation initiative. This is typically a manager / executive.
Business Stakeholder / Sponsor
Person who will own delivered solution. This is typically a manager / executive.
Business Analyst / SME
Person who is familiar with the functional needs of the targeted solution.
Implementation Lead / Solution Architect
People that are tasked with formulating the initial solution vision and architecture. They will drive this initiative through discovery, designing and planning phases, with the implementation lead continuing on to delivery.

Below outlines available supporting content for this section:

Supporting Content
DESCRIPTION
This template is useful for anyone tasked with gathering requirements for a K2 solution. The resource using this should also be familiar with gathering requirements for all K2 elements such as forms and reports.

Evaluate Infrastructure and Integration Needs

As part of the solution planning stages it is important to understand and plan for the infrastructure to support this solution. Common areas of discussion 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 (SLA) needed for this new solution?
    • Recovery Point Objective (RPO) – is the amount of data at risk and is 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. The 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 then 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 other 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.

Note: Keep in mind that exact roles can change based upon specific project needs. Additionally, it is common for individual people to be responsible for more than one role.

Role
DESCRIPTION
Implementation Lead / Solution Architect
People that are tasked with formulating the initial solution vision and architecture. They will drive this initiative through discovery, designing and planning phases, with the implementation lead continuing on to delivery.
Business Analyst (BA)
Person who is familiar with the functional needs of the targeted solution and specifically understands the mission criticality of the system and supporting SLA’s.
Various Systems Administrators (e.g. SharePoint, SQL Server, Active Directory…)
As needed, administrators of various dependant systems to help ascertain integration and authorization considerations.

Below outlines available supporting content for this section:

Supporting Content
Description
The technical documentation contains sample diagrams to capture the required information.

Create Functional & Technical Designs

The goal of this phase is to document the functional needs of the solution and the technical design to support that functionality. A functional design outlines what needs to be accomplished by the solution to achieve the stated business requirements. This often involves a wireframe (UI) and Visio (workflow) level of depth. For example:

Thus 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 help assess validity of the proposed direction.

The technical design’s purpose is to articulate how to implement the concepts in the functional design. Specifically, the technical design will lay out the details around what needs to be built. The target audience for the technical specification is experienced technical resources have the capability to understand the technologies being discussed. The technical specification is often reviewed by the various technical leads to sign off on the implementation architecture and then both it and the functional specification are provided to the developers on the implementation team to be the basis from which the build effort will based.

Depending on the size and complexity of a project, the functional design and technical design may be one single document or separate documents. Examples of a functional design and technical design are provided at the end of this section in the Supporting Contents table.

It is important to note that this phase often leverages rapid application prototyping. This involves using K2 tooling to quickly mock up workflows, SmartForms 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 respective parties have the ability to visualize what may be possible and react and discussion 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.

Common roles that participate within this phase are outlined below.

Note: keep in mind that exact roles can change based upon specific project needs. Additionally, it is common for individual people to be responsible for more than one role.

Role
DESCRIPTION
Implementation Lead / Solution Architect
People that are tasked with formulating the initial solution vision and architecture. They will drive this initiative through discovery, designing and planning phases, with the implementation lead continuing on to delivery.
Business Analyst (BA)
Person who is familiar with the functional needs of the targeted solution and specifically understands the mission criticality of the system and supporting SLA’s.
Various Systems Administrators (e.g. SharePoint, SQL Server, Active Directory…)
As needed, administrators of various dependant systems to help ascertain integration and authorization considerations.

Below outlines available supporting content for this section:

Supporting Content
Description
An example of a 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 the intended functionality or provide feedback.
An example of a document that is at sufficient technical depth that will 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…) will review the technical design document and formulate their respective work breakdown structures and then 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 (SA&P phase). Please refer to the Supporting Content table at the end of this section for a reference to an example K2 Estimating template. 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.

Note: keep in mind that exact roles can change based upon specific project needs. Additionally, it is common for individual people to be responsible for more than one role.

Role
DESCRIPTION
Implementation Lead / Solution Architect
People that are tasked with formulating the initial solution vision and architecture. They will drive this initiative through discovery, designing and planning phases, with the implementation lead continuing on to delivery.
Business Stakeholder / Sponsor
Person who will own delivered solution. This is typically a manager / executive.
Various Systems Administrators (e.g. SharePoint, SQL Server, Active Directory…)
As needed, administrators of various dependant systems to help ascertain integration and authorization considerations.

Below outlines available supporting content for this section:

Template
Description
The same spreadsheet used to provide an initial estimate for a K2 project based now gets refined in this Elaboration & Design phase. The initial estimate may go up or down at this time.

Identify Milestones and Versions

This sub phase focuses on reviewing the design, detailed estimates and determining a phased implementation approach that permits for the displaying of value and progress early and often. Additionally, this focuses on enabling structured change through the overall solution lifecycle. This is achieved by leveraging a phased implementation approach based upon tangible shorter term goals. These short term goals / deliverables are called milestones. A milestone is based upon achieving a discrete set of functional requirements and is comprised of the build, test and review cycles (details on these are provided later in this document). Multiple milestones can be grouped together as a version. A version is what will ultimately be deployed to production. The main participants within this phase are the Project Manager working in conjunction with the Implementation Lead and Business Stakeholders to determine the proper balance of business value and technical foundation when determining the milestones and versions.

In addition to quicker visibility into progress, this milestone based approach’s usage of smaller units of deliverables also enables more granular test cycles as well as ability to gather feedback sooner. Thus it handles change more efficiently, as compared to solution deliveries that focus on big bang type of development efforts that try to include 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. Then 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 around 2 weeks in duration. A single version will 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.

Note: Keep in mind that exact roles can change based upon specific project needs. Additionally, it is common for individual people to be responsible for more than one role.

Role
DESCRIPTION
Business Stakeholder / Sponsor
Person(s) who will own delivered solution. This is typically a manager/executive.
Implementation Lead / Solution Architect
People that are tasked with formulating the initial solution vision and architecture. They will drive this initiative through discovery, designing and planning phases, with the implementation lead continuing on to delivery.
Business Analyst (BA)
Person who is familiar with the functional needs of the targeted solution and specifically understands the mission criticality of the system and supporting SLA’s.
Project Manager
Works to align various perspectives to formulate the milestone and version roadmap.

Formulate Project Plan and Resourcing

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

Below outlines available supporting content for this section:

Supporting Content
DESCRIPTION
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.
Project Management Tool
Online tools are typically used, options include TFS, MS Project, TeamWork, Jira, etc.

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 less than a couple of hours of conversation where the key stakeholders of the solution, such as business subject matter experts (SME), technical leads and project manager have a 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 to discover initial functional scope, business requirements, technical drivers and integrations. This phase is typically lead by the Business Architect and the Technical Architect leveraged during the Initial Discovery phase. Once the functional and technical factors are determined, a high-level solution vision and reference architecture can be formulated to articulate how the key components of the proposed solution can be aligned and leveraged to achieve the functional requirements. Additionally, initial infrastructure planning can be formulated to support the project needs. With this reference architecture in place, initial estimates can be formulated and work breakdown structures generated to allow for initial project costing; allowing for more detailed budgeting and planning discussions.

Implementation

The below Build, Test and Review cycles fall within a given milestone. This section goes into detail on who should be involved and best practices to follow.

Roll Out

The rollout phase is when a version is deployed to the Production environment and becomes operational within the business unit. This requires planning and coordination across multiple units.