Three Types of Problematic Consulting ClientsIf you’re an independent client and you’re looking to add one or more clients to your project list or you’re looking for that next big gig, then you may not be thinking clearly and looking for the warning signs. But often they are there…flashing loud right in front of us…if we learn what they are and learn from our own mistakes that we have a tendency to walk right in to. Yes, we may need the work…we may be desperate for the revenue. But avoiding certain problematic clients by learning how to quickly identify them can save us frustration, anxiety, stress, and possibly even save us from a failed consulting engagement.


We must be watching out for ourselves and determining if this is a client that we want to work for. We have to look and listen for certain cues to help us sort that out and make wise decisions for our consulting practice.


Through my experience, there are three types of potential clients that I generally like to try to avoid – if I can identify them before diving in head first into a new engagement. Let’s examine each…


Can you give me a better rate?


Experienced consultants warn you to be wary of clients who are overly creative with payment methods, in particular clients who tempt you into working for royalties on the software you develop for them instead of offering cash for your development work. Never fall for the statement, “The market is huge for a system like this – you’ll be able to make a fortune when this thing is done!” All that client wants is free software development and a share of your future profits for ‘making you rich.’


Watch out for clients who express surprise – or even irritation – when you charge for things like hour-long support calls or site visits to explain things that have already been documented (and similar legitimate billable actions). If you’ve made it clear up front that these are things the client should expect to pay for, then the client should be willing to pay up. The client who is constantly trying to get free work from you is not a client you want to deal with. You can sometimes identify these clients in the sales process when they repeatedly try to get you to do significant amounts of work for free, or if they show irritation when told that you charge for all but the first meeting with a client.


Have it done yesterday


Next, be concerned with the client who is incredibly rushed and demanding before anything even really gets started. This type of client may even want you to get started immediately without a signed contract, spec, or any ‘trivial’ paperwork relating to the engagement that might keep him from meeting his deadline. Be afraid…be very afraid.


When you encounter a ‘drop everything and do my work’ type of client, you know right away that you’re dealing with a selfish, demanding and likely very disorganized client who can’t manage their way out of a paper bag. Worse, this client will likely also turn out to be a rate chiseler who will express shock when presented with your bill. NEVER ever proceed without the engagement properly documented – no matter how rushed the client says it is. You’re going to get stiffed more times than not from this type of client. Run away fast.


The big ego


Finally, by very wary of the client who raises a red flag is the ‘ego hog.’ This type of client tries to turn every situation into one with a winner and a loser. The tip-off that you’ve encountered this type of client may come during contract negotiations when the client shows inflexibility about modifying even the smallest of terms he’s suggesting. He may become insulting and possibly even aggressive. Or he may attack your qualifications and abilities in a personal way. This should represent a huge flashing red light to you and tell you to “run, don’t walk” from this situation. Do you really want the work that badly that you’ll deal with this type of behavior on a potentially long-term basis? I don’t think so.


In this same vein of client is the know-it-all who responds to your initial attempts at solving his problem by shooting them down trying to blow you away with techie snippets he’s obviously picked up from the internet. This is the type of client who is likely to try to get a detailed proposal out of you only to turn it down and take that information somewhere else and try to get it down cheaper – with your ideas.


Summary


These are just three of many possible scenarios or variations of problem clients we can and probably will run across during our consulting careers. What clients have presented you with problems? What flashing red lights have you learned to identify meeting with potential clients for the first time or when you’re just starting consulting engagements? How have you responded?

Your advertising has worked and you’ve made contact with a potential client who has a need and thinks they might want your consulting services. That’s the easy part. Now you’re ready to sit down with the potential client and get details on what it is they think they need. The easy assumption is that the client always knows what they need – but in reality they rarely have a good handle on their entire need. They usually know a symptom or a portion of the need…but what we as consultants need to uncover is the real need or the full need or the root cause of the issue.


Here is a discussion of five key questions that I have found need to be addressed at the beginning of any potential consulting engagement in order to kick everything off on the right foot and to know that this is something that I really want to take on….


Do you have a budget in place?


It’s important to ask this question early. I’ve wasted too much time in the past with potential clients who’ve asked me in to discuss taking on projects for them only to find out that there is no budget in place for this effort yet. I’ve met as many as three times with one of these types only to end up with nothing to show for it.


So, I’ve changed my process. This is the first question I ask of all prospective clients, even if we really have no idea what it’s going to cost at this point. The client must have some idea of what budget they have available for it – even if that means we tailor what I can do for them based on monetary limitations. At least I know they’re coming into the discussions with some money approved. It’s not necessary to know how much they can spend. But it is necessary to know that they can spend something.


Is there a deadline?


If there have been some corporate promises made, then you need to know about them. I once led an effort to create an interactive website for a pharmacy. What they didn’t tell me at the beginning – and what I failed to ask – was “is there a drop-dead date on this activity?” There was, and it was as unmovable as the Rock of Gibraltar. To top it off, they forgot to tell me that the drug database they were using was from a third-party who had originally hoped to create the interactive site. Needless to say, that database vendor was less than excited about cooperating with me and the team I had assembled for the effort. It took my best negotiating skills to get them to cooperate. Thankfully, the project was completed successfully and on time, and the website was used by this huge Fortune 500 company for the next 10 years to service their employees. But this incident taught me a valuable lesson and I’m more careful in several of the questions I ask – including the specific timeframe needs of the client.


What is the biggest issue that brought you to this point?


There’s always one big need that the customer is aware of that has caused them to seek out your service. Beyond that there are also one or more ‘elephant in the room’ type situations that you have to dig for and find out about. You ask the right questions to find the customer-perceived problem, and then you ask more questions to see if that problem is really only a symptom of the real problem or problems that need addressed.


If you address only the customer-perceived problem and fix that, you make the project sponsor happy for the short term, but the end users will not be satisfied and it won’t take long for that to become a major issue. If you dig and find the real need, you’ll save the day, likely have a longer and more profitable consulting engagement, and a happy, referenceable customer when the project is over.


What have your end users been telling you about the situation?


The end users of either the current process that you’re going to be working on or the end users of the potential new process you’ll be implementing need to be included – probably both if they are different groups. Make sure your customer hasn’t come to you without first discussing the situation with their end users. If he hasn’t, that will become your job, but you need to know this up front because it will affect your estimate and it will affect how you address these individuals going in. With no advanced warning you may be basically ‘cold calling’ them and if a new process affects – or eliminates – their jobs, then you may have a mutiny on your hands. It’s just very helpful to know what you’re walking in to.


Have you taken the issue to your subject matter experts?


The last thing you want to happen is the perception that you are coming in and immediately stepping on toes. That can lead to push back, dead ends, and an overall major lack of cooperation. You need to make sure that this isn’t a project thought up in the head of the client sponsor with no consideration given to those ‘experts’ in the organization who may be able to either shed light on the issue or may have their own potential solution to the problem. These are the people that you’ll be working with to come up with additional requirements that weren’t derived from just seeing the end users’ perspective.


Call for responses


Let’s hear from other consultants. What’s on your list of questions for new or potential clients? What is your ‘need to know’ information that you absolutely must gather before you can even say ‘yes’ to taking on the work?

I’d like to discuss the how we determine the data requirements for our issue management and our change control needs on the projects we manage. We capture issues, but what else do we need to capture? What data is needed to fully understand the issues, track them, assign them, and ultimately resolve them? What data do we need to capture and track for change requests and change orders on the projects we manage? All of these are key questions and all highlight the fact that the data we capture is critical to the ongoing nature of the work we do and report on for these engagements. Without the right data, what are we tracking? How can we know that we’re working on the right stuff and resolving the right issues?



What issue info do we need?


What is critical to capture when we’re performing issue tracking, management and resolution? First, we need to know the normal who, what, and why information. Who is reporting, who and what is affected, what the issue is at a high level and why it has been reported…meaning basically what are the symptoms or problems that brought it to someone’s attention. We need to know if it’s a showstopper, top priority issue or if it’s a small bug that can be taken care of with the next release or the next batch of work that gets performed.


What else do we need? As we perform further analysis of the issue, we certainly need to capture additional detail – much more than the initial high-level detail we captured when the issue was first reported. We need to capture dates as well. When was it reported, when does it need to be resolved, when do we think it will be resolved…realistically. Next, we need assignment and accountability information. Who is the issue assigned to – which individual or group? And finally, we need to understand how we’re going to test this issue upon resolution to know that it’s resolved and ready for implementation. Along with that, we need to capture customer signoff and approval including dates for these.


What change request info do we need?


Does the change request info differ from the issue information we must capture, track and report on? Well, yes and no. Basically, it’s the same. However, since change requests concern work that is to be performed beyond the original scope of the project, there is definitely a financial aspect to them. Estimates may be gathered for issues – and likely they will be. But they MUST be for change requests because they’ll be affecting the bottom line on the project. The budget will change as a result of change requests and often the customer must pay additional funds so there’s documentation, accountability and customer approval of any effort and cost estimation that goes into the change request. Beyond the cost info, most other key data will remain about the same – we still need to track the who, what, why, and when. It still must be assigned, tested and implemented. That’s why issues and change requests are generally very closely related and are often tracked together and reported together on project engagements.

I’m not going to say that this is the complete list of the top 15 mistakes that every project manager makes…we’re all different. But through my experience in organizations, with colleagues, and my own shortcomings, this list of 15 mistakes is what I have resolved to call my own personal “top 15”. I fully realize that there are hundreds of mistakes waiting out there for project managers to make. I've probably made many more than just the list in this series of articles somewhere along the way in my 25 year IT career.  One thing I like to believe is that I've learned from my mistakes and from those mistakes that I've witnessed others making – though that doesn’t mean I haven’t repeated a few from time to time.


These are in no particular order – they are all important and all can lead to extreme budget overruns, failed schedules and frustrated project clients. And they are fairly easy to make without realizing it before it’s too late. So, here is the first part of my list….


Not asking enough questions to get the project off in the right direction


Our project clients come to us with problems. Big problems. And they are almost always certain that they know their need and they may even be telling us how to solve it including what technology to use. Sounds easy, right? The problem is, we’re the project experts and it’s our job to ask questions – the right questions – to uncover the real need of the client. What they are presenting as the problem may only be a symptom of what really needs to be addressed. It’s the responsibility of the project manager and team to ask the tough questions to get to the real requirements and the real problem. Then, and only then, can we understand the need, price the effort and map out a solution. If we act on the customer’s initial concerns without digging deeper we may end up solving the wrong problem and spending a lot of the customer’s project dollars on a solution that won’t work for them.


Get too much help or input


It’s ok – even wise – to seek out the advice of colleagues, peers, senior management, and more experienced project professionals who may have already encountered issues similar to what you’re facing. Project managers who lack experience with a given situation should do this – especially if the project has reached a critical point and needs quick action. However, more is not always better. Involving too many ‘subject matter experts’ in a decision process can lead to a significant delay in the actual making of the decision, meaning you may miss the boat on responding to the issue or at least cause the project to suffer severe damage in the process.


Not communicating openly enough with the project customer


The project manager who thinks they are ‘protecting the customer’ by keeping things from them runs the extreme risk of alienating the customer or worse – causing the customer to loose all trust, faith, and confidence in the integrity and ability of the project manager and team. I like to work on the assumption that the customer will always find out. I always do with my kids. My parents always did with me. My wife always does. It’s just that way. Sooner or later you’re going to have to give the customer the bad news so do it quickly and get them on your side as you work to correct the problem situation. Never go it alone. Only keep it from them long enough – if you keep it from them at all – to think up some possible courses of action to present to them…and that better be quick.


Putting too much trust in the self-management of the project team


No one likes to be micro-managed. But allowing your very talented and egocentric team too much leeway can cause your project to veer off course. Give them an inch and they’ll take a mile. Seriously…these are skilled individuals who already don’t like to be told what to do – especially by someone less technical then they are. Assign them their tasks and hold them accountable for them and keep abreast of what they are doing by communicating frequently with them. You must assume that if you haven’t heard from a project team member in awhile that they might be working on some tasks that are slightly to significantly off course. And with that extra effort there goes your project budget. Stay on top and keep them focused.


Micro-managing the project team


I already said that no one likes to be micro-managed. And sometimes new project managers will feel that they have to do that. A skilled project team with big egos will resent this behavior immediately and make life miserable for the new project manager. For the experienced project manager they may become confrontational or passive aggressive. At any rate, their behavior may become detrimental to the rest of the team and the progress of the project. Allow them the proper freedom to do their job. They’re experts. Recognize that and treat and trust them accordingly.


Relying too heavily on senior management direction


You need senior management. And they need you. But they have their own jobs to do. Make them interested in your project and have them at the ready if you need them to knock down barriers your project may encounter. Do this by sending them weekly status reports and schedule updates. But that’s just informing them and that’s a good thing. The flipside is being far too needy and running to them with every issue and decision that needs to be made. Your project will suffer from your lack of decision ownership and your career will suffer greatly when you show your senior leadership that you’re really not a leader at all. At least not a very confident one.


Failure to carefully manage project scope


Project scope is like the lid on a shopvac. Leave it on and it successfully manages all the dust and grime in the shopvac. Take it off while it’s running and chaos and a significant mess ensues…and you get to clean it up. The project manager and team must be in control of the project scope throughout the engagement. If it looks like it might be out of scope, something has to happen. The work or issue must be assessed and a change order must be presented. If scope isn’t managed and change orders aren’t created then the project budget and timeline will take repeated beatings throughout the engagement and the end result will be a project that is either canceled or deployed way over budget and way off schedule.


Failure to continually monitor the budget


I make it a habit to check the project forecast every week as I update the project budget with actuals that I get from accounting. By doing this I know I’m never far off budget. A 10% budget overrun is far easier to fix as you discover it than a 50% budget overrun is to fix three months later when it rears its ugly head. And it’s much easier to break the news to the customer or your senior management that the project is going to come in 10% over budget – assuming you can’t fix the overrun – than it is to tell your CFO that a $1 million project is coming in $500,000 over budget. Ouch.


Signoff on requirements that are not detailed enough


I always say that requirements are the lifeblood of the project. Documenting requirements is never easy and getting good, detailed requirements from the project customer that mean something to the delivery team who will be creating the solution is a very difficult task. What the customer considers good and what your solution architects consider good are usually two very entirely different things. The experienced project manager anticipates this gap and plans for enough time in the schedule to sit down with the customer and hammer out real requirements…no matter how much the customer contends that they already have done that on their own. They haven’t. At least I’ve never seen it in 20 years of managing IT projects so far.


Don’t plan enough planning time – Plans the project schedule too tightly


Being overly optimistic with the project schedule and task durations is never a wise move. It’s noble to say, “We’re going to get this done in two weeks instead of the usual three weeks.” But it’s also stupid. If there’s an extreme crunch, that’s one thing – and even then you need to let whoever is putting the thumbscrews on you that the date is not likely to be met. But if you’re just trying to look good…don’t do it. I’m not saying you should ever pad. I’ve been a developer and I know how much estimates can get padded anyway…that’s why I’m glad I was once a developer and I’m still and excellent technical estimator. Don’t pad, but be real. Your project needs a good leader, not a superhero who thinks he can accomplish the impossible.

Do you have great content and want it posted and promoted to the world? I will post as much content as you want for a month in exchange for your donation of older (2010 or newer), working and unused Macbooks or Macbook Pros you might have laying around collecting dust in a closet.

Read about my mission for this here (and yes, as is often the case for these things - this is personal to me):

http://www.bradegeland.com/m4ck.html

Contact me or email me to get started. Thanks!

Working multiple jobs is nothing new. With minimum wage lagging far behind the cost of living in the United States, many workers make ends meet through a patchwork of full- and part-time jobs — some working freelance gigs that add up to more than 40 hours a week without the benefits of full-time employee status. According to the Bureau of Labor Statistics, in August nearly 7.5 million workers, or 4.7 percent of the overall workforce, were working more than one job. A 2021 report from the Pew Research Center found nearly 60 percent relied on gig work to meet basic needs. And now inflation is driving those numbers of supplemental-job seekers even higher.


Singletary: 7 ways a recession could be good for you financially


But some workers have found a way to increase their income without increasing their overall hours through a practice they’re calling overemployment. Instead of clocking out of one job and into another, overemployed workers perform multiple full-time jobs simultaneously from home, their employers usually none the wiser.


I first heard about overemployment early in the coronavirus pandemic from a neighbor who knew of several software engineers holding two full-time jobs at once. More recently, Wired magazine reporter Fadeke Adegbuyi explored overemployment. Thousands of users on Reddit and TikTok, as well as the site overemployed.com, swap strategies, warnings and success stories about their overemployment experiences.


It’s not hard to see the appeal. Having multiple employers allows workers to diversify their labor the way smart investors diversify stock holdings. If they lose one job through a layoff or reorganization, they have another paycheck to fall back on. They often can enroll in multiple health-care plans, allowing them to coordinate benefits to keep medical costs down. And if done correctly, being overemployed doesn’t mean being overworked. By accepting junior-level positions and efficiently arranging their hours, workers can keep their personal and professional obligations in balance.


But there are challenges to overemployment. One of the biggest, to my mind, is the need for secrecy. While it’s not generally against any law to hold multiple jobs, employers generally have the right to fire anyone they catch doing it. As employers develop more sophisticated means of tracking remote workers’ activity (“tattleware” that monitors mouse movement and captures screenshots), workers are coming up with more elaborate ways of escaping detection (mouse jigglers, multiple devices, freezing employment and earnings data that can show up on background checks).


Proponents of overemployment argue that they’re simply turning the tables on years of exploitation and under-compensation.


'Zero regrets.' Six months after quitting, these workers are thriving


Overemployment can also become a self-defeating cycle if workers lose sight of their financial goals. Extra disposable income can lead to lifestyle creep, and overemployed workers may find their extra income going to pay for services, takeout, and other needs they no longer have time or energy to tend to themselves.


While overemployment, as Adegbuyi writes, feels like “the new cheat code to financial freedom” for those who can successfully pull it off, the income gap between surviving and thriving is only widening for those without access to those kinds of jobs. That’s not the fault of overemployed workers, of course — although I wonder how experienced workers squatting in junior-level jobs might be affecting opportunities for entry-level candidates.


Finally, the overemployment phenomenon, like other pandemic-enhanced work trends, stirs up questions about what employers and full-time employees owe each other. Are employers paying for exclusive rights to an employee’s time and attention, or are they paying to have tasks completed regardless of when and where the work happens? If it’s the latter, what distinguishes an employee in that position from a contractor?


Opponents of remote work will probably seize on overemployment as evidence that unsupervised workers can’t be trusted. Some might argue that collecting 80 hours’ worth of pay for work completed in 40 hours is greedy and unethical. But if an overemployed worker is completing all tasks on time to employers’ satisfaction, what exactly is the problem?


Five misconceptions about remote work, debunked


As one Reddit user notes, it’s long been accepted for people to work for two or three low-paying jobs or gigs just to scrape by — “But as soon as we talk about getting two real paychecks, having secondary insurance, having twice the opportunity to save for retirement — it becomes a big ethical issue!”


Put that way, it seems the main objection to overemployment is not that people are working multiple jobs to earn more, but that they’re doing so without working themselves to death in the process.

by Karla L. Miller for the Washington Post

Age discrimination? Is it a thing? What's your experience? How do you deal with it? Is a lot of experience always a good thing? Is being young always a good thing? Or always a bad thing? These are all pretty loaded questions and I'm hoping we can get some good topical feedback from the thousands of monthly readers this type of article will likely encounter. If you are uncomfortable posting a comment or response here, please feel free to contact me personally through my website listed below.


So, age discrimination in project management... Is it happening and what does it look like if and when it does happen? I'm not personally experiencing it as I'm independently consulting and have been for several years, but if you're 50 or 60 years old and you are trying to change jobs or switch companies are you finding it difficult even with a great deal of successful experience. And what about the younger crowd among my readers? Are you 25 or 30 years old and finding it hard to make career changes because you just don't have 10 years of project management experience to document even though you may have just successfully led projects as successful as landing the Rover on Mars? Read on but be ready to tell us about your thoughts and possibly frustrations at the end.


You're too old for this position. I don't know when this happens... but I'm certain it does. Does it happen at the human resources level, at the PMO director level? I don't know. But somehow, somewhere, someone – a hiring manager or project manager who is part of the interview process - sees that a candidate has 30 years experience and thinks “this guys is old and set in his ways – he won't fit in here.” BAM!, age discrimination. I'm not talking about some discrimination that is illegal, of course. They can hire who they want to hire, but overlooking the experienced candidate can really short-change your organization when you're trying to build the best project management infrastructure or best project management office (PMO) possible. Someone with that much experience – if it's been good, successful experience using best practices and possibly, hopefully certified – usually has some great ideas or experience with successful (and unsuccessful) PMOs and projects and can bring a lot to the table.


We can learn a lot from the successes and failures we encounter during our careers and from those colleagues we've worked closely with. When a project manager comes to the table with 25 or 30 years of experience to share with others and the ability to mentor you project managers on the path to project success and career growth, then your organization will be the big beneficiaries of that experience. You're reading more words now, right? There's your proof right there. I have the experience and I'm sharing it now.


You're too young for this position. Just like being too old, you can be weeded out just because you don't have 10 or 15 years of experience already. It may be a government contract that mandates that and I understand when that happens, but judging an individual solely by the years of experience listed on their resume without looking to see if they have other key skills and experience is a bad call. You an end up losing out on great candidates who may have a 25 year run in the organization and may even be your next great CIO, CEO, cybersecurity expert, PMO director or some other major contributor. You won't know if you boot this person to the curb because they only have three years of successful PM experience.


All successful project managers have to start somewhere. Yes, they need to gain some experience, they need to gain some successes and some failures, and will need some training and probably project management certification. All of that takes some career time and organizational dollars to accomplish. But some of your best candidates may not have 10 years of experience – don't be bias and overlook them just because you're too busy to consider a wider pool of candidates.


How to get past the first roadblocks. Experience, success, attitude, excellent communication skills and the ability to lead are the biggest qualifiers for the best project managers. That can be all experience, experience plus training and certification, or maybe just some experience and certification. You don't need to list 40 projects that you've excelled on – one or two will do. And take liberties... make them sound as good as they really are because full-on project successes are hard to come by. It doesn't matter if it was a $50,000 implementation or a $5 million implementation, you still succeed and that's what's important. You led a very successful project, own it.


And in terms of experience, be general not specific. Eventually they'll find out how old or young you are. Your goal is to get in the door and make them want you for you, not your age. So if have a million years of experience, don't say that because it won't necessarily impress them. If you have 30 years experience, tell them in the application or cover letter that you have 20+ years of experience or maybe even 15+ years of experience. It's the same thing. Likewise, if they are asking for 10 years of experience and you 8, don't address that. They'll figure it out on their own. Don't lie about your experience – ever. But don't flag it either if it can be a negative. Make them want you for you and what you bring to the table, not your age. They'll figure it out eventually, but by that time they will already be hooked on what you have already done and can likely do for their organization.


Summary / call for input


So you may be too old or too young – which you aren't... experience, success, training, certification, best practices, a good team... these are all ingredients to success that have little or nothing to do with age. Age is an excuse for the lazy and ignorant hiring individuals. By looking at age – either young or old - they are likely overlooking the best candidates available in an effort to make their own hiring jobs easier and their candidate pool smaller. It's sloppy and it's the reason why some projects – and project management offices – ultimately fail. They weren't built with the best available.


Readers – what is your take. Have you been deemed too you or too old for a project or a job or by a hiring supervisor? Maybe not outright told that is the reason, but you have reason to believe this is true. Please share your thoughts and discuss.

Awareness training plays an important role in an organization’s overall cybersecurity posture. But while security tools and platforms are regularly updated or replaced to meet the challenges of a constantly changing threat landscape, security awareness training has remained stagnant. 


Training is the first, and often the only, interaction with the security team, said Marisa Faga, head of trust culture and training at Atlassian. It’s an opportunity for the security team to create a positive experience that delights as well as educates employees, which could have big payoffs later with faster incident resolution and fewer mistakes with security impacts.


That’s in a perfect world. In the actual workplace, security awareness training isn’t meeting those objectives. 


At the Insider Risk Summit in late September, Faga explained that traditional awareness training does not focus on outcomes, it’s not interesting or engaging, and worst of all, it doesn’t convince anyone to actually care about security. 


It isn’t surprising that traditional cybersecurity training approaches aren’t working. 


“When you look at the data over the past five to 10 years, the approaches haven’t moved the needle in materially reducing organization risks,” said Mary Dziorny, cyber strategy manager at Accenture.


What’s missing from traditional security awareness training

Security awareness training has stagnated, in part, because it is a financially undervalued — and underfunded — piece of the cybersecurity platform. 


Security awareness training professionals end up spending most of their work time on other projects, according to a study from the SANS Institute. Or they have the wrong people in charge of awareness training, relying on those with high technical skills to lead the effort who might not have the soft skills needed to engage co-workers.


Also, there aren’t enough people on the awareness training team. Most companies have one or fewer people in charge of training programs. The organizations that have more mature training programs and a more mature security posture are those that have four or more people responsible for awareness training. 


Not having enough — or the right people — to do the job could be why security awareness training itself misses the mark. 


“Fundamentally, the industry is struggling to connect the realities of adult learning best practices with how organizations need to run their businesses, which is efficient and effective,” said Dziorny.


Security training today tends to emphasize specific focus areas, like how to ensure the organization is meeting compliance regulations or to improve employee production, but it skips things like employee engagement or improving employee job satisfaction. 


“Through more hands-on learning and upskilling, rather than outmoded table-topping exercises, security teams can see how their organization performs on relevant and timely exercises and simulations — even within hours of a new threat going live — so they can prove their ability and stay current,” said Max Vetter, VP of content at Immersive Labs.


Revamping awareness training through behavior

As cyberattacks become more sophisticated, employees need to take a more active role as the first line of defense. That means more effective cybersecurity awareness training, while working through the parameters of current budgets and staffing. 


It should focus on making the training more engaging and looking at how to change human behavior.


One change to awareness training is to either get rid of or deemphasize the term awareness. 


There’s a simplistic take that just by saying “awareness training,” users will automatically become aware of all the security issues and problems solved. 


It doesn’t work that way, said Ira Winkler, field CISO and VP with CYE. 


Rather than focus on awareness, the emphasis should be on how to change behavior. With behavioral science, you want to put things in place like reward systems, modifications to the user experience, or more established guidelines. 


“The goal is to have measurable improvement in security-related behaviors, and that’s very different from the concept of awareness,” said Winkler. 


Read More in Strategy 
 Nov 21, 2022
Tech sector execs see potential recession as a business opportunity
 Nov 21, 2022
Where will the security community turn, if not Twitter?
 Nov 21, 2022
Palo Alto Networks reports strong fiscal Q1 as security needs outpace economic fears
 Nov 17, 2022
SMB cyber budgets under pressure amid slowing economy
 Nov 16, 2022
Critical infrastructure providers ask CISA to place guardrails on reporting requirements
 Nov 15, 2022
Confidential computing critical for cloud security, Google and Intel say
 Nov 14, 2022
K-12 schools lack resources, funding to combat ransomware threat
 Nov 10, 2022
5 security musts for industrial control systems

One way to achieve this is to actually catch users performing good security behaviors and reward them, rather than looking for mistakes and punishing them. This could include highlighting when employees take security training classes, report a phishing email, or regularly use multifactor authentication. 


You might reward these behaviors in different ways — the point is to have a constant system to do so.


Storytelling as training

Another behavioral training method is to use storytelling. 


“Not only is storytelling a proven educational method rooted in behavioral science, it has the added feature of being entertaining as well,” said Faga. 


Educating and entertaining should work in tandem to cement security-related concepts in employees’ minds. Security should become a habit, but to get to that point, training should follow the pop culture format. 


“The most successful security training content creators are now providing rich, engaging HD videos that tell stories with characters over several episodes with interactive elements,” said Faga.


Like popular TV shows or NFL games, security training videos should aim to generate “water cooler” discussions around the office to reinforce the messaging. 


“Using this method, we’ve seen a second wave of people view the training in greater numbers than in previous years simply because they wanted to understand what the first people to take the training were talking about,” said Faga. 


Cybersecurity is a distributed business problem, and it is time to move beyond the annual “how to spot a phishing email” style of training, and do more to support users to incorporate cybersecurity into their everyday work behaviors. 


“We need to use realistic exercises that span from executives down to the most technical teams to unlock new levels of real-world performance measurement,” said Vetter.

by Sue Poremba for Cybersecurity Dive