Tag: Skills

HR professionals and headhunters classify skills into two categories, hard skills and soft skills.  “Hard” skills are easier to define because they apply to a specific function  – computer programming, database management, driving a truck, piloting a plane, designing a house or office building (architect), building a cabinet (carpenter) or wiring a building (electrician).

Soft skills, on the other hand, embrace all the interpersonal relationships vital to selling a company’s products or services. In the past, many organizations considered hard skills more important than soft ones when considering job candidates.  While an IT or engineering company may initially put more weight on technical skills when evaluating job candidates, they look for candidates who have both. They’re ultimately the most valuable because they have the potential to go the furthest.

People Skills Open Career Doors

The quality of interpersonal or people skills is one of the important reasons rank-and-file employees are promoted to management positions,” according to John Agno, an Ann Arbor, Mich.-based executive coach and career counselor. “As they move up the organizational ladder people skills become even more important. “Executives are promoted for their abilities to ‘bring in the numbers,’ take tough stands and create strategic plans,” says Agno, “But when they bomb, it is usually because of poor or mediocre people skills.”

To improve people skills, Agno offers four tips:

1. Learn to Conduct Productive Conversations. Comfortable people skills open the door for easygoing conversation, says Agno. Excellent rapport between people is built through conversation. Initially, conversation may be hard to start. That’s why it’s important not to think about the structure of a conversation, “Be open to conversations that you are unprepared for. Focus on the interests of the other person rather than your own. And look for opportunities to ask non-threatening questions.”

   “It may seem awkward at first, but it sets the stage for a respectful exchange,” Agno adds. Good decisions are usually made when the right questions are asked.

   And don’t let anxiety or tension stand in your way.  It’s normal to be nervous when interacting with people for the first time. Most people mistakenly dwell on discomfort, failing to realize that the other person is nervous as well.  So take it as a given and use small talk (the weather, the economy, sports) as a bridge to relaxed and comfortable rapport.

2. Read Body Language. Successful salespeople have learned how to get a reading on people based upon their facial expressions, gestures, posture and eye contact. Once they read the body signals in others, they can apply it to themselves. A relaxed expression and constant eye contact communicate a sense of self-confidence and poise that relax the person you’re dealing with, making it easier to sell a product or rally support for a position.

3. Seek Feedback and Criticism. It takes time and hard work to build strong people skills. Learning can only take place if you’re constantly seeking feedback and criticism.  Open yourself up to the notion of lifelong learning and bettering yourself.

4. Master Listening. Masterful communicators have learned that building a comfortable rapport is finding the divine balance between speaking and listening. Most people are too intent on speaking. They don’t realize that the only way to get a true reading on another person is to listen to what they have to say. It sounds obvious. But listening often involves learning how to be silent and waiting for the other person to express his viewpoint. Silence often opens the door to active, fruitful conversation. In time, you’ll learn to be an empathetic listener.

A number of years ago I was privileged enough to listen to Ken Mattingly give a keynote address to a room full of project managers.  If his name doesn’t ring a bell, think of the movie Apollo 13.  Ken Mattingly was the astronaut played by Gary Sinise who had to stay behind because they were sure he would get the measles while enroute to the moon.  Mattingly is now Rear Admiral Mattingly and I was eager to hear what he had to say about project management.  When he opened the floor for questions, someone asked him if he could give his definition of project management.

“Sure,” he replied.  “Project management is doing a specific thing within a specific time with insufficient resources.”  We all laughed but I scribbled it down.

It’s almost universally true.  After all, if you had more than enough resources and unlimited time, who would need project managers or project management?  Lots and lots and lots of people would work on the project until it was done whenever that was. 

Everywhere I go, project resources are overloaded and project managers struggle to allocate those resources on the work that they have committed to accomplish.

In a multi-project, matrix organization, everyone wants their project to be selected and approved.  In a 2006 survey done by UMT for Microsoft, the majority of organizations polled reported that they selected projects for approval based on their individual merits only rather than comparing them against the merits of other projects.  In fact, this method was more than 50% more popular than any other answer.

Not only do project sponsors want their projects approved, but once they’re approved, they want them to be done first, as the highest priority, before any other project is undertaken.

That is a lot of pressure towards a resource management crisis. You can see the result below

I see this picture all the time at the clients I visit and when you’re as used to it as I am, it doesn’t take too long to interpret.  The blue bars represent resource capacity.  The red bars represent resource requirement.  In any period where the red bars exceed the blue bars, the resources are overloaded.  In this example which would be taken at the beginning of January and looking forward to the next 12 months, the resources are overloaded in January through June.  Then the resources are underloaded from July through the end of the year.  If we look for a moment or two longer at the height of the bars, we can see that the requirements in January through April are overloaded by about 300%. 

This is not going to be fixed with a little overtime and some elbow grease.  This overload is unfixable.  It was caused by starting too many projects within this period and it’s a fact that they won’t happen when they’re planned.  And yet, if I look at the end of the year, it is clear what will happen here.  The underloaded months will take the projects which are sure to be delayed and by the end of the year, most of this work will be accomplished.

If you’re reading this and saying under your breath “How can that guy see our internal data,” don’t worry.  The good news is, you’re not alone.  The bad news is, you’re not alone.  This is a very common scenario.

Now, it’s clear that the projects which have been pushed into the first half of the year won’t all happen as they were scheduled so what will happen?

1. Management by Emergency.
   This is almost certain.  All the projects underway in the first half of the year are going to be under tremendous pressure.  That pressure is sure to translate to emergency after emergency after emergency.
2. Low Staff Morale
   This is often characterized by high staff turnover, though in the last 18 months or so this has been less prevalent due to the economy.  As a side note, one thing to be cautious about if you are in this situation is that the economy may be postponing staff turnover, even if staff morale is low.  That may make for a big wave of staff changes as the economy improves.
3. Low Productivity
   It’s simply not productive to have priorities change hour by hour or day by day.  Staff are told “Do this.  No, do that.  No, do this other thing.  No, do this again”.  All the change in focus inevitably means loss of focus and less productivity.

Well if it’s that common, it should be easy to fix right?

Fixing this kind of problem is unfortunately easier said than done.  The source of this problem originates at a couple of levels higher that the PMO and can only be fixed there.  Yet project managers have the methodology to fix this.

Now, you may have seen software tools that promote the kind of functionality that will “automatically” resolve resource overload challenges.  Every project portfolio management (PPM) tool has something in this category.  However, no matter what tool you choose, you will need to do the core work with management if you want to solve this dilemma.

Whether or not you choose software to help you fix this problem, here is what you’ll need to do from a process standpoint:

1. If you want to prioritize projects, forget about just giving them a ranking or some number. Doing so just makes all the project sponsors crazy as they argue why their project should be a priority of 75 rather than 92.  Instead, work with senior management so they agree on what business factors affect the importance of projects.  Some examples might include:
   • Return on Investment/Profit (an obvious one for private firms)
   • Project risk (again pretty obvious)
   • Technical competitivWheteness might be a little less obvious
   • Client satisfaction
   • Strategic advantage to the organization
   • Reduction or avoidance of threat to the organization
2. Create a set number of answers for each business factor.   Try to stay away from a score of 1-5 or 1-100 and instead go for a descriptive answer.  It will be much more powerful if you can have the answer correspond to a measurement.  For example, “Improve Customer Satisfaction by 10% as measured by our quarterly customer satisfaction survey
3. Now you’ll need to create a formula that scores the answers from the business factors.  This is where software may be attractive.
4. Finally, you’ll need to weave in the cost of each project.  You can think of cost in almost any denomination so long as all projects are measured the same way.  So, total person-hours or person-days, total dollars or whatever.  This will allow you to create a business factor score/cost calculation so you can determine which projects will give you the biggest bang for the buck. 

Now, if you’re thinking you can do this in isolation and then present it ‘fait accompli’ to management, think again.  Doing so will make you responsible for any project which is not priority number one, and that puts you no better off than you are already. The secret to success in this process is get senior management to define these factors themselves and to agree on the relative responses for each one.  When that happens, the resulting levelled schedule is, by definition, doing the projects that are in the best interests of the organization first.

Project prioritization is often a part of project management that is avoided by senior management, but the impact in a tough economy of avoiding prioritizing can be significant.  That’s why looking at project prioritization now may be timely.  PMOs may find management more receptive than ever to participating in making this kind of process successful.

Don’t forget to leave your comments below

---

Chris Vandersluis is the founder and president of HMS Software based in Montreal, Canada. He has an economics degree from Montreal’s McGill University and over 22 years experience in the automation of project control systems. He is a long-standing member of both the Project Management Institute (PMI) and the American Association of Cost Engineers (AACE) and is the founder of the Montreal Chapter of the Microsoft Project Association. Mr. Vandersluis has been published in numerous publications including Fortune Magazine, Heavy Construction News, the Ivey Business Journal, PMI’s PMNetwork and Computing Canada. Mr. Vandersluis has been part of the Microsoft Enterprise Project Management Partner Advisory Council since 2003. He teaches Advanced Project Management at McGill University’s Executive Institute. He can be reached at [email protected].

You can always spot the project managers who have just received their PMP – they are eager, idealistic, and prone to proclaim at length the necessity for “Change Control” as if it were the cure for all project management evils.  Don’t get me wrong – I am glad that the level of training that new project managers receive is increasing, and I am glad that they are learning that change can derail a project. However, new PMs appear to have a naïve view of how projects work in the real world, and I would like to do my part to correct that.

To start with, there is NO SUCH THING AS CHANGE CONTROL.  Yes, you read that correctly.  The idea that we can control change is a myth.

I’m well into my second decade of being a PMP, and I’ve taught project management for almost as long as that, so I am quite familiar with what PMI tells us in the PMBoK Guide.  The book is filled with the words “change control” with the phrase appearing in most chapters.  Yet, if you read the description of change control, say for example in section 4.3 (Overall Change Control), you’ll see that what they are really talking about is change management. 

Now, I know this sounds picky, but the distinction between the words control and management is very important – the word you use can affect your thinking and drive very different behaviors.

There are many sources of change, some generated from within the project, and some generated from outside the project.  Let’s look at how we should respond to these under normal circumstances.

External changes come from stakeholders and others who are not part of the core project team.  Some examples of external changes could be new government regulations with which we must comply by a certain date or face severe penalties; new corporate leadership with a different vision/strategy for the organization that no longer includes our project, or a competitor beating us to the marketplace with a new product that has more features at a lower cost than the one being produced by our project.  In each of these cases, the project manager (even the project sponsor) will have little control over these changes. The change just happens and we have to learn to adapt to it quickly.

Internal changes come from core project team members.  Sometimes we have a small measure of control over these changes, but other times, we do not.  Examples of internal changes to a project could be a core project team member having to take a sudden medical leave; team members realizing that the product or service that they are producing or modifying is much more complicated than they at first thought; the project sponsor asking for a new feature that was forgotten during the requirements gathering phase of the project; team members suggesting changes that would greatly improve the functionality or performance of the product or service being built, or even design defects uncovered during later testing stages in the project that require the team to go back and redesign a portion of the solution, then rebuild and retest the solution to match the updated design.  Each of these internal changes can also generate significant chaos on a project if they occur without any restraint.

So, realizing that we cannot “control” most of these types of changes, we need to find a way to make sure that unrestricted change does not completely derail any chance of our project meeting its business case.  If we cannot control then we at least must manage.

Change management can be done in a number of ways, and there many tools that have been developed to help.  Traditional approaches to change management are discussed in the PMBok Guide, including having a system of formal, documented procedures that describe how a change will be assessed and approved within the project, usually by a “Change Control Board.”  Other approaches used in agile management methods include having a prioritized list of project scope items that can be easily updated and reprioritized before any iteration of the project, ensuring that the team is always working on the next most important outstanding pieces of work.  Of course, there is usually still a formal signoff of this modified scope list, but the underlying concept that scope will be fluid during the project, and providing formal mechanisms for managing the dynamic scope, are quite useful on high-change projects.

Perhaps the most important difference between “change control” and “change management” is one of attitude.  The term “change control” is often found on projects that are being managed using deterministic planning models such as the ubiquitous “Waterfall Method” – a sequential series of gated phases within which all work must be completed before we can move through the gate to the next phase.  Deterministic models try to create a “perfect plan” and then the rest of the project is spent trying to adhere to the plan.  In fact, most project tracking and control metrics found on these projects are measuring how well the project is doing in relation to the plan.  For example, Earned Value metrics track our variance from plan and use these metrics to try and reforecast the impact of this variance on the project end date and financial spend.

Change management is the term found most often on project managed with empirical methods.  Empirical methods recognize that there are often too many variables on a project for a project manager to control them all.  These methods permit a tolerance range for the variables, and monitor them to ensure that they stay within acceptable boundaries.  In essence, these methods are accepting that there will be ongoing and frequent changes within a project, and that changes are allowed – even encouraged – as change helps the project deliver the optimal level of business value.  Examples of empirical management methods include the agile methods Scrum, Feature-Driven Development, and Lean Development.

Lastly, the attitude of a project manager may be affected by the terminology used.  Change control sets up (at least in new or junior project managers) a confrontational mindset that tends to see project managers trying to stop or discourage change, often to the annoyance of business stakeholders who are trying to adapt to a changing business environment.  More senior managers tend to take a more collaborative approach towards working with the project sponsor in determining how best the project can adapt to new changes. These managers understand that the real game is one of change management not control.

Change can be good – we need change to allow us to incorporate lessons learned from earlier stages in the project; and adapt the scope, timeline and budget of the project to match evolving business needs This ensures that we are delivering the optimum level of value to the project sponsor within our project constraints.  What we need to do is manage the process of how we adapt to the changes to ensure that we are always focused on delivering this optimal level of value.  It is not a perfect science; there is a lot of uncertainty and predicting the perfect answer is not possible. However, there are change management techniques that will allow us to stay responsive to internal and external changes while still keeping the project performing within acceptable parameters. 

As professional managers, we need to understand the range of tools and techniques available to us for both deterministic and empirical project management environments, and to know which ones to use for a given situation.  Our basic project management training, and even the  PMBoK Guide, is lacking in some of this sophistication.  We need to begin teaching the next generation of project managers about how we respond to change in the real world – a management paradigm that works collaboratively, not confrontationally, with project stakeholders.  Remember:  without change, many projects will surely fail.

Don’t forget to leave your comments below