The DelCor Connection Blog

Pressing Cancel

“Select form of payment.”
[press Credit]
“Swipe your credit card and follow the instructions on the keypad.”
[swipe credit card]
[press Credit on the menu]
[press Cancel]
[press OK when asked if the amount is correct]
And so on…

At grocery stores, pharmacies, and other retail locations this scene plays out all day every day.  This is a process most of us know so well we do it without any hesitation or confusion.  However, it IS confusing.  It ISN’T usable.  Once you indicate your type of payment, why are you being brought through a process that requires you to indicate it again and then press Cancel?  Cancel isn’t a word that leads a user to feel they are getting closer to completing their task, it is just the opposite.  It leads a user to believe they are going to have to start again.  Still, we press the Cancel button.  Why?  Because we’ve learned the system through using it enough times that we excuse its absurd violation of the standard (and pretty much only) definition of the word "cancel."

As we look at websites during usability testing projects we see website users make the same type of jumps.  They understand the nuances in the search results, registration, or profile setup so they excuse the poor user experience because the value of completing the task is greater than giving up or making a fuss about the speed bump in their process.  That’s not good enough. You should strive to delight your users with a good user experience.  Test your member registration/renewal, event registration, community profile completion, and search functions to see what your users see.  There’s much more to test than that, but these heavily used functions are worth testing if you do nothing else. Don’t expect your users to excuse your Cancel button whatever that may be.

Giving Murphy His Due: What's Your Project Risk?

The following is a guest post from our own senior consultant in technology management, Kathleen McQuilkin. This post also appears in the October 2011 edition of ASAE's TechnoScope newsletter.

Murphy's Law tells us, "Anything that can go wrong will go wrong." As anyone who has ever given a live presentation that depends on technology can attest, Murphy's Law certainly applies. This also holds true when undertaking technology-related initiatives.

Planning for the unknown in a project can be a daunting task, but managing project risk is a fundamental element of project planning and management, regardless of the type of project. The Project Management Institute (PMI) defines project risk as being "an uncertain event or condition that, if it occurs, has a positive or a negative effect on a project's objectives."

When considering this definition, it's clear that identifying risks before they materialize and determining the effect the risks may have on the project is critical—whether the risks are threats (negative risks, e.g., storm predicted along with likely power outages) or opportunities (positive risks, e.g., wind generator is usable, thereby reducing battery costs).

While it's unlikely that anyone would say that taking the time to consider risks is a waste of time, it's often one of the tasks that gets overlooked or postponed until late in the project—often to the detriment of the project.

What can you do to ensure you are engaging in appropriate project risk management? Follow these six steps.

Plan your risk management. Determine your risk-management approach or strategy and document how related processes will be executed for your project. Ensure your stakeholders recognize the value of managing risks. Do not be swayed by those who advocate a positive or "can-do" attitude instead of considering potential risks. Those attitudes can be great but should not replace risk management. Just think about the fire-safety instructions that are given to children starting in preschool: where to go in a fire drill situation or even the simple lesson "stop, drop, and roll." It's evident that planning for a risk and identifying corrective actions is ultimately easier than having to figure out a response after the problem occurs.

Identify risks. Identify all of the possible risks that could occur with your project. Consider scheduling estimates and timelines, cost estimates, staffing, management, and scope. Determine who "owns" each particular risk (e.g., IT staff, vendor, specific department, or staff member).

Conduct qualitative risk analysis. Assess each risk and ascertain the probability of the risk occurring as well as the potential impact if it does occur. For example, list all likely risks, assign a score for probability of occurrence, assign a score for impact, and then evaluate scores to identify those risks with a higher probability and impact.

Conduct quantitative risk analysis. Analyze the effect of risks on the project to provide some numerical estimates to help you understand each risk and its impact. Examples of quantitative methods include the Monte Carlo simulation and decision-tree analysis.

Determine what type of response you'll have for each risk. Based on the analysis you have conducted, determine your risk responses, get approval for the responses or strategies, and document the risk responses. Keep in mind there are four typical strategies for handling negative risks: avoid risk, mitigate risk, transfer risk, and accept risk.

Monitor and control risks. Once you have identified the risks, calculated the impact (qualitative, quantitative), and determined responses, monitor your project and identify any new risks or changes to current risks that could impact the overall analysis. Risk management efforts must occur throughout the entire project life cycle.

Ongoing Risk Management

Risks are a part of every project, and no one benefits from avoidance that encourages one to think about difficult subjects another day. By considering risks early in the project and on an ongoing basis, you're taking proactive efforts to better manage and control your project. Below are a few resources that could be helpful:

• Waltzing With Bears, Managing Risk on Software Projects, by Tom DeMarco and Timothy R. Lister
• Against the Gods: The Remarkable Story of Risk, by Peter L. Bernstein
• Practice Standard for Project Risk Management, Project Management Institute