A Sandwich is a Sandwich – or is it? “Owning Your Business Requirements”
I am not the easiest person to live with. I think my husband would be the first to tell you. And while I am at home on bed rest in the final stages of pregnancy – I think the high maintenance factor could be a little higher than normal, even for me. But my current state of health has not made me shy about what I ask him to help me with. If he goes to the grocery store on my behalf, he is usually armed with a thorough, defined grocery list. If he goes to Old Navy to pick up some t-shirts for our daughter, he may call me a few times to verify his strategy before purchase. Heck, he does not even go to Subway without clear requirements on what kind of sandwich I want – my mood can change depending on the day and while the Italian sub worked well a few weeks ago, the only thing that will work today is a veggie on whole wheat.
You may be asking, what’s your point Kiran? (Other than the fact that your husband is a very, very patient man). And Kiran, why the inordinate fascination with lunch meat? (see previous post “No Free Lunch …”).
My point is that if I ultimately want a deliverable (in this case my six inch sub) that meets my expectations, I better be able to communicate those expectations clearly. I can have no qualms with my husband if he brings me home something that I am not in the mood for if I don’t tell him what it is in the first place (My husband will tell you I have not always followed this logic in the past, but I am going to ignore those situations for now to make my point).
So it’s interesting to me that I am finding more companies who are shying away from the very basic, fundamental step of defining requirements as they implement expensive and expansive web analytics solutions. Or that I am encountering with greater frequency, very large companies that are willing to compress this very necessary piece of any successful implementation down to a bare minimum in order to “kick start” the good stuff.
I am not sure what the disconnect is and I certainly don’t understand the rush to implement without clear requirements. Is there a growing comfort level with the knowledge that vendors bring to the table that makes companies more willing to hand the reigns over? Is there a belief that these things will “work themselves out” as you implement? (I am not asking rhetorically. If your company or someone you know exhibits any of the symptoms described above — I would like to hear your take on this).
The reality is that bypassing this necessary part of the software development life cycle can lead to very expensive repercussions for an enterprise downstream. Here are just some of the reasons you can’t afford to take this process for granted.
Where is your voice?
The most obvious piece of this is that your company’s vision must be accurately reflected in whatever solution you implement. Software alone does not give you answers – no matter how much you spend on it – if you can’t clearly define the questions you are seeking to answer and the goals you are looking to drive. Oftentimes, while companies may have some sense of the larger, driving goals (increase conversion, maximize ad spend), the individuals who have been given the mandate to implement the solutions are not given proper guidance from the executive level down on the strategic vision. Understanding the executive vision from the top down will help you formulate the tactical business requirements you should be going after.
Sometimes you think you know, but you just don’t until you get it all down and you have signoff from your executives. Most often, a mid-level manager will be tasked with the implementation piece. They will work arduously with the vendor on implementing their perceived vision of the analytics solution, only to find that there is a big disconnect with what they ultimately deliver back to the executive level.
So find your voice – and make sure it’s in harmony with the voices of your executives or you can fall flat. Don’t just rely on the fact that you can communicate and verbalize their needs. Document everything and have confirmation from executive level down.
And remember the famous words of Patrick Swayze in Dirty Dancing — “Nobody puts (insert YOUR name here) in the corner.” Ensure that your voice gets heard and that it continues to resonate with the documentation and communication system you build around it.
The game of telephone is one we are all familiar with. Brandy told Eddie, Eddie told Jane and Jane told Shawn. By the end of it “Michael wants a pair of new jeans” becomes “Michael wants a pair of pants.” No big deal, except if you are the one tasked with buying Michael his present — now he has a pair of khakis he really didn’t need and they sit in the back of his closet. Poor Michael.
The more explicit, the more detail you can provide – the better you are arming everyone to ensure you get what you are looking for. It also makes it that much clearer to identify areas that the solution in question may not work and that alternatives may need to be identified or explored. But without that blueprint, you are more likely to open up the possibility of error in interpretation and delivery. Why take the chance? Like Michael’s khakis that are sitting in the back of a closet, you don’t want the solution you are working so hard to build to become relegated to the back of people’s minds because it never was relevant.
It’s a fluid world. Change is everywhere. No matter how much you think your boss will be at your company forever or no matter how much you want to believe that your key analyst just loves working for you – you can’t count on continuity just through your resources alone.
I was recently on a call with a Fortune 500 company where I was fighting resistance on this exact thing – trying to get commitment to have the business owners actually document requirements. My concern was driven by many factors, but mainly that they were putting themselves in a position of weakness versus a position of power. They brought up the fact that they expected to have the same staff on hand and also the same Omniture consultants to ensure the legacy remained. Contingency and risk planning were obviously not being considered here.
Listen up everybody – don’t ever make this mistake! If it’s the burden of collecting and documenting the requirements – outsource it. We all know where our vulnerability points in our organizations reside due to key resources that we just can’t afford to lose. Turn your vulnerability into an asset and just make sure you document the living daylights out of everything. People leave, people get sick, people have accidents, software changes ownership within an enterprise. Don’t ever put yourself in a position of weakness by taking any of these possibilities for granted.
How do you evaluate your deliverables?
If you haven’t documented clearly what the mandate driving your end deliverables are, how do you assess the success of your implementation? What are you measuring? Is it just that it produces some cool, nifty new dashboards and reports that you never had before? (I really hope you are defining success as more than that).
I was recently on a call with the director of an analytics organization and he was expressing dissatisfaction with some of the tools out there today. He was quick to point out which solutions would not work for him, but could not express WHY very clearly.
If you can’t express that vision or the “why”, you are setting yourself up for disappointment right out of the gate. Perhaps, ultimately, there truly is no solution that will work for this gentleman’s company. I find that hard to believe. What I do believe is that he was responsible for an organization that could not prioritize and itemize all their requirements in a way that would ultimately allow him to determine which software would meet the majority of their needs. Everything seems so overwhelming until you can factually present it on paper. It gives you the opportunity to filter out the “noise” and the meaningless drivel that sometimes deters this process from happening. When I say “noise” — I mean all the requirements on the “nice to haves” that nobody was ever able to present a logical, business driven explanation for having. You will find that once you eliminate that distraction, it becomes much easier to hone in on what’s important.
So yeah – as you may have guessed — I am passionate about this and I really think it’s one of the most avoidable pitfalls to any implementation (analytics or not) that a company proceeds down. It may not be the easiest thing and it may take time to really develop a strategy for how you collect and document everything and ensure all critical stakeholder involvement – but it is the foundation for everything you do to drive your implementation forward.
You know that Allen Iverson clip where he goes off on his coach for being mad about his skipping practice too many time with his Detroit Pistons teammates? “I mean, we’re talking about practice. Practice people!” Well instead of the word “practice”, which was said 20 times throughout that diatribe, replace it with the word “requirements.” Yeah — that’s how strongly I feel about this.
Don’t underestimate the value of the time you invest in this piece of your project. If my husband won’t buy me a sandwich without clear requirements, why would you arm your analytics team and vendor with anything less?