Category Archives: process

The difference between innovation and sloppiness

I took a couple of art classes in college. In Life Drawing we were supposed to look at the arrangement or person in front of us and put it on paper. In pencil, then charcoal, then ink … watercolor … oil … etc.

I was always good at photorealism. I might not have been fast, but I had some pencil drawings that could have passed (at a distance) for black-and-white photos.

There was another student, an art major who fancied himself an “artiste”. His work spanned the range from abstract to really abstract. He looked down on my mere technical facility.

But my grades were as good as his, sometimes better. It seems when he talked about his rejection of formal rules, it really meant he wasn’t able to do realism. He didn’t have the command of the tools, the mere technical facility. So everything he did owed as much to chance as to intent.

He may have been right, that I didn’t have the creativity to do modern art. I’ll admit that I appreciate paintings that simply look good, without high-flying pretension or socio-political overtones. I guess I’ll never have a SOHO gallery showing. C’est la vie.

But with all his fervor, and whatever glorious visions he had in his head, he couldn’t reliably get them onto the paper. He couldn’t create something specific, on purpose.

[Cue un-subtle segue … ]

But what does this have to do with the business world? Scott Berkun wrote recently about how constraints can help creative thinking. When a large corporation does “blue sky” thinking, they can wander aimlessly and never produce. Constraints set a direction.

But I think there’s another problem with “blue sky” thinking that goes beyond a lack of direction. It’s summed up by Voltaire’s famous maxim:

The perfect is the enemy of the good.

When a company tries to “blue sky” a problem, they are implicitly seeking perfection: With no limits, what would be possible?

But there are always limits. They may be self-imposed, inconsequential, misunderstood, overblown, or in any number of other ways not real limits. And it helps to know the difference.

When you start out by asking people what they would do if there were no constraints, don’t be surprised when they come back with a solution that can’t possibly work. And then convince themselves that theirs is the only possible solution. By then, you’ve already lost.

How to Fail by Succeeding

Dave Christiansen over at Information Technology Dark Side is talking about perverse incentives in project management, which he defines as:

Any policy, practice, cultural value, or behavior that creates perceived or real obstacles to acting in the best interest of the organization.

One class of these perverse incentives comes from the methodology police. These departments exist to turn all processes into checklists. If only you would follow the checklist, everything will work. But more importantly, if you follow the checklist you can’t be blamed if you fail.

How’s that for perverse?

A great example is that there is rarely any incentive to not spend money. Before you decide I’m out of touch with reality, notice I didn’t say “save money.” I said “not spend money.” Here’s the difference.

IT by the numbers

Let’s say you do internal IT for a company that produces widgets. Someone from Operations says that they need a new application to track defects. If you follow the checklist, you:

  • engage a business analyst, who
  • documents the business requirements, including
  • calculating the Quantifiable Business Objective, then
  • writes a specification, which is
  • inspected for completeness and format, then
  • passed on to an architect, who
  • determines if there is an off-the-shelf solution, or if it needs custom development.

At this point you’re probably several weeks and tens of thousands of dollars into the Analysis Phase of your Software Development Lifecycle. Whose job is it to step in and point out that all Ops needs is a spreadsheet with an input form and some formulas to spit out a weekly report?

Let’s put some numbers to this thing.

Assume the new reporting system will identify production problems. With this new information, Operations can save $100,000 per month. A standard ROI calculation says the project should cost no more than $2.4-million, so that it will pay for itself within two years.

Take 25% of that for hardware costs, and 25% for first-year licensing, you’ve got $1.2-million for labor costs. If people are billed out at $100/hour – and contractors can easily go three to four times that for niche industries – that’s 300 man-weeks of labor. Get ten people on the project – a project manager, two business analysts, four programmers, two testers, one sysadmin – and that’s about seven months.

If everything goes exactly to plan, seven months after the initial request you’re $2.4-million in the hole and you start saving $100,000 per month in reduced production costs. Everyone gets their bonus.

And 31 months after the initial request, assuming nothing has changed, you break even on the investment. Assuming the new system had $0 support costs.

But what if …

Way back at the first step, you gave a programmer a week to come up with a spreadsheet. Maybe the reports aren’t as good as what the large project would have produced. You only enable $50,000 per month in savings. That week to produce it costs you $4,000 in labor, and $0 in hardware and licensing.

You are only able to show half the operational savings, so you don’t get a bonus. You don’t get to put “brought multi-million dollar project in on time and on budget” on your resume.

And 31 months after the initial request, the spreadsheet has enabled over $1.5-million in operational savings.

How to Finish IT Projects Faster with Less Documentation

If you’re responsible for running an IT project you want things to be done on time and within budget. So how do you set your schedule and budget? Hopefully you define what you want to accomplish, and then ask the developers how long it’s going to take. If you’re putting out a request for proposal (RFP) you’ll have several different answers to that question. Typically the highest consideration in the selection is the total proposed cost. But really, the total time is a better choice.

Why that’s true is based not on ideas about processes, but on ideas about people.

Consultants live and die by billable hours. In the short term, they don’t have any incentive to finish their current project any faster. But in the long term, finishing faster should lead to more work as clients come to respect their ability to meet a deadline. If project managers and clients learn to value that behavior, that is.

How it Could Be

Let’s look at a production support issue for an example. Production support is completely different from most project work in one very important way: the problem is well defined. Something worked on Monday, it doesn’t work on Tuesday. Make it work just like Monday again.

For something with six-figure impact per hour of downtime – and if you think that’s an artificially-high number you’ve never worked with credit card processing – you don’t want a programmer with an impressive resume, dozens of certifications, and decades of experience with your primary programming language. You want Bob, the guy who wrote the system from scratch and demands $1k per hour with a four-hour minimum.

Once you’ve got Bob and his hand-picked team of support people, you get out of their way and let them work. Status reports might be no more than, “We’ve found the problem … We’ve identified the solution … We’re ready to test the fix … It’s live.”

How it Is

But when it comes to new development, companies play it “safe” and look for the best qualifications on paper. They hire based on keyword matching and offer rates based on industry standards for a given skill set. They require specific processes and deliverables (pet peeve: when did “deliverable” become a noun?) and status reporting becomes a significant percentage of the total budget.

Why the Difference?

There are two reasons expert teams get away with less formal process than is typical, but I can only prove one of them. The public answer business sponsors tell themselves to justify the exception to “official methodology” is that the experts have worked the methodology for so long that they can follow the same procedures without exhaustively documenting all the steps. And there is some truth to that.

But I suspect the larger reason is that experts get the work done so much faster there just isn’t enough time for documentation to build up.

The best athletes make things look easy that most people could not even do. A high jumper might clear six feet without even trying hard. Most people would never come close even with months to try.

The best IT people do the same thing. They complete projects in weeks that other people could never do. As “safe” projects drag on specifications are refined, status reports are produced, contracts are negotiated, updates are requested and provided. Meanwhile the expert team has just released to production – so it must have been a small project.

The hard part for the client is to recognize the difference between a project that went smoothly because it was easy, and one that went smoothly because the team made it look easy. But here’s the secret: You don’t really need to recognize the difference.

How to Do Better

The reason you hired someone else to do the work is because you couldn’t do it yourself. Which means you can’t accurately judge which projects really are hard, and which ones just look hard. So don’t judge the project, judge the people.

The people who seem to always be working on small, simple projects – after all, they always go quickly with no major problems – are better at execution. They will be better no matter what the project is.

Get to the point

Dave Christiansen over at Information Technology Dark Side has a good graphic representing what he calls the FSOP Cycle (Flying by the Seat of Your Pants). The basic idea is that when smart people do good things, someone will try to reproduce their success by doing the same thing that worked the first time.

The problem with trying to do this is that every time someone tries to document a “successful process”, they always leave off the first step: get smart people working on the project.

Dave outlines several reasons why capital-P Process will never solve some problems. Joel Spolsky described this same issue in his Hitting the High Notes article when he wrote, “Five Antonio Salieris won’t produce Mozart’s Requiem. Ever. Not if they work for 100 years.”

So if Process can’t solve your problem, what will? According to Dave, it’s simple:

Put a smart PERSON in the driver’s seat, and let them find the way from where you are to where you want to be. It’s the only way to get there, because process will never get you there on its own.

I’ll assume that when Dave says “smart” he really means “someone good at solving the current problem”. I could have the world’s smartest accountant and I wouldn’t want him to remove my appendix. Okay, I don’t want anyone to remove my appendix. But if I needed it done, I’d probably go find a doctor to do it. So what Dave is saying is that you’d rather have someone who’s good at solving your current type of problem, than have Joe Random Guy trying to follow some checklist.

This isn’t a complete answer, though. Some songs don’t have any high notes.

In the middle of describing why you should choose the most powerful programming language, Paul Graham writes:

But plenty of projects are not demanding at all. Most programming probably consists of writing little glue programs, and for little glue programs you can use any language that you’re already familiar with and that has good libraries for whatever you need to do.

Trevor Blackwell suggests that while that may be changing, it was still true at least until recently:

Before the rise of the Web, I think only a very small minority of software contained complex algorithms: sorting is about as complex as it got.

If it’s true that most programming doesn’t require the most powerful language, it seems fair to say most programming doesn’t require the best programmers, either.

You might notice at this point (as I just did) that Dave wasn’t talking about programming, or at least not only programming. The same principle seems to hold, though: Average people can do the most common things with the most common tools. Exceptional circumstances require exceptional tools and/or exceptional people. If only there were a way to predict when there will be exceptions …

The other problem

But let’s say we’re looking at genuinely exceptional people who have done great work. Should we ask them how they did it? After all, they’re the experts.

Well, not really. They’re only experts on what they did, not why it worked. They might have simply guessed right. Even if they didn’t think they were guessing.

Need another example of false authority? Have you ever heard someone describe a car accident, and attribute their survival to not wearing a seatbelt?

First, they don’t know that. They believe it. They obviously didn’t do a controlled experiment where the only difference was the seatbelt. Second, even if they happen to be right in this case, statistics show that it’s much more common for the seatbelt to save you than harm you.

So if you want to design a repeatable process for creating software, you can’t do it by asking people who are good at creating software.

The other other problem

One change I’d make in Dave’s FSOP diagram is in the circle labeled “Process Becomes Painful”. It’s not that the Process changes. Really what’s happening is that the project runs into some problem that isn’t addressed by the current Process.

Every practice you can name was originally designed to solve a specific problem. On very large projects, there’s the potential to encounter lots of problems, so extensive Process can simultaneously prevent many of those problems from appearing.

But attempting to prevent every conceivable problem actually causes the problem of too much time spent on the Process instead of the project.

That’s where Agile comes in. It solves the problem of too much process. Do you currently suffer from too much process? Then you could incorporate some ideas from Agile.

But make a distinction between using ideas to deal with specific problems, and adopting a whole big-M “Methodology”. Once you adopt a Methodology designed to solve the problem of too much Process, you face the danger of having too little Process.

Your expert programmers may be the best in the world at the problem you hired them for. But now you want them to do something different. And you have no way to recognize that they’re not making progress, because you’ve eliminated all the governance that came with the heavyweight Methodology.

So what’s the point, anyway?

Process is not something you can measure on a linear scale, having “more process” or “less process”. Always adding practices — even “best” practices — to your current Process is simply trying to solve all possible problems, whether you’re currently having them or not.

For each practice you have to consider what it was designed to solve, what was the point of it to begin with? Then don’t treat these practices as a checklist that must be completed every time, but follow the principles behind them.

There’s a line in the movie Dogma that I think describes this really well. Just substitute “process” for “idea” and “Methodology” for “belief”:

You can change an idea. Changing a belief is trickier. Life should be malleable and progressive; working from idea to idea permits that. Beliefs anchor you to certain points and limit growth; new ideas can’t generate. Life becomes stagnant.

The program is not the product

Managers want programs to be like the output of a factory. Install the right robots and tooling, start the process, and good software comes out the end.

WRONG WRONG WRONG WRONG WRONG WRONG WRONG WRONG WRONG WRONG!!!!!! (Can you tell I disagree?)

Nearly everyone who makes the factory analogy misses a very fundamental point: the program is not the product. For one thing, unless you work for a software company selling shrink-wrapped software products you aren’t ever selling the program. Conventional wisdom says most programmers actually work for internal IT, so it’s safe to say most programs are never sold.

Businesses don’t want programs, they want credit reports … and loan contracts … and title searches … and purchase orders … and claim forms …

So what is the right analogy? The program is the assembly line! So measuring bugs in the program is wrong. Even comparing compiling to manufacturing — which is still better than comparing programming to manufacturing — is wrong. What you should be looking at is the output produced by the program. Is your program a website? Measure the number of pages it can produce per unit time, without error. Is it an editor? Measure the number of pages it can spell-check per unit time, and with what accuracy.

When measuring the output of a manufacturing process, you literally shouldn’t care what the process looks like, nor what tools are used, so long as it consistently produces the same output. This is not to say the process and tools don’t matter. A bad process may be prone to unexpected failure. Tools may be harder to maintain or have a shorter service life. You may be locked into a service contract with the manufacturer. And coincidentally [ahem] all these factors apply to software.

So yes, programming can be compared to manufacturing. As long as you remember that the program is not the product, the program is the assembly line.