Elaboration and Design

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.

Supporting content for this phase:

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.

Supporting content for this phase:

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.

Supporting content for this phase:

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.

Below outlines available supporting content for this section:

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.

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:

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