+
4 Tactics to evaluating, buying, and implementing Vendor technology packages - Keith Privette Home / Business Analysis / 4 Tactics to evaluating, buying, and implementing Vendor technology packages

4 Tactics to evaluating, buying, and implementing Vendor technology packages

Being a Business Analyst nothing drives me more up a wall when I hear “Oh it is a vendor package, we don’t have any requirements.” My first response to that is Really?  Or depending on the political and relationship of the environment a little attitude will be thrown in with the response of Really?  In this post I will lay out 4 tactics as to why this thought process dooms your project before you even start. Yes it dooms it, sorry no nice way to put this. In my career I have seen many many many vendor technology packages suck companies dry because of not following these 4 tactics.   If I added it all up in the last 10 years, I have seen at least $500 million dollars wasted because the company did not know the technology they already have, what they really wanted or what they really needed.

This goes back to very simple premise; know thy business! Sorry to break the news, but your business is run by good technology and good technology selections.  Using these 4 tactics when evaluating, selecting and implementing a Vendors software package you will save time, money and whole lot of headaches.  The tactics focus more on using a more iterative, collaborative, and co-creation methodological process (Please insert your methodology definition of what that is, most software development lifecycles SDLC’s are basically all the same  with different terms, thought leaders, and definitions.  These tactics still do not change).


1. Understand your requirements from a business scenarios context:

Organize all your business scenarios and collaborative processes and technology that will be touching the Vendor package.  Yes in todays world there is no longer the black and white of process vs technology.  They are and always will be interwoven.  No more of this separation of process from technology!  Sorry “I only worry about the business process without technology” people!  The business scenarios will allow for the project team to put information into containers for easier decomposition, decision making, gap identifiers, and nice to haves highlighting.  Without organizing into containers the project team ends up trying to make decisions on a laundry list of requirements and never can answer the question “Do we have everything we need and want?” Having this layer of information will help people find vendor software packages that support their business scenarios.  Below is an example of how to model those business scenario containers.

Business Scenario Goals and Users

The Business with Circles and Stick Figures

You also will avoid buying software built for the aviation industry and retrofitting to use in financial services (this never works, I have seen this once).  This model will help you organize around decisions based on core vs nice to haves.  It will also show you how many different users there are for a particular implementation. It is simple circles, arrows, and stick figures to depict how big is this “bread box” (this is the term thrown around when trying to figure out scope).  Gather as much information from as many different users, process documents, technical specifications, and industry users as possible. At all costs do try and avoid requirements gathering overload (this is the art that a good Business Analyst brings to the team)!  Estimated time for producing a model like this 2-3 weeks.

Now that you have you have identified your business scenario containers you can beginning filling those containers with requirements based on the process diagrams each business scenario has in regards to business rules, functional or user interface requirements, data requirements, non-functional requirements, and security and information requirements.  Within the world of software development a project team could provide details of your business scenarios with 57 different types of requirements, that all come with their own set of attributes.  All these requirement types make up the ecosystem of requirements management including traceability, impact analysis and conceptual design of the technology.  Here is how the information is linked together to understand your whole picture of requirements:

The Typical Requirement Types

How Requirements Trace

This is typically how requirements trace to each other. The names may slightly differ depending on the methodology you are using, but the model will be somewhat the same across a multitude of methodologies.  These are the details that will fit inside each one of the circles above according to your business scenarios.  Keep in mind,  some of the business scenarios above kick off other business scenarios within the model, that is ok!  This will help establish input and outputs of successful completion of that business scenario. This is why having a team that understands the complexity in very usable containers is key to evaluating, buying and implementing vendor software.  Without this, good luck and may the force be with you……

The Management Work

The Requirements Management Hard Work Model

This model depicts the process a project team goes through to manage all the information within the business scenario containers. Without this for guidance, project teams often find themselves in chaos, analysis paralysis, or worse stuck on what comes next.  All three paths lead to wasting time, money, and resources, not only the Clients, but the Vendor also.

2. Download a free copy make screen shots

This step will be critical in your evalaution process.  Start taking screen shots of evalaution copies of software and bounce your business scenario processes and requirements up against the technology you are researching.  Yes I know, this causes rework.  You have this either way.  I would rather do a whole lot of rework on information, than in production when your audience can now see the garbage on the lawn.  It is not pretty, trust me!  I also said this was not going to be easy and take a couple of hours to do either. Taking the information from tactic 1 will help you bounce your business scenarios up against the vendor’s interpretation of your industry. Start running through your business scenarios in these evaluation copies.

At this point start refining your requirements.  They are not set in stone and never will be.  If you have a multiple disciplines (SME’s, PM, BA, Tech Lead, Architect, Infrastructure Architect, Support personnel) co-creating you ensure continual buy-in and a successful implementation.  You may even discover some requirements for your business using two different vendor packages.  Document this information and use them in tactic 4.  This information can sometimes lead to changes on the vendor side, which will lead to a better partnership of trustworthy sharing and collaboration (This is a behavior that is missing in most vendor client relationships to begin with)

Sometimes you may find a software package has found a better way to do your business scenario.  That is ok!  Your business does not always have to have all the answers to weaving business scenarios and technology solutions together.  Do not get caught up in thinking this is where your competitive advantage lays for your business. It is your people and empowering decision making with the use of the information in and out of the vendor packages is where your competitive advantage lays. I have seen where companies have gained huge competitive advantage by allowing the vendor package to dictate the process and technology of particular business scenario.  The reason is the company gets back to focusing on delivering top notch business services and products to their audiences, this is where you earn your keep with your audience.  Additionally,  it makes getting to market a lot shorter.

The Vendors you buy packages from focus on one set of  processes and technology for a particular industry.  These companies live and breathe making the industry specific business scenarios the most efficient, intuitive, and easy to manage within their software package (for the most part….).  Take salesforce.com for instance.  They focus on making the sales process the most efficient it can possibly be with sound business scenarios and technology to support those business scenarios.  Your business scenario is selling a certain product or service to your audience.  Let the experts in the sales process and technology worry about that while you sell the product, that is how your business makes money.  Your business does not make money by re-engineering your sales process, so partner with the process and technology experts that live and breath certain business scenarios, trust me finding these partnerships will lower costs and increase revenues!  I hope this analogy make sense?  If not drop me a comment and we can discuss further

3. Get your Business Analysts, Testers, Developers, Subject Matter Experts, Infrastructure, and Project Management disciplines collaborating on the information:

This tactic is probably the most difficult to manage or implement depending on the whole culture of your organization, the behaviors of your people towards collaborating and sharing, and do your disciplines have the street and book smarts in regards to discipline collaboration.  A company can state that they are agile or iterative until the cows come home, but  if the people don’t process the information in a culture of collaboration and co-creation it just isn’t true.  Disciplines must have the comfort and trust built up in their relationships to encroach respectfully into each others disciplines.  I show these overlaps in the Business Analyst 3.o post.

The team you pick for performing these tactics must be full time on this effort, any thing less you will not make it a priority and the project will fail.  This tactic also brings everyone to the table for the demonstrations of the Vendor package to satisfy all parties involved and will facilitate making a good technology decision.  These decisions can not be made in the vacuum by strategists or leaders that will not be using this package on a daily basis.  Great, the vendor package has great executive reporting dashboard for executives, but the tactical and operational information going into the package is garbage and slows down your business scenarios. Garbage in Garbage out, this affect is more prevalent in vendor packages, if the decisions to buy and implement is done at a too high level away from executing the actual business scenario.

 

4. Take control of the dog and pony shows based on requirements

This is where your gathering, analyzing, and scope definition will pay huge dividends.  If you allow the Vendor to run these reviews you will be sold to.  This is not the fault of the Vendor!  They are trained and coached to sell the cool features that cost money.  The fault really falls on the Client for not preparing, understanding, and knowing thy business working within a technology platform.  This step is where Clients can take back the control and get what is needed and on occasion what is wanted for their business scenarios.

This collaborative demo really makes for a good working relationship with your potential Vendor.  Let me explain.  The Vendor will not have to waste time helping the Client figure out what they need and can focus more on being a true partner in consulting, recommending, and creating for the Client based on a clear vision.    The Client should not be paying $200.00 per hour to figure out their own business…..this to me does not make good use of the of a scarce resource called money!

An additional suggestion I would make is have two demonstrations of the vendor software package.  The first one would be completely understood as a time for the Vendor to do their sales, dog and pony show, and offer up their road-map for their product(s).  The second demonstration would be completely controlled by the Client with reviewing the product through the lens of their requirements, process flows, and wants and needs of the product features based on their business scenarios.  The mood and behavior of the second demo should be collaborative, co-creative, and sharing of “garbage on each others lawns.” All along the way refining the requirement information.  There may even be a resource on the project team completely dedicated to keeping information up to date.  This is where your triple AAA BA’s learn their craft!

Implementing these 4 hard work tactics (yes sorry to tell you, you will be doing some hard work here, no silver bullet!) will pay dividends for your short term and long term success for your projects to implementing vendor technology packages.  These techniques can work for Software as a Service (SaaS), Off the Shelf Install products, Platform as a Service (PaaS), Infrastructure as a Service (IaaS), and Social Technology Ecosystems (sorry no silver bullet in this area either).  I have seen both sides of this equation and utilizing these techniques has led to buying and implementing the correct technology for true return on investment of time, money and resources.

If you have additional techniques that you have seen be successful on a project please leave a comment.  This old dog loves learning new tricks! One added thought on these 4 tactics is swap out the word “business” for “technical” in front of scenarios and it works the same way just a slightly different type of language used in your requirement statements.  So you technical infrastructure (servers, routers, modems, switches, wireless hardware, pbx’s, ivr’s, mainframes, etc.) folks we have you covered too!

Comments are closed

%d bloggers like this: