Raising your Credibility

As a project manager of a software project, one of your biggest responsibilities and greatest challenges will be to make people understand things they don't want to understand and believe things they don't want to believe. You will be fighting a kind of self-hypnosis, where people believe what they want to believe because it's just easier that way. (See also: The Power of Suggestion) This is the hardest kind of convincing. In order to pull it off, you're going to need to have a lot of credibility saved up. Credibility is like money - you earn it today so you can spend it tomorrow. Like with money, you can do things to invest in your credibility that will have bigger credibility payoffs later (a kind of Return on Investment). And of course, nothing builds credibility like a solid track record of delivery. It’s hard to argue with results.

Here are the kinds of beliefs you will have to dispel before you can get your various messages through:

• "Other Co. is pumping out products at twice this rate, why can't we?"


• "The development department has a pool table, so they aren't working hard enough."


• "The developers all wear jeans and rock T-shirts so they don't take their work as seriously as the rest of us."


• "Nothing else the company does takes as long as the software does, so something must be wrong with the way we develop."


• "If we ship it now, we can fix the architecture later."


• “We can’t just freeze all of the requirements for the next 8 months while we build the software. We need to be responsive to the market.”

Here's the strangest factor you’ll be battling: The very people that claim development takes way too long and is always late are the very people that will try to beat you up to lower your time estimates and cut any buffer time you put into the schedule (and thus jeopardize the project’s chance of success). Some of your stakeholders will be Sales people – professional negotiators. When they convince you to strip your buffers from the schedule and lower your time estimates, they believe they’ve won something. Go figure.

One approach to dispelling these development myths would be to arm you with various well written explanations and superbly logical arguments as to why they are false. In my experience, that doesn’t work. The truth is the very nature of software development starts you off with a negative credibility balance:

1. The net productivity difference (all-in) between a good developer and an average one can be as much as 10 times (various organizations have studied this), so attracting the “good” ones is very important


2. Attracting and retaining good developers is a highly competitive business, so perks like a casual (comfortable) work environment, good pay, stock options and flexible work hours are thrown in to sweeten the deal


3. Developers typically love their jobs, so even when the pressure mounts, they may not show the stress cracks as much as someone who is equally pressured but doesn’t love their job quite as much

Add to the mix the fact that most development projects (even some of your own) have been late or troubled, and you don’t have a lot of credibility to begin with. Because of these software development realities, you as a leader need to be on top of your game to counter the negative perception of the nature of software development. If you want to convince one of your stakeholders of something unintuitive, you need to be the pinnacle of professionalism with credibility to boot.

Here are the things I’ve found that build credibility and help you get your message through without falling into the trap of arguing about how hard the developers work, whether or not shirts and ties make you more professional or why attracting and retaining top-notch developers is in the company’s best interest, compared to another type of employee:

1. You need to deliver. You need to keep your word. When you say you’re going to be done in 6 months, it is critical that you are. If you succeed, the next time you need to convince someone of something counter-intuitive, you’ll have more credibility in the bank, so it will be easier. If you fail, the next time will be even harder. It’s a cumulative thing. Each success or failure affects your credibility balance.


2. In order to deliver, you need to protect your schedules. I call it Risk Management and it’s your #1 job as a software project manager. Since statistically most software projects fail (70%), you’re inherently on the defensive anyway, so you need to think like everything is a possible risk. One of the best techniques you can use to protect the schedule is to build-in time for all of the things that typically throw software projects off the rails. Things like: Time Estimation Error, Distraction Rates, Overhead, Requirements Churn, etc.


3. In order to protect your schedule and the “padding” you’ve put in, you’re going to need a solid rationale as to why that particular % of time was chosen, and what factors you’re padding for. Otherwise, when you go up against a professional negotiator (like a Sales person), you’re going to walk away having been talked out of your padding. And while simply “refusing to give in” is better at protecting the schedule than giving-in, being able to convincingly articulate what you’ve padded for and why you chose the amounts you did is even better. It protects the schedule and builds your credibility at the same time.


4. Never use your “gut” as an unsubstantiated argument. You can talk about how good your instincts were after-the-fact, but it’s not very convincing up-front unless you already have a huge credibility balance. While I’m a big believer in using your instincts as one of the data points in decision making, it’s best to figure out a way to prove or disprove them anyway. If you disprove a gut instinct, you save yourself a costly mistake. If you prove it, you gain more credibility anyway, so it’s a win-win.


5. Be an obsessive note taker. Most people don’t do this. It takes discipline to get in the habit. In the moment, it’s hard to know which decisions or facts you’re going to need as corroborating evidence later, so write them all down. Any time you can point to written historical evidence of decisions that were made, when, and by whom, you’re going to have a psychological advantage in getting your point across. People regularly (and conveniently) forget how often they’ve changed their minds on their priorities, or a feature list.


6. Use metrics. Figure out what metrics you think are important for your type of project and track them. Whether it’s the rate of change for requirements, or how often time estimates are wrong (and you are therefore padding for that fact), nothing backs up padding in the schedule like stats. It’s hard to argue that a 30% buffer in the schedule is too much when you can point to statistical proof that developer time estimates are off by 30% on average, over time.

Hopefully some of these tips will help you incrementally increase your credibility balances. Unfortunately there’s no overnight solution, but with discipline and a structured approach, you can do it.

If anyone has any other tips or tricks on the subject, I’d love to hear about them. Please post a comment.