The M2 Factor: A Project Manager’s guide to Magento 2
There has been a lot of noise about Magento 2 after its official launch almost 12 months ago. It’s been around 9 months since a selection of agencies started to debut their first Magento 2 projects. The goal: To deliver new eCommerce sites on the latest open-source technology, without tying new clients into a platform that would soon be redundant. And given there are some great new features, we couldn’t wait to start exploring at Matter Of Form…
A bit of history.
Although the intention to upgrade the 7 year-old platform with the most up-to-date programming frameworks seemed a natural evolution, it quickly became obvious that the learning curve was steeper than expected. Developers and strategists quickly had to adapt launch plans to slim down requirements. Project plans were thwarted. PMs everywhere were struggling to come up with mitigation workarounds for broken functions, often having to deal with base-level, hygiene factor features that would not work as expected.
To scope, or not to scope.
For team members without previous experience on Magento 2, including community enthusiasts who follow every new commit on GitHub, the change was akin to literally learning to change the tyre whilst driving. Development leads globally were realising that a basic installation was causing issues, let alone more advanced features that clearly weren't ready (check Alan Storm’s excellent Open Letter to Magento’s Leaders here). It was time for the PM teams to review their waterfall plans and force through a more AGILE process.
Golden lessons learned: If the team involved hasn’t completely delivered at least one or two full Magento 2 projects (back-end and front-end), any PM should account more time for the specification phase (think, factor of four). If the scope includes the creation of new basic modules from scratch (carrousels, top navigation, OMS/ERP integrations), think two to three times more time to design than a similar scope for Magento 1. And design and UX teams – take heed from your Dev team, this is not the time to work in a silo.
Don’t kill time, time kills.
The breakdown and estimates sessions were a nightmare. Our team were super excited by new, contemporary dev frameworks - but so much has changed, previous experience with Magento 1 counts for very little. How to estimate the final effort for any task, when everything had a completely new set of dependencies? Should the team create workarounds for minor bugs, before a seemingly endless stream of critical upgrades being launched by Magento either fixed or exacerbated the issue? How to account for inexplicable latency issues experienced on local installations? Finally, how to get the Server environments production ready and working robustly which such a dramatic change in format (note to Dev Ops teams – prepare well in advance).
Cost, glorious cost.
From the Project Management Triangle, cost if often a fixed threshold. Regardless, wherever possible, an AGILE approach is best for eCommerce planning and execution, and allows for quick changes and iteration.
Golden lessons: The application of a proper discovery phase to cover UX & Design, development breakdowns and estimates is vital. The final outcome should include a realistic view of the budget, considering the scope and estimations. If third parties are involved, i.e. for modules or payment/shipping/logistics integrations, their lack of Magento 2 knowledge and experience needs to be considered and not in any way underestimated.We were lucky that the third parties we were working with were responsive and eager to learn, but this level of cooperation hasn't always been the case and would have derailed many critical integrations.
Five members of our eCommerce development team worked tirelessly through nights, inspired by the challenges presented by the new version of Magento 2, as frustrating as they might have been on occasion.