Forklifts or Fortune?
While we know little about these ubiquitous workhorses, we have great respect for them. Theyre apparently pretty reliable. Some companies would come to a standstill without them. When it comes to forklifts, the difference between having one or none is huge.
Consider the collective knowledge that benefits todays forklift buyer. This machine has been around at least half a century, and hundreds of engineering improvements have been made along the way. Its the same for other technologies, from telephones to cars.
Business computing started in the accounting department. Then word processing became indispensable. Desktop spreadsheets started a revolution. Networks facilitated email and the Internet.
Now the smallest of enterprises employ the technologies that only global corporations could afford just a decade or two ago.
And so it is with our new client. They have an evolved technology infrastructure, and identified areas for productivity improvements.
Will our solution prove as productive for this client as a new forklift? It had better. Why else would they sign the contract?
Indications are that well exceed all expectations with our new system for this client. But perhaps we should be most grateful that they didnt need another forklift at this particular time.
Most clients are managing multiple projects and responsibilities. Our project cant always be at the top of their list. Our ego is only slightly bruised.
Two of our solutions were launched over the last ten days, and theyre succeeding by any measure.
Both were approved in early March, and scheduled to go live in early April. And then they were delayed on the client side for several weeks for legitimate reasons.
We love momentum. The development process thrives on it. And developers cringe when its lost.
Once we get submerged in these projects, wed rather not come to the surface until theyre done. When a timeline protracts, after a while those minor issues you left dangling can haunt you.
You might find yourself mentally reconstructing the system diagram and triple-checking the database relationships.
Or opening up the beta version under review to ensure that related line items are deleted when an order is cancelled.
But one issues looms over all others: Will we be able to successfully submerge ourselves into the project again when the time comes?
But our worries are unfounded. Development is the fun part of this business, more fun than writing proposals or even newsletters.
So we found ourselves enthusiastically (and simultaneously) resuming development of these two projects and launching them over a ten-day period.
If it was easy, our clients would do it all themselves.
The Goodle Days
I can be nostalgic about peculiar things. For example, I recently glommed onto an inventory project for a client as if by instinct.
I was a paper boy, seed seller, dishwasher, shoe shiner, envelope stuffer, photographer, filmmaker and sales clerk all by age 18.
All of these endeavors required analysis and planning to do well, things Ive always been good at.
So coordinating this inventory project called upon some of the primary skills that precede technology. It got me out of the office and into the warehouse to evaluate the situation which allowed me to generate the best tools to take the physical inventory which Hey, it was fun, I promise!
Lets stay in touch.