Management

I’ve been holding off on this announcement until I finished the paper (mainly to make sure I actually finished it!).

I’ll be speaking at University of Texas at Dallas’ 2nd Annual Project Management Symposium on August 18-19 in Richardson, TX.  I’ll be presenting in the Project Management Methods - A (Track 3) on August 18 at 4:40 to 5:40 PM.  There are some other very interesting topics being presented…hope mine doesn’t get lost in the shuffle!

The presentation and paper is on an interesting topic (more on that in a few minutes).  My co-author, Chad Jordan, and I were able to get some interesting ideas down on paper and get it accepted for presentation at the symposium.  At some point I hope to be able to share the paper on this blog (or at least link to it).

The paper is titled “Project Management and the Stockholm Syndrome“.

The abstract is:

Project success in the world of client/vendor relationships hinges on two things: The ability of a project team to plan, manage and deliver results; and the ability to build and maintain relationships.  Most project teams understand the pitfalls of delivery but many do not realize that another pitfall is associated with building relationships. For example, what happens when project managers or other team members begin to associate more closely with the client or vendor then with their own organization?   This pitfall, which has the same characteristics as the Stockholm Syndrome, can be a significant risk for any project.

This paper addresses the topic of behaviors similar to the Stockholm Syndrome as applied to project managers and project teams. This is not an in-depth research study into the psychological effects of managing stressful projects and how these stresses might cause a ‘Stockholm Syndrome’ effect.  The purpose of the paper is to provide an overview on the syndrome and its associated behaviors and give some insights gathered from a real-world project where symptoms similar to the Stockholm Syndrome appeared and how these symptoms were recognized and overcome.

The idea for this paper came about one day when chatting with a former colleague, Gene De Libero.  Gene postulated that the affects of stress on project managers might be similar as stresses found in a hostage/captor environment.  We discussed the topic some more and decided to work on a research project. That project never really got underway, but Chad and I were able to grind out a paper on the topic.

This particular topic lends itself to future research, which is a good thing considering I’m working on a Doctorate degree

In a recent posts, I’ve mentioned employee engagement (more on the topic here, here and here)…I’ve had a few emails from readers asking me to give some examples of how they could go about engaging the people on their teams.  There are no ‘right’ answers for this because every person is different, but as a general rule, the following factors would help:

1. Trust your team.
2. Make sure your team knows that failure IS an option.
3. Make your team members accountable for their actions

Let’s look at each of these factors in more detail.  Before you continue, please realize I am not an organizational design expert nor human resources expert…these are just some basic techniques that I’ve used in the past.

Trust your team

Trust your employees.  If you trust them to do their jobs, they’ll deliver.

Treat your team like the adults they are.  Stop using the employment model from the Industrial Revolution and let your team decide when and where they should work.  Look into Results Focused systems (such as Results Oriented Work Environment (ROWE), etc).

Make sure your team knows that failure IS an option

Failure will happen.  If you ensure that your team knows that it is OK to fail, and that you expect them (and yourself) to fail, you’ll be amazed at what they’ll be able to accomplish.  I touched on this subject in a previous blog post titled “Learning From Failure“…an excerpt from that post is:

According to a story recounted in a newsletter from the New & Improved website, Warren Buffett, the semi-celebrity CEO of Berkshire Hathaway, says that the act of making a mistake (and failing) is essential to the decision making process.  As an example of this, Mr Buffett once told David Sokol, the CEO of a Berkshire Hathaway controlled company, that:

David, we all make mistakes. If you don’t make mistakes, you can’t make decisions.

This comment was after Mr. Sokol told Buffett that they would have to write off $360 million for the year due to a project that didn’t work out as expected.

If you truly want to engage your employees, making them understand that failure IS an option is key.  If they know that they have the right to fail, they’ll put their heart and soul into their efforts.

Hold your team members accountable for their actions

At first, this may seem a bit out of place, but I promise you, it will help.  Think back to a time when one of your team-mates / employees / friends / etc weren’t pulling their weight on a task.  What was your reaction to finding out that they were able to ‘get by’ without doing as much work as you?  If you are like most people, you were a bit disappointed in the person responsible for managing  / leading that task.

It’s very difficult for any person to maintain a positive attitude and love what they do if they feel like there are people who aren’t pulling their weight.  If you ensure that all your team members are held accountable for results, and that they must hold you accountable for results, then you’ll have a much happier team.

Conclusion

The three factors listed above will not immediately turn a dis-engaged employee into a happy and engaged one, but they will help you down the road of build a steady foundation for your team.  By trusting your team, holding them accountable and communicating that failure IS an option, you’ll have a team of people who are willing to dig deeper and do a bit more for you and the organization.

Interesting analysis today over on Jeffrey Phillips’ Thinking Faster Blog in an article titled “Productivity Barriers“.

In the article, Phillips discusses a recent newsletter from IFS (an ERP software vendor) that discussed the issues of usability of ERP systems. In the newsletter, IFS relates survey results that tried to, in Phillips’ words, understand:

…how much of a barrier the enterprise software most of us use everyday presents to becoming more productive

The research that IFS presented is quite interesting (click here to read the results on CIO.com). In addition to looking at usability, the research looked at productivity and asked questions around what factors caused a loss in productivity in the organization. The results aren’t surprising…results included things like (not in any order):

• too many emails
• too much work
• lack of clear priorities
• poor IT optimization
• too many meetings

The survey respondents were than asked to supply factors that effected their own productivity and, again, the results aren’t really that surprising…results included things such as unclear objectives, not enough resources, too many meetings, etc etc.

What I found most interesting was Phillips’ take on the root causes of the above issue. He writes:

Unclear objectives/priorities - poor management strategic direction and communication

Too many meetings - poor management skills and time management

Too much work/Lack of resources - downsizing and “doing more with less”

IT not optimized/doesn’t work the way the company works - inflexible technology supporting a business that is required to be flexible and change

So, in my simple analysis, many of the issues related to productivity have to do with clear management direction and communication, and the ability to communicate what’s important. Additionally, in today’s market, flexibility and adaptability are just as important as established processes and operational excellence, but our technology, systems and processes aren’t designed that way.

Jeffrey Phillips’ hits it on the head.

Most problems with productivity today can be traced to a few factors (at least in my experience). These are:

1. Poor Alignment of Information Technology and/or IT Process to the Business goals - If your organization needs to be flexible, don’t put in an inflexible IT system and/or IT process.
2. Reliance on formal IT process - Process is good. Process is necessary. Create process to allow for flexibility, speed and change. Most processes today in the IT world do not follow this mantra. They are created and then their creators expect people to follow them closely with no deviation and no room for change.
3. Poor Communication - Managers need to understand that in order to get the most of their teams, they need to clearly outline the responsibilities and expectations of the people in their teams. Without this clear communications, people will spend time trying to determine what they should be doing and/or who should be doing it.
4. Poor Leadership - with good leadership, an organization can overcome many things. Excellent leaders will overcome poor process (by changing the process), poor alignment (by aligning IT and business), and poor communication (by ensuring communication improves).

Phillips’ analysis of the results of the IFS study were right on the mark….or at least they match up with my own thougths

Heard a wonderful story last week from a developer friend of mine and thought I’d share (with commentary of course!).

He had taken a full-time job at an organization as a Senior .NET developer and was working an average of 55 hours a week for them. He liked the work he was doing but wasn’t too keen on the ‘punch-in/punch-out’ timeclock that they used to track all employees. Nonetheless, he was happy…it was interesting work and good pay.

At the end of his third week there, he decided to head out early one Friday afternoon and get an early start on the weekend. He ‘clocked out’ 1/2 hour early and enjoyed his weekend.

Monday morning comes along and what does he find in his email? A message from his boss stating that he would need to stay an extra 1/2 hour to make up for the previous week. He went to see his boss figuring it might be an automated message from HR but was told that he was expected to work a minimum eight hour day and would need to make up the time.

His response to his boss? A respectful question about the additional 14.5 hours he had worked the previous week and why those hours didn’t make up for early departure the previous week. ‘

The response from his boss is classic ignorance: “we pay you for 8 hours a day…we expect a full 8 hour day from you“. It also shows his ignorance in math…..since when did 0.5 become greater than 14.5 (the number of hours he worked in addition to the 40 hours)?

Needless to say, my friend resigned and is now working as a contractor being paid hourly for the work that he does.

His boss, and the company that he had worked for, were a classic example of the ‘old school’ business management mindset: You must be in your chair for 8 hours a day to do your job. This is so wrong…especially with the research studies that are coming out left and right (see this post and this one).

Timothy Johnson, author of the Carpe Factum blog (great blog…check it out), had an interesting St. Patrick’s Day post titled “The Luck of the Irate” where he talks about the wonderful “hit and run” managers. You know, this managers that step into a situation that they know very little about, offer their opinions and/or bark orders and then leave with the thought that they’ve “solved the problem”.

We all know managers and project managers like this…they don’t wait to find out the details…they barge in and ‘get things done’ but most times they end up confusing the issue and causing more work than needed. I’m a big believer in being hands-off as much as possible and expect my folks to bring up any issues that they need my help with…and it appears that Timothy believes this as well…he writes:

There’s a lot to be said for the finer art of facilitation as opposed to going into a conflict like a bulldozer on a steroid overdose

The “Tao of Project Management Blog” is quoted by Timothy to help make his point about using less of a bulldozer and more of a facilitator:

The wise project manager does not interfere with the work of the team unless all else has failed. Delicate facilitation is the way not sudden intervention. By using a sudden intervention the work of one or more members of the team is cast aside and they will feel violated. The team will be weakened and what may, at the time feel like a victory, is actually a failure.

Managing a team of people requires a lot of skills…being a bulldozer isn’t one of them.

In early March, Mind Hacks had an interesting article titled “Are you experienced? Does it matter?” which adds another wrinkle to my the argument I made in my Experience vs Ability post.

The article, which cites a Time magazine article titled “The Science of Experience“, states that, according to research reported in the Time article:

research has failed to show that experience, on its own, predicts task performance. In other words, old hands often do no better than novices (Reference).

The Time article reports on a study conducted at Florida State University over the last 30 years. This study claims that:

three decades of research into expert performance has shown that experience itself — the raw amount of time you spend pursuing any particular activity, from brain surgery to skiing — can actually hinder your ability to deliver reproducibly superior performance (Reference).

The article quotes Anders Ericsson, author of Cambridge Handbook of Expertise and Expert Performance (2006) as pointing out the following:

rather than mere experience or even raw talent, it is dedicated, slogging, generally solitary exertion — repeatedly practicing the most difficult physical tasks for an athlete, repeatedly performing new and highly intricate computations for a mathematician — that leads to first-rate performance (Reference)

The basic point of the article and the Mind Hacks post was the following: Experience doesn’t guarantee a higher performing employee….it might…but it might not. The performance will come down to how passionate, how committed, and how interested the employee is in constantly pushing themselves. The question now is: how do you quantify these traits when looking to hire?

I still say that innate ability + passion + an interest in constantly learning will bring an extremely high performing employee, and therefore a high performing organization.

Technorati Tags: ability, experience, Florida State University, Mind Hacks, Research, Time

“Don’t let perfect ruin good”

That’s what Harry Beckwith, author of “Selling the Invisible” has to say on the subject. He goes on to say the following:

“You easily can get stalled in the shift from strategy to tactics because you are paralyzed by your desire for excellence”

I see this type of thing all the time in the shift from an ‘idea’ to a ‘plan’ when people get paralyzed by analysis….everyone gets caught up in making the plan perfect (and therefore the realization of the idea) that they don’t actually start anything.

There’s nothing wrong with striving for perfection…but you’ll never reach it so why hold back a project or an idea trying to make it perfect? I say make your plan very good and start executing…you can tweak your plan while executing.  Once you’ve started, you may realize that your original idea was flawed and find a more innovative way to accomplish your goal.

Don’t get caught up in the ‘analysis paralysis’ trap…make a plan that will work, execute on it and then be willing to change at a moments notice. Spend your time (and money) on being more flexible (i.e., agile) rather than crafting the perfect plan.

Technorati Tags: planning, agile, seeking perfection

I just read an interesting article at Tyner Blain titled “Specializing Generalists and the Politics of Agile“that is a good follow up to my “Better to be a Generalist or Expert?“article. An excerpt is:

By staffing a team with people who have an area of expertise, but can do anything, you can maximize the value of each delivery cycle. In our example, where all of the tasks for a release are UI tasks, they can be interchangeably assigned to any of the developers. The UI expert may suggest an implementation approach, do code reviews, or provide guidance to all the other developers. But every developer (including the database guy) can sling code effectively to get the job done. Specializing generalists.

Go read the article…very interesting.

Technorati Tags: Expert, Generalist, Specialist

Jeff Attwood over at Coding Horror wrote a great article titled “The Years of Experience Myth” that everyone should add to their ‘must read’ list.

The article discusses the use of phone screens to in the hiring process (and points to a couple of great articles on the topic) but the point of the article pertains to the trap of trying to be overly specific in your hiring.

Jeff writes about the myth of ‘years of experience’ and how many organizations fall into the trap of trying to hire the perfect person. You know the job descriptions that require “7 years experience in J2EE in a manufacaturing environment”. An excerpt from the article is:

This toxic, counterproductive years of experience myth has permeated the software industry for as long as I can remember. Imagine how many brilliant software engineers companies are missing out on because they are completely obsessed with finding people who match– exactly and to the letter– some highly specific laundry list of skills.

Somehow, they’ve forgetten that what software developers do best is learn. Employers should be loooking for passionate, driven, flexible self-educators who have a proven ability to code in whatever language — and serving them up interesting projects they can engage with.

Emphasis mine.

Jeff’s article discusses software engineers specifically but this same issue can be found in any technical area and many other areas. I’ve talked with recruiters and organizations are filter out way too many excellent candidates. For example, the “7 years in J2EE in Manufacturing environment” sample I gave earlier is one that I saw while searching indeed.com (great site btw) for this post. What does someone with 7 years in experience know that someone with 6 years experience doesn’t? Does it really matter that the J2EE experience come from the manufacturing environment?

I’m of the mindset that you hire the best person you can regardless of the number of years of experience that they have. I’m not convinced that someone with 20 years experience is a better hire than someone with 2 years. I’d rather hire the person that will get the job done. As Jeff writes:

Employers should be looking for passionate, driven, flexible self-educators who have a proven ability

Absolutely.

Next time you go to hire someone…look at what they can do and what they have the potential to do; not what they may have done in the past.

Technorati Tags: Hiring, Experience vs ability, Coding Horror, Human Resources, Management

This post is a follow up to my post titled “Employee Onboarding“.

Research reported on a recent Management Issues article titled “How to lose half your hires within a year” provides a bit more insight into the Employee Onboarding problem in the US. They report (bolded text is my emphasis):

A study by consultancy Novations has found a third of employers report that a quarter of their new hires leave within the first year, while more than a fifth carelessly lose nearly half of their recruits within the same timeframe.

The research, reported by SHRM Online, the website for the Society for Human Resource Management, found fewer than half of employers have a structured programme to help new recruits settle in, or “onboarding” as it is called.

Under a third of employers train their hiring managers in onboarding techniqures, with 15 per cent even leaving it up to their hiring managers to sort out all the paperwork.

Similarly, fewer than half give candidates a realistic job preview or provide interviewers with tools to help them evaluate a candidate’s skills.

While six out of 10 do follow a structured selection process, just 46 per cent establish objective hiring criteria for all open positions.

Can you imagine?

How much money is wasted every year by organizations by selecting employees and then just ‘throwing them to the sharks’.

You can read the SHRM article on this research at “Many Employers Admit They ‘Wing’ Support of New Hires“. Some other interesting stats from the research report are:

• 57 percent of all those surveyed have never had a performance review, or, if they did have a review, they found it neutral or not useful.
• 79 percent don’t receive career mentoring.
• Only 12 percent said their employer offers them a career path plan.

Other articles you may find interesting:

• The Hiring Challenges
• Blaine Collins on New Team Members
• Organizational Culture
• Follow-up to Organizational Culture

Technorati Tags: Organizaitons, Hiring Challenges, Employee Onboarding, Onboarding, Culture