Introduction
This paper describes how to plan an Enterprise Resource Planning (ERP) project using an iterative and incremental approach.
Implementing an ERP solution provides many benefits to an organization, including process efficiencies, improved user interface, technology enhancements, lower maintenance costs and the ability to leverage leading industry practices. Iterative planning on an ERP project provides many benefits: major risks are identified and addressed early in the project; requirement changes are identified and prioritized efficiently; project team utilization is optimized; and progress and quality are continuously monitored and corrected.
The following topics will be addressed in this white paper:
- What Iterative and Incremental Means to a Project Manager
- A Layered Approach to Planning ERP Projects
- Planning an ERP Project
- Planning Considerations for ERP Projects
The Oracle® Unified Method (OUM) is Oracle's standards-based method, which recommends an iterative and incremental approach to planning ERP projects. OUM leverages one of the de facto industry standards, Unified Software Development Process (UP) and will be used as the basis for the examples shown in this white paper.
What Iterative and Incremental Means to a Project Manager
Iterative
In an iterative approach such as OUM, the project is divided into periods of time, usually from two to six weeks (in some cases, two to four weeks), called iterations. During each of these periods, the team executes tasks in order to achieve the iteration's goal(s). Therefore, the term, “iterative” means that work on an ERP project is divided into a series of “iterations” that are essentially run as mini-projects.
Incremental
Incremental means that the system is developed in chunks, iteration by iteration. Each iteration results in an increment, which is a “release” of the system that contains added or improved functionality compared with the previous release. At the end of an iteration, the resulting increment of functionality is presented to users, and requirements are re-evaluated so as to plan the next iteration.
Putting this all together, iterative and incremental means that the ERP solution is developed through a series of mini-projects (iterative) and in smaller portions at a time (incremental), allowing the project team to take advantage of what was learned during development of earlier parts or versions of the system and incorporate external feedback from project stakeholders.
Differences from Waterfall Planning
Waterfall planning is often known as the traditional approach to ERP project planning, which was inherited from engineering disciplines. Waterfall projects are most often planned using a strict “gated” methodology, in which the project is completed in a series of phases. Each phase is completed and signed off before commencing the next phase. In waterfall methodologies, a project will rarely execute a phase or task again once it is completed. This approach presents a higher level of risk than the iterative and incremental approach, because errors and/or missed requirements may not be caught until later in the project when corrections are more costly.
A waterfall approach can be successful and possibly faster than an iterative and incremental approach when requirements are fully known up front. However, ERP projects often face continuous change and reassessment of organizational processes and priorities. The project planning approach used on ERP projects must support adaptability in the face of these challenges. An iterative and incremental approach to planning ERP projects provides many benefits over the traditional waterfall approach and helps to address many of the unique challenges faced by ERP project teams.
Layered Approach to Planning ERP Projects
ERP project plans need to be scalable for different project sizes and complexity and contain the right level of detail for the current planning horizon. Plans that are too detailed are almost instantly inaccurate and obscure key objectives. On the other hand, plans that are too high level will not allow for measurement of project progress nor keep the project team focused on their day-to-day activities.
ERP project plans also need to display the appropriate level of detail and planning horizon for specific audiences. For example, C-level executives, business area managers, and external stakeholders have their focus on the release date, major milestones, business impacts, and points at which major decisions must be made. On the other hand, the project team needs the details on the lower level plans to plan their daily work and measure progress.
As shown in Exhibit 1 below, there are two plans active in the project at any given time on an ERP project — the implementation and the iteration plan.
Exhibit 1 – Layered Planning Approach
The Implementation Plan
The implementation plan is a brief, coarse-grained outline for the project, which provides a roadmap for achieving the objectives for the project. The implementation plan's purpose is to demonstrate how the project will achieve its objectives and display targeted dates for major achievements and/or decisions in the form of milestones.
The Iteration Plan
The iteration plan represents the lowest and most detailed layer of planning. An individual iteration plan will be created for each iteration in the project. The main purpose of the iteration plan is to lay out how the team will achieve the stated objectives for the given iteration.
Top-Down/Bottom-Up Planning
Planning should start early in an ERP project where the focus is on the implementation plan. Also, the initial iteration should be drafted to the degree that the project is able to move into the first phase of the project.
As the project moves along, the initial implementation plan is further refined as more project requirements and risks are uncovered. As the project iterates through the later phases, the plans at each layer (implementation and iteration) will be adjusted based on the results of iteration assessments and as project objectives shift, as is often the case. Furthermore, an iteration plan for the upcoming iteration is created before that iteration begins. Also, the implementation plan must be examined to ensure it is still valid as the iteration plans are created and maintained.
Therefore, at any time on an ERP project, the following plans should be active:
- One implementation plan
- Two iteration plans — one for the current iteration and a draft for the upcoming iteration
Planning an ERP Project
Building the Implementation Plan
The implementation plan represents an outline of the project, showing the total number of planned iterations across the project phases, as well as key milestone dates for each of these iterations. Using the estimates for the project and the known priorities, the project manager, along with the team, lays out an implementation plan, mapping requirements (both functional and technical) very roughly to each projected iteration. Each iteration should have an associated objective that contributes toward achieving the overall project goal. The team may find certain requirements pose design or architectural risks, and they should consider assigning them to earlier iterations, in order to address those potential risks as early on in the project as possible.
A sample implementation plan using OUM as the base method is shown in Exhibit 2 below.
Exhibit 2 – Example Implementation Plan
The implementation plan above shows a project with one iteration in the Inception phase, two in the Elaboration phase, three in the Construction phase, one in the Transition phase, and one in the Production phase. The triangles at the end of each phase represent the milestones for completion of each project phase.
Iteration Planning
Iteration planning is where the bulk of the planning for a project occurs. In OUM, as with other iterative and incremental methodologies, each phase contains one or more iterations, which should last between two and six weeks, with the duration depending on the type of work being accomplished within the iteration. Each iteration should be planned such that a set of specific objectives are accomplished and a group of project risks are addressed. A project manager will typically analyze and manage the current iteration plan on a daily basis.
The team's capacity is a broad measure of the amount of effort the team will be able to take on in the iteration. The team capacity must be considered when planning the scope of work for the iteration. The capacity is determined by the team's size, availability, and velocity, which refers to the speed at which a team can implement and test user cases and/or user stories and change requests.
The iteration plan information should be compiled into a simple document. The first section of the plan should reflect the scope and objectives of the iteration. The primary goal of the scope is to make clear the iteration's objectives, priorities, and evaluation criteria. This information can be used to track the iteration's progress and drive the iteration assessment. The rest of the plan captures the detailed plan for the execution of the iteration.
Keep in mind that each of the layers – implementation and iteration plans must be kept in synch. The degree to which an iteration achieves its objectives will impact future iterations, as well as milestones on the implementation plan. As the phase and iteration assessments are conducted, feedback will be gained, which will lead to the need to adjust the plan(s).
Partitioning
In a large and/or complex ERP project, the project manager should consider breaking the project into several product partitions — one for each major release of the product to be developed, implemented, or upgraded. Projects which are more than a year in duration, those with high risk factors, projects where there is business value to be gained from delivery of a sub-set of the overall functionality, and/or those where resources are constrained are all candidates for partitioning. This approach allows risk to be spread over a number of releases and permits business value to be delivered sooner.
In the case in which multiple partitions will be used to accomplish the project's objectives, an overall plan should be established to map out the execution of all of the anticipated partitions. Partitions can be executed in parallel, serial or in a staggered fashion, and should be planned, so that the delivery of some subset of the project's benefits is realized through the delivery of working software. This is done by examining the business drivers and schedule goals for the project, laying out the work, and assigning the milestones in the overall plan for one or more partitions. A possible option for partitioning the implementation of two business flows in a parallel fashion is shown in Exhibit 3 below.
Exhibit 3 – Partitioning the Implementation of Two Business Flows
Considerations for Planning ERP Projects
ERP projects contain many of the same tasks as other IT development projects (business requirements, requirements analysis, analysis, design, implementation, test, etc.). As part of requirements analysis, ERP projects must include a mapping be performed of the known requirements onto the products or applications that have been chosen. This is often referred to as “Fit/Gap” or “Map and Gap.” Essentially, an analysis of the requirements is done to determine which requirements can be met by configuring the product set and which requirements will drive the development of custom application software. The resulting configurations and custom extensions must be planned such that the resulting custom components are integrated with the configured product software and the resulting integrated system is tested.
Early on, an ERP project's iterations typically emphasize requirements-configuration-analysis-design. These iterations may also include implementation-test activities (of a prototype, for example). Also, in the early phases of a project, an iteration is most likely to result in an incremental improvement to models, documentation, and prototypes. Later iterations have a greater emphasis on implementation and test, but will also likely include some refinement of the requirements-configuration-analysis-design work products. Therefore, during the phase in which system construction occurs; an iteration will more likely result in an internal release of software. On projects where heavy custom extensions are built, integration and integration testing tasks should be considered for each iteration to ensure the customizations and configurations work together as a complete system.
Given the fluid nature of ERP project requirements, the iterative and incremental approach will often be managed somewhat differently than in highly agile custom development projects. Project managers should consider planning for “controlled iterations,” meaning that the content and objectives of each iteration are planned early in the project and monitored closely throughout the project. The project team determines the content of the iterations by identifying project risks and addressing the highest priority risks in the early iterations. In this more controlled manner, changes in scope can be readily identified and handled through the project's change control process.
Conclusion
An iterative and incremental approach to planning ERP projects gives project teams many advantages over the traditional waterfall approach and helps to mitigate the challenges associated with ERP projects. When planning an ERP project, it is recommended that a project manager use a layered approach to project planning rather than a single, highly detailed plan. Planning and managing at each layer (implementation and iteration) free the project manager and project team from the need to create and “feed” detailed plans that have a tendency to quickly become outdated and unwieldy. The layered planning is scalable and empowers the team to focus on the key goals, measurements, milestones, and controls that enable effective project management.
