A Reader Responds: “How I Improved a Companies Processes, Sped Up Project Timelines, and Saved Them a Fortune, and Was Fired for It.”

During my senior year at the UCSF, I served as an intern for a SaaS company specializing in account management software.  The company's primary clientele comprised small to medium-sized enterprises, with a particular emphasis on emerging industries.  My role was within the Client Success and Implementation Management Office, where I worked closely with an Implementation Success Manager (Project Manager in most other organizations).  While the sales team were exceptional in securing clients, the implementation process was notably suboptimal and failed to deliver on the promises made by sales.  

The onboarding procedure for new projects entailed three weeks of discovery and requirements solicitation, followed by four months of development work segmented into four three-week sprints, interspersed with one-week intervals for client approval, culminating in two months of testing and adjustments.

Upon closer examination, I discerned that only approximately 20% of the product was customizable, with the majority of the software being standardized.  I proposed the utilization of Adobe XD (RIP) to create a functional prototype for client review prior to the commencement of development, thereby expediting the project timeline.  However, my suggestion was dismissed, and I was advised to “stay in my lane”.

Undeterred, I developed a presentation to demonstrate the potential time savings of my proposal, intending to present it to the Director of the Client Success and Implementation Management Office.  My proposed solution was straightforward:

1. Requirements Phase – Four weeks:

   • Weeks one and two: Distribute a workbook to capture any customizable elements.

   • Weeks three and four: Conduct meetings with the client to refine and finalize the customizations.

2. Prototype Testing and Adjustment – Two weeks:

   • Utilize a template prototype in Adobe XD to incorporate any customizable features.

   • Provide the prototype to the client for extensive testing and feedback, making necessary adjustments during this phase.

3. Development Phase – Two months:

   • Eliminate the need for additional weeks between sprints, thereby reducing the overall development time by nearly a month.

   • Minimize rework by securing client approval on the prototype.

4. User Testing – One month:

   • Focus solely on testing the coded product, as the user experience would have already been validated through the prototype phase.

In total, my proposal aimed to reduce the development timeline from 27 weeks to 18 weeks.  Despite the potential benefits, I was terminated for allegedly wasting company time on an unfeasible project.  Interestingly a fellow alumna who had been hired at the company full-time informed me that the company had implemented my strategy and achieved delivery times of approximately 12-15 weeks.

-            Noël M.

Thank you, Noël, I hope you don’t mind but we shortened your 5-page fucking master’s thesis down to a few paragraphs (finally a decent use for AI).  Nascent?  Really?  Spurious, parsimonious, obsequious, I had to have a fucking dictionary next to me to understand a damn thing you were saying… Love you.

Companies Focus Too Much on Making a Sale, and Not Enough on Delivery

“Nothing happens until you sell something,” a quote often attributed to Frito-Lay founder Herman Lay.  Considering Frito-Lay is one of the largest direct sales organizations in the world, maybe he was on to something, right?

No, fuck that. 

If things aren’t happening before you make the sale, then you are doing something wrong.

I attended a talk that featured a VP with a sales focused company who gave a breakdown of the most important aspects of sales. 

1. Make saying yes as simple as possible

2. Make the experience between saying yes and delivery as hands off as possible for your client

3. Make sure what is delivered is what the client expected.

He went on to say that actually making the sale probably only barely cracks the top 10, since the most important aspect of relationship selling is not making the sale, but what you do with that sale.

I think about this a lot when working on delivering a product to a client.  It’s one thing to deliver something, it’s an entirely other to deliver on expectations.  Noël’s experience demonstrates a need for Project Managers, sales teams, and implementation teams to focus on the use of technology to streamline and redirect expectations to clients in a meaningful way.  A way to make it as easy as possible to sign off on the work, a way to ease the burden on the client throughout the project lifecycle, and a way to have the expectations established very early on.

Why No One Prototypes Anymore

I admit, this is an extreme take, there are certainly organizations that still use prototypes, and prototyping software like Figma, XD, or others to help streamline the development process, but a significant number of organizations have left it behind, and I started to ask myself, why?

I reached out to a former colleague, who is the director of user and client experience for a major insurance company.  His take was that it relates to a philosophy in UX design that you should never show a client a mock-up or prototype that looks too polished, because it might negatively affect feedback.  Basically, if it looks too nice, then people are less likely to criticize it, or be honest when providing feedback on their assessment.

It reminds of something my high-school art teacher said about Michelangelo’s David.  That it was too perfect, so Michelangelo deliberately marred the statue, so that it wasn’t offensive to God (or something like that).  True or not, would project teams need to deliberately nerf a prototype because it’s too perfect, and potentially offensive to god (the client in my rant)?

Would it be enough to explain how simple the prototyping process was?  That you literally just copy and pasted shit into a template, and it took you all of about 30 minutes to do?

Well… the studies say no, it’s not enough.

How do you overcome the politeness of your client?  One suggestion, proposed by my former colleague, is to be manipulative as shit.

You see, what he’ll do is deliberately miss something.  When he’s demonstrating the prototype, and walking the client or stakeholder through the mock-up, he’ll catch the missing thing, making a big deal about missing it (apologizing, being self-deprecating, etc.).  Then he’ll just copy what needs to be updated, and paste it in.  

Once the client sees how easy it is to make these changes to the mock-up, they are significantly less likely to have reservations about providing honest feedback.

The other reason, proposed by Noël, was that leadership sees the extra time spent on the prototype, and the time spent with the client going over it is just added time to the project as a whole therefore costing them more money. 

Which is bullshit, because…

A Well-Informed Client is an Easy Client

I’ve worked on both sides of an implementation project, and let me tell you, the more those involved know, the easier they are to deal with.

I can’t tell you the number of times I’ve sat on a call, while a developer tries to explain how something will work, and the poor client is completely dumbfucked, because they can’t visualize what they are talking about.  What follows is the client asking (TBH) dumb questions, while the developer just keeps saying the same thing over and over again, because they don’t understand what the client isn’t understanding.  Everyone is pissed, and you’ve just started the project off in a really shitty position.

One of the most common feedback from clients I received in these types of implementations is that they “wished they could see it in action before having to test it.”  The reasons for this vary, but at the heart of it lies the same desire, they want to be more (read: better) informed.

This shouldn’t be a radical take.  Keeping the client informed is kind of part of the job description, so it’s odd that providing the client something tangible early on as a way of informing them and gaining valuable insight is frequently seen as too expensive for the project as a whole.

It’s because there is no guarantee that it will reduce development time.  There’s no guarantee that it will provide clearer direction early on.  There’s no guarantee that… or a guarantee that… or some sort of… guarantee… that… um… it’ll be profitable.

When I shared this with fellow PMs, I got a lot of hand wringing that nothing should be done in a project unless there is some guarantee that there will be a positive return.  Some followed this up with the argument that it would actually inhibit the development cycle because a prototype doesn’t demonstrate how the backend works, which makes up a significant portion of the SDLC.  Therefore, prototyping is a waste.

Well, Varun, I’m here to tell you that’s a shitty ass take.  Why? 

Well…

The Backend is Never Seen, Just Experienced

Again, this shouldn’t be a controversial take, but here we are.

I always figured that the difference between frontend and backend was self-explanatory.  You don’t see what’s going on in the backend, but it’s what drives the user experience in the frontend.  Right?  Can we all agree on that? 

The argument that a prototype can’t show how the backend is going to work, and therefore renders the entire prototyping process moot, is batshit insane.  Yeah, you don’t see the backend, because you never do, but you see the effects of the backend on the frontend.  You can demonstrate all these things in a prototype, fairly easy.  The DB can only store date format in CCYY/MM/DD and therefore needs to be displayed in the FE as such, great, we can add that to the prototype really easily. 

The user experience will be slightly different between an unsecured page and the secured page?  We can handle that as well.  We can add delays, icons demonstrating that the site is secure, slower page response times.  All of that can be faked in the prototype, and with most prototyping software, it’s as easy as a couple of clicks.

This is why I argue that the backend isn’t seen, it’s part of the experience.  Understanding this allows us to customize the prototype so that we can also explore how users would experience it when it’s actually live.  We’re not building out a back end, but we are demonstrating how decisions in the backend can and will affect the final product.

Fuck You, My Software Doesn’t Even Have a UI

I’m not saying that every single vendor should have some prototypes for their clients to have a little in-out with.  There are plenty of times when a prototype would be so complex, that it ceases to be of any value.  Similarly, plenty of software offerings don’t actually have any GUI to speak of, it’s simply a process that runs in the background of other software, so again, the prototype process would be a complete waste of money.

What we are saying is that PMs should always be exploring how to modify their methods to increase the possibility of a successful project.  Frequently, that entails constant reexamination of the project in a way that frequently makes PMs uncomfortable.  “What if, in the course of discussion, we determine that the project is no longer viable?  All I wanted was to use Figma, and now they are saying the project is dead in the water!”  Deliberate melodramatic takes aside, I am a firm believer that there needs to be regular come to Jesus moments for the project team, where everyone asks themselves:

Is this really working?

Is this the best way to serve the client?

Is this how we make it as easy as possible to say yes to singing off?

Is this meeting the expectations of key stakeholders, and organizational leaders?

Is this the most cost-effective way to present our product to our clients?

Is this the most cost-effective way to serve our clients?

It’s uncomfortable to have to dig deep and introspective about these things, especially since I would argue that at some point in all projects, the answer to these questions are probably no, or some variation of it.

But the thing is when you stop and ask yourselves these questions, you might actually find that, while the answer is no, the way to get it to a yes is by introducing something like a prototype that clients can dink around in.

Why You Should Care

One thing I remember in the early days of my career was that a PM should expect to spend their entire budget.

The rationale is that the project has a budget that has been allocated.  If you don’t spend it, then it’s money without a home.

If the project is budgeted for $500,000, then you should be damn sure to spend all $500,000!  The source of this philosophy seems to be somewhat contentious, and there is significant arguments to be made one way or the other, but my personal take is that it’s probably more related to governmental spending, and the need to track expenses such that you don’t exceed a department’s budget.  That is, since the department was allotted a specific annual budget, and they turned around and budgeted the project a specific sum, any of that money that isn’t used is simply lost.

This has carried over into the business world.

Now, consider a proposal that would cut the project time in half, and save an estimated 25% of the budget.  Shit, that’s $125,000 that you need to figure out how to make disappear, so that you don’t undershoot your budget!  Fuck that, why would we undertake that and lose $125,000 of our annual budget!

Yeah, this can be a problem.  It was raised by several academics as being a problem: a problem without a clear solution.

But, I think there is a solution.  A solution that we can borrow from other project work.

In construction, when a new technology is developed that can make the work easier and more cost-effective, the cost of the initial investment and training isn’t shouldered by the first project that uses that technology.  Instead, that cost is spread out across multiple projects, and the savings that you can start to track is then subtracted from the cost of implementation moving forward.

If implementing a prototype will save you 25% off your budget, you can start by cutting the budget by 5%, and the costs of building that prototype and training the specialists how to refine it and present it are added to the cost of implementation.   Next project you might cut the budget by 20%, until finally settling on a new budget for all projects moving forward.  The point is, you don’t have to suddenly lose that budgeted amount off the current project, instead, it can be strategically reallocated to build out the prototype, and any future underspends can be handled by refining the prototype to better serve the client.

This is something that, in talking to elder PMs, used to occur all the time.  It made sense then, and it makes sense now.  One client isn’t going to shoulder all of the responsibility for your organization to implement some new technology, when everyone can and will benefit from it moving forward.

It becomes too easy for PMs to be hyper focused on the project in front of them right now, to the detriment of a bigger picture.

Implementing a prototype for the client to toy around with probably isn’t going to save you too much the first time it’s implemented.  It’s probably not going to save much more the second time. 

The question isn’t what do we do with our extra $125,000?  The question will probably be, look, we saved $5,000, which is much more inline with an acceptable variation in budget.

Take this, and apply it to future projects.  Last time we budgeted $500,000, but had a 1% variance.  Ok, this time we’ll budget $475,000, next time we’ll budget $400,000, etc.  Until you arrive at a new cost for implementation, and you can stick with it moving forward.

But it requires you, as a PM, to think beyond the current project, to future implementations.