Five Tips For Working With a Company’s Personality

There’s a lot of discussion nowadays about company culture, core values, and mission statements.  While there can be a cynical tendency to treat these as checklist items of a management fad, I think there’s really something there.  Companies do have personalities, and if you can read them correctly, you can predict how a company will make decisions or respond to challenges, and at the very least instruct you on the sort of questions they will ask.

It’s not always so simple, however.  Understanding a company’s personality and adjusting to it for project success is a continuous effort of analysis and interaction.

At one client of mine, the project’s objective was (in my words) attempting to make Microsoft SharePoint work like Facebook.  I thought I was doing a great job to question this immediately, as it sounded like a really bad idea.  Why do this? I asked.  Why not call up Facebook and try to buy a private instance?

I was told that the client had a strong bias towards building things themselves – this was the company’s personality.  As a consequence, I was told to simply drop the question.  So we built a prototype that tried to twist SharePoint into uncomfortable shapes, and given that it was the sort of project that should never have been attempted, I think we did a pretty good job.  The client?  The client was ultimately dissatisfied and proceeded to look for a product to buy.

So what happened?  We thought we understood the company’s personality, and maybe we were right.  In the end, though, they did exactly what we thought they wouldn’t do.  What could we have done differently?

I think there were several factors at play here.

First, we may have simply been wrong about the company’s personality.  That assessment was handed to me by someone else on my second day with the company, and I had no information to make that assessment myself.

Second, right or wrong about their personality, I shouldn’t have let myself be warned off when I asked the question initially.  I should have taken that up with the project stakeholders to hear their thoughts on it.

Third, it’s always possible that the only way the company was going to realize the need to purchase a solution was to see how difficult it was to build something custom.  From that perspective, our prototype was valuable: we helped them get to a conclusion they would not have reached on their own.

In short, having been alerted to the company’s personality, I should have confronted it and talked about it.  Leaving it unspoken – and assuming that we understood the personality and its consequences for the project – simply led to frustration.

So what are the steps to engaging with a company with full recognition of its personality and culture?

1. Be aware of the company’s personality, but constantly test your assumptions to improve your understanding.
2. Be open with your client about the tendencies you see. Ask questions about how to modify your project’s approach and communications to fit the client.
3. Understand when your project will be in conflict with the company culture and prepare for it. Sometimes you’ll have to challenge it, and the case you make will have to be extra strong.
4. Work to the strong suits of the company culture. A company’s personality will have positive attributes you can leverage to your project’s advantage.
5. Be respectful of the company’s culture and personality. You may have to challenge it for your project, but you don’t have to be adversarial when you do.  And you’re definitely not going to be able to change it.

This recognition, respect, and collaboration can all lead to a more positive project experience and build to project success.

This is an edited excerpt from my book, Project Leader to Project Believer.

Advertisement

The Mail Must Go Through

We talk a lot these days about corporate cultures.  Mostly it’s because we focus on how, as a person and employee, we fit into the company, and whether we share its values.  This is certainly important, but there’s another dimension to this: how does a company culture impact its projects?

Some years ago I was working a for a major international overnight delivery service.  When I worked there I learned that they had gone through different cultural phases, such as one where information technology was valued, for example.  The dominant theme in my time there was successful delivery at any cost.

Remember the movie “Castaway” with Tom Hanks, and how his character is fixated on time and keeps himself sane by keeping a package safe until he can deliver it himself?  Those were certainly the values of my client.  I heard many times about how they made a special flight to deliver medicine to a sick little girl.  Regional managers had to have complete discretion in order to ensure that deliveries were made.  Nobody wanted to be the guy who stopped medicine from getting to that sick little girl.

Those values came into play on my project.  We were planning the implementation of a procurement system, but we were taking a holistic view of it: people, process, and technology all had to be aligned.

In the process area, we spent a lot of time assessing process best practices in procurement and how they could assist the client.

A significant case in point was spending limits: how much money could somebody spend before a manager or someone else had to approve it?  I forget exactly what the spending limit was when we got there, but was on the order of thousands of dollars each, regardless of who the employee was.  This meant that, any given time, the collective employees could commit the company to hundreds of millions of dollars of expense with no approval by anyone.  Naturally, we put together a standard signing limit table: the average employee could to spend up to $250 without approval, a supervisor could spent $1500 or so, and so on.

When we presented these ideas, however, we got no response.  Eventually we were able to extract an explanation.  If that spending limit meant a part couldn’t get purchased to fix the truck to make a delivery on time, it wouldn’t be acceptable.  No one was willing to take any part of that risk.

The technical side of the equation was equally frustrating.  Part of the planned system implementation was PeopleSoft, which was especially noted at the time for its vast configurability.  Any business rule, any business function, could be configured to suit the company’s needs.

We explained this to our client, but kept getting the same confusing response.  How does it work? they would ask.  How does the system say it has to work?

You can configure it, we kept saying.  How do you want it to work?

Eventually we figured out what was going on.  Our team members weren’t dumb.  They were well aware that no limitations could be put into the business process that would conflict with the power of a regional manager.  If the system could be configured, it could be configured with any parameters desired.  They would have to go ask people what those parameters should be.  The explanation would reveal the broad capabilities of configuration that were available, and then all hell would break loose.  The loosest possible business rules would be demanded.  Anything to provide ultimate flexibility when a package needed to be delivered.

To solve that, our team wanted to tell everyone that it wasn’t configurable at all.  They wanted the system to dictate all the process best practices we were discussing, so they would never have to deal with the demands for flexibility, which they knew would ultimately undermine the whole project.

There’s more to the story of that project, but in the end, the big, high-impact vision we had for the project was simply unattainable.  All because of a company’s culture.

Are You a Project Manager, or a Project Leader?

Project management is big business.  Every day, there are thousands of companies around the world trying to get things done.  When they want to do something differently, they create a project to do it.  And once they have a project, they need to manage it.

The Project Management Institute is just one of the many authorities advising would-be project managers on what to do and how to do it.  You could fill a library and a good part of a warehouse with guides, manuals, and methodologies for project management.

Virtually all of them will tell you that a project needs to have a project charter, a project schedule, an issue log, a risk log, a project governance structure, and so on and so forth.  Furthermore, there’s metadata about the project.  What methodology is it using?  What tool will be used for documenting the project schedule?  How will progress be tracked and reported?

Driving all of these tasks – managing them, if you will – is the job of the project manager.

What is commonly not the job of the project manager?  Surprisingly to some – but not to others – the project manager is often not responsible for the actual delivery of the project objectives.

In many organizations, the project manager is an administrator.  Better ones will be proactive and vocal, asking for status on deliverables before the day they’re due, discussing issues before they’ve turned into burning oil platforms.  But, as I often call them, they are professional nags.  Everyone else is busy actually getting something done, and they’re making sure their PowerPoint slides look good for the Steering Committee.

No wonder that in some organizations, project managers get very little respect.

And no wonder that in many organizations, they also get very little accomplished.

I worked with someone whose project management mantra was “Projects get behind a minute at a time, a day at a time.”  His point was that a project manager has to be on top of things every single moment, because once you’ve let something slip, the time’s gone.  You’ll never get back the half a day that you lost because someone’s computer went down or a key business contact was out sick.

I’ll concede that there’s a basic point there.  You almost never make up time on a project.  If you’re late getting to your first milestone, you can safely push them all back.

I found this mantra tremendously annoying, however.  First, it demanded an intensified experience as a project nag.  Simply thinking in terms of human communication, there’s a limit to how often and how rigorously you can ask people to provide updates on what they’re doing.  Ask enough times, you can be sure you’re going to get evasions, estimates, and outright lies.  Anything to get rid of you.

Second of all, it oversimplifies why projects are late, and suggests that every problem is either avoidable with proper foresight or fixable within its original timeframe.

Project management is about planning, predictions, and mitigations.  I may sound critical of it, but there is no question that sound project management is key to project success.

Project leadership, on the other hand, is about owning the outcome and working with everyone involved to deliver it.

A project can be well run, knock off all its project management artifacts, produce its deliverables, come in on time and under budget, and still be a failure.  That’s what happens – best case scenario – when there is no leadership.

Here are some more specific ways in which a project leader differs from a project manager:

• A project manager accepts resources as provided. A project leader constantly reviews project resources needed for project success.
• A project manager accepts the project structure provided. A project leader constantly reviews the project structure for project success.
• A project manager drives administrative completion of standard project management tasks. A project leader selects standard project management tasks as tools to enable delivery success.
• A project manager focuses on project management deliverables. A project leader focuses on the delivery of the business outcome, regardless of the source of issues or solutions.
• A project manager supports team delivery of a business outcome. A project leader collaborates on achievement of a business outcome.

In short, a project leader:

• Is engaged with the team
• Is engaged with the project sponsor and shares ownership of project outcomes
• Takes personal responsibility for project success

Nine Communication Tips for Project Leaders

As a project leader, communication is a tool, an objective, and a key determiner of success.  Here are some tips for leadership-oriented communication.

*             360 degrees communication.  It’s as important to communicate downward as upwards; and don’t forget laterally, either.  Some companies very much have a personality where people only want to communicate upwards so they can impress their boss.  If that’s what your team sees you do, it sends a message that they’re not very important to you.

*             Make communication important – schedule it.  Communication within a team, or between team members, is always important.  Prove it by putting it on the schedule.  Set up time to meet one on one with your team members so you can hear their concerns and ideas.  Not only do people like to be heard, you may see a number of other benefits from this less formal communication.

*             Make respectful choices.  How often have you had a meeting planned with your boss or your client, and had them cancel your discussion in order to have another one?  How did that make you feel?  While you might have accepted it happening once or twice, by the third time that happened, you probably felt like you weren’t very important.  That’s not a trust-building event.

As a project leader, you won’t always be able to avoid scheduling conflicts.  It’s what you do next that’s important.  Apologize.  Don’t assume this had no impact on your the person you were supposed to meet with.  Make it up to them by letting them set the time for the replacement.  Show that you consider their time to be as valuable as yours.

*             Make up your own mind; don’t use somebody else’s.  Quite often you’ll get advance warning about somebody you’ll be working with.  Maybe it’s a team member who isn’t a good performer.  Maybe it’s a thoughtless boss or a confused client.  It might seem wise to use any intelligence like that to prepare yourself for a rough time of it.

I’d agree with preparing yourself, but in a different way.  Try to put yourself in their shoes.  Think about how you can communicate with them to establish your own relationship with this person, rather than re-living someone else’s.

*             Don’t avoid communication.  The fact of the matter is, you don’t get to be choosy about who you communicate with.  If someone’s connected to your project and its success, you’re going to have to work with them.  When you avoid someone, you lose all the benefits of communication.  What’s worse, they may notice that you’re not talking to them.  Are you hiding something?  Does your avoidance mean something?  Maybe they’ll decide they shouldn’t like you, either.

As a project leader, you should push yourself to seek out communication in a case like this.  Try to learn more about the person.  Make sure you listen to them.  Make sure the lines of communication are open.

*             Set expectations on communications.  When you join a project, you should establish expectations around communication.

For example, every time I start a project I discuss communications with my boss or primary stakeholder.  Should we have a regular time to meet?  How often do they want to receive communications from me?  What form should our communications or interactions take?  I’m not only trying to make it as clear as possible that communication is important to me.  Every part of the message is that I will communicate in the way they meets their preferences.  I want them to consciously set their expectations of our communications.

You can do that within a team, too.  Do you expect team leads to meet with each of their team members regularly?  How about with their whole team?  How about the team leads together?  Set expectations on communications and follow up to see how it’s working for your team.

*             Watch the non-verbal communication.  Things such as tone and posture are known issues with communications.  Your words say one thing, your body says another.  This is difficult to observe in yourself, but worth paying attention to.  You might ask for feedback on this from someone you trust.

Suppose you go to someone’s desk to talk to them.  You’ve asked them if they have a moment to talk, and they said yes.  Now you’re talking, but they’re still looking at a computer screen or their phone.  What message are you getting from that?

Sometimes the sentence you say means one thing, but your words sent a different message.  For example, you can say, “I really need that report on my desk by noon; is there anything you need to help make that happen?”  Or you can say, “Get that report on my desk by noon.  I don’t care what you have to do.”

Another sub-message lies in courtesy words.  Does a person say “please” and “thank you”?  It may sound unimportant, and often it is – right up until the moment you notice that a person never thanks you for anything.  It’s not just me.  Say “please”, “thank you”, and “how are you” – and mean it – and watch how positively people respond to you.

*             Don’t draw attention to something by ignoring it.  Remember what I was saying about how much context people have to filter your communications?  Here’s a classic: people notice when you’re not saying something.

Imagine you’ve got a situation on your project.  Someone’s not being a good performer and there’s been a lot of drama.  It’s starting to impact the team, as the gossip is overwhelming productive work.  Will the person quit?  Will they be fired or reassigned?  You have a meeting to discuss project plans and you completely avoid the topic.  You probably thought that you’d rather not distract the team with a topic that you really can’t discuss with them, but now you’ve got even more questions to answer.

*             The medium is the message.  Learn what tools people like to communicate with, and use them.  Your stakeholders may use email, your teammates use the instant messaging tool which came installed on the company laptops, and your incredibly hip development team uses an esoteric web forum full of macros and in-jokes.  You may want to set a project standard for some kinds of communication, if only to make sure that not every sub-team has its own and you can never find anybody online, but you need to recognize that the tools people use are part of their personal identity.

As with every other part of project leadership, you need to make communication a conscious action and demonstrate its value by example.  Everything you say or do can have meaning to your team, and you want them to get the best message every time.

(This is an edited excerpt from a draft of a book I’m currently writing about project leadership.)