All Posts in Strategy and Tactics

|In: Process Management and Improvement|Last Updated:

“Proof” is a tricky concept. “Proof of concept” is, if anything an even trickier concept.

Before we go on, a warning: If you buy into what follows and try to promote the ideas, you’ll gain a (or add to your existing) reputation as a persnickety pain in the keister. You might be better off just going with the flow, without worrying about all those nasty details that can be the difference between successful implementations and pouring money down a rabbit hole.

Still with me? Don’t say I didn’t warn you.

Mathematicians and geometricians more or less invented the notion of proof. They start with explicit assumptions, including a class of assumptions that are the rules of logic. They rigorously apply logic to their assumptions to create, one at a time, proved statements they can then rely on to take their proof to the next stage in the sequence (so long as their assumptions hold).

It’s like FORTH programming, where you combine defined verbs to create new defined verbs (and if you knew that you have, like me, joined the Geezing Geek Club).

Wouldn’t it be lovely if you could prove business concepts through pure logic? But you can’t.

Businesses are, among other things, collections of processes and practices. And business processes and practices have to handle, not only the mainstream set of inputs, but also a wide variety of exceptions. How employees handle many of those exceptions isn’t documented, because documenting them is impractical. There are too many of them and none happen often enough to be worth the time to document once an employee figures out what to do with it and moves on.

Which is just one reason proofs of concept are necessary in the first place. Add the rest (listing them is left as an exercise for the reader) and you get to the result: Logic can only get you so far. Then you need evidence.

Beyond mathematicians and geometricians is the next level of professional provers — researchers in the hard sciences. They develop hypotheses in much the same way mathematicians develop proofs, except that as scientists deal with the physical universe they have to accept that their assumptions might not always hold; also that there are almost always too many variables that might affect a phenomenon to include them all in a formal mathematical model.

Which is why they have to test their hypotheses through observation and experiments.

What scientists and philosophers of science figured out a long time ago, though, is that they can never prove anything through observation and experimentation, if for no other reason (and there are actually lots of other reasons) than that the next time they do the exact same thing, something different might happen.

So all good researchers understand that the best they can ever do is fail to disprove a proposition. Subject it to enough different tests and have it not fail any of them and, over time, they start to have confidence in it.

Which is why scientists have great confidence in Einstein’s theories of relativity and the Darwin/Mendel/Fisher theory of evolution by natural selection, and, for that matter, an increasing level of confidence in the theory of anthropogenic climate change: Each makes predictions about what scientists should find if the theory is true; so far, when scientists have looked, they’ve found what the theory predicts … or they’ve found something that doesn’t completely invalidate the theory but does call for modification or elaboration, after which the modified, elaborated theory is what’s subjected to future testing.

But they’re never certain, and good scientists never say they’ve ever proved anything. They say they’ve tested it thoroughly and it’s held up.

Think you’ll ever have the opportunity to test your business concepts this thoroughly?

Nope. At best you’ll be allowed to conduct one or two so-called proofs of concept, which are, by the above standards far far short of proof. Your average “proof” of concept is really nothing more than an attempt to disprove the simplest and easiest application of whatever the concept is to your business.

It’s a bit (but just a bit) like strapping a jet engine to the back of a cart and adding a big parachute. You might win a drag race with it, but you certainly haven’t proven the concept of jet-powered automobiles.

You’ve barely scratched the surface of testing it. If you have any more confidence than that, you’ll almost certainly find yourself in the middle of a fiery crash later on.

Comments

|In: Career Management|Last Updated:

Let’s get down to cases.

No, not use cases, and can we all please stop adding “use” to “case” to try to sound cool unless we’re planning to use the Rational Unified Process to actually define one?

Thank you. I feel much better now. Where was I?

You want to provide technology leadership. You’ve assessed the situation and all the factors we’ve talked about over the past two weeks are in place, including an enthusiastic business partner. Now what?

Now you’ve learned something about the danger of success, that’s what. Because if everyone you pitched your idea to had said no, you’d have the satisfaction of saying “I told you so” in a few years. Much easier than all the hard work of actually making something happen.

Don’t say I didn’t warn you. Anyway …

You and your sponsor will be tempted to do this the easy way: Evaluate development partners who are experts in whatever the technology is you’re talking about, make sure the winner agrees to adhere to your technical standards and (if you’re advanced) to work with your enterprise technical architects to make sure the new stuff has a clear place in those standards, sit back, and enjoy the show.

It’s tempting. But it misses the point, which is that your most important goal isn’t a successful implementation. Your most important goal is to build a reusable organizational capability.

To be fair, sometimes the best way to build an organizational capability is to establish a firm, deep, durable relationship with an outsourcing partner. If that’s your plan, fine and dandy, but make it a clear and explicit choice, not a default, slippery slope you fall onto because you took the path of least resistance. And even then …

If you outsource, you have a bit more to do. If you don’t, you have more.

Start with the basic framework of organizational design:

  • Process — how you want the work to get done.
  • People — new skills and knowledge you’ll need in your organization.
  • Technology — not only the technology you’re trying to introduce. “Technology” means tools, which includes little niceties like how the new technology fits into your overall development environment, what you’ll need in the way of testing tools, and how IT operations will make sure the new system is working right.
  • Structure — once you’ve finished a successful pilot project you’ll need to assign responsibility for the various bits and pieces.
  • Culture — everyone’s mental habits around how we do things around here. If the impact of culture isn’t immediately obvious, think back, if you’re old enough, to the early days of the World Wide Web, when IT figured the company website should be developed using the same disciplines it used to implement the general ledger system, but Marketing figured it should use the same disciplines it used to build marketing campaigns.

Don’t get too far ahead of yourself. Pilot projects give you more than quick business benefits and “proof” (hah!) of concept. After the pilot you’ll have the benefit of hands-on experience, unlike now when all you have is the benefit of abstractions and theory.

For the pilot, engaging an experienced outside partner is generally a good idea, assuming the technology isn’t so new that there is no such thing. But engaging an outside partner isn’t the same thing as handing the project over to the outside partner with little or no internal involvement. Don’t do this: You and your staff won’t learn anything, except for what you’ll learn about the resentment you’ve caused by giving the fun stuff to the outside vendor.

So make blended teams a project requirement. Assign project management responsibility to the outside vendor. Fair’s fair — allow a certain amount of inefficiency as the team members you provide come up to speed.

But your goal is, at a minimum, owning business leadership, and very likely self-sufficiency. This is your opportunity to build enough expertise to accomplish this.

And in particular, don’t forget the critical role your business analysts will need to play. They’re the ones who match what information technology can do (both the stuff and the organization) to what business executives and managers want to accomplish.

With any luck you’ll have an obvious choice — the business analysts who have already been in your office, trying to persuade you the technology in question has important potential for the business.

Haven’t had any? You aren’t alone. In my experience, relatively few business analysts think maintaining awareness of new technologies and trends is something they ought to do.

The same thing seems to hold among developers, sad to say. So on the people side of things, give this opportunity to the happy few exceptions who do.

* * *

Truth in advertising: I’m employed by Dell Services, which is in this business, which means I’m not entirely impartial in thinking vendor support, either for your early-stage efforts or for building your capability through an outsource, is a good idea.

Comments