How to use Agile Principles for 3 to 6 months long ERP enhancement projects

In the previous article, we discussed how to use agile development principles to maintain and enhance ERP ecosystems where time to market is 30 to 45 days. In this post let’s discuss how to use agile principles for projects that span over 3 to 6 months. These undertakings usually help better integrate ERP systems with other applications (Salesforce, MDM systems) or automate key business process (invoice and payment processing).


The Minimum Viable Product to enhance or automate ERP business process requires much more configuration, development, and testing with larger interdependent project teams. Proposed enhancement must work end to end; otherwise, it will be considered a failure.  However, as a project manager, you can orchestrate the project teams using agile principles.

1. Build your team using business processes: As a project manager, try to build a team by the business processes. For example, if you are implementing invoice entry and approval automation process with 3 software components viz. invoice-entry thru image capture and OCR, machine learning to improve OCR capabilities and routing invoice for approvals. Such a project would need a product owner, an infrastructure team to install software (unless it is a cloud deployment), a team of business analysts, product SMEs, and testers. In such projects, you can build 3 individual teams to collaborate and deliver the results.
   
   
2. Determine number of sprints and user-stories each sprint will accomplish: Now break-down your project into architectural-runway and sprints. Agree on what functionality will be delivered to users for testing at the end of each sprint. Help people understand and appreciate that the product is not fully functional but that at the end of each sprint users can better visualize the final product.
   
   
3. Daily Scrum Meetings: Make sure to hold daily scrum meetings across all teams. Help teams understand inter-dependencies. You may have to help teams visualize the big picture and understand how an individual and their team fits into it.
   
   
4. Manage R.A.I.D log: Manage your Risks, Assumptions, Issues, and Dependencies by and across the teams. Make sure you over-communicate your assumptions and dependencies to avoid ending up in the below situation.
   
   
5. Deal with bad news early on: As the saying goes, bad news does not get better with time. Engage your stake-holders and try alternatives. You may still end-up delivering the minimum viable product and subsequently add bells and whistles through monthly release cycles.
   
   
6. Don’t undermine testing efforts: Complexities and current tool maturities may not support full ERP automated end-to-end functional, system integration, regression, and user acceptance testing. Try to automate what you can to reduce future testing cycles and cost. However, don’t be over-ambitious and reduce your testing scope.
   
Please share your thoughts and comments below. 

Using Agile for ERP Implementation & managing ERP eco systems

There has been lot of conversation recently on using Agile software development to implement, enhance, and manage ERP systems. Most of us are familiar with the multi-million-dollar ERP implementation projects, which span over years, to tear down existing legacy systems and implement monolithic or best-of-breed ERP systems. These projects put the very organization, its culture, and its people at risk in the hope of getting better information. These projects face several challenges, one of which being its waterfall implementation approach. End users only see the product after 9 to 12 months, inspiring the below cartoon and several other versions by Scott Adams.

ABOUT ME: I have been blessed to be involved with ERP implementation over the past 15 years, and for the last 5 years I have been managing and enhancing the ERP ecosystems with upgrades, and integrating it to post-modern ERP, MDM, and business process automation systems.

One can read more about the Agile software development principles here. Through this article, I will first try to address how a mature ERP IT shop can use Agile software development methodology to better manage and enhance the ERP ecosystems. Before we dive into how’s, let’s examine the key guiding principles that a team needs to follow to be successful on its journey (yes, it is a journey and not a destination) to be more “Agile”.

• Close, daily interaction between process owners, business analysts, developers, and testers
• Customer satisfaction through early and continuous delivery of working software based on principles of iterative delivery, continuous improvements, and integrated testing
• Self-guiding, motivated teams which organizes itself and can agree on what can be delivered and tested by end of one or two weeks
• Daily stand-ups to resolve impediments, to hold each other accountable, and to agree on what will be accomplished by end of day.

In a mature ERP IT shop, you have scheduled releases which may include reports, integrations, configurations, user interface personalization, bug-fixes, security patches, and small to medium scale projects that help improve or automate business processes. You can follow the steps below to streamline and improve your team’s capability to deliver.

1. Establish Backlog: Meet with your business owners to prepare the backlog of outstanding requests. Once the backlog is complete, establish business priorities (business values) and technical complexity to the backlog. Finally, agree on what will be delivered in the next release.

2. Establish Predictable Delivery Schedule: Agree with the team on how often new enhancements will be delivered to production. For an ERP shop that has no established release schedule, you can start with predictable monthly release schedule. Below is a sample schedule:

• All development and unit testing will be completed by the 10th of the month
• All system and user acceptance testing will be completed by the 15th of the month
• All changes to be reviewed by the Change Control Board by the 20th of the month
• All enhancements will be delivered 7 days before the month end process begins. This will allow complete business validation of the new releases in production and minimized impact to the month-end process.

3. Agree on who will be responsible: Identify all key players for each backlog item that has been agreed to be delivered in the next release. You should be able to answer following questions:

• Who will be able to make business decisions?
• Who will develop and unit test the code?
• Who will test the integration and user acceptance testing?
• How will we know that enhancement is ready for production?

4. Hold daily scrum meetings: Depending on the complexity of the objects, hold daily scrum meetings for each object or for all agreed backlog items. Hold team members accountable for their commitments. Provide support and guidance to remove any impediments.

5. Celebrate your success: After successfully delivery of the release celebrate success with your team, analyze what went well and what was challenging. Be careful not to throw anyone under the bus.

6. Go back to step 1.

After completing, say, 3 or 4 monthly releases, meet with the stake holders to explore the opportunity to increase the frequency of releases. If you are on monthly release schedule, see if you can try your hands at a bi-weekly release. Within a year, you should be able to mature your delivery organization to have a weekly release.

In the next blog, we will look at how we can delivery 3 to 6 month long projects using the Agile approach.

Negotiations - dominance or deference

An article on Negotiations by Scott Wiltermuth on HBR,  introduces why dominance and deference is critical to create a win-win situation in negotiations. Dominance can be matched with dominance derailing the negotiation leaving each party bruised. On other hand, meeting deference with deference may not reliably lead negotiators to discover the tradeoffs that create “win-win” agreements.  A very interesting read.

Importance of R.A.I.D. Log

 

Every project or a program in its life cycle will experience series of Risks, project team will have to make certain Assumptions, act on Issues and make critical decisions to remove Dependencies. It is very critical for the project manager to track these events and articulate it back to project stake-holders. Also at the end of the project it will be critical to review the RAID log, to document true lessons learnt.

Let’s understand each of these terms in context of a project.

• Risks can be defined as a potential of losing something of value as a result of an action / inaction, foreseen / unforeseen. As a project or a portfolio manager you have to help your team identify risk freely, help evaluate severity and put in place plans to mitigate the risk.

• Assumptions: In any project due to time and resource constraints project teams have to make certain assumptions to keep moving forward. If these assumptions at later date are proved to be wrong, it will require changes which may impact project cost and timeline. It is important to track these assumptions and keep stakeholders aware of critical assumptions being made.

• Issues: an event with a potential to disrupt desired outcome. Issues can be related to business processes, current designs, product limitations, or resources. It will require an action from the team to resolve the issues facing the project. Addressing the issues at hand will require project team to make certain design or business process decisions, assume risk or make assumptions. Issues and resolutions need to be tracked as it has impact on the outcome of the project.

• Dependencies: The direct or indirect reliance of one Process or Activity upon another which is currently impacting or slowing down project progress. It is critical to track dependencies and bring it to the attention of right stakeholders so a decision can be made and dependency removed.

Tracking RAID

Depending on the sophistication of a project methodology, several tools may be available for a project manager to track RIAD. On many of my projects I have used a simple Excel spreadsheet or a SharePoint List to help me in my day to day role.

Creating Talent+ Personality

Author John C. Maxwell identifies 13 habits to make one self a Talent+ person. A Talent+ person attracts Talent+ friends, Talent+ Employers and Talent+ relationships in his life. It is not very difficult to be a Talent+ person. Adopting below habits will make you a Talent+ person:

1. Belief in yourself will help lift your talent
2. Passion for your talent will help energize you to work to your goal.
3. Initiative will activate your talent and attract more opportunities.
4. Focus will help direct your talent and achieve what you dreamt for yourself.
5. Preparation will help position you for next big opportunity.
6. Practice will help sharpen your talent.
7. Perseverance will help sustain you and your belief in yourself.
8. Courage will test your talent in adversity.
9. Teachability will help expand your talent.
10. Character like Courage will help protect your talent in adversity.
11. Relationship will help influence your talent.
12. Responsibility will help strengthen your talent.
13. Teamwork will help multiply your talent.

Share your thoughts.