How project managers should work with support organizations

Inside the nether regions of large companies lurk individuals and offices that are part of executing a project but reside organizationally outside of the project’s chain of command. Placed within the somewhat amorphous group of support organizations are specialists in IT, travel, legal, facilities, HR and many more. A project manager rarely interacts with these individuals, but when their support is needed, there are ways to gain quick efficient help and methods that ensure your request is at the bottom of their to-do list.

Do your homework
If you are new to being a project manager or new to an organization, find out what support organizations are available and what their authority is. A few corporate documents that help are organization charts and the P&P (policy and procedure) or SOP (standard operating procedures) manuals. I know that reading the SOP manuals is no one’s idea of pleasure reading, but at least skim the titles in the table of contents to get an idea of what’s available.  And who knows— they may even be online for reference!

Look at the signatures required on routine forms like travel requests, conference room reservations, document releases, network access requests and presentations. Introduce yourself and your project to the people in those areas.

Before you have to work with the support organization to get something done that has a deadline, find out what information they need from you and their typical processing timeline. Build that into your project schedule.

If in doubt, check with a secretary or admin. You might have thought I was going to say, “see your supervisor or manager”. However, in my experience, the people who best understand how things get done are not higher in your management chain, but rather the office and administration staff.  They are the ones that have to “get it done.”

What to do
Put sufficient time into preparing support service requests and allow them time to respond. Remember the secretary’s motto:

“Your failure to adequately plan does not constitute an emergency for me.”

If possible, walk the papers or send the email yourself. I try to make sure that my dealings with support staff are good and friendly so that they remember me.  Make sure you provide everything the support service needs to do their job. After a reasonable amount of time (an hour or a day, depending), check back. Ask if they need any additional information. Offer to pick up the document or materials rather than wait for the inter-office delivery system. Use both opportunities to get to know the support personnel as people and not functions. In addition, let them get to know you.

When the task is completed—especially if the task was complicated or outside normal business operations—thank them personally for their work on behalf of your project. If the effort was particularly noteworthy, provide a more formal “thank you” to their manager (see organization chart) emphasizing how they helped meet broader organization goals. This not only makes them feel good and part of the team, it will establish a warmer reception for your next support request.  I have been known to drop off a box of doughnuts or candy after someone has really gone the extra mile to help me out.

If something goes wrong—late, incorrect, rejected—leave your ego at the door and try to understand. Offer to help, if possible, or learn from the experience. A Mind Tools article on “Conflict Resolution” suggests the best way to solve a conflict is to keep good relationships a top priority, separate people from problems, and explore options together.

What NOT to do

  • Act as if your project is the only one they have to support.
  • Be an anonymous voice demanding action—see “get to know the support service people”.
  • Try to bully them into cooperating. No matter how high on the org chart you may be or how important your project is to the organization, you do not want the support organizations as enemies.
  • Cop an attitude.
  • Fail to confirm the facts.

Support organizations can help you do your project management job or they can make your life miserable. The ball is in your court. Share your experiences and recommendations on working cooperatively with support organizations in your company via comments.

 

 

The Accidental Project Manager – Part 2

Or, Improving the Perceived Value of Project Management

In Part 1, we talked about how some people end up with the title “project manager”.  It sometimes seems that organizations created the position of project manager so they will have someone to ask about project status and someone to blame when a project goes south. This is sometimes due to project management being seen as a task, not a career or profession. In addition, project managers are rarely part of the greater management team—those who possess knowledge, vision, and skills essential to driving the organization. So why is a function so critical to project and business success trivialized and minimized in the organization?  Or better yet, how do we help project managers become more respected or valued?

"The fault, dear Brutus, is not in our stars, but in ourselves, that we are underlings." (William Shakespeare in Julius Caesar)

A bit of history
In 19th and 20th century business models (think Henry Ford), projects were activities outside of business-as-usual. Projects were managed ad hoc, operated for a short time, and then disbanded. According to Wikipedia on the history of project management, the 1950s marked the beginning of the modern project management as a specialized field with the advent of formal mathematical project-scheduling tools.

As Information Technology matured in the latter half of the 20th century to become profitable businesses, projects became business models in many companies. Perhaps because those who managed IT projects were technically trained rather than business trained, managing projects was deemed a support function rather than a skill essential to success. Companies valued those who brought project dollars in the door more highly than those responsible for executing the project.  As Harold Kerzner states in his book Advanced Project Management, “For almost 35 years project management was viewed as a process that might be nice to have, but not one that was necessary for the survival of the organization.”

How to improve the perception of value
As a reader of Fear No Project, you know I believe strongly that project management can be done well or done badly. Project management is a profession, and businesses that understand, embrace and reward effective project management will do better in the marketplace than those that do not.  So, how does a project manager or project management organization (PMO) improve the over-all corporate perception of its value?

Think like a CEO when you interact with clients, create status reports, ask for resources, make assignments, establish priorities, create benchmarks, monitor expenses:

  • Consider the value of your project in terms of corporate identity and long-range plans. (To the CEO, projects are rarely ends in themselves, but part of a bigger picture.)
  • Understand the importance of risk identification and risk management
  • Work to get new customers and keep existing customers happy
  • Look for and become an advocate for opportunities
  • Think outcome not process (process is what you do, outcome is the result)
  • Solve problems do not present them. In the words of a CEO Curt Finch, “Be an executor and not an academic.”  If you cannot solve the problem, see “Talk like a CFO”.

Talk like a CFO when you create a project budget, present project status, or identify and solve project issues:

  • Know the status of key project tasks at all times
  • Become comfortable assessing costs of labor, time, success, and failure
  • Talk in dollars made, dollars lost, and dollars at risk
  • Evaluate recommendations in terms of ROI (return on investments) and ROA (return on assets)
  • Project costs forward relative to project budget
  • Present possible negative outcomes that might result from failure to follow correct PM processes in terms of tangible costs and intangible impact on reputation

Sell like a Salesman by using data and specifics. Your instincts and intuition—based on years of project experience—may be correct. However, real data talks louder and with more credibility than opinions, no matter how well founded.

  • Use costs and LOE estimates based on previous project experiences
  • Track project costs in terms of actual versus planned costs
  • Apply predictive scheduling to show dependencies and implications of schedule variations
  • Analyze prior project debriefings or lessons learned. Use summary data to backup recommendations or conclusions
  • When presenting opportunities, quantify the risks and benefits of action and inaction
  • Check out Jimmie White’s post “Selling the Value of Project Management”. He references a new report from PMI that promises specific research data on project management value added.

Act like a politician when you engage executives, stakeholders, customers, and other parts of the organization:

  • Know what is important to the person you are talking to
  • Form a relationship with the influencers and decision makers
  • Learn to negotiate in order to be successful

Alright, so you start behaving and performing with these four attributes – what does this do?  It begins a process that shows a huge difference between the accidental project manager and the dedicated professional.  I have always held the belief that if you want to be something, like a vice president or manager, then start behaving like you are one.  And the best way to show an organization the value of a good project manager is to perform.  I am not saying this will be a quick process, but I will bet that when you and all career PMs start behaving and performing this way, your organization will take notice and have a new respect and value for the profession and role.

So what do you think?  Do you face any of these challenges in your organization?  Please leave me a comment or suggestion on how to address the culture of accidental project management.