Tips for end-user acceptance

Any solution, no matter how well it has been conceived will not be successful unless it is embraced by its intended end-users. Here are some quick tips to help promote acceptance (though I don't guarantee it.)

1. Understand how end-users work: Find out why they do the things they do. If you show an interest in them, they will be more comfortable with what you're trying to accomplish.
2. Provide opportunities for feedback: This is particularly important when there are user interfaces involved. At regular intervals, let people see the development and direction and be willing to listen to suggestions and feedback.
   
3. Manage change: If something has to change let your customer understand the rationale. "Because it has too..." is not a useful response. If the change is meant to make things better explain how.
   
4. Make it seem familiar: People by nature are resistant to change. Perhaps there is opportunity to gradually phase in changes (smaller changes are easier to digest) or provide an interface that is similar to an existing one.
   
5. Enlist champions: End-users that can teach other end-users are a great way to provide support. It also gives the champions a sense of ownership for the adoption. Early adopters are good individuals to use as champions.
   
6. Teach don't point: When someone asks for help one of the worst things you can do is point them to a manual. Spend time to teach them how it works. Show them they're important.
   
7. Measure & report: If the new solution is meant to improve productivity, show them the gains that have been made over time as the end-users become more familiar and move up the adoption curve. This type of information shouldn't just be provided to the project sponsors and management.
   

Projects are usually justified quantitatively based on achieving benefit targets (e.g., gains in efficiency or increases in sales.) Maximum benefits will not be achieved if the end-users do not embrace the solution wholeheartedly.

Why we do things - ROI

Long ago, one of my professor's told me, "The purpose of education is to increase pleasure enjoyment." I've yet to fully grasp exactly what he meant (he was a professor of philosophy and often spoke in riddle), but I think it was something along the lines of, "Knowledge allows us to improve our station in life." It may take the form of allowing us to obtain better jobs, improve our ability to appreciate things or allow us to take better advantage of the opportunities presented to us.

Let's examine a familiar concept - investing. Whether it is because we want to be able to make a large purchase (a house or car), enjoy a comfortable retirement, or live out some of our dreams, most of us are putting money aside. This money is invested based on our individual risk / reward preferences. If you lie awake at night worrying about your investments, you may be outside of your risk / reward sweet spot.
Individuals who want to be safe, invest in financial instruments such as money market mutual funds, treasury bills or other assets where the risk of losing the investment is small (note that small risk generally implies small potential return.) Individuals with a higher risk tolerance purchase financial assets with higher potential returns.

The prudent investor analyzes their assets periodically to ensure a suitable return on investment (ROI) is being realized. There is a good guide on ROI available on SearchCIO.com explaining basic ROI concepts from a business perspective.

I want to introduce another concept - opportunity cost. Opportunity cost is defined as:

The cost of an alternative that must be forgone in order to pursue a certain action. Put another way, the benefits you could have received by taking an alternative action.

In business, all else being equal, you fund projects that have better rates of return for your company. Businesses use capital from their shareholders and money they've borrowed to fund their projects. Furthermore, a company is expected to invest in projects with ROI that exceeds their opportunity costs (e.g., projects that make them grow!) From the perspective of an individual investor you probably wouldn't be willing to purchase shares in a company that wasn't trying to increase its future earnings. Would you?

Thus, in business the ultimate goal is to increase profitability. A business does this by undertaking projects that are expected to yield a return above their opportunity cost. These projects have specific goals and objectives that support the business' strategy. This is why it is important to tie requirements back to business goals and objectives. As well as business goals and objectives back to strategy.In business and in our personal life, we do things to improve, to grow, and as my old philosophy professor would say, "...To increase pleasure enjoyment."

Webinars: PPM & ITIL

Here are some webinars that may be of interest. Note that you may need to sign-up to get access to them.

Project Portfolio Management for the Skeptical IT Organization
You want to run IT like a business; you know Project Portfolio Management (PPM) can get you there, but you are worried about long implementations, high price tags, and consultants taking residence in your shop. In this webcast you'll learn how a web-based model with the right level of functionality has helped organizations like yours get a PPM solution up and running in two weeks and producing value right away.

Part I: Introduction to ITIL for the IT Executive - Podcast - Expert Podcast
Based on a practical approach to addressing real-world challenges of IT service management, ITIL allows organizations to better package and deliver IT services to their customers. ITIL enables IT organizations to align their capabilities with business requirements.

Leadership styles

I remember taking a course developed by the Leadership Research Institute on leadership styles. The purpose of the course was to help identify the most appropriate way to interact with an employee given an understanding of an individual's:

1. Ability to perform a task.
2. Motivation level to perform a task.
   

Using these two factors to create a simple matrix you get a picture similar to the one below. For each quadrant a different approach is warranted for handling an employee.

1. High ability to perform the job but low motivation to do it. Convince the employee to persevere and outline the task's importance.
   
2. High ability to perform the job and motivated. Allow the employee to perform the task unhindered. There is no need to provide direct support or exert control.
   
3. Not able to perform the job and not motivated either. Basically you need to tell the employee exactly what to do to complete the task and monitor his (or her) progress.
   
4. Not able to perform the job but motivated to try. Provide support, feedback and guidance to help the employee complete the task.

These guidelines assume that you are able to determine the competence and motivation level of an individual.

Intuitively, this framework makes sense. When you understand how to perform a job well and are highly motivated to do it, you don't really appreciate someone looking over your shoulder, telling you what to do and asking for constant status updates.

The purpose of the course was to improve managing employees, however, I feel that these fairly simple guidelines can be used in any situation where you need a task performed by someone other than yourself.

Tips for Business Intelligence

There was a short set of slides posted on BaselineMag.com outlining 6 Tips for Business Intelligence Success. Make sure you check it out. The tips are:

1. Understand your enterprise
2. Involve key users
3. Make sure components of a BI system work together
4. Be mindful that different employee groups will want different interfaces
5. Consider making applications broadly available
6. Create a competency center

Some of these tips are applicable to normal business analyst engagements as well.

Knowing when it's good enough

A business uses cost-benefit analysis as one of its evaluation criteria when deciding whether to pursue an opportunity or not. One concept central to this is the assessment of potential risks. To me there are a few components to risk assessment:

1. Likelihood of the risk materializing. What's the probability of the risk becoming a problem?
2. Potential cost (monetary, compliance or reputation) to mitigate the risk. How much is it going to cost you? This also includes implementing any mitigation strategies.
   

Combined, these factors provide a value to each risk. Risk assessment can be applied in many different areas:

• Managing the risks encountered in a project.
• Understanding the importance of a defect or bug in a system.
• Managing financial assets.
  

For the purposes of this post I'm only going to write about the second item.

What do you do if you find a defect or bug in a system? You evaluate it to determine whether it's a show stopper or whether you can proceed despite it. Creating bug-free software is the ultimate goal but it has cost and time implications. Here's a quote from an article, They Write The Right Stuff, from Fast Company about a specific software system.

This software never crashes. It never needs to be re-booted. This software is bug-free. It is perfect, as perfect as human beings have achieved. Consider these stats: the last three versions of the program -- each 420,000 lines long-had just one error each. The last 11 versions of this software had a total of 17 errors. Commercial programs of equivalent complexity would have 5,000 errors.

The piece of software in question runs the NASA space shuttle. The consequences of failure could result in the deaths of the astronauts, the loss of a multi-billion dollar piece of hardware and many years of setbacks to the space program. Many of the systems we deal with in the business world do not have this level of criticality. In my past jobs I have worked with time sensitive trading systems where 1/2 second delays mean losses in the $10,000's of dollars. On other projects, variances in marketing and market research data were explainable ("Yes, someone did purchase 50 rolls of toilet paper and it skewed the numbers.") We need to understand when something is good enough as it is instead of always trying to be perfect.

How "bad" requirements can stifle innovation

A great way to curb innovation and creativity is to impose improper limitations.

Limits by themselves are not bad. Clearly a project needs to operate within a set budget, resource allotment and delivery schedule. These types of constraints can actually spur creativity and novel solutions.

But let's think about business requirements and how improper requirements can hinder the process of innovation. More specifically let's examine how requirements that are not design independent can unfairly constrain a solution to a business opportunity (or problem.)
Many times during my requirements gathering and elicitation engagements I have heard subject matter experts and clients tell me their requirements based on existing applications and functions. They assumed that the products delivering the new capabilities they desired would actually be enhancements to the existing applications. In truth, the eventual solution may be based on an existing one (particularly with software products), but this is not always the case.

Suppose our company designs cars. The newest set of requirements for the upcoming model year state the driver has the ability to:

1. Determine where he / she is (e.g., location) at all times.
   
2. Receive driving directions to a user specified address.
3. Interact with the system through the car's dashboard.
   

By themselves, these requirements seem fairly benign. Suppose our project advanced to the stage where we are developing a solution to meet these needs. Our team decides that a global positioning system (GPS) is required. Based on the third requirement, it is decided that an on-board system similar to Onstar is appropriate. Implementing this solution requires our company to purchase units of the GPS product and integrate it into our assembly (line) process.

Nothing appears terribly wrong with the proposed solution, but what if the car model in question is marketed to first time car buyers and students (people who want to be sporty but on a budget.) Large scale changes to an assembly line are costly. Acquiring GPS units and integrating them into a car's electronics are expensive. The cost of the new model will increase as a result.

Because of the third requirement we have ignored other solutions that may have been more optimal. Perhaps we could have offered portable GPS systems (e.g., Tomtom's) to people who purchased our vehicles. Our needs would be met in a more cost-effective manner.
The third requirement constrained our innovation and creativity to the point where a more optimal solution was missed. This is how a requirement that is not design independent can stifle innovation and creativity.

Understanding the goal

When gathering requirements, one of the most important things to understand is the answer to the question, "Why?"

The answer to this simple question will provide clarity and guidance to your requirements gathering efforts. This is because you will be able to evaluate whether the requirements you are gathering will solve your problem (or capitalize on the opportunity.) Thus, a business analyst should always seek to understand the underlying business objective.

Suppose a client receives five sets of different reports. The client is concerned because it takes him a long time to get the necessary reporting. His request is for his five reports to run faster so he can perform his analytics. The business analyst (doesn't probe any deeper and) works with the IT developers to optimize the SQL used in the reports, create database views to reduce the number of multiple-table queries and revamps the reports so they are more efficient. Finally, the business analyst presents five optimized reports. The client promptly looks at each report, takes two pieces of information from each and then creates a dashboard sales report for one of his customers.

If the business analyst knew that the goal was to prepare a dashboard sales report, could a more optimal outcome have been achieved?

Here are a few comments about what happened:

1. The requirements were not design-independent. It was pretty much determined to rework the existing reports and make them more efficient.
2. Ultimately, a useful result was obtained however, it may not have been the most optimal one. The business analyst also ran the risk of not achieving the goal at all because the business analyst did not probe deeply enough to uncover the underlying objective.

If the business analyst had used active-listening techniques and probed the client, both of these issues could have been avoided.

How does your project contribute?

I recently attended a training session called Business Acumen. A good amount of the course's material was dedicated to understanding financial statements (the company providing the training was affiliated with the National Association of State Boards of Accountancy.) The rest of the course's material was based on the book, What the CEO wants you to know: Using business acumen to understand how your company really works, written by Ram Charan.
The main point of the book was that all businesses, regardless of their industry have the same underlying principles.

• Cash - Money and near-money equivalents used to fund a company's operations.
  
• Margin - The amount of money left over after paying off expenses (for a product.)
  
• Growth - The rate at which a company's business expands.
  
• Velocity - The rate at which a company's assets can be used to make money. For example, inventory turnover is a measure of velocity in some industries.
  
• Customer - Consumers or potential consumers of your products and services.
  

The interesting part of the training session was trying to understand how your activities (or project) contributed to the well-being of your company. Basically, a project should be contributing to one of more of these elements. For example, a company setting up an e-commerce website would be trying to:

1. Increase the market for its products (especially if it did not have a web presence.)
   
2. Increase the growth rate for the business by increasing the potential sales opportunities.
   

If you or your project is not contributing to one or more of these principles, then you should reevaluate what you are doing.

Getting past the fog

There was an interesting article on Yahoo! recently titled, A Guide to the Latest Batch of Corporate Buzzwords. It's a short piece and examines the usage of corporate jargon and lingo.

A new crop of buzzwords usually sprouts every three to five years, or about the same length of time many top executives have to prove themselves. Some can be useful in swiftly communicating, and spreading, new business concepts. Others are less useful, even devious.

Delayering, rightsizing, unsiloing ... What do these terms mean? Step back and think about how much terminology you use each day that an outsider would not be able to understand.

Using inappropriate language will only further confuse and obfuscate your message. Simplicity and clarity should be valued above all else.