Abstract
Traditional waterfall project methodologies have been used for years to implement complex and large-scale enterprise resource planning (ERP) projects. Often, ERP projects are over budget and late in schedule. Stakeholders are often disappointed in the delayed realization of benefits and the quality of the delivered product. In today's economy, it is a reality that we need to be able to deliver our projects with fixed constraints on resources.
In this session, discover how you can use Lean principles and agile techniques to create a high-performing ERP team that will deliver high value and high quality products to your stakeholders in a shorter period of time. Learn to create cross-functional teams that are collaborative, adaptive, and responsive to customer needs. Find out how you can transform your ERP team to increase productivity so you can realize benefits sooner.
In addition, in this session, you will be introduced to assessment areas and evaluation criteria on how to determine the appropriate approach for your project. This evaluation will help you determine the best approach based on your organization's culture, project characteristics, and resources.
Introduction
Have you ever wondered how to deliver your project quicker and realize business value sooner from your ERP implementations?
Have you ever wondered how to remove all of the “ceremony” of the implementation process and the “waste” involved with an ERP implementation while preserving the integrity of the delivered ERP package methodology?
Have you ever wondered if there was a way to be flexible enough during ERP implementations, and that changing business requirements could be provided to a project team mid-implementation, without significantly affecting the overall cost and schedule?
Have you ever wondered how to improve the efficiency and productivity of your existing ERP teams by doing “more with less” in today's economy?
These are common questions that are asked when discussing how to improve the implementation of ERP projects. Consideration of Lean concepts and agile techniques to accelerate the time to delivery and the realization of benefits is becoming more prevalent. Project managers are challenging the ways they have been traditionally implementing projects and are seeking new approaches; however, there are many considerations in determining the right approach. In this discussion, we will discuss the key evaluation areas to determine if your project is a good candidate for agile or waterfall.
Overview of Lean Principles and Agile Techniques
Lean and Agile Concepts
Lean is a “thinking principle” that focuses on the tasks and activities that are being conducted to complete the building of a product or a process to deliver a service. Additionally, the concepts of Lean include evaluating the flow of work to identify opportunities for improvement. By conducting this analysis and changing the way we think about our work, we are able to identify the specific areas that need improvement.
As we change the way we approach our work, and as we focus on increasing our efficiencies to deliver our projects to our stakeholders with higher quality products, it is helpful to focus on “Leaning out the waste.” Often, we work on projects in which we are required to participate in meetings or activities that are not directly contributing to the end product being delivered. Often there are “overhead” activities that we are asked by our project managers to perform, which have little value to the end product. As team members, we want to start to change the way we think and challenge the processes that are part of our project management approach. We want to reduce “Non-Value Add” activities and increase “Customer Value Add” activities. There are three types of work that we need to focus on as we evaluate our daily activities on a project:
- Customer Value Added Work: This is time directly spent on building the end product or deliverable. Agile teams learn to make this work a priority and maximize their daily activities to be value add activities.
- Business Value Added Work: This work includes any activities that we need to complete to maintain project management or governance compliance. We also need to identify and simplify the ceremonial activities that we traditionally perform to stay viable/compliant/lawful. For example, we may have specific testing and quality assurance requirements when delivering a software project in a federated life sciences environment. Agile teams learn to develop lighter yet just as effective artifacts to support the requirement. We try to replace some of the traditional project artifacts with empirical evidence (demonstrations and stand-ups versus status reports).
- Non Value Added Work (Waste): These activities include the time that team members spend on work that is not directly related to building the end product. These items are often considered “overhead” or “waste.” Teams learn to negotiate this work completely outside of the project's specifications.
What is Agile?
Agile is a project methodology and approach that is derived using Lean thinking. Agile projects apply “Lean” concepts in the information technology environment. It is the proven project management methodology that encourages the following key concepts:
- Frequent inspection and adaptation
- A leadership philosophy that encourages team work, self-organization, and accountability
- A set of engineering best practices that allow for rapid delivery of high-quality projects
- A business approach that aligns development with customer needs and company goals
Some of the foundations of agile include the following:
- Empiricism – Ability to perform, stop, reflect, improve, and continue in a step-by-step process in efforts to increase productivity
- Prioritization – Deliver work based on value to the business
- Self-Organization – The team knows best how to deliver the work based on the resources and constraints
- Time-Boxing – The team is required to complete the assigned tasks within the defined timelines.
- Collaboration – The team commits to delivering the final products within the given timelines, which will encourage cross-team collaboration and ingenuity in completing the tasks.
Key aspects of the agile project include the following:
- The Overall Team – Team, Scrum Master, product owner
- Product Backlog – the ongoing, prioritized list of “to do” tasks and features that are defined by business customers
- Sprint Planning and Backlog – planning session at the beginning of a sprint to determine the items that the team agrees to take on and deliver as the output of a sprint
- Stories/Story Board – collection of collective elements, functions, or “features” that are to be delivered within a sprint
- Daily Standup – daily discussion on what was accomplished, what remains to be done, and obstacles
- Sprint Burndown Chart – artifact showing progress and work remaining in a sprint
- Sprint Demonstration – demonstration conducted at the end of the sprint to show product(s) delivered
- Retrospective – team discussion following the sprint to identify successes and improvement opportunities
Exhibit 1 – Waterfall and Agile Project Approaches
Agile Project Techniques
A few techniques typically used on agile projects and that directly contribute to accelerating the time to delivery and the increased quality of the product being delivered, include the following:
- Frequent inspection of the product and adaptation to the changes and input during the project
- Aligning development with customer needs and company goals
- Co-location of resources to the same work space
- Self-organization and accountability
- Becoming a team player
- Elimination of “waste” and “ceremony”
- Empirical demonstration of results
- Customer is always present
- Product managers and owners
- Focus on key planning events: product planning, release/feature planning, iteration planning, sprint review, and stand-ups
Waterfall versus Agile
There are some key differences between a traditional waterfall project and an agile project and these include the following:
Waterfall
- Detailed, long-term project plans with single timeline
- Definitive and rigid project management and team roles
- Changes in deliverables are discouraged and costly
- Fully completed product delivered at the end of the timeline
- Contract-based approach to scope and requirements
- Customer is typically involved only at the beginning and end of a project
- Linear-phased approach creates dependencies
Agile Project
- Shorter planning based on iterations and multiple deliveries
- Flexible, cross-functional team composition
- Changes in deliverables are expected and less impactful
- Product delivered in functional stages
- Collaborative and interactive approach to requirements
- Customer is involved throughout the sprint
- Concurrent approach seeks to reduce dependencies
Challenges of ERP Project Management
Over the past 10 years, as agile adoption has grown, the primary focus has been on custom application development projects. Projects implementing commercial off the shelf (COTS) or enterprise resource planning (ERP) products have had a slow transition to adopting agile as a preferred project methodology. The reasons for this include the fact that COTS software vendors typically prescribe an implementation methodology with their software. For over 20 years these software packages have been delivered with traditional waterfall implementation methodologies. Therefore, the systems integrator communities have also adopted their implementation models to be in alignment with the ERP vendors.
For years, large-scale ERP projects have been delivered using these “tried and true” project approaches. Unfortunately, however, we also have seen many projects that have under-delivered in quality or functional capability as well as run over schedule and over budget. There are many reasons why these projects experience these challenges, which are usually not due to the methodology or approach. The agile approach, however, where it is deemed to be the best approach, will expose project risks to management earlier in the project and force key decisions that may prevent typical project issues from arising.
When considering adopting agile as the ERP project implementation approach, there are key considerations that the project management team needs to consider. Based on their ERP implementation experiences and the resources they have to dedicate to the project, the team should be aware of the following typical challenges:
- Agile is a new way to manage projects:
- Makes all the typical “dysfunction” in a team or organization visible
- Depending on how agile is introduced to a team, there may be resistance to the adoption and it ay follow the mechanics but not the values of agile
- Agile is not right in all environments:
- Spend time up front in assessing the environment and culture to determine agile readiness
- If agile adoption is not managed well, the team will continue to deliver bad products but sooner, and doomed projects will fail faster.
- People are most comfortable with what they know:
- Project team members are familiar with the phases and deliverables of the waterfall life cycle
- ERP consultants have an attachment to waterfall development
- Lack of incentive to increase speed to delivery
- ERP solutions are all encompassing:
- Environment includes development, proprietary programming system/language, a run time environment, a source code control system
- Integrated end-to-end business process that are difficult to decompose
- ERP is about business process configuration; it is NOT about development, coding, and programming
- Managing dependencies and sequencing of stories, tasks, and activities
- Management of large development objects (e.g., interfaces and conversion programs) in line with Sprint delivery
- Integrating off-shore development
Evaluation Criteria to Determine the Best Approach for Your Project
When the project management office is faced with the business case of a project and needs to decide on which project methodology is best to use, there are key areas that need to be evaluated in making this recommendation and some of the key areas to review include:
- Project Characteristics:
- Requirements – how rigid and defined are the requirements?
- Effort/duration – How long is the planned project duration? >6 months, >12 months, >18 months?
- Interfacing systems – How many interfacing systems are in scope? How complex are these interfaces?
- Regulatory compliance – Are there any compliance requirements that provide restrictions or additional requirements for the project team?
- Project inter-dependencies – How many other projects are running concurrently? What is the impact to the key decision-makers? Are they any overlaps with project resources?
- Sponsor Characteristics
- Sponsor buy-in – Does the project have the right level of sponsorship? Are they committed to the mission of the project?
- Sponsor time commitment – Is the sponsor dedicated and willing to support the project as needed?
- Training for agile – Is there an investment for training the team/organization in agile?
- Periodic validation – Will the sponsor be available to participate in key validation sessions?
- Project Resources
- Team size – How large is the team? Can it be broken down into teams of 8 to 12 people?
- Resource dedication – Are key resources dedicated to the project? If not, can parameters around resource availability be established and supported?
- Technology/business domain knowledge – How well do team members know the product being delivered? Is their domain expertise at the level that it will not impede the team's velocity?
- Collaboration – Does the project environment foster collaboration? Are there tools in place to facilitate project team collaboration (e.g., video conferencing, shared document repositories, and so forth)
- Co-location – How many of the team members are co-located? How many are distributed to different locations?
- Testing – automated – Are there any automated testing capabilities?
- Agile Awareness and Acceptance
- Training at all levels – Has the organization committed to training the executive, project team, and subject matter experts in agile?
- Ability to apply agile techniques for all aspects of the project – Is the project management team committed to the values of agile and to the techniques being used?
- Coaches are available – do not do it alone – Are there agile coaches available to support the project team?
Below is an example of an evaluation template that can be used to assess the agile readiness of a project; it takes the characteristics discussed above and asks the user to evaluate his or her project environment. This will help identify the key risk areas and starts the conversation of where to focus improvements to becoming more agile.
Exhibit 2 – Evaluation Scorecard – Waterfall vs. Agile
Success Criteria for Your Agile ERP Project
Over the past two years, as we have worked with many large organizations that have experimented with agile in ERP environments, we have been able to consolidate the common lessons learned and key success criteria. These items are critical to any organization considering implementing an ERP project using the agile approach and they include:
- Conducting an agile readiness and cultural assessment before starting the project
- Identify the executive champion(s) – make sure they support this approach
- Establish “buy-in” to the agile process at all levels
- Be flexible in creating a model that works for the culture of the organization – Establish a process and framework that works best with your culture, resources, and environment
- Consider varying the steps of adoption of agile techniques (it's a journey…)
- Select the right first project – Not all projects are good candidates for agile
- Start with something that can deliver a quick win – Establish confidence with the new approach in the organization
- The “art of storytelling” – be able to effectively define your requirements in the format of a story
- Do not be discouraged at the moment of “first awkward use” because it takes time for the team to adjust to this project approach
- Integrating members of the team who are not co-located
- Ability to remove impediments
- Manage the flow of work
- Continuously update the agile process and framework – Learn and adjust
- Train the team – at all levels
- Develop a product council that is willing to do the work
- Find the right product owner and engage stakeholders
- Focus on team work over mechanics
- Collaboration over co-location –it is important to have the team collaborate; we all need to deal with the reality of distributed resources.
- Set rules of engagement for the team
- Select the right metrics and the right reporting tools
- Align team and individual performance metrics to tangible project goals
By adopting these key lessons learned, a project team should be able to assess and implement an ERP project using the agile approach. Remember that not all projects are a good fit for the agile approach. Assess each project with the evaluation criteria and make a decision based on what works best in the organization's environment. Agile is a very successful project approach, and ERP projects provide a great target for achieving accelerated benefits by using this approach.
