Gap Analysis Expanded – Vision-Schmision Part 3

Motivation:
Gaps are everywhere – just look

Ingredients:

Triggers to Action – External & Internal
Raw Vision (Requirements Stated)
Any Enterprise Architecture not limited to:
       Organization (Business) Goals & Objectives
       Performance Metrics
       Organizational Process Assets
       All Solutions [Constructed, Deployed]
Ten Stakeholder Types
All Information Available on Risks
Business Analysis Resources As Needed

In Vision-Schmision Part 1 we were handed some “Raw Vision” (Requirements [Stated, Barely]), masquerading as some kind of “cost justification” related to going “paperless.”  In BOKworld this looks like:

In Part 2 we took the raw vision to the kitchen and mixed it up with Business Goals and Objectives, resulting in more of a Business “Knead”:

Our “dough” (we ARE shooting for a business case 🙂 ) is still quite raw. At the end of part 2 it looks like the following (bonus points to those who spot gaps in the “knead” not already noted below):

Problem/Opportunity (Business Knead from Part 2 🙂 )

Recent improvements in automated scanning technology suggest it might be economical and effective to further (we do already have email) reduce the use of paper in our organization. Our current goals and objectives are: 

1. Improve student satisfaction from 82% to 90%.
2. Increase fall enrollment from 37,213 in 2012 to 41,500 for 2013.
3. Freeze hiring at 2012 levels (1017 employees).
4. Reduce employee turnover from 10% per year to 5%.
5. Reduce dropouts from 3723 per semester to less than 1500.
6. Improve community relations by expanding English as a second language (how measured?).
7. Cut archival costs by 90%

Known problems and opportunities related to the use of paper include, but are not limited to:

Specific Issues:

1. Bottlenecks / slowdowns in the student admission process due to sharing the paper application file (any process models – use cases, user guides, flowcharts, meeting notes documenting known issues with the process?). Our biggest competitor can give a prospective student an admission decision in less than two weeks, while our average is currently 5 weeks. While we do not know how many students we lose because of this (how many do we lose for reasons that we know?), surveys show that over 30% of our applicants complain about the delays (were surveys limited to applicants in our systems – did we lose prospects who never applied on line?).
2. Lost or misplaced (how many of each kind?) student transcripts delay financial aid, which we believe is the cause of half of our 3723 student dropouts last semester. Financial aid delays can stretch for months instead of weeks, and always contribute to admissions delays.
3. Grades are being computed and delivered on paper (by whom?), for entry into a grade reporting system (by whom?). When questions arise about the grade, there is no detail to explain how the grade was awarded (what details might be needed?). The student must fill out a form to formally request explanation from the faculty member. The student ombudsman receives about 200 grade related complaints every semester. The number of formal forms submitted each year is less than 5. The reasons for the difference are unclear? There are approximately 37K students enrolled).
4. Archival costs (how much, for which services?) seem out of control due to repeated need to access already archived documents. These documents are often related to students who are taking longer than normal (what is normal, and why?) to finish their degrees. We need better (by what measure?) policies and electronic search to reduce this repeated manual searching (how can we quantify this?).

   General Issues:

5. Departmental managers recently estimated (how?) that an average of 10% of employee time (all employees are affected equally?) is used for filing, handling and re-filing various kinds of paperwork. These include, but are not limited to (are there estimates of quantities, time impacts per document?):
   1. Health care
   2. Counseling
   3. Housing
   4. Part-time work
   5. Hiring (and other HR functions)
   6. Regulatory compliance
   7. Legal work
   8. Grading
   9. Ombudsman cases
   10. Veteran’s educational benefits
   11. Fraternity & student organization oversight
   12. Faculty mentoring and counseling
   13. Preparation and follow-up for management meetings
6. It is anticipated that more specifics are to be discovered if a decision is made to further analyze and detail requirements for a business case (we shall so decide 🙂 ).

Now, for Part 3 we consider how to “Assess Capability Gaps”:

Formally, the BABOK says that this task consists of comparing an “AS-IS” (model) to a “TO-BE” model. Informally, we are seeking requirements, especially missing ones (requirements gaps). To have a good “AS-IS” we need to know we are not missing anything. A good “TO-BE” won’t be missing anything large or important. We have gaps to fill even BEFORE we formally identify “capability gaps”. Once we know enough to specify an AS-IS, we can focus on identifying the bottlenecks that are impeding closing the gaps between current indicators/metrics and target state indicators/metrics. Fixing these bottlenecks gives us potential “TO-BEs”.

The “numero uno” cause of “gaposis” is the failure to understand the needs of one of the stakeholder types. Look for gaps by considering ALL ELEVEN stakeholder types and their needs: 

1. Customers – DO NOT fall for the idea that Information Technology must treat the business people as customers. It is always nice to be nice to people, but IT must help the business people treat paying customers as customers. This is not the same thing as making IT happy – not the same thing at all.
2. End Users – If they don’t understand, it means you don’t understand – the more end users, the better. It is possible to have too many to manage, but that is less common. We tend to speak with those end users most friendly to the project. Don’t forget to talk with some hostile “end abusers” – they know stuff too :).
3. Domain SMEs – The box that you are inviting to think outside itself. If there are no changes to what Domain SMEs already know and do, there are no requirements. If you get resistance to exploring necessary changes, offer to report that there are no requirements, while smiling really hard.
4. Implementation SMEs – Once known as the glass box, they are becoming “cloud”ier. They are missing money, mostly, along with any serious involvement from the business side. In this BA’s opinion IT investment is generally ½ to ¼ of what it could be. It seems expensive to develop high quality requirements, especially rapidly. Rapid development means heavy business stakeholder involvement. Do what you can to get money and people for IT (use your business case mojo for IT too). Don’t fall for IT’s occasional “we can’t do that, it is too [hard, expensive, politically impossible, outside of scope]. When such statements are offered, ask them what it would take to overcome, and negotiate. What they build isn’t for them, it is for the business – remind them if you must.
5. Suppliers – If you don’t trust them with your future implementations, why do you buy their stuff at all? Consider involving them early, especially if their performance affects yours (which it does).
6. Testers – One requirement equals One Hundred tests – work with them early and often or they won’t be able to finish on time. If they are bored waiting for your requirements, engage them in developing requirements.
7. Operational Support – It is NOT NEVER NO-HOW “just an install”. Dump purchased software (or new policies) on operations without requirements and you will see what I mean. The minimum requirements gap to fill with operations is in understanding load (performance) requirements. Real changes in technology require MUCH training, planning and impact analysis and other Transition requirements.
8. Regulators – here, there are only gaps in conscience and execution, as requirements are usually spelled out in words and in spirit as well.
9. Business Analysts – are you REALLY advocating for what you need (BAPM on the head with BA Planning), or just saying yes to the project manager?
10. Sponsors – Don’t let them build skyscrapers without blueprints, nor enterprise systems.
11. Project Managers – Scopes based on Visions are Hallucinations – help them understand where refinements to scope will help them make time and money deadlines with USABLE solutions.

Another place to look for gaps is in Enterprise Architecture (AS-IS). When a solution fails, the failure tends to show up as a failure to accomplish the work of the organization. What IS the work of the organization? Can you list at least 150 processes in less than a day? Try it – it pays in reduced “gaposis”. The more you know about your business, the less likely you are to recommend requirements that will “break” things. 

A wonderful recent example of forgetting business work process in favor of systems was NetFlix, who imagined how much better their systems could be if they divided “on line” subscriber services from “DVD” snail mail subscriber services. The forgot that the process for their users was (AS-IS):

1. Sign up for an account (once)
2. Search for movies you want to see.
3. Put the movies you want in a queue (DVD or online).
4. Watch the movie when it shows up in the queue (mail or instant view).

They imagined the users wouldn’t mind the following changes, which would make their business systems much simpler (TO-BE):

1. Sign up for an account (twice)
2. Choose which list to search for movies – online vs. DVD
3. Search for movies you want to see
4. Put the movie in its queue (online vs. DVD)
5. Choose which queue you want for selecting the movie you want (if you remember)
6. Watch the movie (if you find it)

Hmmm – better for users, or better for coders? 

Another quick and dirty “gap analysis” is to use BABOK requirements types. As a BA, start with the business requirements, which are almost always missing . “No way”, you say. “Way”, I reply, since good business requirements must have good indicators (the thing we will measure) and metrics (the quantity measured), and these indicators and metrics can be quite rare. “Increasing sales” is NOT a business requirement, nor is “increasing sales 10%.” If you disagree, it means that cutting prices 50% could be a solution, as this would surely increase sales at least 10%. Business requirements – often missing – look out!

As for stakeholder “requirements” (Requirements [Stated, Confirmed], according to the BOK), their “gaps” (wishes, misconceptions, ignored innovation opportunities) are found in analysis towards Solution and Transition requirements, after the AS-IS, TO-BE and the full business case are better understood.

Last but not least, remember that risks are a HUGE source of “gaps” in requirements. 

Example 1: Risk of users rejecting new application – 50%. Mitigation – make the application REALLY work for the users, not just for management. This is where the “business requirement” for ease fo use comes from, easy and fun, fewer steps, better interface.

Example 2: Risk of misuse of application data – 90%. Mitigation – make sure that the data requirements are modeled to reflect the true domain (customers have many addresses, addresses serve multiple purposes, addresses serve more than one customer). If we make one address per customer, and one customer per address, we only make life difficult for the users, who must work in the “real world”.

There is much, much more (ask for “pain points”, perform “external analysis” of competitor’s capabilities and changing trends, look for regulations and other solution documentation, understand the history of the “AS-IS” so you don’t regress it and break other requirements. Example: Original Requirement: Quality, validated data for 99.9% accurate reporting. New “request” (requirement [stated]) – users want to load spreadsheets in bulk, skipping validation. You would think the new request would be ignored (“my job is too hard, let me do a worse job”), but this requirement was actually implemented by a client, defeating the data validation.

Again – stir these new ingredients well, rewrite “them requirements as what needs rewriting”, and don’t forget to leave your comments. 

Next month: The Schmision takes on “AS-IS” and “TO-BE” as we look at the BOK formal “Assessment of Capability Gaps”. We will notice that in our organizations, “Solution Approach” and “Solution Scope” tend to precede capailbity gap analysis, as we seek to escape the hard work of evaluating the original “vision” for what it (most often) is – a rush to solution. 

P.S. Look up “vision” requirements in BABOK, and you will find they are mentioned explicitly as not likely to be “ongoing” requirements. Betcha! What do you think?

Don’t forget to leave your comments below.