Joe Carey

There are a number of functional roles beyond "ERP Users" not covered here. In short: - Functional Leads/Analysts - provide business process knowledge - SMEs - provide company/industry-specific expertise - Data - populate static (account names, addresses) & dynamic data (orders placed, POs issued) for go-live - Integrations - establish inbound & outbound data integration - Typical governance roles: Sponsors, Stakeholders, etc - Change Management - Socialization of project, training

Custom software may not always provide the flexibility as described. An application designed to initially support a specific process may require significant development if that process changes, or to support a similar process for a different customer organization/client.

Look at what separates you from your competition, gives you a competitive advantage or makes you unique. I agree w the previous comments that 70-80% of your process will typically be supported by OTS applications, so how to address the remainder needs to be considered in light of whether it provides competitive advantage. If so, it's worth considering custom (or customize the OTS - but that's a different discussion), and keeping your current processes; if not, adapt your processes to what the OTS software supports, in most cases those are built on best practices anyway. There's no need to re-invent the wheel, and in most cases, a general function like AP or AR is not providing a company their competitive edge.

As noted in my notes above, I've had success integrating Agile & Waterfall by treating a sprint as a mini-waterfall. High level requirements need to be gathered to understand effort & complexity for backlog grooming & sprint planning; dev & unit test during the sprint; then capacity in subsequent sprints should be reserved for re-work on features/stories that don't pass unit test. Every couple sprints there needs to be an Integration test sprint.

I'd disagree that the future of Waterfall for stable, low complexity, long projects - I'd question the ROI of a project like that. I believe the future of Waterfall is in very short projects with well-defined requirements that can be completed in 3-4 months. I also believe Agile sprints should be mini-waterfalls.

I've found, in many but not all situations, that developers will use Agile as an excuse to not gather requirements - they claim requirements get sorted out during the sprint iterations. I think this is a huge mistake. The most success I've had w Agile is treating it as a LOT of mini-waterfalls.