Evolve methodology

The Evolve Methodology ©

CRM Best Practices Fit to IT Standards

Authentia Software, Inc.

499 Electric Avenue
Fitchburg, MA 01420
[978] 874-0898

Prepared by: Conrad Sanford
President

Published: June 3, 2007
Revised: December 29, 2010

Version 1.1

The Evolve Methodology copyrighted 2012, Authentia Software, Inc.

Authentia Software, Inc. The Evolve Methodology

Table of Contents

Introduction.........................................................................................................................3
Evolve Framework...............................................................................................................5
Process Principles.............................................................................................................5
Develop iteratively.......................................................................................................5
Manage requirements.................................................................................................6
Use components..........................................................................................................6
Model visually..............................................................................................................6
Verify quality................................................................................................................6
Control changes...........................................................................................................6
Evolve Process Phases......................................................................................................7
Inception Phase................................................................................................................7
Pre-engagement Scoping Step.....................................................................................7
Solution Definition and Project Design Step................................................................8
Evolution Phase................................................................................................................8
Analysis and Design......................................................................................................9
Construction and Validation Step................................................................................9
Deployment Transition Step........................................................................................9
Retrospection Phase......................................................................................................10
The Evolve Plan..................................................................................................................11
Client Participation........................................................................................................11
Delivery Evolutions........................................................................................................12
Artifact Density..............................................................................................................13

Table of Figures

Figure 1: The Evolve Process Phases....................................................................................7
Figure 2: Resource Roles Allocation...................................................................................11
Figure 3: Requirement Groups..........................................................................................12
Figure 4: Artifact Sequence Plan........................................................................................14

Page 2 of 14


Introduction
Evolve is a methodology which augments existing approaches by addressing one of the
major obstacles in the implementation of enterprise CRM solutions, which is adapting
best project design practices to diverse IT organizations. Adhering to these best
practices found in CRM solutions such as Oracle, Salesforce.com and SAP reduce risks to
project objectives which include management of scope and cost, high user adoption,
and delivery schedule.
It is neither possible nor desirable for a consultancy to impose a common project
methodology on all client IT organizations. IT organizations differ greatly based upon the
businesses they support, which is frequently a function of standards for their industry
and maturity of the company, as well as the technical and management styles of the IT
teams.
While there is boundless diversity in the spectrum of organizations, three business types
are notable in their characteristic treatment of enterprise solution projects:
▪ “Entrepreneurial” organizations are small and work to achieve rapid growth,
frequently showing an urgency that will drive iterative deliverables and require
few supporting project artifacts. Frequently the project mission is informally
stated or presumed. They have a high tolerance for risk with few formal
processes in place. Fewer processes allow them to be more adaptable to
schedule changes. Characteristically limited in funding, they have a low tolerance
for increases in planned costs.
▪ “Classic” organizations are mid-sized to Fortune 1000 that have few business
external constraints other than market dynamics. The project mission is typically
documented at the executive level and may be obscure to some project team
members. Frequently they apply a variant of the “waterfall” methodology in
implementing solutions. Willingness to assume is often a function of how
“mission critical” the solution is to the business. Changes impacting users’
delivery expectations are unacceptable and minor variations in project costs are
frequently planned for in the overall IT budget.
▪ “Regulated” organizations may be of any size and are constrained to follow
replicable processes and document quality processes used to develop the
solution. Project missions are documented, reviewed, and published to a project
folder. Projects are phase gated requiring many standardized artifacts, having
resource intensive validation requirements. This validation often makes iterative
delivery prohibitive. Regulated solutions adhere to strict processes designed to
reduce risk. There is a high sensitivity to changes in schedule where changes
could impact commitments to regulating agency. Projects typically have more
funding to accommodate overhead for regulated processes.
Incumbent to these business types are their distinct tolerances to the risks related to
project objectives as measured in terms of cost, time, scope, and quality. These distinct

Page 3 of 14


tolerances challenge many consultancies in rationalizing their differences while trying to
apply best practices in implementing the client’s solution. This rationalization process is
often performed implicitly on the part of the implementation team, unstated to the
project governance, posing the real risk of causing missed expectations between the
client’s and consultancy’s team members.
The interaction between the client and the consultancy has a direct impact on the
project objectives which can be managed. This management can occur as an agreement
between the team members who possess client institutional knowledge and delivery
best practices. There are three distinct aspects of a project where this interaction can be
performance tuned to ensure that the project process is optimized to meet the mission:
▪ Client Contribution: The type and extent of client participation during the
delivery process. In all client delivery models, there is client interaction with the
project team – at a minimum – when providing requirements, validating solution
conformance to requirements, and production deployment.
▪ Iteration: The optimization of development cycles. The decision to use
“waterfall” delivery or to select an iterative approach can be made explicitly
based upon the IT organization business type and the deployment of the
solution. Many solutions lend themselves readily to iterative development
where, for example, the contact center team is asked to use the CRM and billing
systems separately until they are integrated as one.
▪ Scope of Deliverables: The complete set of deliverables expected by the team
during the course of the project. These include software, documentation, and
training.
Thus, performance tuning these areas during project design will form an agreement
between client and consultancy where best CRM practices can be harmonized with the
existing IT project approach.

Page 4 of 14


Evolve Framework
The Evolve Methodology defines a framework to transcend the implementation steps,
enabling the client’s and consultancy’s team to (a) explicitly design the delivery process
steps and (b) communicate using a common terminology to describe the dynamics of
this framework. This effort of defining the project framework is done as a function of
the project scoping effort. The result is software development lifecycle phase with clear
expectation about the solution and the process. A project performance analysis is
conducted once the solution has been fully transitioned to production, which then
completes the cycle.
The Evolve Methodology is based upon the principles of the RUP1 methodology, but
extends beyond solution delivery and can be used from the project’s conception for ROI
analysis and RFP development. Some of the major guiding principles2 are listed below.
Update 12/29/10
The principles of the Salesforce Adaptive Delivery Methodology align with the Evolve
Methodology. These principles have been presented3 as:
▪ Eliminate Waste
▪ Build Quality In
▪ Respect People
▪ Optimize the Whole
▪ Create Knowledge
▪ Just-in-time Decisions
▪ Deliver Fast
▪ On time, high quality, Innovation

Process Principles
Develop iteratively

It is best to know all requirements in advance; however, often this is not the case.
Several software development processes exist that deal with providing solution on how
to minimize cost in terms of development phases.

1
The Evolve philosophy is rooted in the Rational Unified Process (RUP) developed by Rational Software Corporation, now a division
of IBM since 2003. RUP offers an iterative software development process framework rather than a single rigid prescriptive process,
essentially providing an adaptable process framework, intended to be tailored by the development organizations and software
project teams that will select the elements of the process that are appropriate for their needs.

2
Stephen Schach (2004). Classical and Object-Oriented Software Engineering. 6/e, WCB McGraw Hill, New York, 2004.

3
Salesforce Presentation, December 10, 2010, “Agile Development for Force.com”

Page 5 of 14


Manage requirements

Always keep in mind the requirements set by user.

Use components

Breaking down an advanced project is not only suggested but in fact unavoidable. This
promotes ability to test individual components before they are integrated into a larger
system. Also, code reuse is a big plus and can be accomplished more easily through the
use of object-oriented programming.

Model visually

Use diagrams to represent all major components, users, and their interaction. "UML",
short for Unified Modeling Language, is one tool that can be used to make this task
more feasible.

Verify quality

Always make testing a major part of the project at any point of time. Testing becomes
heavier as the project progresses but should be a constant factor in any software
product creation.

Control changes

Many projects are created by many teams, sometimes in various locations; different
platforms may be used, etc. As a result it is essential to make sure that changes made to
a system are synchronized and verified constantly. One tool used for this is Concurrent
Versions System.

Page 6 of 14


Evolve Process Phases
The Evolve methodology focuses on optimizing risks related to project objectives as
measured in terms of cost, time, scope, and quality through managed process steps to
deliver the CRM solution using best practices. These process steps are depicted in Figure
1.

Figure 1: The Evolve Process Phases

Inception Phase
Pre-engagement Scoping Step

The first step in preparation is pre-engagement scoping and begins with a dialog to
understand the business mission and goals for the project’s results. Once this is
achieved, the current maturity of the project is assessed. This maturity may range from
“project concept only” to minor functionality enhancements, and typically determines
the consultancy’s entry point and value in assisting the client with the solution.
Early project entry points include ROI analysis, project scoping, and assistance with
proposal development while later entry points may include solution development from
existing specification or validation of a solution according to requirements.
During the preparation step, the details of the Evolve Methodology are reviewed with
the team and the operating characteristics of the business and IT organization are
understood, including an assessment of the client’s project constraints. For example,
project artifact requirements imposed to meet process needs in a regulated
environment.
In addition to understanding the project’s high-level requirements and scope, the
analysis conducted during this step will include decisions regarding the client
participation, Evolution Cycles, and artifact density which will be documented in the
Evolve Plan.
From this analysis, cost estimates will be determined and a method for tracking planned
versus actual expenditures. This cost tracking approach typically employs the earned
value method recommended by the Project Management Institute.

Page 7 of 14


Solution Definition and Project Design Step

Project Inception is the first step in the engagement with the client and will finalize the
project design in preparation for Evolution Cycles and offer a preliminary solution design
model.
In new implementation, out of the box functionality will be demonstrated to elicit a high
level understanding of solution gaps, along with identifying risks and their mitigations.
Develop primary use cases and essential architectural prototypes needed for proof of
project success completes this step.

Evolution Phase
The iterations defined within the Evolve Plan are executed and the steps in the
Evolution Phase are iteratively completed until the final solution is transitioned to
deployment. During each Evolution the work breakdown structure is updated.
There are two distinct types of delivery evolutions, construction and transition, both of
which are iterative solution development where there is one or more iteration. These
two evolution types are not mutually exclusive, and may be used sequentially or in
parallel with each other.
Construction Evolution is the cycle of:
1. Performing requirement analysis
2. Functional and technical software design
3. Software construction which includes configuration and customization of the
application
4. Validation of the software against the requirements
5. Beginning of the next Evolution Cycle once the software is validated
Transition Evolution is the cycle of:
1. The steps outlined in the Construction Evolution
2. Deployment to production
3. Training of user and those supporting the users
4. Support for the deployed solution
5. Beginning of the next Evolution Cycle once the software is deployed and
supported.
The team should carefully consider the impact of each of these Evolutions. Among these
factors:
1. Validation may require a full regression pass on each iteration.
2. Construction Evolution may offer faster delivery to final production at the
expense of loosing production user feedback, valuable to additional Evolutions.

Page 8 of 14


3. Parallel Evolution Cycles will require careful release management to ensure that
all common solution components are available to subsequent Evolutions.

Analysis and Design

The consultancy works with the business and technical resources assigned to identify
and document detailed solution requirements from which a solution design can be
created.
Business models are documented and validated from team efforts with the business
community and its subject matter experts, typically involving use-cases and
storyboarding modeling. Gap analysis is conducted from the results of these business
models, and the project plan and identified risks are updated. Solution deliverables for
the Delivery Evolution are defined.
Solution design documents are developed and validated with the client. These design
documents include:
▪ A description of the software architecture in a software system development
process
▪ An executable architecture that realizes architecturally significant use cases
▪ A development plan for the overall project
▪ Prototypes that demonstrably mitigate each identified technical risk.

Construction and Validation Step

Software developers work from the specifications created in the analysis and design
step to configure and customize the client solution. Unit testing is performed on the
developed solution. Any additional technical risks are identified and a mitigation plan is
formed by the project team.
Structured validation testing is conducted by the business users who typically
participated in defining the detailed functionality during the analysis and design step.
The structure of this testing will be validated by a traceability matrix if this formal
process has been required in the Evolve Plan.
If the validated software was part of a Construction Evolution then it will become a part
of the baseline software for continued development; otherwise, will be deployed to the
targeted users.

Deployment Transition Step

The solution or a subset of the solution is transitioned from the development group to
the production environment. This transition contains several steps:
▪ Training is provided to the targeted users and those supporting the users and the
environment

Page 9 of 14


▪ Configuration items and customizations are packaged from the reference test
environment and installed on the production environment
▪ Functional testing of the production environment is completed
▪ Larger projects may stage this deployment to a beta test group for validation
against user expectation prior to general release.
▪ Deployment and user adoption risk are identified and mitigated
▪ The Evolution Phase is repeated if all requirements have not been incorporated
into the solution.

Retrospection Phase
The Retrospection Phase provided a means of project closure where final agreement
between the client and consultancy occurs. It is completed when all required
functionality has been transitioned to production.
Based upon determination at Inception Phase, it ensures that:
▪ Solution delivery to the project’s mission is validated
▪ Obstacles in planned user adoption are resolved
▪ The project’s ROI is re-computed and compared against the original ROI estimate
▪ Project artifacts, including solution and process items, are evaluation for future
repurposing
▪ Best practices models are updated
▪ Final Project sign off occurs and a plan for follow up is documented

Page 10 of 14


The Evolve Plan
The Evolve Plan is the document which formalizes and documents the three distinct
aspects of a project where the project process can be performance tuned to ensure that
it meets the mission.

Client Participation
The Resource Role Allocation table in Figure 2 illustrates the recommended client’s
team contribution to specific efforts within the project. Project Performance can be
tuned by the project team to optimize characteristics for the client organization. For
example, the team may determine that more client resources should participate in user
acceptance test and have solution champions from each department to reduce the risk
of low user adoption while increasing the overall cost of the project.
Resource Role Allocation
InceptionSolution Definition and Project Design Evolution Retrospection

Construction and Validation
Pre-engagement Scoping

Deployment Transition
Analysis and Design

Participants

Client Project Sponsor ■ ■ ■ ■
Project Stakeholders ■ ■ ■ ■ ■
Subject Matter Experts ■ ■ ■ ■
Business Users ■ ■ ■
Technical Staff ■ ■
Consultancy Project Manager ■ ■ ■ ■ ■ ■
Business Analyst ■ ■ ■
Technical Architect ■ ■ ■ ■ ■
Development Team ■ ■
Training Specialist ■ ■
Figure 2: Resource Roles Allocation

Page 11 of 14


Delivery Evolutions
Delivery Evolutions sets of requirement groups, referred to as Sprints in the Scrum Agile
methodology4. Each requirement classified into an Evolution Cycle where, at the
conclusion of each cycle, these requirements maybe reclassified based upon:
▪ Unforeseen, additional functionality delivery in the cycle
▪ Unforeseen deficiencies in the functionality delivered which may be
incorporated into a following iteration.
▪ Change orders dictating functionality updates.
▪ Feedback from validation, training or production deployment users
The Figure 3 provides a means for which to classify high-level requirement groups
during the Solution and Project Definition

Requirement Groups
Evolution Cycles
One Two Three Four
EvolutionConstruction



NumberRequirement

Transition Evolution


Description

1.0.0.0 High Level Requirement 1 ■
Figure 3: Requirement Groups

4
Schwaber, Ken (1 February 2004). Agile Project Management with Scrum. Microsoft Press. ISBN 978-0-735-61993-7.

Page 12 of 14


Artifact Density
Artifacts are all of the assets created or associated with the project from Inception to
Retrospection. Artifact assets have five classifications which are:
▪ Process – Project plan, Evolve Plan, communications plan, change requests,
status reports.
▪ Requirements – Use cases, storyboards, flowcharts, data samples
▪ Application Access – Prototype, development, test, and production instance of
the CRM environment, including user logins
▪ Application Modifications – Configuration and customization of the CRM to meet
identified requirements including applets, interfaces, etc.
▪ Training and Documentation – Context sensitive application help,
Documentation describing all changes from “out-of-the-box” CRM, training and
on-line training guides, workbook of all CRM collateral, including “how-to’s”,
checklists, and “cheat sheets”
The density of these artifacts refers to the extent to which these items are needed to
meet the needs of the project team and the business it supports. Figure 4 illustrates a
sample of the artifacts associated with each classification in the Evolve Steps.

Page 13 of 14


Sample Artifact Sequence Plan
Inception Evolution Retrospection

Solution Definition and Project Design

Construction and Validation
Pre-engagement Scoping

Deployment Transition
Analysis and Design
Type key:
(P) Process
Type (R) Requirements
(A) Application Access
(M) Application Modifications
(D) Documentation
(T) Training

Artifact
P Project mission statement ■
P/R Existing project documentation ■
P Evolve Methodology Whitepaper ■
P Proposal to client ■
P Communications Plan ■ ■
P Evolve Plan ■
P/R Project Charter and Sign-off ■
P Resource Role Allocation ■
P Risk Assessment & Mitigation Plan ■ ■ ■ ■ ■
R Application Security Requirements ■
R Detailed Design Document ■
R Gap Analysis ■
R Validation Plan ■
R Cutover Plan ■
P/R Data Migration Plan ■ ■
P Retrospection Document ■
A Solution Development Instance ■
A Solution Test Instance ■
A Production Instance ■
A User Roles and Accounts ■ ■
M Configuration Files ■
M Solution Customizations ■
P Test Cases and Test Scripts ■ ■ ■
D Application Documentation ■ ■ ■
D Embedded Customization Comments ■
T Training Guide ■ ■
T Training Video ■
Figure 4: Artifact Sequence Plan

Page 14 of 14

Evolve methodology

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à Evolve methodology

Similaire à Evolve methodology (20)

Evolve methodology