A brief thought on project justification

Posted by Robert Merrill on June 22, 2013 under 100 Words, Business Analysis and Requirements, Estimation, Process Improvement | Be the First to Comment

Another thread on the IIBA® LinkedIn forum, this one called, “Disturbed by seeing a raft of costly projects with no projected ROI – thoughts?” (you might have to be a group member to see it) prompted me to write a reply that I didn’t want to bury in the LinkedIn forums.

The author, Lance Latham, reported that of 32 projects, only 6 had any cost-benefit analysis at all, and 4 of those only looked at the costs of doing the project in different ways. I’m not surprised. Here are some suggested reasons why this is, and a thought on why it’s not a complete disaster.

Fear of being wrong

If I’ll be punished for being wrong, and I know that early estimates of cost and benefit are likely to be wrong, I won’t create them, or I won’t publish them. If I think the project is a good idea, I’ll create just enough supporting documentation to get it funded.

Ranges and probabilities instead of hard numbers

If I’ve never learned, or am not comfortable, working with numbers that I know are imprecise but not meaningless, I will struggle to come up with them, especially if the scope is vaguely defined. And the scope is always vaguely defined at first.

Chicken-and-egg, scope-and-estimate

The very process of refining the scope requires decisions about whether a particular outcome is in scope or not, and that involves some kind of cost-benefit analysis of the thing in question. Or it at least means a guess at the cost of the thing, and a comparison of the uncertain total cost of all the things in my scope basket with a vaguely known budget. (The budget itself is subject to negotiation.) And at this point, the outcome or feature in question is itself only vaguely defined. It’s like a nested Russian doll of chicken-and-egg problems. How do I deal with that?

Organizational natural selection

People who are good at working with nested chicken-and-egg problems using uncertain numbers don’t seem to climb the corporate ladder to the height where they’re approving major projects. Or they lack other traits which are needed to keep from falling (or being pushed) off the ladder. Or they don’t want to climb the ladder at all.

But maybe it’s not the end of the world

If we believe Jonah Lehrer (“How We Decide”),  maybe we shouldn’t be surprised. When analyzing complex decisions, we reach the point of diminishing returns relatively quickly.

Of Latham’s 32 projects, how many were turning out to be not worth the cost (the Ultimate Non-Functional Requirement)? How many projects that were shelved in favor of the 32 would have been winners? How much would additional analysis have helped?

I sometimes advise, but I’ve never ascended to the heights where I approve major projects. But I’ve watched (and been downwind). Here are my impressions.

  1. We do two levels of initial cost-benefit analysis: a) none that I can see, or b) way more than the uncertainties in the numbers justify.
  2. We’re not quick enough to radically re-scope or even cancel projects based on their actual progress.

Give and Take and Two Mistakes

Posted by Robert Merrill on June 5, 2013 under 100 Words, uFunctional Values | Be the First to Comment

A couple of days ago, I learned about Adam Grant’s book, “Give and Take,” through LinkedIn or Twitter or some other digital fire hose that I’ve turned on myself. Being very interested in the role of altrusim, collaboration, and chains of trust in business, I followed the link, read about the book, and saw that authors I like were endorsing it. I was impressed, and was planning to order a copy.

Like a lot of people, I’m a sucker for lists and surveys, so I took the survey at www.giveandtake.com. The questions were interesting, although it was sometimes frustrating because the answer I would have given wasn’t one of the choices. That happens. Good surveys are incredibly difficult to write; I’m sure Adam Grant (Ph.D. in Org Psych) knows that. Read more of this article »

Sorry, College Grads, I Probably Won’t Hire You (and my knee-jerk reaction)

Posted by Robert Merrill on May 13, 2013 under 100 Words, Concepts, uFunctional Values | Read the First Comment

I just read a WSJ article with the provocative title, “Sorry, College Grads, I Probably Won’t Hire You,” by Kirk McDonald, an accomplished Manhattan (not Kansas) digital media executive.

McDonald says that college grads lack “the ability to know enough about how these information systems work [to] be useful discussing them with others.” As an example, he throws out a client question about how long a project will take. As a remedy, he suggests spending the summer learning a little bit about one or two programming languages.

I wish I was being trolled, but I’m afraid I’m not. So here comes some advice of my own. Read more of this article »

The Cloud Shouldn’t Be Scary, Either…

Posted by Robert Merrill on March 18, 2013 under 100 Words | Be the First to Comment

Here’s what cloud computing means, in layman’s terms. You can go to Amazon Web Services and literally put computers in your shopping cart and they’re ready to use within a couple of minutes. When you’re done with them, you give them back.

So what? In layman’s terms, this isn’t like having a new laptop appear on your desk, ready to use. These cloud computers are servers, meaning they’re for other computers (increasingly, tablets and smartphones) to use, not for you to use directly. A techie has to make them useful. And there’s the problem. Read more of this article »

Making Software Better, Step 2: Get Serious About Internal Quality

Posted by Robert Merrill on March 11, 2013 under 100 Words, Agile Methods, Waterfall (SDLC) | Read the First Comment

One frustrating evening years ago, when I was a professional scientist and a self-taught programmer, I blurted, “Programming takes longer when I’m in a hurry than it does when I’m taking my time!”

Graph of Unit Cost against Quality; unit cost decreases with increasing quality for typical business software, and then cost rises sharply for the level of quality required for life-critical software. Due to a lack of internal quality, most organizations have higher software costs than necessary.I had stumbled upon what is sometimes called the Law of Software Quality.

Whoever said “Fast, Cheap, or Good—pick two!” started a dangerous lie. Unless it’s extremely simple software, to be used by its creator, once, and then deleted from the computer, improving quality makes the software less costly, not more.

OK, this isn’t true if you’re writing software where people could die if there’s a single bug (mistake) in it. That level of quality costs extra.

But for typical business software, there’s a sweet spot of quality, and most organizations aren’t there. Unless you have intentional quality measures in place, you can probably double your productivity by doing a little extra work of the proper sort at the right steps in the process.

So, why are effective quality practices not universal?

  • To uninformed outsiders, everything but typing looks like Extra Work. Budgets with tasks (as opposed to features) as line items invite cutting quality measures to save time or money (but it doesn’t work in the end). Feature-based budgets are better because they drive conversations about feature value and scope when “cutting to fit.” But if your organization has separate groups that do quality-related tasks, task-based budgets are hard to avoid. Many big shops are organized this way.
  • The most cost-effective quality measure, formal Inspection, isn’t as fun as programming. Lesser forms of requirements, design, and code review, while not as anal-retentive as Inspection, are less effective and still not as fun as programming. “The only problem we have around here is not enough meetings,” said no programmer, ever. Startups begin with just programmers (and maybe UI designers) and it’s easy to establish an inefficient code-and-fix culture and lay down a foundation of low-quality code that makes it hard for the business to pivot or scale up.

The first “quality measure” most firms introduce is Testing, in order to keep External Quality at an acceptable level. (External Quality is essentially, “does it work?”) The problem is that testing can only detect mistakes, not prevent or fix them, and then it can only detect certain kinds of mistake. Software can have high External Quality but still be made of Magic Spaghetti—poor Internal Quality.

Improving Internal Quality is where the payoff really happens. The reason why the quality curve looks the way it does is that tracking down mistakes in software is the most time-consuming form of Extra Work there is. It’s also hard to predict. Quality measures other than manual post-coding testing pay off because they detect mistakes relatively soon after they’re made, when they’re still easy to find.

Although I believe it’s easier for most teams to create high-quality software using an Agile method (I’m assuming this means automated testing, one of the Load-Bearing Walls of Agile), quality isn’t the main reason I prefer Agile. Regardless of methodology, introducing the right quality measures is a sure win.

Waterfall shops tend to use more formal requirements, design and code reviews, while Agile shops tend to use refactoring, supported by automated testing. Coding standards, especially naming conventions, are a good idea anywhere, provided they don’t trigger a religious war. Most languages have one or more de facto standards. Pick one and use it. Pair programming is the Agile form of code review. It catches a lot of mistakes but drives cost accountants crazy, unless they believe the quality graph. The most common review mistakes are reviewing too late and reviewing too much at once.

Another term for poor Internal Quality is Technical Debt. Like financial debt, it bears “interest,” in the form of extra time spent changing, enhancing, repairing, and upgrading a system that’s full of Magic Spaghetti and therefore hard to understand and change without making another mistake.

So whenever I have to help a firm Make Software Better, I first help them get a grip on their commitments. That frees up some time for them to introduce some quality measures. Those take time to gain traction. The longer the cycle time (time from gleam in the eye to feature in use), the longer it takes for the low-quality work in progress to clear the development pipeline and—gasp!—enter production, where it will continue to drive higher-than-necessary costs until remediated.

Making Software Better, Step 1: Get Control of Your Commitments

Posted by Robert Merrill on March 4, 2013 under 100 Words, Estimation, Process Improvement | Be the First to Comment

I’m writing for a typical client of mine—a software team of a half-dozen people, and the firm that pays them to do projects of a few months to a year in length. Let’s assume it’s you.

You want to get better at making software. You know that change is difficult and that there are no silver bullets. But you also know that you could be twice as good as you are now. (If you’ve never intentionally tried to get better at making software, I can almost guarantee it).

You’ve looked at “Software Process Improvement,” and your head is spinning. Where do you start? You may not even have a software development process. (Correction—you may not have an intentional software development process. The fact is, everybody has a process for everything they do, whether it’s making software or taking out the trash. It’s whatever they do now).

You want to make some simple (but not simplistic) changes, and you need to understand why they will probably work. (You will see below why this is important).

So you hire me and ask me what to do. Read more of this article »

Former Weatherman Rediscovers Clouds

Posted by Robert Merrill on February 18, 2013 under 100 Words | Be the First to Comment

Color photograph of a puffy Cumuls Cloud like you might see on a summer dayReal clouds

My first career, from my university days until the mid-1990s, was as a behind-the-scenes meteorologist. I looked at thousands of satellite pictures of clouds, usually those produced by hurricanes. I also took two courses about clouds. Clouds are really interesting, mainly because water is really interesting. Did you know that a cumulus (low, puffy) cloud inland is radically different from a cumulus cloud over the ocean? It’s the salt.

Computer clouds

Fourteen years later, a client asked me to create operational procedures and a staffing plan for a new product that they were going to run “in the cloud.” Who hasn’t heard of “cloud computing?” I knew that it was near its peak on Gartner’s Hype Cycle.

Cloud symbol used for the public Internet on network diagrams, from which Cloud Computing gets its nameI knew about Software as a Service (SaaS), epitomized by SalesForce.com. And I knew that you could rent computing power and storage by the hour from companies like Amazon and Rackspace. The web page you’re reading was served up from a computer out there, somewhere. “Out there” is also called “the Cloud,” from the cloud symbol used on network diagrams to indicate the not-our-problem, it-just-(mostly)-works public Internet. What’s the big deal?

As it turns out, The Big Deal is not just that you can have a computer Out There Somewhere, it’s that you can have a few of them, or a lot of them, automatically, and pay for them by the hour, and write computer programs that create, modify, and destroy—computers! And storage, and switches and routers, and firewalls, and load balancers.

Software is the new Hardware.

As with everything, there’s good news and there’s bad news.

For Business People

The good news

For business people, it’s almost all good news. Your up-front capital costs just went way, way down. You don’t have to overbuy hardware or fear success. If business takes off, rent more computers, and have them in minutes, literally. There’s only a little bit of bad news, but it’s a people thing and not a technical thing.

For Technical People

The good news

For technical people, the good news is that you’re no longer hamstrung by hardware availability based on business constraints. Need a sandbox to try something new? You don’t have to worry about finding space on an existing server, and worry about whether or not your experiment will interfere with what’s already there. And when you’re done, you don’t have to clean it up. Just delete it. The whole computer! Need a test environment that looks like production? Rent one for just as long as you need it, and then give it back.

The bad news

The bad news is what they told Spider-Man. “With great power comes great opportunity to make a colossal mess,” or something like that. All the mistakes that you can make with software, you can now make with hardware, too! Computers all over the place, no one knows what they do, and no two alike, and being created ex nihilo by software you—yes, you!—wrote. It’s like the Sorcerer’s Apprentice from Fantasia! And you get a bill at the end of the month, every month, for the whole mess.

The way to prevent the bad news is to get disciplined without getting bureaucratic about it. Hey, if it were easy, everybody would do it.

Cloud fitness

An amazingly helpful guide for my return to IT infrastructure and the cloud has been a pair of books from the IT Process Institute:

The Visible Ops Handbook book coverThe Visible Ops Handbook explains, in around 100 pages, how to get from a nerve-wracking, fire-fighting operation to a sane one—nice in its own right, and essential for cloud. You have to stop being a cowboy and get a lot of discipline:

  1. Change management—fast turnaround, but no exceptions,
  2. Configuration management, including finding all the one-offs,
  3. Standardization of configurations to eliminate one-offs, and
  4. Identify and eliminate root causes for every incident.

In return, you get your nights and weekends back.

Visible Ops Private Cloud book coverVisible Ops Private Cloud explains how to keep your sanity when you move to a private cloud (hardware-as-software, only running on hardware you own). You need yet more discipline, and you’ll need to learn some new (but cool) tools:

  1. Design and configure services, not just individual servers,
  2. Dramatically increase monitoring, and
  3. Fully automate provisioning.

In return, you get amazing efficiency and reliability.

When ITPI comes out with a public cloud book, I’m buying it. Public cloud (Amazon owns the hardware) is even more difficult because you can’t actually see and monitor the hardware, at least not directly.

For Business People

The bad news

You’ll need to hire and pay technical people who are not just smart, but disciplined, and that means disciplined enough to stand up to you. In return, you’ll get amazing efficiency and nimbleness—what Gene Kim (of The Visible Ops Handbook) calls “Amazing Kung Fu.”

Focused Perspective

Posted by Robert Merrill on January 21, 2013 under 100 Words, uFunctional Values | Be the First to Comment

Thanks to digital cameras with zoom lenses, even casual picture-takers now know about “wide-angle” and “telephoto.” It’s easy. You move the little lever until the scene looks right and push the button.

Many difficult jobs are difficult because they also require switching back and forth between “wide-angle” and “telephoto.” But it’s not so easy to switch, and it’s much harder to tell what you’re missing by not switching.

Smiley face made up of dots, with a magnifying glass showing that the dots are frowning faces.Working with software is like that. On the wide-angle end, it’s about improving a business process or opening a new sales channel. On the telephoto end, it’s about getting two pieces of third-party software to play nice, and writing bug-free code, often on deadline. It takes Perspective to see how software will change the work done by people in multiple departments. And it takes Focus to find out why the tax still isn’t being calculated correctly.

Common sense tells us to start with the big picture—Perspective—and proceed to details—Focus. But experience tells us—at least those of us who’ve been around software very long—that it’s not a one-way trip. Quite often the first dive into the details reveals some things which would change our perspective, and that’s not easy to do. But it is essential to avoid a lot of stress and wasted money, and that’s why I’ve called out “Focused Perspective” as one of my professional values. Read more of this article »

Principled Pragmatism

Posted by Robert Merrill on January 14, 2013 under 100 Words, uFunctional Values | Read the First Comment

Pragmatism is about getting the best results I can, with what I have to work with.

Principles are what I stick by even when no one’s looking, and even when they cost me. Read more of this article »