When managing projects, one usually focuses on big things: biggest costs, biggest features, biggest risks, etc. The same is with building an eCommerce site – the biggest, most important things are, well, most important.
But large topics are not the be-all and end-all of the project.
In this post, we will illustrate how tiny issues can have an outsized influence on the project. Through analysis of several examples from our experience, we will try to understand how small perturbations shape the course of the project.
So let’s start with something totally relevant, let’s start with – Napoleon.
We all know the story. He conquered Europe, and then turned his sights on Russia. His conquest started with an army of 680 000 men, and in a short time marched into Moscow. Russians evacuate Moscow and burn down three quarters of it! Napoleon, short on supplies retreats from the empty city. During the retreat, he loses most of his army. Out of 600 000 men, only 30 000 survive, and only 1 000 are fit for service.
A great story of brilliant defensive strategy.
Or is it?
In 2001, workers digging trenches for telephone cables in Vilnius, Lithuania found over 2 000 skeletons, stacked three on top of each other, arranged in v-shape. Analysis revealed that those were soldiers from Napoleon’s time, and with their remains, the complete story of Napoleon’s defeat was revealed:
Napoleon starts his attack on Russia in June 1812 from Germany. Things turn downhill in Poland. The summer is unusually hot and 20 thousand horses die of thirst. This stretches and strains the supply lines and the resources are scarce. The hygiene is bad and lice are becoming a huge problem – they are visibly crawling on men and the whole army is infested. Lice carry typhus, and in a month 80 000 soldiers die or are incapacitated because of the disease.
In August Napoleon conquers Smolensk, but another 105 000 men are lost to typhus. In the next two weeks, typhus claims another 60 000 men. In September, a week after the battle of Borodino, Napoleon enters Moscow with 90 000 men. The city is deserted and burned. Napoleon requests enforcements, but out of 15 000 men sent to him, 10 000 die from typhus. The winter is coming, and supplies have run out. Napoleon decides to retreat.
In December they come to Vilnius, with only 20 000 men fit for service. Fearing the coup, Napoleon urgently leaves for Paris, and general Murat organizes the retreat.
And now it is clear: a military genius of Kutuzov, and the coldest Russian winter and all the Russian cannons heard pounding in overture to Tchaikovsky’s 1812 weren’t enough to defeat the great general. It took the smallest creature of them all, unassuming, ordinary lice to bring destruction to Grande Armée.
With that in mind, what are the small, seemingly insignificant things that have an outsized influence on our projects?
Let’s walk through few examples of the small challenges or hiccups that proved to be big in the end (whether we acted proactively to resolve them and prevent the excrement hitting the fan, or we learned the hard way from addressing them too late in the game).
We will start with technical topics, and move slowly into organizational and pure project management issues.
Comment? What comment?
– When comments in code are bad
You know how developers often comment out pieces of code while working, in order to speed up a process or go around specific bugs in Magento (what bugs in Magento, you ask?!?!)
Well, it happened probably too many times that a piece of code that was commented out during development made it through to production that way, causing havoc on live site. Why is this commented out? What does it do? What did it use to do?
Lesson learned: Establish proper git branching model – And stick to it for dear life!
Leave commented out code out of committed code. Instead, keep it in git-diff – this may be subject to interpretation and depends on the project at hand, but this is a good rule of thumb. For controlling different versions of our code, we should use – version control software.
Attack of the Robots
– Ignore crawlers at your own peril!
Magento site works the same with or without the robots.txt file. The file itself does not affect the functioning of the store. The interesting thing about it is that it is one of few items that must be different between staging and live site (on staging we want to exclude everything from crawling, and on live site we are targeting specific files and folders – though usually it is a large number of them).
What happens is that after deployment, because of gitignore developer inadvertently deletes robots.txt file without noticing. Actually, nobody notices – the site works ok and everybody is celebrating new feature release.
Nobody notices, until we got a call from the client that the site is down. Next call is with the hosting provider – they will yell how they are bombarded with requests and how Google crashes our site. All because of one simple small txt file that does not affect our code or the user.
Lesson learned: Establish post-deploy check procedure – And execute it every time!
There are a lot of small tasks that need to be done and are easily forgotten during deploy. Having a checklist that we can rely on releases our mental energy to focus on executing the task at hand.
I-Track, U-Track, DDoS-Track
– Newsletters gone wild!
Newsletters are a great way to inform customers about new promotions and discounts. One large client had a big subscriber database and was sending a newsletter to them without problem for years. The URL in the newsletter was a hefty complex query, but as Magento has full-page caching, it was not a problem for the server.
At one point marketing came to a very reasonable idea to track which subscribers open the newsletter, so they could analyze and segment the campaigns. The tracking was implemented by adding a unique ID parameter to each newsletter URL, so when the user opens the newsletter, the hit is registered.
What that meant is that each user was served a unique page, Magento’s full-page cache was no longer used, and the query was executed for each hit. With a huge amount of subscribers opening their newsletter at the same time and thus executing the enormous query, the site went down. The client DDoS-ed themselves.
Lesson learned: Establish a Change Request Procedure – Make it simple, clear and stick to it!
Change is a fact for any project, that is why we have to be prepared for change. By establishing a Change Request Procedure we will make sure that relevant persons vet the change. For example, should the request be checked by Development, SEO specialist, Marketing? In our example, the solution was to setup caching to ignore the parameter – something a developer would notice in a second.
Extending the non-extendable
– Assumptions are just that!
We have a relatively large client (around 80 000 products) that wanted to track stock for a subset of products, and if a customer tries to order out of stock product, offer them a subscription to notification when the product is in stock again.
The notification is easy to do if the stock management is global, if Magento manages the stock for all products. If the stock is tracked only on a subset of products, as was the case with that client, then Magento will trigger the subscription message for all non-managed products (since their stock is 0)
We planned to go with Magento 1, so the solution was simple – extend the core to additionally check does the product have managed stock and if not, suppress the message. 30 minutes work.
Then Magento 2 became a thing. And the plan was changed, we’ll go with Magento 2. Because why not. Now, Magento 2 does not allow extending core. In general, you don’t extend a component, you write your own. In this case, we were deep in the core, we had to rework the whole Product page, which landed us with 30h of work. Add few similar customizations, and you have a project deep in red.
Lesson learned: Check your assumptions – Then double check them!
Every project is built on a series of assumptions. If one of them changes or proves wrong (we’re using Magento 2 instead of Magento 1), then the project is in danger (in this case, our estimates are way off). But if we know the assumptions we’re building our project on (dare I say: if we have them written down), then we can always check them and react when they’re changing.
Most important lesson: build a relationship of trust with the client, so you can work together when problems like these arise.
An admin, an admin! My kingdom for an admin!
– Who handles system administration?
We had a client where we took care of everything on Magento side, and everyone thought (ok, we thought) that their hosting company takes care of permissions and overall server-side setup.
However, when we came close to deploying to the live site (there was a specific environment in place where we were allowed to push changes to live in a very specific way), we brought the site down only to realize that our latest deployments failed to go to production due to server-side setup mixup. We were not in a position to fix this ourselves, hosting company wasn’t aware we expected them to handle this, the client didn’t know whose job this would have to be in the first place. A small omission in communication caused a huge issue when the push came to shove.
Lesson learned: Know your scope – In more details than you think you need
Ask questions, a lot of them. Prepare a checklist for the Sales team and on-boarding process. PMs should make sure to have all of this information in place before the team starts working.
Roses are red, violets are blue
– Clash of personalities
When a new project kicks off, you have to establish a good rapport with a client. Sometimes, when the deadlines are tight and you are already stretched, you don’t have enough time to think about personality match with the client. Things can go south quickly if there is a personality or communication style mismatch that you put under the rug hoping it will sort itself out.
We’ve had a scenario in which our lead developer, who acted as the main point of contact, and the client had almost an outing over a specific task where they poorly communicated the feature request. The confusion, combined with poor judgment on how one can/should communicate directly with a client created enough bad blood to force us to remove the lead developer from all communication with the client and get another team member assume this role.
Fortunately, the timing was not off, and we made it to a point where we managed to salvage the relationship and the project.
Lesson learned: Know your client – Adapt your communication to the client
Keep a close eye on the communication, invest time to learn who you are talking to on the other side, who is the client’s representative, what communication style they prefer, how technical are they… so that you can decide what communication tone and frequency would be the best from your end. In PM-speak, do a stakeholder analysis and use it as input for creating communication matrix for the project.
Six is not enough?
If the six examples did not convince you, we could spend hours talking about:
- Client thinking something is irrelevant or easy and forgetting to tell us until it’s too late. E.g. automatic order processing is “just one button”, or the client doesn’t mention they have multiple stores,
- The time we did not contract 3rd party support (for integrated systems),
- That project where we did not include all stakeholders from the client side (e.g. not all departments) which led to last minute changes and budget overruns,
- When we did not explain our process to the client, so they were late with their deliveries (e.g. logos, transactional emails),
- The client that was too detailed and wanted to have spit-polished plans – the whole budget was spent only on planning,
- Or many projects where we did not check if extensions really work with the latest Magento version (e.g. M1 -> M2 upgrade)
- Or …
Instead of conclusion
“By failing to prepare, you are preparing to fail.”
– Benjamin Franklin
The six examples we covered are ranging from technical to social, but they have one thing in common. The solution was not technical, it was better processes, communication, organization – in short, better Project Management. They are the best illustration that the biggest risk and the biggest opportunity in projects come from good or bad project management. Please share your experiences in comments – what were the small things that made or broke your projects, and how did you deal with them?
Oh, I almost forgot…
Those skeletons in Vilnius? That wasn’t a mass grave, they were not burying the bodies. The ground was too frozen to dig, so they could not dig trenches. They used frozen corpses of their friends to build a breastwork, a shield, barricades to protect them from advancing Russian army.
Don’t let that happen to you because you ignored small things.
