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.

Below outlines available supporting content for this section:

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.

Below outlines available supporting content for this section:

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.

Below outlines available supporting content for this section:

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.

Below outlines available supporting content for this section:

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.

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:

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