The M2 Factor: A Project Manager’s guide to Magento 2

9 months ago  •  By  •  1 Comments

The story nobody told you, poor PM.

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.

A typical Magento 2 project should eventually cover an easy-to-implement responsive template and simple, effective modules for PayPal, Authorize.net and Braintree. The performance should be awesome – full page caching on community edition; compatibility with the newest versions of PHP and JavaScript libraries; compilation and the new “production mode” all working smoothly together, supercharged by Varnish (think, Nitrous). A dream come true. Surely.

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).

Golden lessons learned: A good Magento 1 development team is not necessarily good on Magento 2. Full stack and literate PHP, JavaScript and CSS skills are essential. Having these resources, it is mandatory to listen to concerns and how they affect estimations. Again, if there’s no Magento 2 experience on board, PM’s must be aware that breakdown sessions may be longer, and the resulting estimate can be up to four times higher than for Magento 1. It’s taken a few stores for us to feel fully Magento 2 ready at Matter Of Form. Our wonderful clients have worked side by side with us to ensure we prioritize and deliver, in face of issues that have occasionally been frustrating and difficult to diagnose (Tangle Teezer and Parka – you’ve been great!).

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.

Gabriel Zamprogna – eCommerce Project Director

Comments 1

  1. Stephen Hill
    Nice article.

Submit a Comment