• Data Crunching

      You’ve got data. We can turn it into information.

      You’ve got data.  Lots of it.  Some call it a “Data Deluge”.  It’s just a bunch of transaction values, names, addresses, or commodity codes.  It’s not worth much, until it’s turned into information.  That’s where we come in.  Reasons for downtime, popular combinations of product, and demographic trends.  There’s a story in your data, let

      read more

  • Requirement Gathering

      Business Analysis starts with asking the right questions of the right people.

      Does your software seem to create more work for your employees?  Does it require a myriad of work-arounds to get simple tasks done?  Sounds like proper requirement gathering wasn’t done before system implementation.  Our requirement gathering process starts with your end-users, not your out-of-date SOP manual (and yes, it’s out of date).

      read more

  • Project Management

      Is your organization distracted with putting out fires?

      Day-to-day operations have your team stretched to capacity.  Do you put off forward-thinking projects to fight fires?  Let us help you take on transformative projects that your team is too busy to engage in.  Your organization’s future shouldn’t be shortchanged because of the here and now.

      read more

  • Government

      In modern campaigning, technology is what separates winners from also-rans.

      The political campaign is evolving at a staggering pace.   Micro-Polling, Virtual Call Banks, Voter Targeting, and Robo-Calling are a few of the technologies that separate successful campaigns from also-rans .   Once cost prohibitive, these techniques were the domain of well-funded Federal races – not anymore.  These technologies can be put to work in the smallest

      read more

Sharma Analytics Blog

New Workshop: “How to talk to software developers”

May 15, 2013

For the past few years we’ve offered a workshop to our clients we call “How to talk to your software developers”.   It’s a half-day session for executives and managers who want to be more confident when they interface with software developers.  The lessons learned are useful whether the software developers are in-house or vendors.

We’re making this workshop a stand-alone service for groups that are interested in this sort of training for their organization.   If you are interested in learning more, please contact us via our contact form.

“It’s what I asked for but not what I wanted!” – User

March 28, 2012

For all of our talk about requirement gathering we realize that it’s awful easy to get lost in the weeds.  We’ve seen large IT projects  that run for years and by the time UAT (user acceptance testing) comes around you hear the customer say “It’s what I asked for but not what I wanted!”.

Requirements are not set in stone.  The requirement process (especially on large projects) should be ongoing.  The needs of today, are not necessarily the needs of next week or next month (surely not next year).   The the business needs can change, so should requirements.

Tagged , ,

What are your users doing with your software?

November 16, 2011

Sounds silly, but do you really know what users are doing with your software?  Business process evolves over time, yet software tends to get released every other year (at best).   Software might mirror your business process when it’s released,  but over time (quicker than you think) the software and business process become unaligned.   Your users end up spending more time making their process work for the software, than making the software work for the process.  We can help you answer the question “What are your users doing with your software” to help you bring IT and business process in alignment.

Tagged , , , ,

Requests vs. Requirements

May 17, 2011

The other day a client was describing a project that is currently in “recovery mode”.    While describing what caused the project to spiral out of control the words “too many requirements” came up a few times.  Now, considering we’re in the requirement gathering business, you would think we’d say “there can never be too many requirements”.  This is not the case, it’s easy to smother a project with too many requirements early on.  Often, requests are confused with requirements.  Everyone has requests, from changing the size of a font to adjusting a formula in the database, the key is identifying which ones are requirements.

Tagged , , , ,

Don’t get lost in the weeds, focus on the ‘What’ not the ‘How’

April 9, 2011

The Requirement Gathering process can get a team lost in the weeds quickly.   When the Requirement Gathering process starts out, it pays to worry about the ‘What’ and not the ‘How’.  In other words, worry about ‘What’ the software should do for the Business not ‘How’ IT will implement it. The business customer doesn’t know the difference between WebSphere or IIS.  PHP or Ruby, MySQL or Oracle.  For IT and Business to be properly aligned, it pays to make sure that the ‘What’ is captured properly.

Tagged ,

Business Analyst – 21st Century Interpreter

March 24, 2011

The Requirement Gathering process is a strange beast.  The best practitioners are Business Analysts who are comfortable speaking to technical people (Network Engineers, Developers, DBAs) as well as  the non-technical (Management, Consumers, Operations).   These two groups see the end product through different glasses and they speak different languages.  It’s the Business Analyst’s job to make sure the two groups are able to communicate through good Requirement Gathering.  In the 21st Century you could say the role of a Business Analyst it to be an Interpreter.

Tagged , , ,

What do you base your decisions on? Data or Assumptions?

March 19, 2011

This week we did some polling in Metro Detroit for a customer that was having an internal debate about political strategy.   Neither camp was ready to concede their point so the decision kept on getting postponed for weeks.    Why they took so long to come to us, I don’t know.   However, I do know that within a business day we were able to provide our customer with polling data to assist their decision making.   What do you base your decisions on – Data or Assumptions?

Tagged , , , ,

An easy trick to manage the dreaded “Scope Creep”

March 9, 2011

Scope Creep or Feature Creep, regardless of the name, is the number two project killer (I’ll save number one for another post).  It’s tough to complete a project when you don’t know what “complete” is.  Think of a project like a target with a bulls-eye (must have requirements), first ring (should have requirements), and second ring (nice to have requirements).

The bulls-eye is non-negotiable, fulfillment of all these requirements will make this project a success.  After that, you shouldn’t be moving to the next ring, unless completion of the current ring seems likely.  This is especially helpful with iterative development that has short cycles.

Tagged , ,

Why the Subject Matter Expert’s point of view needs to be assessed.

February 25, 2011

Beware of the Subject Matter Expert (SME)!  Often we get an SME assigned to a project based on availability.  In other words, we get the least busy member of the team, which doesn’t say much for their body of knowledge.  Even when we work with a super-user there is another issue to be concerned with.  Their perspective is their own.  Maybe they are administrators or maybe they have elevated permissions.  Either way, they are often unaware of the permissions the general user population has.  An SME that isn’t 100% aware of how the general user population uses a system can lead to some dangerous conclusions!

Tagged ,

Gathering requirements does not mean copying the old manual!

February 23, 2011

Q.  What is the first thing that happens when we start a requirement gathering project?

A.  We are given a manual that is woefully out of date!

Happens every time, and to be honest we do like to start with training materials, SOP (standard operating procedure) guides, and user manuals.  But requirement gathering is not simply copying these materials into a requirement document.  Often, these sources are woefully out of date (the last update was when the current system was launched x years ago).  Even worse, sometimes they were never followed by the folks doing the actual work!

Tagged ,