I was hired by an agency to create an online storefront for a Commercial Flooring business. The business was looking for a way their sales reps could sell their overstock products that their warehouse was holding onto that were left over from previous jobs.
The flooring business was somewhat clear from the start that this would be a multi-phase project; that should have been my first red flag. They wanted to test the storefront to “iron out the kinks” internally, and make sure it was a good solution for the public.
It was never determined upfront though what those potential kinks or hypotheses were. Was there internal alignment among the flooring business with the decisions we were making? And how exactly would an internal site validate a public-facing site?
When we wrapped up Phase 1 of the project, I wasn’t sure what we created, if it was what the company actually wanted?
How do I make sure what I’m building today stays tomorrow?
The plan, presented by the Vice President, was to test out Phase 1 for a few months and iterate to a Phase 2. In Phase 1 I built:
- Custom importing tools
- FTP automations
- ERP mapping
- Custom templates
- Custom eCommerce reserve functionality
I knew upfront that this project was going to make a transition, but was there something better that I could’ve done to avoid this painful transition of throwing most of the above list away for Phase 2?
To test the first Phase 1 site, the flooring business wanted 1 or 2 specific sales reps to use the site on their tablet and try to reserve some stock for resell. The business didn’t want sales reps entering payment information into the site because there was no easy way to integrate the business’ CRM / ERP to the new storefront.
I spent so much time writing clean code and it was scrapped for another plan. Removing what I originally built was honestly the best thing for the project, but it’s so hard to see while in the midst of the build.
If the first time wasn’t good enough, could the second time be better?
The President didn’t like what was initially built for Phase 1 – the company couldn’t use it to sell products (to this day I couldn’t tell you why), and they needed to come up with another solution.
Now that the President was involved, he removed the VP from the project; I could sense his overall frustration with the VP and not with me, so we were on a good start.
He brought on another middle manager in the business that would be more hands on and my new main point of contact for managing the Phase 2 project. Her sole mission was to make sure Phase 2 would be as the President wanted.
Was Phase 1 a flop or did we need to go through this expensive exercise to determine what really mattered to the business?
Phase 1 was a painful and costly learning experience, because after the flooring business paid for their employees to be involved in this build, ultimately the site was not what the executives wanted.
- How could I have known Phase 1 wasn’t what the President wanted?
- Should I have asked the question ahead of time or throughout the project if there are any other stakeholders needing to see this work?
I was happy that the business still wanted to work with me, but I wasn’t sure I would be able to deliver what they truly wanted. I was unsure that the new direction is actually what they wanted now.
Throwing code/development away for the next version
I took pride in my code, and the functionality I unlocked for the company. When they said they wanted to throw it away and move onto the next phase or version of the site, it stung. Not because I didn’t know we were going to eventually make the transition, but because the first phase was such a flop, with literally 0 data to back up what we were working on, it all just felt like a waste of time.
Scrapping a project though – fortunately and unfortunately – is inevitable at times though because once you build that first phase and realize it isn’t how you envisioned – this is first a hard decision for the company that is paying for the work to be done. The flooring business was paying the marketing team, the IT team, the agency that hired me to “project manage”, and me as the consultant/developer. For them to scrap the project is a large investment that they are throwing out as well.
When it came time to launch though – radio silence. For a month or so after we launched the first phase, the business was struggling to use the site for its originally intended purposes. Why? I got the sense that the VP didn’t either do a lot of internal discussion and alignment about this build, so there were only a few people on the team that only knew what was going on, and the rest of the business couldn’t adjust to what we were building. We were close to scrapping the project unfortunately, after spending months and months trying to get this Phase 1 to work.
What are the RIGHT questions to ask to get the TRUE direction of the business and project
Multiple builds of the same website in my case could have been avoided by asking more specific questions upfront to the leadership team heading up the Phase 1 or Phase 2 builds.
The following questions focus on going that extra step to uncover what isn’t considered to just get the job done.
- “Who are the stakeholders in the company, and who will be managing the site post-launch?”
Identifying the right stakeholders for any project is key to making sure that what you are building is actually what the business wants. If you assume that all key stakeholders are apart of the build process, and then come to find out afterwards post-launch that there are others in the company that have a say in whether what you build is good or not – you want those people in the room as often as they can be to make the final decisions before launching the project – even if it delays the timeline of the project.
Also, when the project you’re building is officially deployed, who is going to be managing and supporting after the launch? I would hate to see all your hard work go out the window just because, even if you presented the company with thorough walkthroughs and documentation (does the client ever read this?), the client will still “not know what to do” and allow the site to deteriorate because they didn’t have proper guardrails in place to keep them locked into the design you intended. - “At a high level, what is the true business problem you are trying to solve? And does this scope truly solve that problem?”
In my Commercial Flooring example, the client came to me with a “solution” that they already thought through; my job working through another agency was to validate the Commercial Flooring company’s idea, and show them how it can be done.
The client is not always right though. Instead of diving straight into the scope of the project, first identify what the problem is that is needing to be solved. If the problem cannot be communicated clearly, then the “solution” truly isn’t a solution.
If the problem cannot be communicated clearly upfront, and you deliver on the client’s scope, this will end poorly for both you and the business. What you developed will never be used by the business because they truly didn’t need it in the first place. - “Once we have this built, will you be proud to show this to your executive team (if they are not an immediate stakeholder in the build)?”
This goes along with question 1 above, but if the executives don’t want to get involved with the build process, but will have a say if this project is successful or not – ask this question often throughout the build and QA process.
If the project manager is so wrapped up in the details of just getting the project done and not considering the perspective of executives and if this solves a real problem, than you are probably looking at either a refactoring, complete rewrite, or worse – just scrapping the project all together.
Worst of all, this is going to put a sour taste in the executives mouth because of the amount of funds used to build what you built that wasn’t a good investment for the company – doesn’t look good on your resume. - “Who will see this that isn’t in the room?”
This ties into #1 and #3, but you want to make it crystal clear if there are others in the business that will have a say in the success of the build – they need to somehow either be part of the conversation, QA, or pre-deploy process.
Your time and experience is valuable, and you need to make sure what you’re contributing is worth it to the business to build.
As developers, we are called to be something greater than just “task-doers”. We need to strategically think about the overall value and impact we are having on the company by the work that we do. May it be for our employer, freelance, or small business – there should be a clear reason why you’re building and coding what you are working on.
If that reason isn’t clear from the start – you have 2 options. The first is either you build knowing that in the back of your head most of this will be scrapped so don’t put a lot of effort into it, or second you pump the breaks, invest more time into the scoping of the project – measure twice and cut once – and make sure what you’re building will make a difference for the business for the long term.