The Most Profitable Mindset Shift for Access Consultants

I write and maintain a lot of Microsoft Access applications.  I consider myself an Access developer.  But it turned out that thinking of myself as someone who develops software was artificially limiting.

A more powerful (and profitable) mindset was to think of myself as someone who solves business problems.

How to Recognize Opportunities

A few years back, I was rewriting a web application for a client.  The client served the original website from a public-facing server within their local network.

Hosting an external site from within the internal network greatly increased the network's attack surface.  The client had trouble hiring and keeping employees with the technical expertise to manage this scenario.

The web server was nearing end-of-life.  As part of the web application rewrite project, our client would need to deploy and maintain a new web server.

When I spoke to the IT director about the hardware requirements for the migrated web application, he mentioned again what a security headache it was to maintain the web server.  His staff was already stretched thin.  He was constantly worried that a web server vulnerability would open a back door into the broader internal network.

What do you call it when a client uses emotional language on multiple occasions to describe the same problem?  A business opportunity.

How to Seize Opportunities

I delivered a software proposal for the web application migration as the client had requested.  As part of the proposal, I included a section on client responsibilities.  Specifically, I listed our requirements for the new server.

In the past, I would have stopped there.  We're a software development company after all.  I had no desire to get into the hardware business.  But I kept thinking about my client and about the conversations I had with the IT director.

On a whim, I wrote a second proposal.  To be clear, the client did not ask us to do this.

I started by describing the situation.  The client had legitimate concerns about hosting an external web server from within their internal network.  A more secure option would be to host the web server outside of the network.

I presented three options for how we could help with this task, whether they chose to continue hosting the web server within the network or to move it to the cloud.

Option A: Technical support for setting up new server hardware

This option was basically maintaining the status quo with updated hardware.  The client would be responsible for purchasing, configuring, and maintaining the server.  We would provide technical assistance on an as-needed basis at our prevailing hourly rate.

Option B: Technical support for provisioning a cloud web server

We explained the security benefits of having a web server that was completely air-gapped from their internal network.  The client would be responsible for provisioning and maintaining the cloud server.  Once again, we would provide technical assistance on an as-needed basis at our prevailing hourly rate.

Option C: We provision and maintain the cloud web server

This was our white-glove option.  My company would provision and maintain the cloud server.  The client–and, critically, the IT director–would have one less thing to worry about at night.  We would charge an annual fee for maintaining the server.

How to Price Opportunities

The first two options would be billed hourly on an as-needed basis.  They were mainly there to make it explicit that our technical assistance in setting up the web server would be above and beyond the software development of the web application itself (i.e., it fell outside the scope of our first proposal).

The third option was outside of our core competency of software development.  I struggled to come up with a number for this white-glove option.  Based on time and materials, I estimated it would cost us about $3K - $5k per year to provide the service.  The first year would be on the high end of that range, but subsequent years would likely be on the low end.

My gut instinct was to charge $5k for the first year.  If I was desperate to win this contract, that's probably how I would have priced it (if not even lower).  But the more I thought about it, the more I realized I did not particularly want to be in the business of web server management.

But I did not have a strong sense of how much my client also did not want to be in the business of web server management.

I spent the weekend thinking about how to price this option.  In the end, I went with a simple thought experiment: What's the least I could charge and still not feel a single pang of apprehension if the client said, "Yes"?

For me, that price turned out to be $7,500 per year.  To sweeten the deal, I guaranteed that price for five years.  I also guaranteed that any future web applications we wrote for the client could be hosted on the server at no additional charge.

Much to my surprise (at the time), the client went with Option C.  

Lessons Learned

Pay attention to emotional language

I wrote the second proposal only because I recognized my client's emotional problem language.  On multiple occasions, the IT director bemoaned the fact that he struggled to hire and keep good people.  This added stress to the already-stressful task of securing an in-house web server.

No one is forcing the client to say yes

There's no such thing as a "fair" price.  In an arms-length transaction, if the client does not feel your proposal provides them good value, they can simply decline it.  Use this to your advantage to charge higher prices than you might otherwise.  Especially for projects where you don't care if the client says No.

Don't be desperate

Of course, if you are concerned about winning absolutely every bid, then you will have trouble maximizing your profit margin.  If I needed the extra business from that second proposal, I likely would have priced Option C significantly lower.

Shift your mindset from software developer to problem solver

As the title of the article suggests, this is the most import lesson learned.  If you think of yourself only as a software developer, it's like wearing blinders that stop you from seeing the opportunities that present themselves every day.

You're not a software developer; you're a problem solver.  Embrace that mindset.

Image by JackieLou DL from Pixabay