Skip to main content

Author: Marcos Ferrer

AS-IS or Which TO-BE – What IS the Vision? – Vision-Schmision Part 4

ferrer Feature article june11Motivation:

AS IS or WHICH TO BE – Multi-Vision Clarifies!

Ingredients:

Business Need (rising in spite of constraints)
Any Enterprise Architecture not limited to:
Organization (Business) Goals & Objectives
Performance Metrics
Organizational Process Assets
All Solutions [Constructed, Deployed]
Ten Stakeholder Types (and all their ideas)
All Information Available on Risks
Business Analysis Resources As Needed

We have imagined a vision, created a business “knead” and filled some gaps in the recipe, but are still waiting for “dough” to rise (to review earlier iterations of the Schmision, click on the numbers to the right for Parts 1, 2 and/or 3). We are ready to consider where we are and where we would like to go. Let us consider what is the AS-IS for our “document management” vision quest, and what the TO-BE could be. Don’t put away your red pencils yet, learning never ends, and new “requirements related” information is never complete!

Take the repeatedly kneaded Business Need(s) out of the fridge (it is good for flavor and clarity to let these things cool overnight, jell in your mind, re-stir and then feed back to stakeholders). Work the need(s) and the stakeholders for yet more ingredients to help fill gaps then jell the AS-IS and clarify possible TO-BEs. As the business “knead” continues to rise, new gaps form, to be filled anew by available BA resources. Any gaps not filled by BA “kneadiness” now (curiosity is cheap, and less annoying than failed projects) will be filled with expensive and extensive re-work later (not so cheap, but good steady work for those who can stand it).

Here is what we have so far:

Problem/Opportunity (Business Knead is iterated yet again – progress, not perfection! 🙂 :

Recent improvements in ease of use and cost for automated scanning technology could make it possible to reduce the issues and costs from the use of paper in our organization. It seems that the improvements can increase our effectiveness for enrollment growth, rapid deployment of new programs and increased student satisfaction. Our current goals and objectives are as follows:

  1. Improve student satisfaction from 82% (2012 results) to 90% by the 2013 annual “Student Satisfaction” survey to be given 12/1/2013.
  2. Increase 2013 undergraduate enrollment from 37,213 in Fall 2012 to 41,500 for Fall 2013. (Are there plans to increase the number of applicants? From what to what? How many applications are received, how many accepted by us, how many then accept our offer to attend?)
  3. Reduce dropouts from 3723 per semester to 1500 or fewer. This should result in enrollment levels of at least 38,500 at end of Spring 2014.
  4. Increase summer school enrollment 10% from 9833 in 2012 to 10,816+.
  5. Increase Fall graduate enrollment from 12,360 in Fall 2012 to 13,500, to be split between academic departments as follows:
    1. Law – 200+
    2. Business – 430+
    3. Media / Arts – 120+
    4. Public Safety (new department) – 320 plus
    5. PhD Programs – 70 plus
  6. Freeze hiring at 2012 levels (1017 employees). (Which Dean will run Public Safety?) While adding 20 contract faculty for new teaching workload and 20 more to offset expected attrition (how do contract employees impact paper workloads?).
  7. Reduce employee turnover from 10% per year to 5%.
  8. Improve community relations by expanding English as a second language, to be measured by the annual community feedback session plus a (new) formal survey of the community and trends in feelings and attitudes.
  9. Cut annual document archival costs by 90% for FY 2014.

===========================================

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

Specific Issues:

  1. Bottlenecks / slowdowns in the student admission process due to sharing the paper application file (see Admit Student process in Appendix A). 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 delay, surveys show that over 30% of our applicants complain about the delays. Reasons given by applicants for not completing attending included missing financial aid, acceptance by other colleges, family or health issues, inability to provide a complete (Were surveys limited to applicants in our systems – did we lose prospects who never applied on line, because they knew they were too late?).
  2. Lost or misplaced (how many of each kind?) student transcripts delay financial aid. There are other reasons that delay financial aid (missing information from students), 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 decision delays.
  3. To hire faculty requires that anywhere from 10-20+ persons and 3+ academic departments (undergraduate, graduate and professional, and any “related” graduate programs) examine the prospect’s academic transcripts. Confidentiality & privacy considerations discourage or forbid photocopying or e-mailing the transcripts. It can take from 2 to 12 weeks for the official paper transcript to pass from hand to hand, group to group.
  4. Grades are being computed and delivered by faculty on paper, for entry into a grade reporting system by each department (Dean’s Office). When questions arise about the grade, there is no detail to explain how the grade was awarded. Faculty explains that the criteria for grading are explained and/or handed out? at the beginning of each class, student complaints to the ombudsman notwithstanding. 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).
  5. 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:

  6. Departmental managers recently estimated from their own observations that employees spend anywhere from 10% (executives) to 50% of their time finding, moving and re-filing paper documents in support of their more expert administrative and academic work. 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. Recruiting, hiring, firing, benefits administration (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
  7. 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.

=================================

OK, now what?

Many gaps in requirements remain, of course, (I can’t put 2000 hours into one blog, I have only 3 months to deliver Affordable Care Act requirements, like the rest of you). I offer BA Times Kudos to any readers who name specific killer gaps in this “toy case study”. To keep the blog going, we pretend we have enough requirements by extrapolating what we do have, just like in a real project.

For Part 4 we consider what our AS-IS and TO-BE might be. As we saw last month, the formal task “Assess Capability Gaps” has certain formal inputs – “Business Need, Enterprise Architecture (AS-IS) and Solution Performance Assessment (more AS-IS)”. It produces a single output – “Required Capabilities (TO-BE). Some of the required capabilities may already be in place (part of the AS-IS), and the project need only implement the capabilities that represent changes (new requirements).

Here is a weak try at Analysis:

AS-IS: Everything (xxx doc pages) is on paper @ $0.50 per page

TO-BE: Everything (xxx doc pages) will be electronic @ $0.11 per page

This is the analysis implied by the original “uncooked” vision in part I of Vision-Schmision. Even if the implied savings of $0.39 per page is realistic, it offers ZERO guidance to WHERE the savings and costs will change. The requirement emerging from this is the typical COTS RFP “failure mode” requirement:

Electronic document scanning shall be implemented in every department. This shall be accomplished by purchasing XXX scanners, YYY servers, ZZZ software.

ZZZ software shall allow scanning of any paper documents up to 14 x 11.
ZZZ software shall allow grouping/indexing/classifying of documents once scanned.
ZZZ software shall allow searching and finding of documents when needed.
ZZZ software shall reduce the time it takes to handle a document by 90%.
Blah, blah, blah, if wishes were horses, we should all ride!

This is failure mode because it presumes that buying the stuff will lead to behavior changes among employees and students, presumably because it is so expensive? There is NO clue about what would change to realize the savings. One might try to account for this with a LOT of assumptions, but these kinds of assumptions are embarrassing to document (we assume that the departments will index and classify their documents WELL – whatever well means).

Here is a stronger form of Analysis (free BABOK study materials to anyone who offers something in between the two):

AS-IS: Admit Student – “Happy” Path:

We assume:

The student is qualified by our acceptance criteria (To be Determined) (there are no obstacles to accepting the student).

INSERT TABLE

Step # Step Description Costs, Effort, Time, Intangibles???
01 Applicant (potential student) fills out an accurate and complete application package Everyone’s time/inconvenience to:

  • Research the information (1 day to never???)
  • Answer applicant calls/inquiries (1 to 10 calls / letters per applicant, taking 1 minute to 120 minutes of effort over 1 to 30 days of elapsed time???)
  • Fill / Re-fill paper form (4)
02  Applicant mails application package to Admissions
  •  Elapsed time lost between finishing the form and mailing it (1 minute to never???).
  • Applicant’s time/inconvenience to get form into mail (5 to 500+ minutes???)
  • Postage/Overnight ($0.44 to $19.95???)
03  Post Office provides delivery service to Campus Mail Processing twice per day Elapsed time lost (1 to 7 days???)
04  Campus Mail Processing sorts application packages into Admissions delivery box Elapsed time lost (5 mins to 1/2 day???).
Applications are (level of effort):

  • About 1/4th of all mail handling from June to August
  • About 1/20th of all mail volume from September to May.

(Do TOTAL mail volumes vary seasonally??? What are the volumes??? What are the cost and/or level of effort to handle ALL mail???)

05   Admissions sends a Mail Pickup Person to Campus Mail Processing twice per day to:

  • Pick up Admissions mail and bring to Admissions department.
  • Deliver Evaluated Applications for copying and distribution to multiple departments
Elapsed time lost (10 mins to 1/2 day???)
Level of effort (20 mins to 40 mins???)
06  Admissions time stamps all received mail. Level of effort (1 hour to 10 hours each day???)
07  Admissions Clerk distributes mail to Application Evaluators. Elapsed time lost (10 mins to 1/2 day???)
Level of effort (1/4 day to 1/2 day???)
08  Application Evaluator time stamps all received application packages before working on any particular package. Elapsed time lost (10 mins to 10 hrs???)
Level of effort (10 mins to 3 hrs???)
09  Application Evaluator selects the application package with the oldest time stamp. Time creating and maintaining an accurate paper queue is estimated at approximately 5-10% of Application Evaluator’s time.
10  Application Evaluator determines that the application package is complete. Elapsed time lost (10 mins to 1 hr???)
Level of effort (10 to 15 mins???)
11  Application Evaluator determines that the application package is accurate. Elapsed time lost (1 hr to 10 hrs???)
Level of effort (10 mins to 3 hrs???)
12  Application Evaluator passes the application package to Campus Mail Service inbox for twice daily delivery. Time and effort guesstimated above.
13  Campus Mail Service copies application package for distribution to multiple departments:

  • Academic Advisor’s Office (Verify Academic Qualifications)
  • Financial Aid Office (Coordinate Financial Aid)
  • Veteran’s Aid Office (Coordinate Veteran Aid)
  • Prospect Marketing Office (Coordinate Prospective Student Events)
  • Admissions Office (Communicate Acceptance to Prospect)
  • Housing, Cafeteria, Infrastructure (Prepare for Student Arrival)
  • Student Orientation Office (Prepare for Student Onboarding)
Elapsed time (1 hr to 6 weeks, more in extreme cases at Veterans???)
14  Repeat something like steps 4 through 12 above for every department involved, and then once again when the approved application is submitted to the Admissions Acceptance Committee. Assume that levels of effort vary by department, and provide reasonable ranges???
 Other Issues:
 Total application packages lost or misplaced from paper handling.  (33 to 100 per year)
 Application package “re-work” from inadequate completeness & accuracy checks, or paper lost, misplaced or damaged after such checks.  (500 to 1000 per year)
 Lost prospects that were lost due to clumsy Administrative processes.  Estimated by Academics as 15-25%??? of the lost (not all) prospects.
 Prospects lost due to slow Academic processes.  Estimated by Administrators as 15-25%??? of the lost (not all) prospects.
 Prospects lost to competition.  Estimated by surveys as 30% to 45%??? of the lost (not all) prospects. ???Where are the rest???
 Valuable employees lost to permanent work process / environment frustration.  Hard to say exact impact on turnover, but frustrating and tedious processes might have some impact.
 ETC.

I trust that my readers have no trouble imagining some TO-BE solutions. Jumping to solutions let’s us stake a claim to the idea. That is why it is so important to provide choices instead of over specified solutions, especially if we are doing the business case as a “PMO Project” to help choose projects.

Being certified (or certifiable, as many of my readers are) we choose with the biggest, highest level kinds of choices. We start with Define Solution Approach(es), instead of jumping straight to Define Solution Scop(es).

One approach would be to replace many of the steps in the Admissions process with a fully integrated system, providing needed information and workflow to every department. This workflow could happen in real time, organized into prioritized queues. It could free employees to make better decisions and provide better service. Electronic data can be “validated” at time of capture (not BA validation, data validation, arghhh-on the jargon :). Workflow organization can make needed information and easy to find (already found!) at the moment it is needed. This is one of my favorite solution approaches AND it has a bad reputation from multi-year, failed projects.

We shall address this bad reputation in the next blog, when we show an actual (partial) business case, and how it can be used in support of project success for… Hint: Stakeholders talk business and the work that affects them. They speak technology, and make technology decisions, because YOU ARE ASKING THEM TO. Don’t ask questions that you don’t want them to answer. BE CURIOUS ABOUT THEM, not the technology that might result.

Here are some other solution approaches:

  • Scan all application packages and convert them into images easily emailed by workers to each other based on their existing process, bypassing Mail Processing.
  • Store the images in such a way that they are easily found by workers based on applicant “scan time stamp”, name, address and birthday. ???Application Status might be considered, BUT it will imply a more complete workflow system without necessarily delivering it – it will depend on worker searches and expert prioritization, without assisting many workers to prioritize expertly.
  • Grab some of the data from the images and do some automatic “validation” of the various data field values for accuracy and completeness.
  • Add automatic “validation” of cross-field relationships.
  • Invite applicants to submit scanned images electronically.
  • Grab ALL of the data from the images, and add more accuracy and completeness checks.
  • Add automated assistance in determining academic suitability (social network data collection, automated background checks, online tools for student’s references to use, online data about school student last attended, secure online sharing of transcripts, etc., etc., etc.
  • Re-organize the mail delivery and admissions distribution function in such a way that Application Evaluators are relieved of any “sorting, organizing, paper handling or time stamping. They simply work on the next application in priority sequence until they are finished or are stopped. (???how would this be decided by hand??? We may need to know if we are to ever have a chance at automating “priority”).
  • Here is a group of approaches that don’t demand automation, and a caveat:
    • Instead of having departments send persons twice a day to get their mail, have the mail department deliver application packages with extreme urgency immediately after each twice day delivery.
    • Once application packages are verified as complete and accurate (to be defined???), have admissions immediately copy and distribute packages to other departments at least once an hour, instead of transferring to Mail Processing twice a day. ANALYST’S Note: Many requirements remain to be refined and defined. This document is still just a business case, and much is being imagined (creativity) in order to understand possibilities and narrow solution choices).
    • Instead of waiting for the post office, send Campus Mail to the post office at least 4 times a day (as many as 6?).
    • ???Don’t forget to add staff to process the faster flow, since they may or may not have automated assistance. Analyst estimate

And, with praise to all the remaining readers who see how many gaps still remain, I invite you to contribute your ideas to fill gaps. Especially any show stopper gaps. And additional solution approaches. And feedback as needed, as these remain the ravings of a Business Analyst, until analyzed and validated with all 🙂

Don’t forget to leave your comments below.

Frayed Agile Pools – The Ultimate Methodology At Last

Ferrer May21 ArticleVision-Schmision is Taking a Break

To bring you this breaking news!

V-S vill be bock!

A new paradigm has emerged, and just as some (the fools!), were starting to think that Agile might be a fad after all, fading just like April showers of the recent past. As team after team has struggled with the productivity gain potential (stress!) of more teamwork and less messing around, many have found Agile wanting.

Scrum is often used as a scapegoat, as in statements such as: “They used Scrum rituals but did not practice agile” and “They are Pond Scrum.” Scrum is a simple set of rules and calculations that anyone could follow, and they do. Scrum is easy.

Concerned Agilists* protest that true implementation of Agile is hard, and that Scrum is not Agile. Some say that agile teams that fail must not have practiced Agile at all, since Agile cannot fail by definition. Enlightened management sees this as a critical error. As Edward Deming said: ***

When you think of all the underuse, abuse, and misuse of the people of this country (US), this may be the world’s most underdeveloped nation.”

It seems that blaming people**** is not the way to “fix” Agile. If, as Deming claimed, it is the “system” in which we work that accounts for most behavior. If Agile is our “system”,  Then Agile itself must be at fault! *****

The good news is that the Agile Control Group******* has done a root cause analysis, and has just done a press release******** announcing the solution to any Agile “blues”. They have figured out that it is possible to create multiple Agile teams capable of handling ANY project in ANY timeframe, however short.

For example, one of the Agile principles is:

“Agile processes promote sustainable development. 
The sponsors, developers, and users should be able 
to maintain a constant pace indefinitely.”

Root cause analysis shows that employees are underperforming against management’s expectations almost everywhere these days. Many employees will , and will pad their task estimates so they can web surf and tweet on employer time. The “constant pace” principle is SO tempting that employees will set a pace lower than a boss has a right to expect, especially if the employees are experts (IT) and the boss is not (Product Owner). Frayed Agile Pools can address this issue in the following ways:

By splitting a large project into smaller (fractal) pieces (fraying). This allows a boss to make ANY deadline with no whining. Let’s say that your worst Agile team can produce 100 lines of code a day. If success is achieved by producing 1000 lines of code a day Then the boss can succeed by creating 9 more Agile teams (the “pools”) and merging their code every day. This has the advantage of increasing the number of “product owners”, each with the correct expertise to support each team in the pool.

This “fraying” fractal process eliminates all excuses, is “free” in the sense that the cost per line of code need not rise (bring in or outsource contractors), and cannot fail to produce more code. If productivity suddenly drops below 1000 lines per day, the boss will KNOW whom to motivate. Knowing whom to motivate is a management “key success factor”.

Because of the brilliance of self-commitment, the coders must achieve their own “estimates”; else they will look weak to the team. In this kind of “self-organizing” productivity environment, management can slowly increase pressure, by insisting on increased code production as Agile succeeds where the team could not succeed before. If the team protests, remind them that Agile says:

“At regular intervals, the team reflects on how 
to become more effective, then tunes and adjusts 
its behavior accordingly.”

This may “fray” some nerves, but you can tell the teams that it is more fun to be busy, and that stress is what coffee and donuts are for. Forgetting donuts is one mistake where it is OK to blame management.

Another Agile principle is:

“Business people and developers must work together daily throughout the project.”

Root cause analysis for this principle is, of course, trivial. No businessperson has time to work on projects, and most are too old or overweight to sprint. They are too busy fixing what is failing, even though what is failing is also the driver for the project you are asking them about. They are too busy sawing to sharpen their saws. They have meetings to plan how to plan other meetings. They installed Quicken on their home PC, and can’t understand why you can’t get SAP (or Oracle, or PeopleSoft) up and running without infuriating other business people. They can’t take their fingers out of the dam just to talk with a hydrological engineer – the dam could collapse, and besides, fixing the dam is not the business’ problem. 

Frayed Agile Pools offer some ways to fix this “broken Agile” problem.

Reassure the business people by letting them know that the dam WILL collapse, but not to worry as there are MANY pools of developers to absorb the flow, and no businessperson will need to be washed away.

Reassure the developers by pointing out that every pool will have access to whatever time is available from business people, so that all pools are on a level playing field. By spreading stakeholder time across multiple pools the business’ knowledge goes further.

Encourage the multiple product owners to ask for more complicated solutions, since they have so little time to spend with the developers. Since we are able to produce as much code as needed without increasing the cost per line of code, this will maximize our delivery of working software.

One could go on an analyze root cause issues with other Agile principles, but we end by mentioning one principle that is honored by every Agile team I have witnessed: 

“Simplicity–the art of maximizing the amount of work not done–is essential.”

The simplest teams are always the best – with practice, and judicious application of inhibitors; a top-notch simple Agile team might not ever break anything, ever again 🙂

For other BA Times articles on Agile and how it affects project outcomes, try these links:

Pursuit of this breakthrough might even lead to the holy grail of project management, the plan they shoot for (aim, ready 🙂 many times:

Requirements For Nothing and Tests For Free.

Have fun, and don’t forget to peer review with your comments!

* What else takes a 3 day class to get certified for a $115K** job?
** Prices set by the state of Virginia unemployment job service 🙂

*** Deming finishes with: “It’s about time for American management to wake up.”
**** Management are not people, Deming believed most were short sighted.
***** Logically, IF the first part is false  THEN the whole statement is true. ******

****** This is different from the truth of the second statement – fun lookup! 🙂

******* They are coming to get you, woooooo…. 🙂

******** If the press release still exists 🙂 Then you will find it here.

Gap Analysis Expanded – Vision-Schmision Part 3

ferrer April30 IMG01Motivation:
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:

ferrer April30 IMG02In 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”:ferrer April30 IMG03

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”:ferrer April30 IMG04

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.

Cooking The Business Case – Vision-Schmision Part 2

Ferrer March26 Img01Last month we saw a “cost justification” posing as a business case. It showed money but, but it did not show WHERE to find the money. Nor did it show how the “paperless” tactic aligns with the goals and objectives of the organization. It did not show any requirements at all. The implied requirement (“Replace all paper with scanned documents?”) is a very, very, very low-quality requirement, and nothing like a vision at all.

A vision paints a picture clear enough to reach for. “Scan all paper” is not even close. What about junk mail? Can we ditch the office printers? What indexing, if any, & who decides how? What about email “documents”? Restrooms?

This month we will combine the ingredients listed above (slightly changed from last month’s list – hooray for iteration and a shout-out to Peter Gordon, CBAP for peer review!). We will use a proven recipe to “COOK” the business case, instead of throwing the kitchen at a sinking project later.  🙂

Every Business Case must start with preparation of a well-formed Business Need. Start by sifting through the Business (Organizational) Goals and making sure they are refined into edible objectives (Specific, Measurable, Attainable, Relevant, Time-bounded – BABOK® section 5.1.4.1). Mix in any new objectives that are missing (gap analysis one) to balance the vision and let rest for 24 hours. Allow conflicting or ambiguous objectives to rise to the top. 

Use any available whisks (risks) to beat the Sponsor (Stakeholder type 1) into the mixture until the raw mixture is clarified. Chef’s note: When this process fails, it is typically because of sloppy (or no) Measurement leading to irRelevant objectives. It may be better to throw such a batch out right away and start again, while is cheap and easy. Without measurement everyone is unsure of the recipe even though they know the time left to bake. Even if personal taste approves of the final dish, no one will be able to say exactly why. Such dishes will be difficult to duplicate, and appeal to narrow tastes.

If the vision clarifies, refrigerate it overnight (Business Requirements [Stated]). After additional stirring the following day, use the aroma of the clarified vision with the sponsor as a guide to specific stakeholder sauces worth adding. Make a BA Plan to quickly hunt real meat from a sample cross-section of steakholders – (some say puns are the highest form of humor. Some don’t 🙂 ). 

Following the BA plan, mix the clarified vision with validation and other input from the 10 stakeholder types (BABOK section 1.5.6.1, figure 1-3. Including the BA there are 11). To avoid unnecessary boiling, keep the types apart before blending their flavors into the mix. Grind any distasteful issues or problems until their root causes float to the surface. Use honey (opportunities) to catch any flies in the kitchen. Remix until all stakeholders are nodding (use alcohol if it helps, or doughnuts and coffee). You will know that the business need is ready when every stakeholder has identified desired (and S.M.A.R.T.) outcomes for the meal to be served.

For the “paperless” meal in question we had this “implied Business Need” last month: “We are going paperless to save $5M.” Compare that to what might emerge from the recipe above, shown below:

Problem/Opportunity:

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 goals and objectives are currently as follows: 

  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.
  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. 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, surveys show that over 30% of our applicants complain about the delays.
  2. Lost or misplaced 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, for entry into a grade reporting system. When questions arise about the grade, there is no detail to explain how the grade was awarded. 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. In spite of this, the number of formal forms submitted each year is less than 5. There are approximately 37K students enrolled).
  4. Archival costs 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 to finish their degrees. We need better policies and electronic search to reduce this repeated manual searching.

General Issues:

  1. Departmental managers recently estimated that on average 10% of employee time is used for filing and re-filing various kinds of paperwork related to student, faculty and administrator needs. These include, but are not limited to:
    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
  2. 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 🙂 ).

Reasonable people may notice that the above is far from complete, or even remotely detailed. It certainly isn’t a business case at this point, and is just barely a “Business Need”. There may be premature “solutioning”, more “root cause” work needed, and almost certainly major gaps (are we “collaborating” on documents or just “sharing” them?) What solutions or workarounds already exist? Can these be improved without new acquisitions? How many employees will have to change what they do? How will the employees find out, and what will that cost?

The above is not correct, clear or complete or concise. Hey, it’s just a blog! The point is to compare the above with the information in the cost justification last month

Which imperfect, incomplete example offers more guidance as to next steps? Which offers some hope of “stakeholder success criteria”? Which one suggests specific questions? Which one helps identify specific “gaps” in knowledge? Which one is more typical of “failure mode”, which one has a greater chance of consensus? 

Having kneaded the Business Need, and allowed it to rise, we are ready to continue with the recipe. Without a high quality business “knead”, there is nothing to cook.

NEXT TIME: Part 3: Filling the Gaps in Gap Analysis.

Don’t forget to leave your comments below.

Vision-Schmision, Where’s The Business Case? Part 1

Ferrer Feb26 Img01The first time I ran into a Project Manaagement Office (PMO) I was delighted! I loved the idea that projects might be researched and understood before the really big checks were written. The PMO Director explained: “Anyone who wants a project funded has to submit their request to the PMO. A committee reviews the submissions and decides which projects can be initiated.”

“What do the requestors submit?” I continued. “How much analysis is required for a given business case? What kinds of projects get funded?”. The PMO DIRECTOR beamed as she explained “We are using a software to manage the PMO, and requestors have to fill in all required fields, including a cost estimate and projected benefits.” We both looked over the screen as he went on. “This is the information that is used by the committee. They use it to choose a mix of large, medium and small projects.”

The answer to my next question woke me up: “I see the cost field and the benefits field, but where is the business case that calculated the costs of the changes and how those changes result in benefits?” The PMO DIRECTOR replied dismissively “Oh,  this software has a place where you can attach anything you want. We don’t require the attachments, as long as everyone agrees that the project is justified. You only need a detailed business case if people aren’t sure that the project is worth doing.”

Carefully, seeking greater understanding, I suggested: “How hard would it be to look at one request where people weren’t sure about a project?” “Sure”, came the quick reply. “When we needed to do document management, every department had to give estimates. At first, no one could agree on the right way to combine them, and we had meeting after meeting. Eventually the different approaches were reconciled and combined into one spreadsheet that showed we could put in a document management system for less than $3,000,000 and save more than $10,000,000.” As the PMO DIRECTOR navigated to the project in question I imagined that the involvement of many departments COULD mean a high quality business case. It would be natural for there to be disagreement with so many “first drafts” in play by so many different authors. I figured this disagreement COULD result in discussion and refinement and improvement of the different departmental analyses and approaches. With luck the approach agreed on would align with and illuminate some of the changes* needed to achieve business goals and objectives.

“Here’s the project, and here’s the spreadsheet” said the PMO DIRECTOR. “I’ll open it.” Here is a slightly summarized, “changed to protect the innocent”, version of the information I saw:

Cost Benefit Justification for Going Paperless at Organization X 

The following are a consensus based on Sums and/or Averages of Dept Estimates:

Ferrer Feb26 Img02

The following are Dept Page Estimates: 

Ferrer Feb26 Img03

At this point I decided to keep my mouth shut. The project had been “justified” – 5 million dollars justified, and not a single requirement in sight (nor any NPV, IRR etc, but let us not go there – not just yet). Deals were going to be made, software and equipment was going to be purchased, and vast amounts of time would be spent setting it all up and outsourcing training, and replacing, etc., etc. Nothing would stop this juggernaut, and it was not in my specific scope, which applied to BA on future projects only.

Once I saw how “business cases” were built in this organization, I went back to basics in my mind (is there anything else?). It would take a lot of thought to explain the basics It was going to be COMPLICATED to explain the difference between justifying a vision (what the organization was doing) and creating a business case (a true cost-benefit analysis and a key guide to next learning steps). If I failed in making this point it would be hard to help future projects, since my assignment was quite temporary. 

I glanced at the business case on the screen one last time. WHAT IS the Business Need? Just saying MONEY doesn’t count as a useful Business Need. Everyone wants money (except that adorable little girl who thwarts Jimmy Fallon’s pitches on television). The trick isn’t wanting it, it is figuring out how to make it so. This is TRIPLY true in non-profit or governmental organizations focused on MISSION over money. How would scanning documents lead to the savings or the mission to be accomplished? WHAT WOULD CHANGE* and what would those changes cost? What if our ideas about what would change, could change or should change or did change? How can we succeed when so much could change? What will the potential cost of employee turnover be? What benefits are we prepared to work for instead of wish for? Why do so many Document Management Projects frustrate almost as much as they help, and sometimes produce only “spare change”? Why do documents need so much management in the first place – most get used once and forgotten, others are constant bottlenecks. AS-IS, or NOT-TO-BE, that is the question? How do people continue to avoid due diligence and the most minimal level of enterprise analysis?

When will Marcos stop asking questions?  Feedback welcome, I can take it (cringe).

Next month (I trust my readers will forgive me) we will actually look at HOW to COMBINE THE INGREDIENTS listed at top, in order to “Cook the Business Case‘.

Have fun, and here is a hand picked link collection to BA Times Blogs referencing Business Cases (more available):

* CBAP 007 BA Tip – Use at Your Own Risk and With Your Own Style and Words

Whenever a stakeholder says they want a new solution for their problems, as long as nothing changes, just nod, say something like “I see what you are saying, no changes?”, and let them do most of the talking.
Don’t forget to work with many other stakeholders. Always end the statement with the “questioning inflection”, and hope they respond by saying “Yes, no changes”, and then leave you alone. Don’t think about it or even try to fix it unless you are tired of the BA job. To paraphrase Robert Heinlein “Don’t try to teach a duck to sing. It is a waste of time, and besides, it annoys the duck.” 
 
Don’t forget to leave your comments below.