User:Conrad.sanford/sandbox

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

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 RUP 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 principles are listed below.

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.

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

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

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.

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:

Transition Evolution is the cycle of: The team should carefully consider the impact of each of these Evolutions. Among these factors:
 * 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
 * 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.
 * 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.
 * 3) Parallel Evolution Cycles will require careful release management to ensure that all common solution components are available to subsequent Evolutions.

Analysis and Design Step
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
 * 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