User/Feature Access: From checklists to matrices

One of my experiences was to work for a Software as a Service company that catered to a particular industry. For forty years this company dominated the niche. Their approach was robust mainframes at one central location while their clients used terminal emulator software to manage their data.

This was the age of the web however and the company needed a make-over. Users wanted a graphical user interface with links similar to what they experience every day on the web. A Java web based front end was developed. They hired me to help them implement it across their clients up and down the left coast.

The documentation was really poor--as it always is when it comes from IT. It was done in haste and without the end-customer in mind. It was very technical and even seasoned system administrators at the clients' were puzzled by it.

Enter the BA who is constantly working to simplify and explain in terms end users understand and not all the mumbo jumbo that IT delivers. I had to translate what our Product Management team had delivered and developed my own.

Because we needed to run, the first couple implementations were not pretty. Either I missed capturing the needed functionality or features were not properly turned on. But every implementation left a lesson learned and by the 3rd instance, I started to feel confident. Experience gives one the commanding heights to begin standardizing the process.

Around that time I read Atul Gawande's The Checklist Manifesto and I became convinced that I needed to develop my own checklist for my work.

I developed templates to address all the modules features offered and what the client needed. This ensured I didn't miss anything. List out all functionality by module and if the client uses it, then populate it with user groups. Soon patterns emerged and I saw that the matrix could benefit from coloring coding and grouping those with access from those without. A Yes value became green and a No value became muted with a pink background. Now, I could arrange the groups according to their access. Those with the most access to the left and those groups with less to the left.

Below is what emerged. Here is a list of modules' features/functions along with user groups. Right away you can tell who has access and who doesn't and to what. This was tremendous help with meeting with client's management and they could see who had what in an instant. Without knowing much of the system, you can see what group Management is in.

This simplified reporting, maintenance and facilitated new hires' access as well as those folks that transferred from one role to another.

This was a success with clients and at my company. Soon, other BAs in other regions of the country began to use it as it simplified and standardized the process.

I'd say it was a win-win for everyone around.

Process Matrix

Once, I was challenged with creating a process flowchart from scratch--there was no previous sample to model after and the business subject matter expert was not always available.

Inexperienced that I was, I went straight to do the diagram. After a couple of fruitless hours, I grew frustrated. I needed a different approach.

Excel has always been my go-to tool. I launched it and began simply listing the actors across the columns and the sequence of events down the rows.  This turned out to be exactly what I needed to help me create the diagram later.

The take-away for me was to rely on something I was already familiar (Excel) and matrices. Below is a sample table similar to what I did then.

How about you dear reader? What do you use?

Process Flowchart Diagram

Once, I started a gig where I was given a process flowchart. I cringed when I saw it. I decided to recreate it. While I could have used a swimlane format, I decided to follow my own.

Also, the original was done in MS Visio. I did mine in MS PowerPoint. This goes to show, you don't need fancy schmancy tools to get the job done.

• Stages: I decided to color code the stages that transactions went through.
• System Actors: I also decided to color code the various system interacting and added a corresponding legend. 
• Alignment: Aligning the processes and various data elements is important to give the diagram a unified clean look. 

Here is the original and my flowchart. You be the judge and let me know which one would you rather read.

Evolving needs, evolving solutions

When I started to work in the IT division at a fortune 500 company, I began in the help desk. We supported a proprietary system that the company's partners used to communicate with orders, info, etc. I knew very little about computers, yet the managers took a gamble on me. Since I was newbie, I had lots of questions. I would ask my group lead, others who sat near me, or whoever was around. Needless to say, it drove people up the walls.

Soon I realized that no one person knew everything. Everyone had a specialty. Sure there were some who were very strong at a lot of things but never everything. These strong leaders at times had a small queue of agents with questions. I hated to wait and started to think of ways to reduce this.

Another experience I had around the same time was that when a build was released, a slew of users would call with the same issue. Over a couple of days of calls with the same issue everyone was up to speed, but the first few hours after thousands of users hit the system were grueling...

At the time, the web was still in its infancy, but what I had experienced of it was enough to whet my appetite. I proposed an intranet knowledge base where all issues would be mapped out for all help desk agents. As soon as an issue was discovered and resolved, a write up would be done and posted. This would eliminate the queues of agents waiting for answers to the same questions.

Management approved my proposal a year after I had gone to another division within the same company. But I was happy because it was proof that the concept had value.

At the new group, I went on to design and develop the division's intranet. And sure enough, I added a knowledge base in the format of an FAQ page. Pretty soon, however, I realized that FAQs were limited. What these new folks needed was something slightly different.

When users encounter a problem they call a number for support, right? But wait, what if it's a holiday or it's the weekend or off business hours? What to do then? Wait until the next business day and business hours? But you have a business to run...

In hindsight the idea was actually simple. I developed a troubleshooting flowchart diagram that took users through the various possible paths and detailed how-to solutions at the end of each branch. This was a huge success with the field reps and as far as I know it is still in place 10 years after I left that group.

Here is a screenshot of what it looked like.

Quick-Cards: My approach

We've all been there, we've all experienced the introduction of a new system at some point in our working lives. Along with the customary training, we're handed a colorful, concise, how-to step-by-step procedure to complete one or several tasks in the new system; all printed on heavy-stock paper (for durability and to convey the importance of this card). In short, it is  material that users are to keep handy and refer to it as they start to use the new system. Hypothetically, it is also used for new hires long after the system implementation.

Having experienced a few of these, I began to develop my own. A few revisions later, I arrived at what I currently use--the Quick Card. What follows is a description of the template I follow.

#1. Every Quick-Card needs to fit on a single PowerPoint slide. It is a tight unit of information about a specific procedure. It must contain enough information for both new and experienced users. Yes, even experienced users forget. Suppose someone is promoted and he/she stops doing that procedure. After a few months of no use, even experienced users forget.

#2. The Quick-Card has 3 main elements:
A) Header
B) How-to text on the left pane and
C) Corresponding screenshots on the right pane

A) Header: This is the title of the Quick-Card. It can have company, system, screen name, etc.

B) How-To Text: The left pane itself is further divided into several sections:

   > Objective: This is a one to two sentence statement that describes what you're trying to do. In other words, this is the "what".

  > Intro: Again, one to two sentence statement that describes the why of the procedure. This provides background to the task or the "why".

  > The How-to procedure: This section is the actual step-by-step description of where the user clicks, types, etc. Each step is numbered and corresponds to the screenshots on the right pane. It is very important that this section not exceed 7 steps. The lower the number, the better. If the procedure has more than 7 steps, it is no longer a Quick-Card; at that point, you should consider a video.

  > Further details: This section tells the user what to expect after they've completed the procedure or it provides guidance should they not be successful in completing it.


C) The screenshots pane: This pane contains a screenshot or close-ups corresponding to the steps in the How-to section. Ensure the tags style match to ensure users are not confused by other numbers/text on the screenshots.

That's it, that's what I use. Whether you use this model or it gives you ideas for your own, I'd love to hear from you.

Below are a couple of examples I've done.

Software development under Waterfall Project Management

Intro

I am an experienced Business System Analyst. I've worked for large to medium sized organizations supporting business users up and down both US coasts. I've supported from large advertising agencies to small motorcycle dealers and CPA firms.

I've designed, documented, tested, trained and maintained business systems from Accounting, Finance, Document Management, Customer Management, Service claim managements to Student Scheduling. In terms of platforms, I've worked with back-end mainframes, client-server and web based systems.

My passion is to help businesses and individuals streamline their processes, automate when/where possible, and squeeze every ounce of efficiency where possible. In addition I train users on the new system and show them the "how-tos" of the new system.

The following is a high level outline of my understanding and experience as a BA under waterfall project management.

Software Life Cycle

Requirements Definition/Scope  
The software development process starts with identifying the objectives behind a system or enhancement. One needs to understand whether the new system will address a new opportunity or if it's to replace an existing system. In the latter case, you will need to understand the old system before you can document the to-be system. For this, you will need to review existing documentation or meet with business subject matter experts to review the current functionality/procedures.

There are countless problems in any business, most but not all can be helped with technology. Notice that I did not say solved. I believe technology can get us close, but never quite reach 100%. Even without a silver bullet, however, businesses need solutions pronto. Technology can get us there 80%, and the remainder 20% is a manual task or a future build.

Once the problem/opportunity has a solution identified, scoped and documented, all stakeholders need to review the documentation to confirm that all needs/requirements have been captured.

The biggest challenge: This stage is critical and can take some time as stakeholders can go back and forth agreeing what is needed. Politics often come into play at this stage. It is key to maintain management appraised of this progress. Often times, it is necessary to involve management into the approval process.

The reason this stage is critical is because not capturing the correct requirements can quickly drive up costs in later stages to go back and retrofit the system to address missed needs. Also, if the stakeholders cannot agree on the requirements, the project can and most likely will be shelved or even cancelled altogether. Remember, the business does not have a single problem to solve. Solutions are constantly competing for resources and if one project is taking longer than originally planned, a new, more pressing or with higher return on investment project will take its place.

Once this document is approved, the established requirements become the baseline. Any new requirement should be managed separately from the original ones and developed post system implementation.

Functional Requirements
Once you understand the what and why and have stakeholder approvals, then the BA can proceed to the how of a system. This is the stage when IT is brought about platforms, systems, Databases, Data Mappings, EDI connections to internal and external systems, servers for development, staging and production.

Since IT manages the technical platforms, they will decide the best tools to develop and deliver the new system. For example, a Big Blue shop (IBM) would probably stay away from cloud services or if a client is heavily invested in Microsoft, they would probably not consider installing and running Linux servers.

IT, then, will review the requirements documents, their existing platform, consider future updates/upgrades and will come back with an estimate of resources needed (time/cost/manpower/technology) to complete the system or solution.

Development and Unit Testing
Management will need to review and approve IT's proposal and then and only then can design begin to be followed by development and unit testing also known as Alpha testing. While developers code, network engineers install and test servers, Database Administrators review and plan data tables, elements, SQL extracts for reporting, etc.

Once Unit Test is complete, IT will need to prepare a Staging environment and load it with a copy of production data for UAT.

Planning for UAT in Staging
Because the BA has been involved from the start, he/she is in great position to plan and manage User Acceptance Testing, UAT. The BA will review the success criteria for each functionality and maps it into the UAT plan. UAT is done by Subject Matter Experts, SMEs, or the business users who provided and confirmed the requirements. In my experience SMEs are the only ones who truly understand the business and can spot issues with the data or expected functionality.

Sign-off and Implementation
At the end of UAT, management, based on SMEs recommendations, will sign-off and the system can then be implemented into a Production environment.

Project Sunset
While not everyone engages in this activity, I think they do so to the detriment of both individuals and the organization. This is something that should be done. This is where the team reviews what went right and what went wrong. This is very important: You want to avoid that which went wrong and repeat that which went right.