Cultural Metaphors and Project Plans

There’s a phrase in Chinese that translates literally as “people mountain, people ocean.”  To those raised in (or familiar with) Chinese culture, the phrase evokes an image of a mass of humanity, standing shoulder to shoulder, from the top of a mountain all the way to the shoreline.  “Crowded” is just not an adequate translation.  And that’s the thing about metaphors – they depend on cultural references.  A coyote and a roadrunner only evoke a clear mental image to those who grew up watching Warner Brother’s cartoons.  To the rest of humanity, it’s just a couple of wild animals.

I’ve been drafting a project plan for a SaaS implementation, as part of a much larger program.  The client has an ERP team working on standardizing their financials package and their primary business ERP, from several regional implementations and a couple of different variations.  They have a large consulting firm supplying talent for the financials, the vendor providing talent for the ERP, and a smaller consulting firm as the overall program management office.  They know what SaaS is, and they understand that we don’t do implementations the same way that you would for an ERP.  But they need to manage the program, so they provided a “shell” project plan, with the various high-level tasks in their terminology, so they can integrate our project plan with the others.

I spent about 15 years doing ERP implementations, including similar “standardization” efforts.  I know the vocabulary, and the logic behind the processes.  But the SaaS vocabulary and processes are based on a completely different cultural metaphor, and overlaying the ERP-based shell plan with the SaaS-based project template produced some highly visible differences.  For example, there are ERP references to “enhancements,” which aren’t allowed in our SaaS ecosystem.  You only configure the system; you don’t modify it.  The ERP contemplates development of a “performance and stress test approach;” in the SaaS culture, that’s a vendor responsibility, not a project activity.  The ERP shell has tasks for building non-production environments; all we have to do is process a request before 2:00 PM Pacific time, and it’s ready the next morning.

Of course, these metaphors reflect different technical, operational, and business models; there is nothing arbitrary about them.  The ERP solution is capital-intensive, and the SaaS model is expense-intensive.  The ERP approach is about data, and the SaaS approach is about business processes.  The ERP solution requires significant organizational IT support, and the SaaS solution doesn’t.  I could go on, but you get the idea.

So I was able to map some of the SaaS tasks to the ERP plan, and inserted a number of others.  And I “retired” a number of ERP tasks that simply didn’t apply.  When I was done, I had the first draft of a plan that is neither SaaS nor ERP, but will allow us to manage the work, from both the program and project levels.  And that was the original goal.  We’ll tweak the plan over the next couple of weeks, adjusting the schedule as we get our arms around the level of effort required.  And as we get the ERP folks up to speed on our approach, mostly off-site, with iterative prototyping and no customization, I think they’ll be able to monitor our progress.  Because the two cultures aren’t all that different.

This entry was posted in Best Practices and tagged by Dave Gordon. Bookmark the permalink.

About Dave Gordon

Dave Gordon is a project manager with over twenty five years of experience in implementing human capital management and payroll systems, including SaaS solutions like Workday and premises-based ERP solutions like PeopleSoft and ADP Enterprise. He has an MS in IT with a concentration in project management, and a BS in Business. In addition to his articles and blog posts, he curates a weekly roundup of articles on project management, and he has authored or contributed to several books on project management.