As consultants, we all know that each customer is unique, with unique goals, resources, and capabilities. Therefore, it’s up to us as solution providers to put ourselves in our customers' shoes and understand the difference between the word of the SOW (Statement of Work) and the spirit of the SOW.
In this blog post I’ll be sharing a story I experienced recently which I hope serves as a useful example for those looking to improve in their ability to deliver the highest quality of service and to accomplish what our goal should always be: create happy customers.
A quick backstory
Not too long ago I was presented with an SOW that allotted 160 remote hours to architect and build a Splunk environment and ingest a few dozen data sources. I didn’t think much of it at first as this type of SOW is very common.
The first day I sat down with the customer to discuss the resources needed for their environment, and by the end of the second week we had a fully functional Splunk environment with a few of the easier data sources to ingest in Splunk and mapped to the Common Information Model (CIM).
Not just another gig...
At this point, I realized this project–if executed in its current form–was headed off the rails.
Why, you might ask? Well, this particular customer was very new to both Splunk and the data ingestion process. With dozens of data sources listed in the SOW for ingestion and countless customer personnel needed to sync up with, I realized burning through the last two weeks in a traditional fashion would be extremely wasteful from a time perspective.
Basically, I would be spending hours on the bench while the customer figured out the where’s and what’s needed for the ingestion of a specific data source, only to complete the 160 hours with a fraction of our proposed data sources available in Splunk. Not a very effective use of time. Not a happy customer.
Brainstorm and resolution
I decided to take the weekend to think about what to do to save this project, and at the start of week three, I was able to present the customer with a new solution.
First, I provided the customer with a detailed list of all the informational items I would need to ingest each data source, such as the location of the logs, the logging levels to be set, the actual files we wanted to ingest as well as vendor/application information. Then, I sat them down and went over the data ingestion process, discussing the primary uses of the Universal Forwarder and a high level description of syslog and API ingestion.
I then proposed we complete the SOW in an ad hoc fashion. Once they completed this list for a few data sources, they would reach out to me and we would consume a day of PS hours ingesting this data. I would then map the data to the CIM and take a few days off–then rinse and repeat until the SOW was completed.
Better plan, better results
With management approval–both on their end and ours–we put the plan in place.
At the end of the 160 hours not only had we ingested far more data than we would have originally been able to, but I was also able to spend some days sitting down with their team and training them on the process of searching and reporting, as well as using the data they had just ingested. The customer was thrilled, and the end result was a success.
Next time you’re completing an SOW, don’t just go down the checklist. Instead, inject the human element into the equation and think outside of the box in terms of how to best provide the solution that the SOW is attempting to map out. Even if the solution you decide on isn’t exactly like the one above, if you find yourself in a situation where the SOW is going off the rails, stop, think, and communicate to the customer. I promise, your customers will reap the benefits from it and so will you.