All Posts in Leadership

|In: Industry Commentary|Last Updated:

Bob’s article is a classic on pilots.  This rerun works well with our previous topics.

I was sitting with Moe, Larry, and Curly at lunch the other day (not their real names but I feel an obligation to protect the guilty) when the conversation turned to information technology.

My colleagues (we’ll call them S3 for short) recently left the military, so their perspective on IT is a bit broader than that of most IS professionals. Moe led off with a mention of genetic algorithms. Here’s how these amazing things work: You feed the computer any old airplane wing design (for example) and a definition of what it means for a wing to be optimal. Let the computer churn for a day or two, and just as an automatic bread-maker magically produces bread, it will pop out an aerodynamically perfect wing design.

The algorithm is called “genetic” because it mimics evolution, randomly mutating the design in small increments and accepting those mutations that improve the design. Very cool stuff. If you support an engineering design group, this technology is in your future.

From there, Curly somehow got to artificial intelligence, and in particular the AI golf caddy. Apparently, these little robots actually exist, following you around the golf course and recommending the perfect club for every shot. Larry pointed out the hazards of combining the AI caddy with Y2K: “Carnage on the course,” he called it.

If you haven’t noticed, people are doing amazing things with computers these days. So why is it that most IS departments, in most projects, can’t seem to design a database, create data-entry and transaction-entry screens for it, design and code a bunch of useful reports, and hook it all to the legacy environment without the project going in the ditch?

When I started in this business, a typical big project needed 25 people for three years and was completed about a year after the deadline — if it got completed at all. Compared with the simple compilers we had when I started programming, our integrated development environments should easily make us 100 times more productive. So why is it that as I write this column, a typical big project needs 25 people for three years and is completed about a year after the deadline — if at all?

Do the math, people. One programmer should complete everything in nine months. What’s the problem?

It isn’t, of course, quite that simple. It also isn’t that complicated. Try this: Start with a small but useful subset of the problem. Then, understand the data and design the database. Create edit programs for each table. Work with end-users to jointly figure out what the update transactions are, and design transaction entry screens for each of them. Design a navigation screen that gets you to the edit and transaction screens. Build a simple batch interface to the legacy environment. Do it as fast as you can. Don’t worry about being sloppy — you’re building Quonset huts, not skyscrapers.

Put it all into production with a pilot group of end-users for a month. Turn your programming team into end-users for that period so they experience their system in action first-hand. At the end of the month, start over and do it all again, this time building the system around how the pilot group wants to work. After a month with the new system they’ll have all kinds of ideas on what a system should do for them.

Build Version 2 more carefully, but not too much more carefully because you’re going to loop through the process one more time before you’re done. In parallel with Version 2, though, start building the infrastructure — real-time legacy interfaces, partitioned business logic and so on — that you’ll need for Version 3, the production application that needs a solid n-tier internal architecture and production-grade code.

Does this process work? It has to — it’s just a manual version of a genetic algorithm. I’ve used it on small-scale projects where it’s been very successful, but haven’t yet found anyone willing to risk it on something bigger. Given the risks of traditional methodologies, though (by most estimates, more than 70 percent of all IS projects fail) it almost has to be an improvement.

 

Comments

|In: Leadership|Last Updated:

The first thing to understand about leadership is that effective leaders don’t get anything done. They build organizations that get things done.

The second thing to understand is that effective leaders must master eight capabilities – eight tasks, which are (1) setting direction; (2) making decisions; (3) staffing; (4) delegating; (5) motivating; (6) managing team dynamics; (7) engineering the organizational culture; and (8) communicating.

Third: Each of the eight tasks takes time – something that’s in short supply for most business executives on a typical day at the office.

Fourth? The caliber of leadership in an organization determines, more than any other single factor, the organization’s success.

One more: Many of those in leadership positions don’t particularly enjoy practicing the leadership craft. Given a choice between leading people and just telling them what to do and hoping for the best, hoping, for a certain class of executive, has a lot of appeal.

All of which helps explain, to a significant extent, the excitement many business executives seem to be feeling about artificial intelligence right now. Staff a business with AIs instead of human beings and the need to review resumes and interview applicants goes away, as does motivating the employees they’ve hired, managing team dynamics, and engineering culture.

As for communicating, that changes from listening, informing, persuading, and facilitating to the weirdly conceived “prompt engineering” … apparently, AIs aren’t I enough that they can understand what’s needed from them without translation services provided by actual humans.

It’s enough to make you wonder why you should rely on Google Translate and its competitors.

There’s one more aspect of AI’s appeal as a replacement Homo sapiens that needs attention: From the perspective of running a business, many aspects of staffing are, if we’re going to be honest with one another, annoying. Humans, but not automata, disagree with management about what constitutes fair compensation. Treat humans poorly and they become grumpy and don’t give their work their best effort. Treat them worse and they’ll complain about their managers to HR, and there’s a whole process for that.

Then there’s benefits. Health insurance isn’t just expensive. It also requires a whole department just to administer it. Not to mention the complexities associated with tracking PTO.

We’ve all read the polls, surveys, and person-in-the-street interviews reporting employee concerns about AIs taking jobs away from we mere mortals.

What I haven’t seen is frank acknowledgement that, all things considered, the executives responsible for determining how the work of the business should get done can’t get rid of those pesky human employees (PHEs) fast enough.

Here’s what else I haven’t seen: Advice to our fellow PHEs that we need to frame the conversation about PHE replacement, not as hand-wringing worry and guilt, but as a matter of competitive advantage and disadvantage. That is, PHEs are competing with AIs for each job in the organization. They (You? We?) need strategies for making ourselves more desirable than the AIs that are positioned to replace us.

One possibility, to get things started, is rooted in the difference, celebrated in There’s No Such Thing as an IT Project, between processes and practices. Briefly, processes result in organizations “designed by geniuses to be run by idiots.” With process, the intelligence of experts is codified in the step-by-step process specification. With a practice, in contrast, success comes from the expertise of its practitioners.

Project management is a practice. An assembly line is a process. And right now, much of the opportunity for AI to supplant PHEs in the organization is in the process domain, where AIs probably will prove superior.

But process isn’t the only way to get work done in the business, and the role of AI in business practices will be quite different. Just as personal computers and smartphones have already resulted in “computer-enhanced humanity,” AI-based “Computer-even-more-enhanced humanity” can yield business practices that supplant rigidly specified business processes, resulting in quantum leaps in business flexibility and adaptability.

Bob’s last word: Viewed from the potential computer-enhanced humanity has for replacing inflexible processes with adaptable business practices, replacing human beings with AIs becomes a choice, not an inevitability. But PHEs can’t rely on business leaders to figure this out on their own.

It will be up to the PHEs of the world to make the pitch, and make it convincingly.

# # #

Now on CIO.com: CIO risk-taking 101: “Playing it safe isn’t safe.” But then, neither is reckless risk-taking.

Comments