Custom Software Development: Construction/Implementation

Developing custom software is a very complicated and often hard to understand process. It is filled with difficult to understand technical concepts, processes that are hard to value and pitfalls that often impact project timelines and budget. This document will explain the construction and implementation efforts that are critical to the software development process.

Milestones

Construction
The software construction stage is where software developers begin the “writing of code”, configuration of system components and integration to any other systems.

Rollout/System Implementation
The implementation stage is when the constructed software is placed into production and the organization begins using with real transactions, processes and output.

Construction

The software construction process consists of the iterative activities below:

Pre-coding/Platform Setup

• Setup of “Development Environment”, needed for Software Developers to perform their development activities and is a combination of the following components:
  • Database to store data
  • Code management tools to manage written system components
  • Setup web/mobile hosting platforms
  • Deployment tools for packaging code into “staging” and “production environments”
• Setup of “Staging Environment”, which is used by both Software Developers and Client teams to review/test system components (described as “User Acceptance and Testing” on following page).
  • Staging database
  • Setup web/mobile hosting platforms
  • User interface to review system logic and capabilities
  • Setup any “integrated systems” or other data feeds (if applicable)
• Setup of “Production Environment”, which is where all “live” data and capabilities are managed. Depending on the system and its objective the following may fluctuate.
  • Production database
  • Setup web/mobile hosting platforms for user interface
  • Setup any “integrated systems” or other data feeds (if applicable)

Construction/Development process:

• Mockups and the components in the design are planned for construction
• Milestones are established to develop independent running components of the system
• Features/Functionality are “coded” into components
• Demonstrable versions of the system are developed that produces the desired output from the associated input
• Basically, as components of the system are built they can be evaluated, tested and confirmed before integrating to other system components
• “Releases” are versions of completed Features, Functionality and Components ready for Client review and approval. Client understands that no more than one Release will be done per week.
• “Reviews” are scheduled meetings between Black Line and Client to discuss, evaluate, understand or otherwise clarify Feature, Functionality or Component behavior or rules. Each project will have a defined number of “Reviews” included in the budget (typically one hour in length) and Client acknowledges that additional meetings, or extended meetings, may impact the project budget.

User Acceptance/Testing (UAT):

• The objective of the UAT process is to engage the Client Subject Matter Experts to verify system functionality operates as intended.
• Features, functionality and components are approved by Client
• Critical to this process, is to identify missing requirements or adjustments to currently designed/defined components. This should be expected and planned for in the software development process
• Software Developers are interpreting the needs, rules and logic provided by another individual, this “knowledge transfer” process is not perfect because not every nuance of a system can be identified and documented
• Testing effectiveness is highly dependent on Black Line diligence and Client involvement
• Highly complex business logic or workflows need special attention by Client team
• It is common to find, uncover, or otherwise identify new requirements or adjustments needed to current design during the UAT process
• Another critical aspect of the UAT process is that Client users, who will depend on the system in their job role, will be getting trained at the same time as testing. Being exposed to the new system, insuring it operates and intended and working through the appropriate steps increases the level of “acceptance”.  Acceptance, and providing the opportunity for input, is the most critical component of a custom system.
• Once features are approved through the UAT milestone, the Client accepts responsibility for additional costs if adjustments are requested on previously “accepted” features, functionality or components.

Rollout/System Implementation

The Rollout or System Implementation process is where the system is actually placed into production to be used by Client and associated Team Members.  Typically, the system implementation process follows the steps in the order below:

Training:
Although the UAT process (defined above) should have covered most of the training necessary, there still may be final end-user training for those not included during the UAT process.

Policy/Process documentation:
As important to training on how a system functions, is the need for any supporting policy or process in support of the new system.

• Typically a new system will alter the way an organization operates, the workflow, the people responsible for certain tasks within and outside the system.
• It is very important to consider the organizational impact and adjust responsibilities and the associated processes accordingly.
• Providing policy gives guidance to end users to help make decisions and align their role with the data they are responsible
• Clients should expect time to be spent identifying and crafting policy to address new system capabilities

Workflow:
New systems almost always adjust an organization’s workflow because automation tends to improve efficiencies of impacted users.

• If the new system addresses manual processes then special attention should be applied to those organizational processes
• If workflow controls were added to an existing process then training or policy will need definition
• The above assumes that the organization wishes to avoid operational disruption that typically accompanies a new system

Data Conversion:
This part of the system implementation process is often the most critical, stressful and timing dependent than other aspects.

• In the case where there is an existing system that has data that is needed in the new system, a data conversion process is required.
• Converting data from one system to another is not an easy, straightforward or cost effective task.
• Depending on the system being converted FROM, there may be significant challenges gaining access to the data necessary and in a format usable/efficient by software developers.
• Other challenges:
  • Not all the data needed can be obtained electronically
  • The effort to extract data outweighs the effort to enter manually
  • Data extracted is formatted in a way that requires further “cleaning” before it can be used
  • Data “assimilation” to a new system requires numerous, time consuming and creative solutions to “mold” into the needs of a new system. For example, if a new system has a limitation on the number of characters or data type that is required in a new system
• Repeatable process
  • Typically the data conversion process is defined and tested in a non-production environment
  • This is intended to provide a “test” of the process to determine possible break points, data issues and determine how long the process takes “on the clock”.
  • This last step is very important for cutover planning to provide expectations to users when the system will be ready for production use.
• Validation/Verification
  • Also part of this effort is defining the reports or supporting data to help verify data was converted properly
  • For example, if financial information is being converted, then produce historical trial balance that will be compared to new system reporting

Cutover:
Cutover is the timing of numerous efforts and essentially the event of moving to the full production use of a new system.

• Data cutover
  • Leverages the work performed in the data conversion effort
  • Provide a “deployment window” that the system will be unavailable while the data conversion process takes place
  • Client expectations should be that both the old and new systems will be unavailable while this data process is completed
  • The primary reason for a gap is to eliminate the creation of new data while converted data is being applied to the new system
• Turn on any production integrations
  • Whether for external or internal systems
  • Switch the pointing of systems to the new system
• Cutover testing
  • Data verification is necessary (developed during data conversion step) to verify data conversion was successful
  • This testing may be extensive and should be considered as part of the cutover deployment window