Top 5 Skills & Practices You Need to be a Good Project Manager

Project Management in an agency is a difficult role to prepare for. You need to balance keeping customers happy while making sure that you aren't overpraising, potentially compromising the budget and timeline of a project. Over the years of working with great project managers I have taken note of the following skills and practices that are critical to success as a PM:

  1. Be Good at Saying No
  2. Know Thy Budget
  3. Buffer Your Estimates
  4. Give the Customers the Bad News Quickly
  5. Learn about Process

1. Be Good at Saying No

The most important skill that a successful Project Manager needs is the ability to say no gracefully. The template for a graceful no, is beautifully described in the book The Power of a Positive No. In the book, it's framed as a respectful and principled no, with a redirection to a positive alternative. This requires sincerely listening and empathizing without caving to your customers wishes if you can't make them a reality. Ultimately making promises that can't be kept does no one any good.

2. Know Thy Budget

Knowing where the budget of your project is when compared to your estimates is critical. Close-to-real-time time tracking is essential here (we use and love Harvest) as is competence using a spreadsheet program like Excel. That said, your spreadsheets should be very simple - meaning both easy to read and easy to maintain. My favorite is a simple sheet that loos like this:

Estimated (Hours) Spent (Hours) Task/Feature
2 3 Planning & documentation (10%)
16 3 HTML+CSS
2.5 0 Quality Assurance (15%)
4 0 Deployment/Hand-off
4 1 Project Management & Meetings (15%)
28.5 6 TOTAL

A spreadsheet like this tells you a few critical things:

  1. How much time you have remaining per task
  2. Where your overage is
  3. How much time you have remaining on the project

If your spreadsheets have a delta (Δ) symbol in them or require more than 30 seconds to explain, they are too complex. From what I've seen this is directly the opposite of what is taught in the PMP program. As near as I have been able to tell, the PMP is at best meaningless and quite possibly is counter productive.

3. Buffer Your Estimates

Things almost never go according to plan, don't assume that your projects will. All of your estimates presented to a customer should always account for planning, quality assurance time, deployment time and project management time. I generally use the percentages outlined above. Once that's included any calendar time committed to should be ~150% of the man-hours required. This means a 40 hour task should be budgeted at least 60 work hours. Give people the chance to make mistakes, get sick and go on vacation without ruining your chances to deliver on time. Don't assume that you'll be able to throw more people on a project and/or work weekends to make something happen - this practice almost always leads to burning out your workers. For more information on this and why it should be avoided, the seminal book the Mythical Man-Month is absolutely required reading for any aspiring project manager.

4. Give the Customers the Bad News Quickly

If you have bad news on a project, and you've already gone through contingency planning internally, tell your customer as soon as you can. Whether it's a budget overrun or a calendar delay the sooner the customer finds out about it the better off they are. In a best case scenario the customer may be able to come up with a solution you haven't thought of and in a worst-case you want to give them as much time as possible - even if that means finding another company to do the work. Trust and open lines of communication are more important than any single missed deliverable.

5. Learn about Process

Process is not a silver bullet, and strict adherence to a (or worse the) process is a recipe for frustration for both your customers and your workers. That said, every process you are familiar with puts certain tools in your arsenal. In the web development world some of the best books on process that I have read are Extreme Programming Pocket Guide (a quick read) and Agile Software Development (an epic read). These are far from the only ones and if you are passionate about your job (or future job) every book on process you read will give you more tools to bring to bear. Some approaches/methodologies to be aware of include:

  • Scrum (Agile)
  • eXtreme Programming (Agile)
  • Waterfall

Recommended Reading

Comments

The Mythical Man-Month was required reading in my undergrad program. There are some interesting essays at the end of the anniversary edition where Brooks reflects on what he got wrong or what has changed in the intervening years. Another interesting one is Spolsky's Joel on Software. It's a bit more from the programming perspective, but there are some ideas around project management.

The toughest challenge I've had is defending the idea of a buffer on estimates and enforcing the idea that an estimate is not the same thing as a commitment. There's often a strong push from sales to produce smaller, fixed numbers. I'd love to hear someone else's ideas on that.

Shannon - the best support I've found for defending the buffer is simply pointing out that people will inevitably:

  • Get sick
  • Go on vacation
  • Make mistakes

Undoubtedly there will also be new things that are uncovered that will affect scope/timeline but it's a much tougher argument to try to poke holes in an established plan (you don't know, what you don't know). Nobody can argue with the above three reasons.

I see two kinds of buffering. One is schedule buffering; people getting sick and going on vacation fall into that one. That one is simple since it doesn't translate into time a client pays for.

The second is cost buffering; mistakes and general uncertainty fall into that category. This one does get argued about. The people who are involved in the doing of the work have a tacit understanding of why it's necessary. But salespeople often aren't involved in the doing, and they have a hard time coming to terms with it being necessary.

Granted, I'm describing an organizational dysfunction, but I think it's common.

Some of the problem may stem from the cultural shift from waterfall to agile methodologies and how they deal with estimation. The question waterfall asks is "When will it get done?" or "How much will it cost?" whereas the agile methodologies ask "What can be done by MM-DD-YYYY?" or "What can be done for $X?" That's a change in thinking that's only subtle on the surface.

Getting salespeople to say no is another cultural shift. I'm not sure how to empower project managers in situations where a company has sold X for $Y before they've even had a chance to say no.

I just got a copy of the William Ury book you recommended and am looking forward to reading his discussion on the topic.

One of the line-items I didn't include above is the Change Order Budget, which can be a handy way to ask for new funds. A lot of the time, going back to ask for more money once a project is already running can be very difficult, but things always change. The best way I've found to handle covering that flux is a Change Order Budget, built in as an overall percentage of the entire project somewhere between 5% to 25% (or more) based on the amount of flux you anticipate.

This change order should be kept out of the initial billable milestones, and be exercised only as needed. But it also allows the customer to ask for/plan for an appropriate amount.

Add new comment

Restricted HTML

  • Allowed HTML tags: <a href hreflang> <em> <strong> <cite> <blockquote cite> <code> <ul type> <ol start type> <li> <dl> <dt> <dd> <h2 id> <h3 id> <h4 id> <h5 id> <h6 id>
  • You can enable syntax highlighting of source code with the following tags: <code>, <blockcode>, <cpp>, <java>, <php>. The supported tag styles are: <foo>, [foo].
  • Web page addresses and email addresses turn into links automatically.
  • Lines and paragraphs break automatically.

About the Author

Joaquin Lippincott, CEO

Joaquin is a 20+ year technology veteran helping to lead businesses in the move to the Cloud. He frequently speaks on panels about the future of tech ranging from IoT and Machine Learning to the latest innovation in the entertainment industry.  He has helped to modernize software for industry leaders like Sony, Daimler, Intel, the Golden Globes, Siemens Wind Power, ABC, NBC, DC Comics, Warner Brothers & the Linux Foundation.

As the CEO and Founder of Metal Toad, an AWS Advanced Consulting Partner, his primary job is to "get the right people in the room".  This one responsibility is cross-functional and includes both external business development functions as well as internal delegation and leadership development.

A UCLA alumni, he also serves in the community as a Board Member for the Los Angeles Area Chamber of Commerce, the Beverly Hills Chamber of Commerce, and Stand for Children Oregon - a public education political advocacy group. As an outspoken advocate for entry-level job creation in tech he helped found the non-profit, P4TH, an organization dedicated to increasing the number of entry-level jobs in the tech industry, and is in the process of organizing an Advisory Board for the Bixel Exchange, a Los Angeles non-profit that provides almost 200 tech internships every year.

 

Ready for transformation?