Following the standard RUP for iteratively developing software, the first phase is inception. This is the time period during which teams develop a rough draft of the artifacts that will serve as initial talking points during the work flow design sessions with the business process owners and subject matter experts (SME). This phase constitutes all work on the artifacts that occurs prior to the first design workshop on a given process. With the start of the first workshop, these artifacts are marked final and new copies are created that will be maintained during the next phase of the method.

Phase 1 Requirements

Phase 1 will begin at least one (1) week prior to the start of the first process design workshop for a given work flow. The cost of entry to Phase 1 is the completion of the following action items:

• They are presented to the business
• Listing of the process actors defined and split between the appropriate elements of the PRPC organizational hierarchy (including the names of WorkBaskets).
• Pre-workshop meetings scheduled

During the design workshops, requirements for a process are defined and captured in the Microsoft Visio documents using a palette of PRPC shapes. The Use Case and Rules artifacts are likewise built during this time. Artifacts are maintained in an iterative manner during this phase:

• Process Owner(s) and SMEs must be educated on basic PRPC functionality to allow focus on workflow design and not explanations of PRPCs behavior
• The business identifies changes to the flows, rules and use cases
• The artifacts are updated after the workshop
• The artifacts are distributed prior to the next workshop for review and identification of further changes

After the first design workshop, the PRPC Architects are given the rough Visio flow documents in order to build a skeleton of the process on the PRPC platform that can be uses for illustration during the following workshops. During this phase, all changes to the work flow itself are kept up-to-date in both PRPC and the artifacts. In fact, in all workshops following the initial discussion of a process, all flow-related reviews occur on PRPC rather than using Visio (though a design team member does capture the changes in Visio) allowing for the business users to see, on the fly, how the changes they are requesting impact the flow of their process. The use of PRPC to drive further elaboration of the flow during these design workshops will replace the current prototype review process.

Phase 2 Requirements

Phase 2 will begin with the start of the first workflow design workshop associated with a process and conclude at the end of the final scheduled workshop. The cost of entry to Phase 2 is the completion of the following action items:

• Process Owner(s) and SMEs must be educated on basic PRPC functionality to allow focus on workflow design and not explanations of PRPCs behavior
• Established "rules" around what fields we can utilize for reporting, what data will be available from your Enterprise data store

Though the standard RUP method calls for the beginning of a Construction phase at this point, the waterfall approach to the design workshops that the Service Automation project has implemented does not allow for strict adherence to RUP. Instead, the elaboration phase is elongated to run through the Business Sign-off milestone for a given process in what will be called the Finalization phase. This allows for further definition, clarification and modification of the work flow design, Use Case and Rules artifacts to occur through conversations and reviews with the business process owner and SMEs. During this time which follows the conclusion of the final design workshop, no further active development occurs on the PRPC platform as the On-Shore PRPC Architects will be focussing their efforts on the Elaboration phase of the next process in flight.

Once Business Sign-off is obtained for a given process through the Business Review process, the artifacts are considered final and no additional updates will be made to them. This is in keeping with the designation of the artifacts as BRDs and no SRSDs. Instead, all continuing work on the approved process design occurs on the PRPC platform and changes are logged in HP Quality Center creating a full audit trail for changes to the process via which both the business users who request the changes and the developers implementing the changes are held accountable for the decisions and delivery of those decisions.

Phase 3 Requirements

Phase 3 constitutes the two weeks immediately following the end of the final Process Design Workshop. The cost of entry to Phase 3 is the completion of the following action items:

• Decision on any "global" issues / architecture/ data items finalized

It is in the Construction phase that development on the now-approved process begins in earnest. Though a rough skeleton of the process exists at this point in PRPC, little definition has been given to it in the form of fully usable screens, data validation, interaction with various source systems, et cetera. Construction is when the process will mature into a fully developed, deployable application.

Through weekly development reviews with the core business SMEs, the business process owner, the IBM and Prudential Organization Excellence designers and the On-Shore PRPC Architect, the workflow is scrutinized and changes are identified. A member of the User Acceptance Testing (UAT) team is responsible for logging those changes in HP Quality Center in real-time during the development reviews. This allows for a truly iterative approach to the development of the work flows in the sense that the application reviewed each week is constantly building upon itself, adding and refining features, until a comprehensive process is ultimately achieved.

At the conclusion of each development review, those updates to the work flow design are transferred to the Off-Shore development team for implementation prior to the next development review. This allows the business clear vision into the development process and a pro-active means by which to affect change to the work flow rather than the current reactionary method via which the business only sees snapshots of the process during prototype reviews and then a fully-developed, though not vetted, process at the beginning of UAT.

Phase 4 Requirements

Phase 4 constitutes the time period between the BRD Finalization phase and the beginning of testing. Obviously, a longer development cycle will lead to a more complete - and complex - process, though a time-box of four to six weeks would serve to create a reasonable balance of those two competing outcomes. The cost of entry to Phase 4 is the completion of the following action items:

• Approved, finalized BRDs
• FINAL screen design documents

Once the final development review is completed, testing of the process begins. Prior to testing, the flows that compose the process are exported from PRPC to Visio to serve as maps for the testing teams. During this time, no new changes should be implemented (though they may be identified and logged in Quality Center as Change Requests to be evaluated and potentially implemented in future releases). Instead, the focus should be on identifying defects in the process that will lead to incorrect execution in production.

By extending and providing a significantly greater level of transparency during the development phase, the testing and business groups should not be surprised by the execution of the flow thus driving a substantially shorter testing time frame.

Phase 5 Requirements

Phase 5 represents the time frame that exists between the declaration of a final developed process and the Go-Live (or Production) date. This should typically be a period of two - three weeks. The cost of entry to Phase 4 is the completion of the following action items:

• Developed Process
• FINAL Test Scripts