Accenture Fundamentals

A Typical Project Lifecycle

A Typical Project Lifecycle

At the very beginning
1. Client has a need. 2. Client submits a Request for Proposal (RFP)

Project starts. Plan Phase begins

1. Accenture creates a Current Capability Assessment a. Detailed picture of the clients current state or capabilities. b. We call this the As-Is. 2. Now knowing their As-Is, Accenture can research current industry best practices and current Accenture frameworks to discover opportunities that will meet the clients need. a. We call these potential opportunities the To-Be. 3. Accenture creates a proposal using the information they discovered. 4. Accenture submits proposal to client.

If the client likes Accentures proposal and/or likes the relationship Accenture has created with the client during the process, the client awards Accenture with the contract. Analyze Phase begins...
During this phase, the goal is to define the target (or the what). In order to do so, we need to ensure we have a complete understanding of the clients goals and requirements. There are many tasks that should be done at this stage but the most relevant ones are the following: 1. Analyze Business Processes a. Need to first read and understand the Scope Definition the list of To-Be business processes in-scope. i. In laymans terms, what can we do with the budget and time that we have? b. Accenture needs to schedule and conduct several interview meetings with stakeholders and business users to further understand the As-Is state and the To-Be business processes from the clients point-of-view. c. All information within these meetings is documented. 2. Identify Application Requirements

T00017 / A001 2011 Accenture. All Rights Reserved

Document1

Accenture Fundamentals

A Typical Project Lifecycle

a. During this time, Accenture needs to follow up with additional stakeholders and business users (in some cases these are the same people from Analyze Business Processes) to document functional, technical, and security requirements of theTo-Be application. b. After interviews, Accenture needs to consolidate interview notes, identify requirements and prioritize them. 3. Assess Process Gaps a. For most Accenture projects, the To-Be application is a vendor-packaged software. b. This vendor-package software includes built-in flexibility in the standard version of the software to allow a certain amount of customization to accommodate different customer needs. c. Knowing this, Accenture must complete a Fit/Gap Analysis to understand the missing capabilities (technical or functional requirements) of the software and how the packaged software needs to be configured to meet the clients requirements. i. Gaps Clients business process steps or application requirements NOT covered by packaged software ii. Fits Clients business process steps or application requirements covered by packaged software.

Important note: When clients do not want to use a vendor-packaged software, Accenture uses a Customized Software Solution. When using a customized solution, a Fit/Gap analysis is not needed because we wont have GAPS since the solution is customized to FIT the clients requirements. 4. Test planning a. Accenture needs to begin preparing for the Test Phase of the project to ensure the expected results are closely aligned with the clients requirements. b. In order to do so, we must begin writing our Test Conditions. c. All test conditions are documented in the Test Conditions and Expected Results (TCER) document. d. This document will be updated and refined throughout design and build stages to reflect the system as its built.

Once we have a complete understanding of the clients goals and requirements (the clients target), the Design Phase begins...

T00017 / A001 2011 Accenture. All Rights Reserved

Document1

Accenture Fundamentals

A Typical Project Lifecycle

During this phase, the focus shifts to defining how do we achieve the target. Weve already defined the client's current situation and what the end state needs to be, so now we need to detail how we will move the client to that end-state. 1. Designs vary depending on the project and it is different from Custom to Packaged applications. Normally it is done onshore. Designs are: a. Created based on prior deliverables b. Adapted to address constraints for a solution (e.g., quality, performance, technical requirements) c. Refined until it contains enough information to build and to be transitioned to another team. 2. Teams continue to refine and update the test plan to reflect the system as built.

Once designs are ready complete, the Build Phase begins...

1. Assuming the actual building is done offshore*, deliverables/items are transitioned to the Build Team. 2. During this transition, it is important that the design team communicates effectively to the Build team to ensure they completely understand their deliverables. 3. Someone from the design team will remain as a point- of-contact when the build team needs clarification on their deliverables. 4. Teams continue to refine and update the test plan to reflect the system as built. *It is quite common to complete the build phase offshore using our delivery centers in India, Manila and so on. This practice saves projects a lot of money.

Build is complete. The Test Phase* begins

Testing checks that a specification is correctly implemented and working properly. In testing we are trying to break the solution in a simulated and controlled environment. 1. Before executing the test plan, we must first create test scripts. To do this, we: a. Decompose the test conditions and expected results. b. Organize these them into logical, step-by-step procedures. c. Must add enough detail that they can be followed by someone unfamiliar with the application. 2. We then execute the test script. a. After each script step, the tester should compare the actual results with the expected results documented in the script. b. If a discrepancy is found, the tester verifies if the script step was followed correctly and data was accurate. c. If verified, discrepancy is documented as a SIR
T00017 / A001 2011 Accenture. All Rights Reserved 3 Document1

Accenture Fundamentals

A Typical Project Lifecycle

i. A SIR is a documented record of a defect, including what happened, when it happened, and what the tester expected would happen. ii. SIR is sent back to the Build team to fix the defect. iii. Build team fixes the defect and documents how they did so. iv. Tester retests *In many cases when build is complete, the offshore build team transitions the built deliverables back to the onshore team for testing.

All test scripts have been executed and discrepancies have been resolved. Now the Deploy Phase begins
Deployment is the last step in the project lifecycle and it is Accentures last chance to add value by bringing all the work done thus far to life within the clients organization. 1. Prepare the production and operating environments for application rollout to the users and other application stakeholders. 2. Enable users and other application stakeholders to use or support the new application. 3. Roll out the new application to the deployment groups. 4. Roll out the new organization plan to the deployment groups. 5. Transfer the responsibility for operating and maintaining the application to the operating group.

In the end
The CLIENT NEED has to align with the SOLUTION. If they are both aligned, we have a satisfied client. A satisfied client could potentially lead to future business opportunities/partnerships with Accenture.

T00017 / A001 2011 Accenture. All Rights Reserved

Document1