In certain situations, you may be able to condense the project duration by using acceleration techniques.
Eliminate Checkpoints
The Project Management Method (PJM) imposes phase start and completion checkpoints that are valuable for project management and control, but may disrupt natural process/task overlap opportunities and project flow. In large, complex implementations, the formal phase signoffs may be needed for scope and risk management. Using the standard AIM tailored approach is still the best way to control a project and mitigate risk.
In smaller, less complex projects, there may be opportunities to expedite project activities with an acceptable degree of risk by collapsing tasks within a phase.
AIM processes are conducted with resources and time frames optimized to achieve the earliest possible go-live date. However, by accelerating implementation, you assume a greater risk that some
requirements may be missed, or that you may not achieve quality comparable to that of a tailored approach.
Before you decide to use a pre-packaged approach or an accelerated tailored approach, analyze the associated risks, and weigh the cost and benefits of an early implementation against potential problems after production.
Other considerations:
• If there is uncertainty regarding any aspect of the project, use
the AIM foundation tailored approach to implement good checkpoint and risk management.
• By using multiple parallel business process definition/mapping,
teams can speed up Definition and Operations Analysis. Mitigate risk for this technique by assigning a specific process team for cross-process integration. Use a project data
repository, such as Oracle Designer, for custom developed solutions. The repository automatically cross-validates designs and enforces integrated solutions.
• If there are minimal large, complex customizations, begin work
on them early because of the time frames required for
designing, building, and testing major customizations. It may be possible to selectively overlap specific customizations. To further mitigate risk, define a formal subproject specifically for a given customization.
Consolidate Phases
Operations Analysis
Process teams formed within a business function to define requirements should continue into requirements mapping.
Business Requirements Scenarios (RD.050) created during Definition are mapped to the applications during Operations Analysis. The process teams create scenarios that represent how the process driven business requirements can be satisfied using the standard application features. The goal is to arrive at a new system that satisfies the business needs of the users, resolves current system problems, and optimizes process efficiency. The new system is a combination of several components: application setups, application supported process steps, manual processes or process steps, system features, reports, and background processes.
These prototype solutions are interactively developed by project team members, key users, and application consultants. The application consultants enable features, set system parameters, and guide process mapping to illustrate how the new system supports proposed scenarios. This process continues until a new system design is arrived at, or an application-process gap is identified.
This prototyping method expedites the requirements mapping process by capitalizing on the early knowledge transfer in both directions, from process teams to application consultant, and from application
consultant to process teams. Internal resources can save time by relying more heavily on the consultant’s participation and interpretation of requirements. Less reliance is placed on users’ grasp of new system functionality and experimentation to arrive at the optimal new system design. Therefore, the project team and users can concentrate on business process design and leave the mechanics of application set up to the consultants.
A repetitive implementation process task cycle for business processes is performed multiple times for different subject areas. For example, the Current Business Baseline (RD.020), Future Process Model (BP.080), Business Requirements Scenarios (RD.050), and Business Requirements Mapping Forms (BR.030) occur for each business process. An example is shown in the following figure:
Current Business Baseline (RD.020) (Receiving Process) Current Business Baseline (RD.020) (Payment Process) Current Business Baseline (RD.020) (Procurement Process) Baselining Map Business Requirements (BR.030) (Receiving Process) Map Business Requirements (BR.030) (Payment Process) Map Business Requirements (BR.030) (Procurement Process) Requirements Mapping Business Requirements Scenarios (RD.050) (Receiving Process) Business Requirements Scenarios (RD.050) (Payment Process) Define Business Requirements Scenarios (RD.050) (Procurement Process) Defining Business Scenarios Future Process Model (BP.080) (Receiving Process) Future Process Model (BP.080) (Payment Process) Future Process Model (BP.080) (Procurement Process) Modeling Perform SystemTest (TE.110) (Receiving Process) Perform SystemTest (TE.110) (Payment Process) Perform SystemTest (TE.110) (Procurement Process) Business System Testing
Figure 1-8 Repetitive Implementation Process Task Cycle Example
Operations Analysis and Solution Design
Collapse Operations Analysis and Solution Design into a single phase. Start creating design deliverables as the mapping progresses. This is a popular technique, but incurs greater risk because the Operations Analysis checkpoint is removed. The full vision of the future system does not emerge until Solution Design is nearing completion. This technique increases the risk of major design issues associated with non- integrated analysis and costly rework, as well as scope creep.
Use Multiple Tasks for Program Modules
The default Project Workplan for AIM includes a single task for Create Application Extension Modules (MD.110). In reality, this task is
by the project. When preparing a detailed project plan, add tasks for each individual program module to be built and tested. This gives you the flexibility to assign several developers to the construction tasks and perform resource leveling to derive the detailed schedule. There may also be opportunities for parallel development that can be identified using this technique.
Prioritize Customizations
Some customizations identified during Solution Design may not be critical for initial production cutover. By delaying these Build activities, you can move to Business System Testing (TE) and Production
Migration (PM) more quickly. Development of minor application extensions can continue in parallel with other activities, but should be introduced after production.
Schedule Optimization
Work closely with the designers so that you can define inter-module dependencies in the project plan. You may also wish to assign
priorities, so the auto-leveling feature of your project planning tool can generate an appropriate schedule. We recommend that you use
resource-driven scheduling for program construction tasks to efficiently utilize multiple resources. Fixed-duration scheduling may be used for Business System Testing (TE), since additional resources may be brought in during this process.
Conduct Design and Development in Parallel
Since the primary predecessor for program construction is the detailed design document, the project plan may include Build activities in parallel with Solution Design activities. If development is accelerated in this way, some of the assumptions incorporated into earlier designs could change when later designs are developed. This requires that the earlier designs are revisited and related programs are updated or rewritten. This acceleration technique could also shorten the lead-time of Module Design and Build (MD).
Use Project Tracking
Careful attention to progress reporting, signoffs, and scope control are particularly important while managing Solution Design. Include frequent checkpoints and milestones to stay current on the status of the project.
Operations Analysis, Solution Design, and Build
Collapse the first three phases into a single super-phase. This is only suitable for small scale projects that are easy to control and that use alternative risk mitigation steps.
Execute Phases in Parallel
Solution Design and Build
Build often begins while Solution Design is in process. This technique offers economies in projects with numerous customizations, but there is a risk of non-integrated designs and scope creep.
Define a Tailored Approach — Task Consolidation/Elimination
In many cases, certain tasks are not needed for your project. Use the optional task criteria to guide you in the exercise of eliminating redundant tasks.
Warning: Make sure that you do not eliminate tasks and deliverables that will have a serious downstream impact on the project. Every task in AIM is related to another. If you remove a task, its deliverable will not be available for related subsequent tasks. Before eliminating the task, verify that the information contained in the deliverable is not required for your project.
In some cases, the size of a task or the nature of the resources required to execute a task may lead to an opportunity to consolidate the task with another. Examine the final task loading in terms of labor hours to complete the task, the resources required and the sequence of tasks. If you locate one or more additional tasks that are sequenced together, use the same resources and short in duration, you may have located a consolidation opportunity. This is different for each project.
Select a Pre-Packaged Approach
Oracle provides a number of FastForward and Point Solution pre- packaged approaches that may be suitable for the project. The
FastForward pre-packaged approach uses a predefined set of tasks and pre-seeded deliverable templates. In addition, FastForward combines several tasks and deliverable components into one super task.
because of the limited tasks that are performed and the stringent pre- configuration requirements.
Point Solution pre-packaged approaches provide a lower degree of pre- determination of application configuration with many of the common technical and analytic requirements provided up front. They also tend to address specific business improvement opportunities such as the enablement of strategic procurement or the implementation of an internet store. The use of a Point Solution would accelerate a specific objective as you would be utilizing a proven packaged approach to a specific requirement.
FastForward offerings tend to have broader coverage of a specific business area such as financials, human resources, or manufacturing and often are available as packages including implementation, education and support services and application program licenses.