Agile Project Management Methods of ERP

Agile Project Management Methods of ERP

• 1.
  Agile Project ManagementMethods for ERP Submitted by: Lisa
• 2.
  Things to keepin mind while applying agile methodology to project management How can these minimalist approaches be applied in a COTS integration environment while still maintaining the necessary integrity of the delivered product – cost, control, functional capabilities, resource management, and timely delivery? Which project management process simplifications are appropriate for the ERP domain and which are not? Are all lightweight and agile project management process steps applicable to the ERP problem domain? If not, which steps are applicable?
• 3.
  Any agile processmust include three major attributes: Incremental, Iterative, and Evolutionary – allowing adaptation to both internal and external events. Modular and Lean – allowing components of the process to come and go depending on specific needs of the participants and stakeholders. Time Based – built on work cycles, which contain feedback loops, checkpoints, and guidance on using this information in the next cycle.
• 4.
  Applying Agile Methodsto ERP: 1. Agile Project Values Communication – of information within and outside an agile project is constant. These communication processes are essential social activities for the project participants. Simplicity – defines the approach of addressing the critical success factors of the project in terms of the simplest possible solution. See Fig. 3 for the ERP CSF’s. Feedback – “optimism is an occupational hazard of software development, feedback is the cure”. Courage – important decisions and changes in the direction of the project must be made with courage. This means having the courage not to engage in non–value added activities or artifacts. Humility – the best project managers acknowledge they don’t know everything and must engage the stakeholders to close the gaps.
• 5.
  Applying Agile Methodsto ERP: 2. Applying Agile Principles The following principles create the foundation for managing ERP projects in an agile manner: Assume Simplicity – As the project evolves it is assumed that the simplest solution is best. Overbuilding the system or any artifact of the project must be avoided. Embrace Change – Since requirements evolve over time, the stakeholder’s understanding of these requirements evolve as well. Project stakeholders themselves may change as the project makes progress. These changes are a natural part of an ERP project. Enabling The Next Effort – the project can still be considered a failure even when the team delivers a working system to the users. Part of fulfilling the needs of the stakeholders is to ensure the system is robust enough to be extended over time. The next phase may be the development of a major release of the system or it may simply be the operation and support of the current system.
• 6.
  Applying Agile Methodsto ERP: 2. Applying Agile Principles…..cont. Incremental Change – the pressure to get it right the first time can overwhelm the project. Instead of futilely trying to develop an all–encompassing project develop a small portion of the system, or a high–level model of a larger portion of the system. Evolve this portion over time, and discard portions that are no longer needed in an incremental manner. Maximize Stakeholder Value – the project stakeholders are investing resources — time, money, facilities, and etc. — to create a system to meet their needs. Stakeholders expect their investment will be applied in the best way. Manage With A Purpose – by creating artifacts that have stakeholder value. Identify who needs the artifact. Identify a purpose for creating the artifact. Multiple Project Views – considering the complexity of any modern information technology system construction or acquisition process, there is need for a wide range of presentation formats in order to effectively communicate with the stakeholders, participants, and service providers. Rapid Feedback – the time between an action and the feedback on that action must be minimized. Work closely with the stakeholders, to understand the requirements, to analyze those requirements, and develop an actionable plan, which provides numerous opportunities for feedback.
• 7.
  Applying Agile Methodsto ERP: 2. Applying Agile Principles…..cont. Working Software Is The Primary Goal – not the production of extraneous documentation, software, or management artifacts. Any activity that does not directly contribute to the goal of producing working software should be examined to determine its value. Travel Light – since every artifact must be maintained over its life cycle. The effort needed to maintain these artifacts must be balanced with their value.
• 8.
  ERP Functional Domains:The business domains in which ERP plays a critical role includes:
• 9.
  PDM Domain Relationshipswith ERP: One functional area that impacts many business processes is Product Data Management (PDM). PDM systems manage product entities from design engineering through release to manufacturing. Engineering processes drive product development, so engineering tools are at the heart of the PDM systems interaction with the engineering user community. Engineering processes are good candidates for agile deployment, since the process improvement aspects of engineering processes can usually only be discovered by putting them into practice, experimenting with various tools and user interactions, and evolving these business processes to deal with unknown and possibly unknowably demands from the market place.
• 10.
  Agile PDM DomainPractices: Assume Simplicity : COTS products define the requirements, more than the users do. Don’t make changes in the system if it can be avoided. Start with the Out Of The Box system and discover gaps. Fill the gaps with other COTS products when ever possible Separation of concerns is a critical success factor for both products and processes. Base these separations on the business architecture of the system, and then apply the technical architecture. Decoupled work processes create architectural simplicity. Search for opportunities to decouple work processes along technical architecture boundaries. Stateless management of connections between application domains isolates components. Minimize product structure attribute creation early in the deployment cycle. Provide a means to add product attributes and relations to the object model later in the deployment cycle. Start with the simplest business process; verify the system can be deployed against these processes. Progress to more difficult processes but always search for the simplest solutions.
• 11.
  Agile PDM DomainPractices: 2. Embrace Change: Object architectures enable change, but ruthlessly maintain proper object attributes. Modularity, information hiding, and other object attributes can pay large dividends over time. Model based thought processes focus requirements. Continuous delivery using selected products. Focus on vertical versus horizontal delivery (making the disk move on the first instance and every instance after that). Isolate components to provide a replaceable architecture.
• 12.
  Agile PDM DomainPractices: 3. Enable the next effort: Architecture driven planning in depth is the primary role of the project manager and the architecture staff. Use a Battle Planning paradigm for the daily project activities – it’s chaos at the low level and big picture strategy at the high level. Focus on values for today, while keeping the generation of value in the future in mind. Continuously evaluate the future opportunity costs.
• 13.
  Agile PDM DomainPractices: 4. Incremental Change: Plan globally, implement locally, guided by architecture. Rapid planning in depth is not an oxymoron. COTS integration is an experience– based discipline. Skills are important, but are secondary since most decisions are irrevocable. 5. Maximize Value: Put tools in the hands of the users. Discover what we have to do for the people who have to do the work. Provide these tools in a rapid, efficient, and beneficial manner, with the minimum of resources and disruptions to the ongoing operation. The stakeholders define the dimensions of value, ask them what they want, when they want it, and how much they’re willing to pay.
• 14.
  Agile PDM DomainPractices: 6. Manage with a Purpose: Architecture centered management places the proper boundaries on creativity. Always define the outcome of an action: who benefits? How can this benefit be recognized? What does this benefit cost? Never confuse effort with results. 7. Multiple Views: Objects (static and dynamic) are nice but they don’t show the business process. Data flow is nice but it doesn’t show the underlying business object architecture. Control flow is useful for business process improvement, but be careful about redundant data and persisted entities. Event and data source and sink can be used for isolating business process boundaries. Business processes can be used to define the highest level boundaries. Interface exchange artifacts are critical for maintaining separation of concerns. Inversion of control – the identification and management of the interface control points is a critical success factor.
• 15.
  Agile PDM DomainPractices: 8. Rapid Feedback: Continuous engagement with the stakeholders. War room mentality in which the participants are fighting the system not each other. Continuous delivery of functionality. 9. Working Software: COTS products change this concept, but system integration efforts are just as difficult and important. Continuous delivery using standard products with the minimum of customization. Use the vendor’s tools to get something working fast. Avoid customizing a COTS product if at all possible.
• 16.
  Agile PDM DomainPractices: 10. Travel Light : Analyze and Model once, publish many. Use technology to reduce the white space in the process and organization. Move fast and light. Use experience based behaviors and high–level specifications to guide architecture. Low–level specifications add NO sustaining value in an ERP system. Working code is the value to the stakeholders. Working software is the final specification. Use specifications to capture knowledge that will be needed independent from the working software. This can be interface specification for 3rd parties, justifications for the decisions, and other tribal knowledge conveyance materials.
• 17.
  Critical Success FactorsFor Agile ERP:
• 18.
  References: Ambler, Scott,www.agilemodeling.com. Ambler, Scott, Process Patterns and More Process Patterns , Cambridge University Press, 1998 and 1999. Amram, Martha, and John Henderson, “Managing Business Risk by IT Investment: The Real Options View,” CIO Magazine , March 1999. Amram, Martha, Nalin Kulatilaka, and John Henderson, “Taking an Option on IT,” CIO Magazine , June 15, 1999. Amram, Martha and Nalin Kulatilaka, Real Options: Managing Strategic Investments in a World of Uncertainty , Harvard Business School Press, 1999. Aoyama, Mikio, “New Age of Software Development: How Component Based Software Engineering Changes the Way of Software Development,” 1998 International Workshop on Competent–Based Software Engineering , 1998.