The O'Keefe Consulting Group

noreply@blogger.com (okeefe consulting) — Mon, 02 Mar 2020 14:09:00 +0000

DevSecOps Spotlight – Site Reliability Engineering (SRE)

The Pyramid

Site Reliability Engineering evolved at Google to meet its internal needs in the early 2000s. SRE embodies the philosophies of DevSecOps culture, but has a much more prescriptive way of measuring and achieving reliability through engineering.

Product teams, who are charged with building reliability into their products and applications, will engage several important techniques. These focus areas are embodied in the product pyramid shown here.

SRE Product Reliability Pyramid

It is only after all the basic building blocks are in place can the product be complete. All but the peak of the pyramid are defined by non-functional requirements. One view of this product relationship to the SRE practice is the patient/doctor metaphor, applying the concept of a product team as primary care provider (PCP) to the product as patient.

A good primary care doctor knows all about her patient and can help that patient get specialist help when needed. The PCP is the center of care, and should be informed of all conditions and issues with the patient’s health.

Monitors & Alerts

Service Level Indicators are those metrics that reflect that health. Just as our blood pressure, heart rates, weight, BMI, etc. are indicators of an individual’s health, systems can have similar indicators. Immediately addressing those numbers that are outside of nominal range is critical to health.

As monitoring indicates the health of a patient, an alert is raised when those indicators exceed their objectives, or nominal, ranges. Symptoms of system health issues can include:

End user response time outside of service level objective
Excessive error logging
Errors or slowdowns lower in the stack, such as database, storage, network, or middleware
Database blocking exceeding normal

Google's 4 Golden Signals are the key components of a monitoring approach:

Latency – time to service a request
Errors – rate of failure
Traffic – measure demand on your service
Saturation – how “full” is your service

These monitors can be built with various approaches:

Black Box

Symptom only: “the system isn’t working correctly." This is typically a synthetic monitor generated on a regular heartbeat to validate a business process is working within nominal range.

It does not necessarily report cause, just an effect.

White Box

Typically uses telemetry/instrumentation from the application itself. Allows drill-down to identify specific root cause.

This should also help identify upstream problems such as database response time or other latency issues in the stack.

Product teams should understand the ecosystem of their product and ensure each layer is adequately covered with monitors and alerts.

Incident Response

As alerts are raised, teams then move to the next level of the pyramid, incident response. Ideally, teams engage before severity is high. A strong capability for drill-down metrics is important. If a patient’s symptom is a high fever, the PCP may order blood tests or further probes to determine root cause. The PCP (and product incident response team) must also quickly understand the impact of the issue.

Emergency room staff are trained to quickly triage a patient by looking at all key indicators. Likewise, the system needs to ensure drill-down capabilities exist throughout the stack to find, control, and ultimately remediate damage.

The system’s monitors and logs should be utilized to identify the number of users impacted, as well as potential downstream concerns. This drill-down capability is critical to lowering time to restoration of service, which is the key goal of incident response.

The mean time to restoration as well as mean time to repair metrics are both important measures of a teams’ success with this process. It builds on the monitors at the base of the pyramid to ensure the team has all the appropriate system data at the ready. This data must be metric-driven and transparent, without undue layers of obfuscation or access restrictions.

Postmortem/Root Cause Analysis

Postmortem incident review is a critical component of prevention. Similar to major incident review in ITIL, root cause analysis, despite its sound, is an elusive and sometimes misunderstood practice. It is rare that a single cause is the reason for the failure. While understanding the “root” is important, it is only a part of the opportunity.

A blameless postmortem (BPM) brings stakeholders together to discuss the details of an incident, including actions and observations prior, during, and after the incident. “Blameless” is an important cultural concept that makes an effort to balance safety and accountability. It enables the team to give a detailed account of the details without fear of punishment or retribution.

Often, human error can be a cause of system failure. Engineers work hard to ensure they understand and mitigate risks related to the systems they support. As professionals, we take pride in our work, but also recognize our own failures. A blameless postmortem allows a retrospective review of actions taken, this time with the benefit of hindsight. Often, others from the product and support teams will have a different perspective and can help with unique ideas to alleviate similar future failures.

Following a common agenda for the BPM helps prepare individuals for this meeting. For a complex incident, it is helpful to have an outside facilitator to ensure follow-up actions are tracked. A key outcome of the BPM is a list of action item tasks, including Jira stories, incident requests, or other form of backlog to be prioritized by product and support teams.

Findings from the postmortem should feed the pyramid blocks above and below this layer. For example, additional service level indicators and alerts are often needed as preventative actions. Incident run books may also need to be updated. The pyramid blocks affected above this layer include additional testing, automation, and performance management processes that can help ensure the root cause is captured in a log or instrumented as part of the development process.

Testing + Release Procedures

Once a team has addressed the problem of production detection and incident handling, it is time to build automation into the SDLC. We have probably all heard about CI/CD (Continuous Integration/ Continuous Delivery) and we will have more to say here when we get to the “Development” block of the pyramid. A critical portion of the CI/CD pipeline is orchestrating automated test processes.

These are the basic types of testing, accomplished in order

Unit. A basic component of test-driven development (TDD). Written by developers before functional code is written, unit tests validate the code passes basic logic tests. For example, a function returns the correct number and range of values. Typically run by the build processes.
Integration. Tests dependencies, typically after deployment to a QA or Integration test environment, which introduces other external systems or data sources.
System. Large scale tests in a controlled environment. These can take the form of
1. Smoke tests. These are simple but comprehensive sanity tests and are critical to automatically validating a deployment. Testing of database connections, credentials, known configurations, etc.
2. Performance. Running the code at production volume tests the monitors as well as the code. The 4 golden signals are monitored to ensure adherence to service level objectives.
3. Regression. These are functional tests that ensure bugs have not been re-introduced. This assumes each issue has had a corresponding test added to this regression suite.
Production. Ideally, this uses the same framework as 3a, smoke testing, but ensures only non-destructive tests are performed after a production deployment. They should also include enabling black box monitors, which run their own validation processes.

The deployment pipeline should automatically execute each of these tests in order, and fail or revert the deployment upon any test failure. In an agile world, we build these incrementally and are constantly improving the test processes with each sprint and release.

Other types of tests are also important, such as stress tests, gremlin tests, and canary testing. Beyond the scope of this article, there are several good sources for more information on the World Wide Web.

Capacity and Performance Planning

Monitors and alerts are the critical base of the pyramid. If proper monitors with longer retention are in place, you have a treasure trove of data with which to manage your performance and capacity planning. Trends across time can be derived from this data. The simple example of database utilization is one use case. Using a tool like Splunk, we can chart utilization across the previous 12-months. We might note a spike during October that could line up with Open Enrollment calls requiring the IVR and customer service representatives to perform more membership queries than normal. Then, looking at the current utilization, we can apply last year’s trend line to predict utilization for the upcoming year-end.

Utilization, CPU or otherwise, is just one of many processes that can be enhanced by tracking the right metrics. We might also spot increases in claim volume toward the end of the year. Telephone trunk utilization, storage needs, network saturation, the list goes on.

This planning process is utilized in the load testing processes, where we can synthesize high volumes of data and transactions in a pre-production environment. During those tests, we monitor for the bottlenecks that exist as we build volume to the breaking point. Load balancing at both the front-end and data center back-ends are evaluated. We might also look at other potential options such as cloud overflow capacity.

Typically, performance can be greatly enhanced with query tuning as well. Bottlenecks are not always solved by infrastructure. In one of our tests, we determined that a reduction of CPUs actually improved performance in one of our systems due to overhead associated with maintaining database cache across frames. While counter-intuitive at first, metrics were able to highlight time spent by the system at each layer of the stack, including the operating system work.

Capacity Planning works to proactively manage environmental options to ensure that our systems perform in extreme situations. Failure to address capacity issues can quickly escalate to cascading failures, where upstream and downstream impacts start to occur.

Development

Once a team has solved the problem of production detection and issues, it is time to build automation into the software delivery lifecycle (SDLC). There are plenty of articles and teams using these CI/CD processes, so we will not go into detail here, but here is a good reference/refresher.

A CI/CD pipeline should cover some critical areas. It is more than doing automated builds with Jenkins. Tools are secondary; the process is the key. It needs to cover each of these areas

Security and access control. This securely automates access to secrets storage with logging to maintain separation of duties.
Automated Testing and Validation Framework. Ensuring each build and deploy continues to work without manual intervention and/or testing.
Metrics and Monitoring. Each build, deploy and test is logged and dashboarded.
Audit Compliance. A simple, searchable interface; automated break points to ensure approvals are met before deployment to production.
Code Scanning and Analysis. Includes tools for checking security vulnerabilities, memory leaks, other best practices.
Tool Obfuscation. Whether you are using Bitbucket or Gitlab, or deploying to Cloud, Docker or a Server, the process is the same.
Consistent Best Practices. One framework eliminates the need for hundreds and even thousands of individual build processes. Upgrades and enhancements are available in the framework, and don’t need to be added to each individual instance.

With automation and testing in place for all non-production deployments to various test and staging environments, the full release to production becomes a non-event.

Contact John for other ideas and/or discussion.

Build It and They Will Come

noreply@blogger.com (okeefe consulting) — Fri, 21 Jul 2017 15:54:00 +0000

There’s so much talk about DevSecOps I’m hesitating to write this and add to the noise. Most of what I read is about Continuous Integration (CI) and Continuous Delivery (CD) and that’s great. But many of us are dealing with a lot of legacy code and configurations, along with 3^rd party vendors and products that don’t easily fit that mode. And yeah, we still have a lot of that silo mentality around that makes it hard to “un-separate the duties,” so to speak.

The best acronym to represent DevSecOps is CALMS. It’s been said many times that DevSecOps is first and foremost a culture. And that is as true as it gets. Without a commitment to that culture change, there is little chance of success. So how does true culture change happen? One way is by showing little points of success and sharing the joy. Once we satisfy the WIIFM question, most of the cultural barriers can drop.

Agile and DevSecOps rely on breaking work into the small, deliverable pieces, the MVP. So let’s make sure we’re practicing what we preach. Small chunks that deliver value.

So what could be a little point of success for DevSecOps ? Well, the “A” in CALMS stands for automation, and that’s the place to look first. While automation ultimately needs to be across the entire systems life-cycle (including system provisioning, configuration, build, testing, monitoring, etc.), where I’ve seen the most bang for the buck is in deployment automation. Getting that new code change from development, through the test regions and into production without things breaking. How do we make that happen consistently and error-free? Practice, practice, practice.

So, let’s focus on automating the deployment from the Development source repository to Integration region. Even if the automated tests aren't quite there yet. Even if the build breaks often. Even if the build is done (gasp) manually. Did the actual deployment work? Great. Now run that same deployment automation into UAT. Did it work? No? Ah, forgot to change that configuration to use the corresponding region’s service account! Now, run that same automation. Works! Now, run that same thing, this time with the target region STG. Getting there!

Now that might sound easy, but maybe your deployment is a complicated series of manual steps that’s a little more difficult to completely automate. OK, let’s look to the “L” in CALMS apply the Lean MVP principle and break DevSecOps down further. Maybe the deployment can still be manual for now (just hold your nose), but perhaps now we focus on deployment validation as our first success. Write some code that executes non-destructive tests against the database, for example. Perhaps it just validates that the service account works. Try to call an API/service. Validate that the file directories are writable. Look for a specific success or failure log entry. These are small pieces of code that can catch deployment errors very quickly without having to release it to users who will find those issues on their own.

Back to that culture challenge, now we have something we can show using the “M” for measurement. Look, our validation process passed! Time to “S” for share that success, perhaps in a dashboard that shows the build and deployment statuses. Even if you have to manually update that dashboard.

So we can get small wins along the way.

But, you say, “what about CD? This isn’t DevOps!” Perhaps you have to deal with Release Management because they only want monthly releases? That’s a different fight. Your focus is to make delivery to PROD a non-event. And since you’ve automated deployment across the non-production regions you know it’s just gonna work.

Build that Easy Button. They will come.

What if I turn it up to eleven?

noreply@blogger.com (okeefe consulting) — Mon, 08 Aug 2016 23:52:00 +0000

This is Spinal Tap is a classic in a lot of ways, but one thing the fictional band knew was how to turn up the volume.

Have you cranked up your load testing? In my last large project, there were several critical components that had to be load tested individually and as part of the overall system. We all know that it just takes one bottleneck to spoil an otherwise perfectly good transaction. In our case, there were so many components and handoffs inside of a single synchronous transaction that one bottleneck could easily kill the entire system. But where were they?To ensure we tackled each one, we first had to model all the components of the user transaction from top to bottom. Each sub-transaction needed to be instrumented and measured to help identify those bottlenecks. And there were plenty. The transaction volume (i.e. "load" per time interval for this discussion) is estimated at a "busy hour" based on estimates or actual production data. Then all the different scenarios need to be played out, using "what if" brainstorming. What if a busy hour hits and a heavy batch process is still running? What if one or more of the servers in the cluster fail? What if a database query is constraining the SAN? What if everyone tries to log in before the data reorg is complete? You know the drill, the scenario brainstorm is the fun part. Remember, it's not necessarily the obvious set of transactions that are the killers. The mixing and matching of transactions is critical too.Then it comes down to building the scripts that let you pull the levers to match the scenarios. Don't skimp here. Your test environment should match production as closely as possible. Otherwise, while you'll certainly discover bottlenecks, they won't be the same ones in production. I've had the experience that the negative impact on a transaction can be severe when a production system performs faster than the test system. Because the bottleneck has moved. And a transaction component ends up waiting in line for something completely different -- an outcome that didn't exist in the test environment.After the tests are documented, the analysis starts. In those scenarios, does the system perform within the SLA? Sometimes you have to answer the question, does it need to? Does your SLA dictate a busy hour response? Or overall average? Smart negotiators will agree on SLAs that include volume estimates as well as performance metrics. No one can guarantee response time for an unknown quantity.So, while functional testing is important, you also need to know how your system will perform under load scenarios as well. A properly constructed load test framework will pay dividends to indicate impact with any change to the system, especially upgrades. Crank it up to eleven!Originally published on LinkedIn

Where's The Problem?

noreply@blogger.com (okeefe consulting) — Wed, 28 Oct 2015 18:40:00 +0000

We're putting the finishing touches on a 4-year project this week. This was one of those once-or-twice in a lifetime things that can either suck the life out of you or energize you tremendously. If done well, it will do both, and this one did. And how cool is this: It works!

It really did enable transformation of our company by implementing a new core system that allows tremendous flexibility in how we define and configure our processes. In doing so, we had to essentially re-engineer everything we've done with technology over the past 20 years. Fun? Yes! Excruciating? For sure!

If that was all we did, we'd probably count it a success. But we gained a lot more. By running an agile team approach, we put business operations leads with architects and IT staff together to live, eat, and breathe each others lives. Eye-opening to say the least, and definitely earned most of us a new level of respect for the others' jobs.

It also made us challenge each other constantly. "The way we've always done it" was no longer acceptable. We had to look at problems in new ways. Having the diversity of talent and background on the teams made a huge difference as we leveraged each others experience and viewpoints.

Agile scrum is an approach that is pretty simple. It brings together a team every day to review what we accomplished the previous day, what we want to get done today, and what barriers we face. The team's job is to crush the barriers and keep progress moving. Sounds simple, right? Barriers are the most common cause of project slippage (John's opinion), yet they are sometimes the most elusive to uncover. Why is that?

Sometimes we just don't want to admit that we're stuck. We may not want to blame someone else for the barrier. This is very common in some cultures and may need some prodding to draw out of someone who isn't comfortable speaking out.

But barriers must be broken down to have progress. Identification (admit you have a problem?) is always the first step. Sometimes the barrier isn't what it seems and may need some root cause analysis to get by. Often it will need help from upper management to break through some sacred cows or get past the one who just 'doesn't get it.'

Challenge your team: Call out the barrier you're facing, no matter how small. Identify it. Search for it. Name it. Then knock it down. Success follows.

noreply@blogger.com (okeefe consulting) — Sat, 18 Feb 2012 21:46:00 +0000

Face the Network

It’s been a really long time since I’ve written here. Busy, I guess. Isn’t that how we all are? Free time is hard to find, and what we have, we give to Facebook.

I won’t repeat all the research statistics here, but wow, this is getting crazy. Facebook’s IPO, scheduled for spring, should raise ten BILLION dollars.

I’m glad all this “wasted” time on Facebook is paying off for someone! So what does this mean for us as a society? I personally love it. I think all the hand wringing is ridiculous. We’ve evolved. Evolution is not always pleasing to everyone at every step. Often it is two steps forward, one step back, but you’re still further along than you were when you started. I’ve been able to connect with old friends that I never had a chance to keep in touch with in other ways. Had it not been for social networking sites such as Facebook and LinkedIn, we wouldn’t have had that opportunity. Is it the same as personal networking face-to-face? Nope, but it can certainly lead to more of that.

Yes, I still do yell at my kids for spending time on the computer when they should be looking for a job or playing outside with their friends (do kids still play outside?) But still, I can’t deny its appeal. Yes, I still get annoyed with people who share too much on their statuses, but sometimes it’s good for a laugh.

So what would I do with that extra time if I didn’t have social network sites to take my time? My Christmas lights would probably be put away; perhaps the carpet would have been vacuumed a few days ago. But I might have missed reconnecting with an old friend that I hadn’t seen in 12 years. I would have been harder to learn about the job opening when my colleague changed positions.

I like being connected. No different than the other half billion people who seem to as well.

John as The Six Million Dollar Man

noreply@blogger.com (okeefe consulting) — Wed, 21 Jul 2010 03:04:00 +0000

Steve Austin, astronaut, had it all. Then, a horrific accident. His injuries were grave. But “we can rebuild him; we have the technology.” Thus, the six million dollar man was salvaged, as was Lee Major’s career.

In the past eighteen months, I’ve had a torn rotator cuff repaired, a quadruple heart bypass, and just nine weeks ago, a hip resurfacing. If I were living in the nineteenth century, uh, well, I most likely wouldn’t be. Medical technology continues to surpass expectations, and it does it quietly. While most of us are excited about our new iPad computers and Droid touch screen smartphones, many of us are beneficiaries of technology that dwarfs home computing advances.

My new hip is a case in point. Made of titanium, it’s stronger than anything organic. The resurfacing surgery lasted about an hour and a half. The hospital stay was four days. Day one I was up and walking on the new parts. Painful at first, for sure. But a mere six weeks later, I was walking better than the day before the surgery. And that’s saying a lot. Without going into the gory details of the surgery, you might imagine what it takes to replace the “ball and socket.” It’s not like unscrewing the old light bulb and replacing it with a florescent one. No, there are a lot of parts to move around to get to the spot. Then there’s the sawing, planeing, cutting, stitching, and gluing! Good thing I was out cold.

Before the surgery, it was all I could do to get out of the car and walk to the hospital lobby. A couple hundred years ago I would be stuck in the cave, not able to hunt, not able to run away from the attacking hordes. In short, I wouldn’t have survived very long.

(By the way, the long wait and poor quality of this surgery in socialized medicine countries Canada and Great Britain are huge problems. So maybe I’d still be in the cave. But more about that another time.)

Medical advances are all around us. My heart bypass back in November of 2009 is another amazing example. It started with a blip on my electrocardiogram (EKG) at my primary doctor’s office (thanks for noticing, Dr. Bill!) I then promptly failed the stress test the next week when he referred me to a cardiologist. That same week, into the hospital for a quick angiogram. Lying on the table, I watched the monitors as my doctor inserted the probe in through my wrist, up through the arteries, and into the heart. It was a strange but incredible experience. Of course, I was hoping for a “simple” stent, which would open any clogged artery during the same procedure. No such luck. So, a quick consult with the chief of thoracic surgery, and into the operating room within two weeks as he opens my chest and reassembles things on my heart while a machine keeps me alive.

Wow. We are blessed with the most impressive medical system in the world, and most of us don’t even know it. Kinda puts technology in perspective for those of us who work in business data processing.

I might not be worth six million dollars, but for the huge investment of dollars and human capital in medical technology, for which many of us are grateful recipients, I say thank you America.

Is Customer Service Dead?

noreply@blogger.com (okeefe consulting) — Sat, 22 May 2010 13:46:00 +0000

I seem to be asking myself this question more often lately. My latest experiences were with La-Z-Boy furniture in Amherst, and Dunkin Donuts in Williamsville, NY. These were two very similar experiences, but very different outcomes.

My Dad owned a La-Z-Boy recliner for 30+ years. It was a comfortable chair, but nobody better be sitting in it when he came into the room!

I wanted to purchase a new recliner to use during my recovery from hip surgery. I was hoping they’d have something in stock, but could certainly understand if it needed to be ordered. The problem is, as I was told, it takes 6-8 weeks to order one. That seemed like an excessive amount of time to order a “stock” recliner. After all, I wasn’t ordering a Mercedes-Benz with custom measurements for my hips and butt! (although that might be a great line of business for someone who actually knew about customer service).

I asked the somewhat-disinterested store salesman about the length of time required. Surely, I thought, another store would have this model in stock. Was there any way to transfer stock to this store? I’d even consider going to another store in the area if they could check for me.

No can do. Six to eight weeks. End of discussion. No “sorry, I wish I could help you,” or “let me see what I can do for you.” Just “nope.” Come on. I can seriously order a custom-option car in less time than that!

Needless to say, I told him that unless he could find a way to speed up the delivery, it would end his sale prospects with me. No response. Oh well, I guess I can live with my old recliner for a while.

I wanted to relate this experience to the corporation. I know if one of my staff provided this kind of customer experience, I’d like to know about it. Here’s my response:

Dear Mr. OKeefe:

Thank you for your inquiry and interest in our fine products.
La-Z-Boy Furniture Galleries are independently owned and operated. Unfortunately, we do not have access to what they have available in stock or on display. Our normal production time is 6 - 8 weeks for a custom order.
We suggest you contact store management at the Amherst location to discuss the lack of service you received.

Regards,La-Z-Boy Incorporated

Let’s look at this one.

From “Incorporated.” Really?
“Fine products?” Maybe. A bit outdated I have to say. As much as I liked my Dad’s recliner, the new ones were almost the exact same mechanicals (clunky and loud). But that’s ok. They should be proud of their products.
The company line sounds familiar. They really don’t have access to their own stores? Do they know the phone numbers? Wow. And I wasn’t ordering anything “custom.” I didn’t even know that was an option. I don’t think it really is.
They “suggest I contact store management.” Isn’t that what I did? Maybe you could help that process along? No, push it back on the customer.

I wonder if this company has a Customer Experience Officer (CXO)? Doubtful, huh?

Here’s a contrast. I am a Dunkin Donut coffee fan. We have to drive a bit out of the way to get coffee at one of their stores. I love cream and sugar in my coffee, but Beth takes it with cream only. She was on her own, and stopped to get a cup on the way to work. “Medium coffee with cream, please.” Again, another long story, but the customer service was less than friendly, and worst of all, they put sugar in her coffee. To her, that’s undrinkable. Unfortunately, she was well on the road before she tasted it. So she had to toss it. No coffee that morning.

She wrote an e-mail to Dunkin Donuts similar to mine. Dunkin Donuts is also a franchised organization, by the way. Here’s her “corporate” response:

Dear Beth,

We would like to thank you for taking the time to contact us about your experience at the Dunkin' Donuts shop located at xxxxxx.We work hard to maintain the highest standards in guest satisfaction however, it appears we have let you down and for that we apologize. We have forwarded your comments to the owner of this location as well as our Dunkin' Donuts field executive to make them aware of your experience and request that the owner of this location contact you.We hope that you visit us again soon and give us the opportunity to serve you.Thank you and have a great day.

StephanieCustomer Relations Associate

From Stephanie. A real person?
Thanks for contacting us about the “experience.”
“We let you down.” Wow, they understand.
“We apologize.” Unique. “La-Z-Boy Incorporated” didn’t apologize to me.
“We have forwarded to the owner.” OK, saved me the step. There was no “not our problem, it’s yours” type of response as in the La-Z-Boy version.

Within a day, she had a phone call and apology from the owner, and ten dollars in free coupons to Dunkin Donuts.

La-Z-Boy, see the difference? We’re still Dunkin Donuts customers. We will never buy a La-Z-Boy again. And we’ll tell all our friends about both experiences.

Customer service isn’t dead, but it’s on life support.

Out From Under The Covers

noreply@blogger.com (okeefe consulting) — Thu, 11 Feb 2010 21:40:00 +0000

I enjoyed the show Undercover Boss that aired after the Super Bowl. In the pilot episode, Larry O'Donnell, President and C.O.O. of Waste Management, works alongside his employees, cleaning porta-potties, sorting waste, collecting garbage from a landfill, and even being fired for the first time in his life.

As his eyes were opened on several levels, he began to understand the impact that his board room decisions were having on the rank and file. Cutbacks meant that staff were working two or three different job duties. He learned from one of the women who worked on the garbage truck that she has to urinate in a bottle along the route because there were no other facilities.

By the end of the show, Larry was a new boss. He understood. He was changed.

Of course we won't know the depth of what changes might happen at Waste Management as a result of this experience. My fear, however, is that the focus on a specific employee or employees who happened to encounter Larry during the filming of the episode won't be pervasive across the company if only attacked at this narrow view.

The reality is that empowerment (yes, that overused and under implemented word) is the only way to ensure that good (and maybe even some bad) ideas get implemented. The President got a fractional taste of the kinds of things that "corporate decisions" impact at the staff level. Sure, the one woman got the promotion, but only because she was in the right place at the right time. Who is making sure that each of the 100s of other employees, also going "above and beyond," are getting noticed? And that someone is actually listening to the women (and men) who don't have a place to urinate on the job?

Management, especially middle management, must take responsibility for soliciting, organizing, facilitating, and implementing staff ideas and recommendations. And if those recommendations need a champion, that manager must be brave enough to stand up for them.

It's a good show to watch. I'd love to see a follow-up on each of these companies 6 months later.

The Need for the Governator

noreply@blogger.com (okeefe consulting) — Wed, 13 Jan 2010 21:41:00 +0000

The word governance in business is one of those terms that is so ubiquitous it has become almost meaningless. It can be applied in many ways, starting with simple process documentation to an iron-clad, locked-down model of authority for all things process-related.

To me, it's common sense that in order to automate something, we all better understand the current business process. That understanding is sometimes a responsibility that gets delegated to a business analyst or a process modeler. Too often, however, that critical step is brushed or skipped over completely. Then the proverbial Chris Alexander cartoon below comes fact.

"It's great, but this isn't what we wanted" the business person says.

"But it's what you asked for," the IT person says in exasperation.

Maybe it was, maybe it wasn't. The technically elegant solution may give little business value. So what went wrong?

For a while now, my passion has been on how those of us in IT can step back from the sandbox of cool technology toys and figure out what will really work to solve business challenges.

We sometimes expect the "business folks" to be separate and distinct from those crazy "IT folks." IT is part of the business. It shouldn't be off in the corner. IT needs to be intimately involved with both the strategic and tactical operations of the business. Some companies have gone as far as to define a best practice where programmers physically work inside the department for which they typically write software. For example, you might have programmers who locate in the Finance department, or in Customer Service. The programmer still reports to the IT CIO/CTO's organizational structure so they get the technical support they need, but they are involved in the business departmental team meetings and other activities. They even participate in departmental parties. They sit with the customer support reps on the phones, and may even take customer service calls.

For many IT departments, that immersion just isn't possible because of the wide range of required skills and supported departments. But the principle still holds true. Only if you walk in someone’s shoes can you appreciate their pain.

But when it comes down to building the systems, we hit “The Rub:” We often find that the business processes (rules) we want to automate aren’t really “rules,” but “suggestions.” We find two departments define things slightly differently. For example, “sales commission” may be defined by Finance as “x percent of sale plus payroll tax.” Sales may calculate it exclusive of payroll tax. The governance team needs to define which is the true business rule. They are called “business rules” for a reason. They should not be left for IT to define.

Documenting those business rule definitions are the job of the Governance Team. There can be many teams; IT Governance, Information Governance, SOA Governance, etc. The bottom line is that governance is not just about adherence to rules and process, but about alignment to the business.

This is also where the Use Case documents are so useful as they capture each scenario in detail for those processes. Only when there is agreement on those use cases and business rules should the software design start.

Business Governance needs to ensure that this alignment is taking place consistently. That communication gap that exists between the “business folks” and “IT folks” has to be addressed. Some of it is just agreeing on a standard lexicon. Yes, many of us in IT are geeks - and that gap can be a stretch for some.

The responsibility lies with the business executives to define a process that makes that alignment possible. Business managers should sit on IT committees and teams that work on technical solutions. Unless the “Business” is driving the change, we’ll continue to have to deal with the glorified tire swing that IT thought was asked for.

The Case for Use Cases

noreply@blogger.com (okeefe consulting) — Fri, 17 Jul 2009 16:49:00 +0000

It strikes me how often technical folks like me expect our customers (aka “users”) to know stuff that took us years to figure out. A big part of my job is designing and building computer software systems that enable the business to automate routine and/or complex tasks. Those systems help increase efficiency and thereby help provide (in theory anyway) profit to the bottom line.

I’ve worked with several leading technology vendors and methodologies to elicit the real requirements from the customers in order to build these systems. The purpose of documenting requirements is that we need to have a common understanding of “what” the system is supposed to accomplish. If we’re good, we try to leave out the “how” the system will accomplish that task until we get the requirements (the “what”) fully understood and agreed upon.

We break out these requirements into “functional,” which is a feature such as “allow the report to be sorted by any column,” and “non-functional” requirements. Yeah, we really call it that. Non-functional in this context has to do with things that aren’t really “features,” such as security, usability (remember how complicated it was to set the old VCR clock?), reliability, performance, etc.

Too often, I’ve seen the technologists go off and build something majestic – a real work of art – that becomes totally useless to our customer because it is too complex. The term is “over-engineered,” and that usually means that we’ve managed to make a really cool thing unusable.

So, this “requirements definition” portion of a software project is critical. We need to understand exactly what the user expects the software to accomplish. Only then should the technology folks go to the design table. Part of our job then, is to apply a logical approach to this process of definition of requirements.

A Use Case is an English representation of the interaction between the user of the system and the computer system itself. It is usually in the form of a scenario, whereby we methodically go through all kinds of iterations on how that interaction might go, in order to produce some result. It’s a kind of mini-story that can be told over and over again.

Use Cases were initially introduced to technologists in 1992 by Ivar Jacobson in Sweeden. As part of the “object oriented” approach to programming, it is a model that has gained momentum to the point where virtually all new systems are now build on the object model. Unfortunately, the adoption of the Use Case hasn’t been as quick, even though it is the foundation of all development, according to Jacobson. So, the sparkling new “object oriented” software still doesn’t meet users’ expectations.

The framework of the Use Case is one that lets us find all those hidden “gotchas” early in the process instead of after the software is delivered. It’s a way to capture the logic of the program on paper, before a lot of time is spent on coding. If we can run different scenarios through the Use Case, we know we’re in good shape to begin the next development step.

Our challenge as technical analysts, architects and developers is to help the customer community understand the value of a Use Case, and work with the users to define and build them early in the project. It should be in the top of the toolbox for every person involved in creating new computerized systems.

z4mxgfukp9

I Read You Loud and Muddled

noreply@blogger.com (okeefe consulting) — Wed, 18 Mar 2009 15:52:00 +0000

“What we’ve got here is a failure to communicate.” That phrase was spoken by the prison captain (warden) to prisoner Luke in the 1967 film Cool Hand Luke. The captain had just knocked him down, both figuratively and literally. The captain was showing his superiority over Luke’s lowly position as a prisoner, and serving as a warning to others on the chain gang that he was indeed the boss, and his instructions were to be followed without question.

Unfortunately, around businesses in America today, that attitude can be found in many bosses. And, just like that warden, communication failure is typically the reason for the failure of leadership. Fredrick Taylor’s principle in 1911 that “the workman who is best suited to actually doing the work is incapable of fully understanding the science,” is no longer the best management model. It lacks the essential communication and feedback processes. The American Heritage Dictionary defines communication as “the exchange of thoughts, messages, or information, as by speech, signals, writing, or behavior.” Key to that definition is the word exchange, which implies a 2-way path.

But it's not just a matter of crafting a clear message. That same message will be heard by different people in different ways. When I went from leading a team of technical professionals to leading a team of call center employees, I learned an important lesson of “situational leadership”. Many years later, I took a course with that subject by Ken Blanchard. Blanchard describes the relationship of the development level of the staff to the appropriate matching style of the leader.

The idea hit home with me. Leadership expectations must indeed be situational. For employees who were at the beginning of their career, much more direction and mentoring must be given, compared to those who have experience and knowledge of their craft. In addition, the ability to identify where a person was in relation to their career was a skill that is more than just a review of their resume of work. Having effective one-on-one meetings with direct reports is an important activity toward understanding the individual’s progress and building a trusting relationship. Early in their career, a more directional approach is required. As the staff member matures in their responsibilities, the transition to more of a coaching model is preferred as they learn to handle the responsibility delegated to them.

I think that excellent communication skills, including both speaking and listening, are the most important proficiency that a manager needs. Communication is always better received when coming from a person with whom you have a relationship. Using that skill effectively will help achieve personal and professional satisfaction, and will most likely propel a qualified manager to a higher level of career growth.

Do You Value Anonymity?

noreply@blogger.com (okeefe consulting) — Sat, 14 Feb 2009 15:45:00 +0000

I've always had the seemingly unpopular belief that, at least in the business world, anonymity is synonymous with secrecy. And it always seemed to me that secrecy among team members is a bad thing. Then why does HR seem to be all for an anonymous 360-degree feedback process?

In my job, I need to be challenged, criticized, and pushed to improve my processes, especially communication. Call me crazy, but I'm just not sure how anonymous feedback helps anyone communicate. For me, it's those one-on-one personal conversations from which I learn the most about myself and my approach to leadership.

Susan Scott, CEO of Fierce, Inc., and author of Fierce Conversations: Achieving Success at Work & in Life, One Conversation at a Time, agrees. Her recent article lists some "worst best practices," and puts the anonymous 360-degree feedback at the top of the list. Scott advocates the "365 Face-to-Face Feedback" process, which essentially is truly open and honest communication 365 days a year. She quotes Kevin Kelly, the editor of Wired and the author of Cool Tools.

"But if anonymity is present in any significant quantity, it will poison the system... Trust requires persistent identity. In the end, the more trust the better. Like all toxins, anonymity should be kept as close to zero as possible."

As Mitch Alegre wrote, we have to understand the ecology of our leadership; our environment and context. Do we value open honesty? As leaders, would our followers agree? And do you, as a follower, give open feedback to leaders in your organization so they can improve?

Check Scott's article here and let us know your thoughts.

Can you develop leadership?

noreply@blogger.com (okeefe consulting) — Fri, 30 Jan 2009 16:15:00 +0000

Leadership skills. What does that make you think of? Last Monday, Mitch Allegre told a group of about forty professionals about the "Ecology of Leadership." We were gathered at the Leadership In Action's Dialog Series event at AAA of Western NY. His often humorous presentations tell it like it is. He referenced the stereotypical corporate "leadership development" events that we've all been subject to. Mitch likened it to someone being taught how to play tennis by practicing their swing indoors, learning the correct position for forehand and backhand. Maybe even hit the ball against the wall. Then, the lesson is over and it's back to work. Get out there and play championship tennis. We just taught you all you need to know.

But wait... there's someone on the other side of the net now! Hey! They're hitting a ball at me! I didn't practice this! What do I do?

The standard approach of academic training lessons on leadership fail. It's all good information, don't get me wrong. But how does it all come together? Only with practice. In his book Outliers, Malcom Gladwell talks about the "10,000 Hour Rule." Whether you are the Beatles, Mozart, or a championship tennis player, practice truly does make perfect.

So how do we apply this to "leadership skills?" Practice. Meet with your peers. Learn from their successes, and more importantly, their failures. Find a mentor. And mentor someone else.

Leaders hip In Action is a group started for this very reason. We wanted to not only provide access to leadership development skills, but also spend time interacting with other leaders in your peer group. That interaction is how we learn. Experience is the key... it's how we learn. Let's get all we can. Visit the website for more details about how you can be a part of it.

Become a fan!

Your competition isn't what you think

noreply@blogger.com (okeefe consulting) — Mon, 22 Dec 2008 14:45:00 +0000

If you've ever watched a teenager doing homework, you probably know this already. The scary part is that we're more like them than we might like to think. Multitasking has taken on a whole new meaning in the world of iPods and text messaging.

If your business needs to capture their attention on the Web, keep this study in mind. According to a recent study reported by eMarketer, you have competition beyond your competition. Nearly six out of 10 respondents to a GfK Roper survey fielded in September and October 2008 said they listened to music or talked on the phone while using the Internet. Half of those Internet users were eating while they surfed as well.

How easy is it to find something on your pages? Clutter is bad. Usability testing is critical. You just have to pay attention to it, especially since your customers are not. Here's a quick check list to cover before you think you might be ready. Have you...

Identified your users with detailed personas?
Identified the top 5-8 tasks for each persona?
Used at least one of the navigation exercises (card sorting, questionnaires, paper prototyping, etc.)?
Brought in folks (from the outside) to test out those tasks?
Actually gone back and fixed some of the things brought to light in #4?
Scheduled your next usability test?

One of the things I learned at a Larry Constantine workshop was to test under realistic situations. Our group had to design a ticket kiosk. Paying attention to the environment that the software will be used is important. There could be long lines waiting to use the kiosk (putting pressure on the user to be quick), lots of background noise, motion, etc. A complex interface simply won't work in that situation like it might when using a home PC browser.

But, even at home, there is TV, music, food, pets and other distractions. We need to move our usability testing out of the lab and into the real world. Not hard to do, but very important.

Let me know how your next test works out!

Do You Belong?

noreply@blogger.com (okeefe consulting) — Tue, 02 Dec 2008 20:01:00 +0000

The Web is a wonderful, terrible, thing. I started working with the world wide web back in the 1990s, we used a text-only browser (anyone remember Mosiac, Gopher and Usenet?). Of course, it only worked on Unix systems, and Windows was just a bad way to do word processing.

Even then, e-mail wasn't used very often. I remember my boss writing memos (or rather dictating them to his secretary to type up), and distributing copies on everyone's desk. As e-mail moved more into the mainstream, communication improved. Today, with the proliferation of Web 2.0, which finally put the user in charge of the web, we are now in a world of connectedness via online social networks (<-- click that link for a definition - it's pretty good).

What does this have to do with leadership? Lots.

Your "network" is the single most important aspect of your career. But it's so hard to keep in touch with everyone. That guy who you used to go to school with (yeah, the one who was such a geek), is now the CEO of a high-flying Internet company. Maybe he was looking for someone with your skills. Maybe he still is. It's not too late to connect back with him.

Keith Ferrazzi is the author of the best seller Never Eat Alone: And Other Secrets to Success, One Relationship at a Time. He describes his technique that for him at least, "quickly forges the kind of emotional connection through which trust, and lots of business, can soon follow." Keeping relationships going is difficult. Heck, it's hard even keeping track of where someone works that you don't see often.

LinkedIn is an online network of more than 30 million experienced professionals from around the world, representing 150 industries. LinkedIn’s simple philosophy is "Relationships Matter." And they do. For those relics like me, it's been a godsend because I have kept in contact with some folks I worked with thirty years ago. That would not have been possible even ten years ago, only because we have each moved on to several other companies, changed our addresses, phone numbers, hairstyles (and lack thereof), and e-mail addresses many times over. With a social networking tool like LinkedIn, that tracking is done for me. It will never replace real face time with folks in your network, but it can help track them down.

Of course there are hundreds of other social networking sites. Facebook, with 120 million active users, is still the most popular, followed by MySpace. Others such as Twitter, Windows Live Spaces, Yahoo 360, Flickr, YouTube, Digg, etc. all have their places for socializing, sharing photos and ideas as well. And once you get your initial network established, the six degrees of separation theory kicks in pretty remarkably.

No, I don't work for LinkedIn or Facebook - but maybe you know someone who knows someone who does. And who knows, maybe they're hiring.

Functional Leadership

noreply@blogger.com (okeefe consulting) — Mon, 24 Nov 2008 20:13:00 +0000

How do you describe the verb to lead? Some of my favorite definitions include these from Merriam-Webster:

to direct the operations, activity, or performance of <lead an orchestra>.
to guide on a way especially by going in advance.
to bring to some conclusion or condition <led to believe otherwise>.
to guide someone or something along a way.

I think we need all four definitions to adequately describe the functions of a leader. Oftentimes, we stop at #1 on the list and assume we're done. Directive-only leaders sometimes work well to accomplish small projects with inexperienced staff. When the project gets bigger, things change. Being a one-dimensional directive leader is shortchanging yourself by ignoring the talents all around you.

The leader who goes in advance is one who can lay out the landscape ahead, as described in definition #2. That part of their job isn't so much to direct, but rather to scout the obstacles. They report back to the team, and then help plan the way to attack. In the Bible, the book of Numbers tells of the story of Moses, who sent out spies to scout out the promised land. Ten of the twelve came back with scary stories, and when Moses heard it, he delayed. God wasn't happy with that response. Perhaps Moses didn't trust his team (with God as leader). God had already told him that it was theirs for the taking. Sometimes, overanalyzing can be a bad thing, and it didn't work out well for Moses, who is one of the top leaders in the Bible.

The third definition, bring to conclusion, is also a critical one. Projects that languish for never being completed is one of the biggest all-time leadership failures. The very definition of project must include a start and an end. Without a specific, measurable, and attainable goal - the project may never complete and therefore remain in perpetuity. Without a conclusion, effort declines, visibility is lost, and energy diminishes.

The fourth definition is perhaps the most critical. The team is what is important. That team can be one or hundreds of individuals, but they all look for guidance. The leader as coach is that thing that captures our imagination. Think back to your favorite boss. Was he/she always telling you what to do? Or did they help you figure it out on your own? Chances are, they could have given you the answer on day one. But by letting you figure it out yourself, perhaps even struggle, you learned by experience. And that experience is what makes you, in turn, a more desirable employee.

I was blessed to have some very good mentors. I'm thinking about one in particular, who stood out as both cheerleader and coach for me. She was the one who kept pushing me when I was ready to rest on my laurels. I had just accomplished something that (I thought) was great! What did she do? A quick pat on the back, but then a big kick in the butt. She recommended me for a position that was way out of my comfort zone. I took the job, and learned more in three months that I had in my previous fifteen years of professional life. Fifteen years later, I am still indebted to her for that kick.

Tell me about your favorite leader. What was so special about him/her? What have you learned to emulate of them?

P.S. I've started a new website Leadership In Action (http://www.leadershipinaction.org) with the mission of building a community of leaders dedicated to the advancement and development of ethical leadership. Come visit us there.

AACRAO SEM 18 - CRM Experiences

noreply@blogger.com (okeefe consulting) — Fri, 21 Nov 2008 15:55:00 +0000

I just returned from AACRAO SEM in Orange County, CA this week. Besides the nearby wildfires, which took an incredible amount of property and effort to control, the trip was great. My presentation there was How To Engage Your Web Audience. I had great feedback from the attendees - thank you all very much.

I sat in on a few other sessions, always looking to pick up new ideas and research data. Many of the sessions were on using Constituent Relationship Management (CRM) for recruitment of college prospective students. What struck me as I browsed the sites and watched some of the demonstrations was Man, nobody has paid attention to the user experience at all!

Some of the tools' created web forms were downright embarrassing. I went online to visit some of the (unnamed) schools to see how they worked. Come on guys! The forms themselves were cumbersome, not well integrated (running on a separate server), designed poorly, and just not at all intuitive. http/https errors abound. After completing one form, it sent me back to the home page using https and none of the style sheets or images loaded. The entire site was text at that point. Yuk!

There is no doubt that CRM tools (Datatel's included) can be great time savers and even increase customer service. They help administrative personnel handle the load and are capable of tracking and reporting prospect status very well. But we have to examine the TOTAL experience from the persona of the prospective student. Millennials and even Gen-X's today have little tolerance for bad web design. Your web site might look awesome, and have all the tools the prospective student is looking for, but you HAVE to make sure that when the CRM forms take over that experience remains consistent.

Will you lose students if that integrated experience is poor? I really don't know. Maybe not. But I can guarantee that their view of your institution will drop a notch or two.

Make sure your vendor knows the Web, and how best practice forms need to look and behave. I highly recommend Luke Wroblewski's book, Web Form Design: Filling in the Blanks (2008, Rosenfeld Media). If your site (vendor or your home grown) follows Luke's simple advice when it comes to forms design, you'll be on your way to brand consistency.

Don't give your prospective students a reason to abandon your site. In Luke's words, forms on your website "are all that stand in the way of your user completing a task." Make it work well.

Not Another Web 2.0 Post!

noreply@blogger.com (okeefe consulting) — Wed, 15 Oct 2008 15:34:00 +0000

If you're not sick of the (mis)use of that term by now, then you're probably not working with the Web much! So, I'll try to avoid the term, and go with what made the concept so wildly successful for so many companies like MySpace, Facebook, and the like.

Peppers and Rogers, a one-to-one marketing consulting organization, said it well:

"Today, marketing must focus on co-creating experiences that engage and entangle consumers – on their terms."

That is a powerful word to use about customers: entangle. But it really is what we want. Our brand should be so compelling that they just can't let go. They are constantly pulled back in because they feel so compelled. When they are entangled, they also tell all their friends. And remember, "friends" in the on-line world is many times more powerful than the off-line world!

The phrase "co-create" should also be a little unnerving. In higher education, why would you let that high school student or college freshman put information on your web site? Because it has to be on "their terms." They are coming to your web site to have their needs taken care of.

According to the Noel-Levitz E-Expectations study, those needs include:

Personalization
Campus Visit Request Form
Engage (IM) with Admissions
Email Current Students and Faculty
Virtual Tours
Blogs
Profiles of Students and Faculty
Financial Need Estimator
Online Application

Those are just the basics - the entry price for playing. We all know about the Millennials and their need for entertainment, interaction, and social engagement. We also have to deal with their helicopter parents' needs as well. In the coming weeks we'll review each of these expectations as well as several other ideas to "engage and entangle."

Engagement vs. Hog Feeding

noreply@blogger.com (okeefe consulting) — Wed, 01 Oct 2008 20:35:00 +0000

I had the pleasure of hearing Al Switzler, co-author of Crucial Conversations, give a speech a few weeks ago. He described an interesting model of human behavior that was enlightening and even a bit disturbing.

We all need to have those conversations that we have been avoiding, whether it be with a spouse, child, boss or staff member. But HOW we have that conversation is, well, crucial.

What happens when we continue to avoid those conversations? Al told the story of a saw mill that his team visited a while ago to work with their management team. Their productivity had been decreasing of late, and they needed to understand how they, as managers, could get things back on track. Well, I'll let his co-author tell the story:

Feeding the Hog

How many of your teammates are "feeding the hog", instead of being productive? According to a recent study from BlessingWhite, fewer than 1 in 3 North American employees are fully engaged. What's much worse is that 19 percent are actually disengaged.

How do you engage your team? Do they feel a sense of purpose? Or do you squash their ideas because they aren't your own? Have you approached that team member who isn't pulling his/her weight? Engaged employees contribute to your success, and they stay longer in the company. Help them turn off the hog and get their unique abilities and strengths put to work. Everyone really does want to contribute, but they are individuals who don't all think the same way. They have unique ideas and ways to do their job. I always have to remember: they aren't the same as me.

And thank God for that!

Where's the Leadership?

noreply@blogger.com (okeefe consulting) — Mon, 25 Aug 2008 15:23:00 +0000

I just watched (again) the movie Network. If you haven't seen it in a while, it's worth a rent. Peter Finch played the incredible Howard Beale, famous for his line "I'm as mad as hell, and I'm not going to take it any more!" No one could have predicted back in 1977 how prophetic it would really be for the television industry. Howard Beale fighting against the corporate empires of the world (as summed up in an outstanding speech by Net Beatty). Without going into too much movie story, Howard Beale hit a nerve with the American people and created a stir that no politician had ever achieved. He had people screaming out of their windows, sending telegrams to the White House, and generally riled up to the point of revolution.

Then everything went back to normal.

Leadership is sometimes the voice crying out in the wilderness. But sometimes it's a softer voice in the boardroom, office or cubicle. But either way, it's a sustained one, not a flash in the pan. Often, as Jim Collins has told us, it is the quiet leader that is most effective. The one who understands his hedgehog -- that one thing that makes the company successful. And, the person who can instill that vision into everything that he does.

What's your hedgehog? Not just what are you good at... what are you awesome at? Then think about how you can develop that strength and become that one that will get noticed, not just for a flash, but for good. Chances are, Michael Phelps is a great basketball player too. But when he's in the pool everyday working out, you can bet he's not thinking about developing that 3-point shot.

There's room for all of us at the top. We just need our focus sharpened.

Usage-Centered Take 2

noreply@blogger.com (okeefe consulting) — Mon, 16 Jun 2008 14:07:00 +0000

I tried to draw a distinction in a previous blog about how user-centered design differs from usage-centered design. Although our focus should remain on the user persona, we have to make sure we have a good understanding of the tasks that user performs.

Unfortunately for the designer, most businesses are no longer in the assembly-line mode. It used to be much easier to design an interface that would fit uniformly across all the users of that system. The green screen character mode was that attempt. Some of us built on top of that a menu layer that allowed certain types of users (administrators, managers, and the like) to see different options that the "regular" user didn't have access to.

That carries on today. We have personas for management, admins, and the "regular" user. Sometimes, however, our focus becomes too narrow. Remember the good old days of systems analysis? For a long time we built systems from the bottom up. Then we were taught top-down design in the 70's – see the big picture and then build out the layers below them to get to the details. It was an approach that worked well for a while. Then, we came full circle again and started building bottom-up, focusing on a single user view of the system.

But we forgot a major tenant of design. Make the work more efficient. We're trained to look at a better way to do things. The user knows how he/she does certain things, and a good designer can put together a screen flow that can make that task sing. But we've forgotten to ask the "why" questions. Designers should always understand the "What" before diving into the "How" issues. Start with the goals. Work your way down through the objectives (they are not the same thing… maybe that's another column). Now, you can look at those objectives and see – is this really HOW you want to do it? Once you understand WHAT they are trying to do, use your training and help them discover the HOW with careful analysis.

The USAGE of a product is more important than the USER. It's really not blasphemy. It's common sense.

It Really Is About Customer Service

noreply@blogger.com (okeefe consulting) — Mon, 05 May 2008 20:54:00 +0000

And customer service doesn't get any better than this! :)

Educator, Test Thyself!

noreply@blogger.com (okeefe consulting) — Fri, 21 Mar 2008 20:01:00 +0000

How many of the higher education institutions you know about actually give tests (quizzes, exams) to gauge the ability of your students? Does it also help gauge the effectiveness of your lessons?

My guess is that all of them do. Then why, when it comes to a website, shouldn't we test it to make sure they "learner" (web visitor) is getting the message we want? It's so easy to gauge the effectiveness of your website by just testing it out.

Users love to get some personalized attention, so recruiting a few of them (you don't need any more than 5 or 6 for any given set of tasks) to let you watch them on your site, is pretty easy.

First, define the set of common tasks you think the web visitor should accomplish. Then, sit them down and watch them do them. Don't give them hints, but you should know what scenario you expect them to take..

Money Back Guarantee: you will be amazed at how much you learn from 5 people in a very short period of time. Try it out and let me know.

-John

You need fanatics!

noreply@blogger.com (okeefe consulting) — Fri, 07 Mar 2008 15:46:00 +0000

Kevin Kelly has it right. "To raise your sales out of the flatline of the long tail you need to connect with your True Fans directly. Another way to state this is, you need to convert a thousand Lesser Fans into a thousand True Fans. "

It seems that, for many, the sale is the end. That just can't work anymore. It has to be the beginning of a great relationship. A "true" fan is one who keeps buying, but more importantly, talks you up among their friends.

Did You Hear What I Said?

noreply@blogger.com (okeefe consulting) — Mon, 03 Mar 2008 14:46:00 +0000

The web is a quiet thing. Well, with the exception of those super-annoying myspace pages who put gawd-awful music on them so that they load at dial-up speeds. Anyway, it's not about yelling, it's about capturing their attention, not with a gimmick, but with something that satisfies a need.

Despite the terminology commonly used, your user likely doesn't have time to surf. They came to your site for a reason. Finding something that satisfies them quickly is your only chance to keeping them, and maybe even converting them to your customer.

Do you really know what your user wants? You can. You just have to ask. But first, you need to know who they are. Personas have been used for many years to identify and well, personify, target audiences. Find out what their keywords (as Gerry says, "carewords") are. Find out what images are compelling to them. Do pictures of buildings really convey the image you want? If you are targeting architects, maybe. If you are targeting high school students, not so much.

Build the persona, then ask them directly in your usability tests and interviews. Get to know them. Hobbies, interests, web habits, technology knowledge etc. Then build out your content. with them in mind. Are they idle words on a page to fill space, or do they really address your target persona? Keep testing and watching them. And learn. And apply.