Enterprise Software Specialist

Relationships matter more than features: Having poured over thousands of RFP questions from hundreds of customers, it’s clear a majority of businesses get software procurement wrong from the beginning. RFPs benefit consultancy organizations not the businesses who commission them. When you build an RFP with hundreds of questions about x, y, and z features, you prompt your vendor to provide formulaic answers to check the box rather than fostering a process to learn what the vendor actually has to offer.

Consultancy organizations love this approach! They squander countless hours consolidating requirements across an immensely complicated organization when in reality, your needs aren’t vastly different from other businesses like you. (You’re special, just like everyone else!) Once the consultant combines this information into an exhaustive RFP, they charge you to manage the process of gathering needlessly exhaustive and complex data from a vast assortment of vendors. Finally they tabulate the results into a Powerpoint presentation with a seemingly authoritative breakdown of graphs illustrating the percentage of percieved requirements which each vendor meets.

Your executive audience feels reassured because they’re making a decision of the best solution based on solid data. Your business users feel like their concerns have been heard through a transparent process. However, you have now chosen a solution based on a hodge-podge of features and the vendor’s ability to learn to the test not based on demonstration of a coherent solution which can solve your business problems. It needs to be the right people and the right product.

Alternatively, the most successful businesses approach the procurement process challenging vendors to engage in shared thought leadership. To be successful in this process you must start with internal reflection, partnering with your business to answer some important foundational questions:

• What are our business goals and how do we approach problems?
• Who are our customers and how do we provide them a product that’s better than our competition?
• What are the important challenges we’re looking to solve through the implementation of this solution?
• How will we know this solution is a success? What are the Key Performance Indicators (KPIs) we’ll use to measure the success of our solution?

Transparently provide this information to your vendors. “We’ve told you a bit about us, now tell us the same about you!”

• How would you partner with us to solve these problems?
• How are your customers who are similar to us solving these problems with your product today?
• What is unique about your product and business that your compeition cannot match?
• What are the challenges in your industry and how are you working to overcome them?
• Demonstrate how your customers have grown with your poduct in the last 2 years.
• Show us (trial, demo, documentation) how your product will fit into our business.

Adopting this approach will glean an immediate difference in your procurement process. Your vendors will understand the needs of your business. Weaker vendors will be exposed as these are not questions which can be answered without critical thought and diligence to the process. From using this approach, you’ll quickly develop insight into the best fit for your business and will have an excellent foundation of a vendor partnership which will provide you with an efficient, effective solution. The outcome is a stronger qualitative recommendation to your Executive Sponsors and Business Stakeholders.

Crawl before you walk: The largest mistake organizations make in deploying new software solutions is trying to tackle too much in a single phase of deployment. Enterprise software investments are huge. When businesses get bogged down in requirements it delays return on investment. Further, the amont of rework explodes due to poorly suited solutions to the products they’re built upon and the inability of a business to accurately describe their own needs. It’s incredibly important to aim small for an initial software deployment and if it cannot be completed in 6 weeks, you’ve missed the mark! This methodology of rapid deployment ensures the business starts to recoup on the initial investment and that iterative functionality is built on a foundation of understanding the basic software capabilities.

By now, it’s probably evident I’m a fan of Agile deployment methodologies. While I strongly believe that agile is the most efficient and successful way to deploy software, I also am extremely wary of organizations which are Agile in Name Only. It’s incredibly difficult to deploy software to business users through an Agile Methodology. There’s a perception that end users need to know exactly what is going to come to them in the next 2 years broken down into quarterly increments. It’s incredibly difficult to pair this precision with Agile Deployment methodologies. Businesses who engage in this Agilefall deployment end up paying twice: Scope expands because it’s agile and anything can go into scope. Timliness is lost because requirements are identified too late and priorities are continually shifting. Cost goes out the window as a result of the inefficiencies of the exercise.

A strong product team can counter this. Examine the software where you invest your time and money. Can you honestly say you know what new features Slack, Instagram, Amazon, Snapchat or Netflix will be releasing in the next quarter? On the contrary, you’re likely an advocate of those solutions because of your experience today and through proven performance. They’re efficient in the ways which you measure your happiness with the given solution. Your business users can view your enterprise software in the same light.

To be successful in Agile Deployments, your business must already have bought-in to the partnership between deployment team and customer and between the deployment team and vendor. Successful teams will have a strong, influential Product Owner. The person in this role must be diligent in collecting information via Voice of the Customer (VOC) from business users by rolling up his/her sleeves and investigating the use cases and processes users perform in their day to day work. The Product Owner must then weigh the opportunity cost of deploying any proposed solution with information from your software vendor. These are weighed against the KPIs which the vendor and deployment team have agreed-to with the business. All development is measured against the effictiveness of those KPIs.