Can Oracle Unified Methodology support Agile Development Reply

The Oracle Unified Method (OUM) is built on the following five main principles as defined by Oracle:

Business Process and Use Case-Driven – Business processes and use cases are used as the primary artifacts for establishing the desired behavior of the system and for communicating this behavior among the stakeholders.

Iterative and Incremental – The development or implementation of a software system is done incrementally through repetition of a series of tasks intended to first define the system broadly, at a high-level, and then refine the definition of the system by adding details in subsequent iterations.

Architecture-Centric – The system’s architecture is used as a primary artifact for conceptualizing, constructing, managing and evolving the system that is being implemented.

Risk-Focused – A key focus of each iteration in OUM is to attack and reduce the most significant project risks. This helps ensure that the project team addresses the most critical risks as early as possible in the project lifecycle.

Flexible & Scalable – OUM is designed to support a broad range of project types. As such, it must be scalable and adaptable. The appropriate point of balance for a given project will vary based on a number of project risk and scale factors. The method has been developed with the intent that the approach for a given project be “built up” from a core set of activities to implement an appropriate level of discipline, rather than tailored down.

Agile project management principles allow for flexibility rather than the rigidity of traditional project management methodologies.
The principles behind ‘agile’ is to ‘go live’ with a minimal set of functions to derive an early ROI. Agile processes use self-organizing teams, a rapid pace, and decreased emphasis on detailed planning to allow for flexibility in managing projects.

So how are these two methods similar? How is Oracle’s OUM ‘Agile’?

Through Adaptability which is represented by the two principles of ‘Iterative and Incremental’ and ‘Flexible & Scalable’.

According to Oracle, in support of the Flexible and Scalable principle, OUM is ‘Fit-For-Purpose’

Fit for business purpose refers to the focus on delivering necessary functionality within a required timebox.

Traditionally, projects have been focused on satisfying the contents of a requirements document or rigorously conforming to an existing set of work products. Often, especially where iterative and incremental techniques have not been employed, these requirements may be inaccurate, the previous deliverables may be flawed, or the business needs may have changed since the start of the project. Collective experience shows that applying fit for purpose criteria, rather than tight adherence to requirements specifications, results in an information system that more closely meets the needs of the business.

In OUM, project managers and practitioners are encouraged to scale OUM to be fit for purpose for a given situation. It is rarely recommended or appropriate to execute every activity within OUM. OUM provides guidance for determining the core set of activities to be executed, the level of detail targeted in those activities and their associated tasks, and the frequency and type of end user deliverables. The project workplan can be developed from this core. The plan should then be scaled up, rather than tailored down, to the level of discipline appropriate to the identified risks and requirements.

Even at the task level, models and work products should be completed only to the level of detail required for them to be fit for purpose within the current iteration or, at the project level, to suit the business needs of the enterprise and to meet the contractual obligations that govern the project.

So yes, Oracle Unified Methodology has some similarities to Agile Project Management methodologies. Both can be tailored or made ‘adaptable’ to the project at hand.

Agile – The ability to be adaptable Reply

Conceptually this makes sense in software development. Changing requirements can derail a software development project. Yet there are always changes, and therefore small incremental software releases that build out a product and get in front of the product owner quickly makes sense. Changes can be adapted to quickly rather than re-designing from the ground up.

How about agile project management?

Changing direction on any project can derail the project. The pace of change in today’s world makes it difficult to absorb and manage scope, schedule and budget for successful project delivery.
Agile project management principles allow for flexibility rather than the rigidity of traditional project management methodologies.
The principles behind ‘agile’ is to ‘go live’ with a minimal set of functions to derive an early ROI. Agile processes use self-organizing teams, a rapid pace, and decreased emphasis on detailed planning to allow for flexibility in managing projects.

The project manager works with the customer to ensure that the product backlog is visible and everyone understands that it directs the team to the most profitable and valuable work possible. The project manager uses product increments and demonstrations of working functionality to keep everyone aware of real progress against goals, commitments, and vision of the product.

Traditional plan-driven software methodology uses a command-and-control approach to project management. A project plan is created that lists all known tasks. The project manager’s job then becomes one of enforcing the plan. Changes to the plan are typically handled through “change control “ that add so much bureaucracy that delivery is slowed to the pace that the plan-driven methodology can accommodate.

Agile project management, on the other hand, is much more about leadership than about management. Instead of creating a detailed plan showing the sequence of all activities the agile project manager works with the customer to layout a common understanding from which collaboration can occur. The agile project manager puts forward the vision and then leads the project team to achieve the plan.

Agile project management continuously evaluates time and cost as primary constraints. Rapid feedback, continuous adaptation are built into the team’s schedules, ensuring quality deliverables.

Requirements, Process or Solution driven methodology for ERP implementation: What works best? 1

This post was co-authored by Christopher (Chris) Sharbaugh 

There are countless papers and articles on top risks for ERP implementation success.  There are an equal number of articles about implementation methodologies to mitigate those risks.

These many thoughts can be distilled into three major ERP implementation methodology categories:

  1. Requirements Based – This is the traditional approach to software development. Collect an extensive set of requirements that the system should be able to meet and then try to map those requirements to an ERP software package.
  2. Process Based – This is a modified requirements based approach. It advocates defining end-to-end processes that satisfy capabilities the organization is trying to deploy using an ERP.
  3. Solution Driven – This approach assumes the vendor’s software has best practices implemented and advocates applying them to satisfy capability requirements; any deviation from that is challenged.

In order to really determine what approach is most suited for the organization, lets start with establishing common understanding of few common terms:

      1. Methodology is defined in the Merriam dictionary as a body of methods, rules, and postulates employed by a discipline. Any Enterprise Resource Planning (ERP) implementation involves multiple disciplines. The extent of each discipline’s importance varies across the industry and across companies; e.g. the extent of organizational change required during the implementation of ERP varies across organizations.
      2. However, there are some paradigms that work best for delivering solutions quickly; they address the needs of the organization, and provide the foundation for users to deliver return-on investment.

To employ those paradigms, there are some important characteristics of ERP packages that you must remember:

  1. An ERP is the vendor’s culmination and implementation of an extensive number of companies’ and industries’ requirements.
  2. Those implemented requirements are packaged as a series of business capabilities and processes that must be integrated into the using company’s end-to-end processes.
  3. And lastly, ERP packages reflect the vendor’s interpretation of the most effective way to perform each business process. These best practices eases compliance with requirements such as Sarbanes-Oxley. They can also help compliance with de facto industry standards such as Electronic Fund Transfer (EFT). This is because the procedure can be easily codified and adapted across multiple businesses that share the same requirements.

At this point you could say, “There you have it; process based implementation is the way to go.”

“Not so fast,” others may respond, “those processes need the company’s data, business rules and employee roles sometimes at the task and activity level documented as explicit requirements to support the configuration.” 

Additionally, the touch-points or interface to the company’s end-to-end processes must be documented and governance-approved so that they don’t create a burden with interfaces.  It’s also vital to face the fact that no ERP will be a perfect fit for the business; there will be gaps that have to be accepted or filled with manual processes, bolt-on solutions, custom code, or SOA components.   The gaps must be defined at the requirements level to properly understand the business impact of filling them or not.

Now you’re thinking, “OK, now they are leading me to the solution driven approach.”

A solution driven approach is when the ERP team uses the actual software with the targeted users as an analysis and design tool.  It is a very powerful approach, especially when you consider users don’t have the time and organizations don’t have the money to perform extensive process modeling or requirements definition.   Additionally, when organizations invest in a process or requirements approach without referencing the ERP solution, more often than not they end-up with great and often expensive documentation of the as-is.  While this has merits, the impact is often more interfaces and extensions than less.  However, the solution driven approach will not support the first steps in the ERP journey: identifying the business problem; identifying ERP as the best solution; and selecting an ERP vendor that fits the company’s needs.

The bottom-line is that you need a hybrid methodology that is applied in the proper sequence to implement an ERP with higher velocity and at lower cost.  This fusion methodology is composed of:

  1. High-level Process Modeling
  2. Solution driven Process Decomposition
  3. Requirements driven Gap resolution

After the problem definition, you need to do some High-level process modeling in order to identify the ERP that is the best fit and select the appropriate vendor.   Process modeling includes scenario, capability, and architecture modeling.

  • Process models should not extend beyond the business and organizational flows with supporting data objects (e.g., invoice, customer, order, receipt, service request) and supporting systems.
  • Business scenarios are initial and high-level use cases.  Remember, the ERP has all the basics covered.  The scenarios should focus on the critical sub-processes or activities that make the company truly unique and are “make or break” for selecting using an ERP product (e.g., remote or mobile transactions, contracts, sales and inventory planning, pricing, invoicing, collections etc.).
  • The capability modeling should identify the must and should have features needed to support the processes and scenarios (e.g., RFID compatibility, Compliance, Multi-language, Automated approvals, Contracts templates, Serialization, Part numbering, # of users, locations, etc.).
  • The architecture model should identify the applications (purchasing, financial, inventory) that will be impacted or replaced by the solution and the enterprise solutions (e.g., security/identity, portal, messaging, ETL, Business Intelligence, encryption, etc.) that must be integrated with the ERP.

If you find the modeling team is at the activity, swim-lane, database table, or protocol level; stop: you have gone too far.    Additionally, the modeling will support investment prioritization, dependency identification, and team alignment for Agile development.

Once you have picked the vendor and modules, the solution driven approach will help bind the remaining processes and architecture decomposition to the ERP capabilities. It will also provide users with something they can see and touch while they define the detailed data, business rule, and role requirements at a level that can be configured by a technician.  Additionally, the team will be able to identify real process and capability gaps and their impacts to inform decisions about building Reports, Interfaces, Conversion, Extensions, Workflows, and Forms.

These gaps are where you can apply the traditional requirements driven or Agile approach; the team is essentially embarking on a custom development effort within the ERP project.  The identified gaps must be carefully evaluated and should be discouraged vigorously.  There are many tasks that will be more efficient with an ERP application and there will be some tasks that will be less efficient.  Keep in mind that any custom development in the ERP environment increases the possibility of a failed implementation. By some studies, 71% of total ERP failures are the result of extensive customizations and/or extensions under the guise of gap resolution.  You must document the requirements well and make sure that they are must have to successful business processes vs. just matching the way your organization/business is accustomed to doing or likes to do things.

An ERP is still the best alternative for replacing legacy applications and standardizing processes across the enterprise. It is important to apply a balanced approach and the right mix of methodology to be successful.