.comment-link {margin-left:.6em;}

Uncommon Sense (for Software)

This blog has been moved to www.UncommonSenseForSoftware.com.

Wednesday, November 23, 2005

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.

Monday, November 14, 2005

Trick Question: Could You Manage a Space Shuttle Launch?

A few months ago I spent a couple hours with a project manager who by all accounts, is rather good at her job (I know several people that know her professionally and did some background checking). We were discussing domain (software) specific project management techniques, like tracking Time Estimation Error, Distraction Rates, and keeping requirements in-sync with schedule. As our meeting was ending, she mentioned that someone had asked her a while ago whether or not a good project manager (or a project manager with a good project management methodology) could manage any type of project – like a space shuttle launch. She quickly said yes, because the basic elements are the same in any project. It occurred to me on the drive home that this is not an uncommon belief – that a project is a project is a project...

So – why we are we (the project management discipline at large) so terrible at running software projects specifically? It’s a well known fact that the majority of software projects globally are considered failures (Standish Group’s Chaos Report) – failure being defined as: late, off-spec, and/or over budget. If general purpose project management methodologies aren’t making software projects slam dunks, then either the methodology isn’t all it’s cracked up to be, or there’s something about software projects in particular that continues to trip us up. I say both.

Here’s a trick question. I will read all sorts of things into your answer to this question and tell you about them in a minute: If you were the head of NASA, responsible for choosing the project manager for the next space shuttle launch, and you had 3 candidates to choose from, which would you choose? Here are the candidates:

  1. “Newbie PM (Project Manager)” – has accreditation from a leading project management school; graduated top of class; knows the PMBOK (Project Management Body of Knowledge) like nobody’s business; can quote the process to you word for word; never managed a project.

  2. “General purpose PM” – has accreditation, and has 10 years experience managing all sorts of projects (but never any 2 of the same type); sample projects ranged from: building a new home, a Windows 2003 server rollout, a training program for a new software system in an organization with 10,000 employees, planning a sales conference, etc.

  3. “NASA veteran PM” – has accreditation, 2 years experience managing a variety of projects (similar to candidate #2), but has been managing space shuttle launches for the last 6 years.

Which would you choose? You’d probably want to know their track record too, but for the purpose of this little game, that information is not available. I’d bet dollars to donuts you’d pick #3 – the NASA veteran. But if you also started this article thinking that with a good process you can manage any type of project, then something is at odds – those 2 opinions are inconsistent with each other. If you truly believed that the process was the key, then technically any of those 3 candidates should do fine, because they all have the process down pat (the accreditation). And candidate #2 actually has more years experience overall. Reading between the lines, here’s what I think is going on:

Managing isn’t a true/false binary thing. Of course you can manage any project with any project management methodology, but the real question is: what would your success rate be? If you chose candidate #3, it’s because your instincts told you that experience with that particular type of project (a space shuttle launch) counts for a lot. Most people would intuitively believe that candidate #3 has something above and beyond the other 2 candidates.

Most project management methodologies are general purpose. For whatever reason, they continue to embody the opinion that all projects are the same – and should be managed the same. They are specifically designed to take the human element out of the equation – to say that anyone following the process can manage a project well – it’s the process that counts. For software projects en-mass, this approach clearly isn’t working, as evidenced by the poor success rates.

Today’s project management methodologies are useful for teaching someone the ABC’s of project management. There certainly is a lot of useful stuff to be learned. Unfortunately, there’s also a lot missing. Just like in school, consider that the typical project management accreditation is like a Bachelor’s degree. And we all know how dazzled prospective employers are when we tell them that we have a Bachelor’s degree right? Well, maybe not so much. Current project management methodology is the scholastic equivalent of reading and writing. You may need it, but you only learn the good stuff after you learn to read and write.

The real power (of success) – the advanced stuff - comes from some degree of specialization. If you want to go beyond the basics of project management, and hike up your success rate, you’ve got to focus on a particular type of project. Most of us do at some point in our careers anyway, because the organizations we work for are somewhat specialized: IT, Construction, Legal, whatever. What isn’t typically specialized however, is the methodology we use to manage those different types of projects. Our organizations specialize in some type of business, we specialize in some kind of project, and then we go use a general purpose methodology – no wonder software projects are late most of the time.

Specializing a project management methodology simply means looking for factors that typically affect a certain type of project (example: software projects), and modifying the methodology to account for those factors. (This is another way of saying: leveraging domain specific experience.) For software projects, some of the top factors that throw them off the rails are:

  1. Time estimates are wrong – granted it’s difficult to produce accurate estimates, but few actually try anything more scientific than gut feel estimates, so we haven’t quite exhausted the possibilities here.

  2. Distraction is rampant – software projects are long term (6 to 12 months) by nature, and are planned to have teams work on them near full-time, but the actual amount of time they get to spend on them is typically far less than near full-time; such is the nature of business.

  3. Requirements consistently fall out-of-sync with schedules – we’ve somehow convinced ourselves that we can continue to evolve requirements and designs all the way through the project, but somehow the initial (gut feel) time estimate should stick.

If we know that these are the biggest common factors that throw a particular type of project off the rails, then what have we done to our methodology to account for them? Not much. Typically, most project managers of software projects are still trying to get away with that plain vanilla (“goes with everything”) project management methodology. It’s never going to work. It’s only half the solution.

Veteran project managers that have a high success rate typically use domain specific tips and best practices to run their projects. They’ve developed their own checks and balances to alert them when something is sliding off track. They’ve learned over the years, what the common factors influencing their particular type of projects are, and how to manage them effectively. Mostly, they do it in their head – they rely on experience and intuition to side-step the common pitfalls. For example, a veteran software project manager keeps tight control over requirements and schedule – keeping them constantly synchronized. He or she knows enough to take developer time estimates and pad the heck out of them, because there is typically an error margin with them. He or she also knows that on any v2 of some project, there had better be some time built in to fix bugs from v1, based on experience.

It stands to reason that these domain specific habits of the successful veterans would be of tremendous value to all other project managers in that particular domain. The trouble is, currently, it takes years to develop that experience and success rate. Wouldn’t it be great if this stuff was sharable, given to each newbie project manager in a particular field, and more widely and explicitly adopted? I think it would have a dramatic impact on the software industry’s track record as a whole. In fact, wouldn’t it be great if that acumen, those tips, tricks and experiences were built into your project management tool so that tracking, trending and reporting on all of it was automatic?! (Blatant plug: My company[Devshop.com], still in stealth mode, is working on a solution to this very problem – stay tuned!)

If you want to improve your success rate with project management, specialize. If you’re taking on projects of similar types (all software projects for example), don’t automatically look to more accreditation or general purpose PM methodology for the answer. First look for the patterns that throw your particular type of project off the rails, and manage those factors first.

Wednesday, November 02, 2005

Customers don't buy "solutions", they buy products and services. May the best products and services win.

Several years ago, I remember being enlightened by some Marketing folks about "solution selling". The idea is that there are some strong advantages to elevating the discussion with prospects from simple feature lists and head-on comparisons with other products, to the broader topic of which "solution" is better than the other "solutions". See, a "solution" is fuzzy concept. It's really hard to quantify a solution, or say with certainty that one solution is better than another solution. Unlike feature lists. With feature list comparisons, one product typically comes out quantifiably ahead. Not good if yours is the weaker product. And so for many companies, solution selling became a great way of taking attention away from the feature lists (where they didn't look so good) and also made them feel like they were taking the high road. "Oh, Mr. Customer, feature lists aren't important. Look over here."

Over the years, I allowed myself to be convinced of this tidbit. After many years of working in the enterprise software space, I've come full circle and no longer believe it. Customers don't buy solutions. They buy products and services. The reason they buy products and services instead of solutions is that in the buying cycle, they typically only hook up with a prospective vendor after they've gone through the first few steps:

  • Feeling the pain of some problem

  • Understanding what that problem is in broad strokes

  • Looking around to get at least a light understanding of what some of the categorical solutions may be

  • Choosing the most suitable "category" of solutions

  • Begin researching products and services in that category

For example: If I have the problem of not being able to get everywhere I need to go with the two legs I was given at birth, then I don't start looking around for a "transportation solution". I already know enough about the various categories of transportation options (bikes, cars, buses, motorcycles) to weigh the various pros and cons of each, without ever talking to a vendor. If I settle on the idea of a car, then a bike vendor is going to have a real tough time convincing me I should go with a bike instead of a car. But, I've still got several car vendors and products (and services) to choose from, so there the selling game begins. Either I approach a handful of vendors on my own, or they "pull" me in with various advertisements, cold calls and free x-boxes with the purchase of every new vehicle. By that time, I'm a qualified lead. I'm not so much looking for a conceptual "solution" to my transportation problem, I've already narrowed it down and I'm now looking for a product or service with which I can solve my own problem.

Sales people know that it is way too costly and difficult to "create" demand. They land more sales and get bigger commissions by seeking out prospects that already have demand, and have determined what kind of "solution" they need. They are now at the product (or service) comparison stage. Now it's your product vs. the other guy's.

Besides. If a legitimate business problem is "we can't keep track of each time we interact with a customer", then most businesses figure out on their own that a CRM system is a categorical solution, and then enter the product comparison stage all by their lonesome, without the CRM company having to do too much to convince them that they actually need to keep track of all their customer interactions in the first place. And as further proof, I submit to you: When's the last time you saw a contract or invoice that read: "Ability to keep track of all customer interactions = $50,000". No, but many read:

  • Server license: $10,000

  • User licenses: $30,000

  • End-user training: $5,000

  • Telephone support: $5,000

There we go. They bought products and services. Not a solution. It's the things that appear on the invoice and in the contract that they actually bought. Not what problem they intend to solve with those things.

The reason this is significant is because it informs some strategic decisions for software companies. If you're selling a "solution", you're probably one of those companies that doesn't put a feature list, sticker price, or screen shots of your product on your web-site because you feel it cheapens you. You expect prospects to call you to ask to get a demo from sales rep that's going to hound them until they either buy or tell them to bugger off. I can tell you from experience, droves of possible customers will turn away without going past your front page if there aren't clear links to some or all of those things prominently displayed on page 1. The reason is, they don't need you to tell them what their problem is or what the solution is. Rightly or wrongly, they already believe they know, and now just want to easily compare your product (or service) to someone else's. I really can't see why hiding important information like that is a smart move.

In the last year I've gone looking through several product categories: Project Management software, Content Management software and Web-site Tracking software to name a few. Those companies that thought they were selling me a "solution" to "knowing my Web-site visitors", "creating predictability for my projects", or "consistent customer service" and hid their key feature lists, screen shots and price from me, didn't get more than 5 seconds of my attention. I don't have time to call a sales rep for each of the 20 products I want to have a peak at. Nor do I want to give you permission to keep emailing me or calling me just because I asked you how much your product was or if I could see some screen shots. If all of that kind of information is hidden, then I proceed to assume: it's too expensive, too hard to get started, and I generally won't like the product.

All this to say, put the focus where the customer is going to put it. On the product. What does it do? How does it do it? Is it easy to use? How much does it cost? What's better about it than the competing products? The one exception to this rule is if you're in a space that is so entirely new that consumers in general haven't even figured out that they have a problem yet, or what any possible solution may be. In which case, you've got a lot of education to do before you can sell anything, and I don't envy you.

It's not that I'm advocating your message and materials should only consist of a price and feature list for comparison shoppers. But somewhere in between the two extremes of completely abstract solution selling, and totally comoditized selling of a bag of features, lies a happy medium, where the focus is still on the products that solve the problem. Being "product" (or service) focused with your messaging doesn't just mean you're a list of features and nothing more. In fact, many times, products with less features are better than their bloated competition. The magic is how those features (I prefer capabilities to features) are sewn together in ways that are more useful, valuable or easier to use than the competition. Those things translate into competitive edge.

The funny thing is, I hear from several Marketing folks as they flip through product web-sites, particular technology companies' sites, a snort of contempt: "They're all so product and feature focused. They don't understand solution selling. They need to elevate the discussion." Actually, I think they just know their audience and want to make it real easy for them to make a qualified decision. If your product is weak, then invest in making it stronger - don't go hiding it from plain site behind a lot of abstract "solution" talk. Stand by your product, and at the end of the day, may the best products win.