Showing posts with label Checklists. Show all posts
Showing posts with label Checklists. Show all posts

April 5, 2014

Archaic Federal Hiring Practices

So the Federal government has some archaic hiring practices.

Some common critiques of the system:

- While gone are the dreaded KSAs (knowledge, Skills, and ability essays), in it's place are what many could consider meaningless multiple choice questions that enable applicants to game the system and answer what they think or know is the right answer just to get the highest points. 

- Also, there is always the potential (however infrequently) that there is a favorite candidate of someone or someone who knows someone, but knowing doesn't necessarily mean best qualified, but rather well-networked or connected. 

To be fair, there are protections in the hiring system to include an oath of truthfulness on the application as well as security clearances which are used to help ensure accuracy. Additionally, there are the Merit System Principles that prohibit favoritism and nepotism of any sort.

However, when it comes to hiring, what you can't really do in the government is just plain and simple see and recognize talent and bring someone on board. 

Anyway, this came to mind today, when we ran again into this amazing lady at Starbucks. She works there right out of college. 

She's a barista and has the most amazing customer service skills I've seen in 25 years of professional experience. 

She remembers us every time we come in and recalls what we talked about on our last visit. She regularly asks about things like my kids talking their SATs, visiting colleges, and more. 

But she doesn't just do this with me, but with all her customers.  

She has a big welcoming hello, and smile for all of them, and doesn't just take their orders, but engages them as human beings. 

I tell you this young lady would be terrific as a customer service representative in my IT shop or any other...and if I were in the private sector or had my own company, yes, I'd conduct a more thorough interview and background on her, but then I'd probably shake hands on the spot and offer her a job. 

I can see her interacting with my customers, capturing their requirements, problem-solving, as well as routine troubleshooting through engagement with the customer and the subject matter experts.  


Because she is a natural with people and intuitively understands how to work with them, engage, and establish trust and good service ethos. 

However, if she applied on USAJOBS in the current system of hiring, I think she'd never make "the cert" (the list of qualified applicants that gets referred to the hiring manager), because she's currently working in a coffee shop. 

Something is wrong that we can't easily bring in young or old, talented people from the private sector or out of school, and grow them into federal service, even if they don't have the perfect checklist answers. 

Unfortunately, this is a problem in many bureaucratic-driven organizations, where if it's not checklist-driven, then it's usually not at all. ;-)

(Source Photo: Andy Blumenthal)

January 22, 2010

Checklists: Safety Nets or Strangleholds

Many functions in government are guided, if not driven by checklists. For example, federal information technology management has many checklists for enterprise architecture reviews, capital planning and investment control, IT acquisition reviews, configuration management, systems development life cycle, IT security (FISMA), Privacy, Section 508, and more.

One of the frequent criticisms is that these functions are just compliance-based and are not focused on the real-world task at hand—whether it be planning, governing, executing, servicing, securing, and so on. For example, many have said that FISMA needs to be amended, because our IT security staffs are so busy with their compliance checklists and reports that they are not adequately focused on strategically or operationally securing the enterprise from attack. Similarly, EA review boards have been criticized for being an almost thoughtless checklist of architecture alignment to the FEA and not of real planning value.

Yet, inherently we know that checklists are valuable and that is why they have been so heavily mandated and incorporated into our processes. Without the checklists, we know from past experiences with failed IT projects, poor IT investment decisions, and security issues that many of these could have been prevented if only we had thought to ask the right questions, and so these questions got codified—and we learned from some of our mistakes.

With regard to this, there was a fascinating book review in the Wall Street Journal on a book called “The Checklist Manifesto” by Atul Gawande.

The author:

Mr. Gawande makes the case that checklists, plain and simple, save lives and we need them. He cites examples of “how stupid mistakes in surgery can be largely eliminated through pre-operative checklists” and how “checklists first became the norm in aviation, where pilots found that minor oversights in sophisticated planes led to tragic crashes.”

Overall, the book’s author maintains that “checklists seem to be able to defend everyone, even the experienced against failure in many more tasks than we realized. They provide a kind of cognitive net. They catch mental flaws.”

The reviewer:

The reviewer points out the important flip side to checklists as follows: “Bureaucracy is nothing but checklists. That’s part of what’s wrong with government—officials go through the day with their heads in a rulebook, dutifully complying with whatever the lists require instead of thinking about what makes sense.”

The reviewer makes the point that someone in authority needs to use judgment and that means: “relying on individual creativity and improvisation—the opposite of a checklist.”

The review goes on to then try and address the seeming contradiction between the need and value of checklists and the stifling effect that it can have by pointing out that “The utility of formal protocols [i.e. checklists, standard operating procedures (SOPs), etc.] varies with the nature of the activity—some activities are highly systematized, like engineering and other dependent on the judgment and personality of the individual. Spontaneity and imagination are important in many jobs.”

So there you have it—checklists—are helpful in defined, routine, almost mechanized areas where we can identify and itemize the necessary tasks, they are common to its performance, and they are proven to help avoid frequent oversights and mistakes. But where agility and innovation is called for, checklists can lead to either bureaucracy and/or missing the mark in getting the job done.

So are checklists helpful or hurtful with technology?

On one hand, technology is a fast-changing, innovative field that drives organizational transformation and thus it cannot primarily be a checklist function. Technology requires visionary leaders, talented managers, and customer-driven staffs. There isn’t a checklist in the world can inspire people, build meaningful customer relationships, and solve evolving, large and complex business problems.

On the other hand, there are common IT operational functions that need to get done and well-known pitfalls, and for these areas checklists can help us not make the same dumb mistakes again and again. For example, we can check that we are not making redundant IT investments. We can verify that appropriate accessibility for the handicapped has been provided for. We can safeguard people’s privacy with appropriate assessments.

The place for checklists in IT is pretty clear:

· STRANGLEHOLDS—Checklists cannot be a stranglehold on our business performance. They are not a substitute for thinking and doing. They cannot replace dedicated, talented, hardworking people addressing challenging and evolving business requirements with new and improved processes and technologies.

· SAFETY NETS—Checklists are safety nets. They are codified best practices and lessons learned that help us in not making routine, yet costly mistakes again.