Talk of IT innovation is the last gasp of the IT cowboys

All this crap about IT being innovators who lead the business is the last gasp resistance of a generation of geeks who can't stand the idea that IT is about as exciting and creative as building roads. A few road builders work in wild canyons building on steep cliffs and across great chasms inventing new solutions as they go, but the bulk of them dump gravel, roll asphalt and pour concrete. Get over it.

I'm all for being people-oriented but that does not mean giving the people free rein to reinvent everythign in their own spontaneous creative way. We did that. We're still cleaning up the mess: unmaintainable undocumented code in a multitude of incompatible architectures, built using RAD and Agile and prototyping and other new-age code-words for "no control".

All this folderol about creativity! If that's what you want, join the queue to go work somewhere in Silicon Valley. People read this stuff about IT innovation and some payments system developer in an insurance company in Pittsburg or Brussels or Taipei or Sao Paulo or Adelaide thinks it is time to start inventing. It's not. Apps should be built/assembled to standard, conventional, documented, engineered, robust, repeatable specifications.

Sure your chief enterprise architect is allowed to spend 10% of their time looking at the fringes for exciting opportunities to innovate in the business. Once in a blue moon they come up with something and a small team is put on a skunkworks project to see where it leads. This is an exteremely unusual exception, it is not how to build IT.

Innovation is in the vendors' R&D labs, in enterprise architecture special projects, in occasional very very rare moments in business application development. Innovation is not IT's day job - engineering is. Demanding innovation of IT is like demanding PhDs of your children. Stop asking too much. In fact it is even more unreasonable: innovation arises from IT far less often than PhDs arise from offspring, costs more and takes nearly as long.

The cowboys can't stand this thought. They can't stand that they have to do things the generally accepted way, the predictable way, the maintainable way, the cheap way. They can't stand that they are accountable for what they do, that records are kept, that they must follow a process and get approvals and be measured.
Enterprise architecture.
Project portfolio management.
Business cases.
Technology approval.
Common off the shelf software.
Production readiness design.
Change control.
Production acceptance.
Post implementation warranty period.
Service evaluation.

Drives them mad. They want to be pioneers, inventors, artists in code. They want to be barefoot free. What they are is childishly petulant, ill-disciplined, and dangerous. We are watching a fundamental shift in IT culture to professionalism, engineering and sobriety. Many of the old school don't like it.

Actually not the old school. There's not much exciting innovation in mainframe COBOL and there were some processes even if there wasn't much standardisation or re-use. It is the nearly-old school of Unix and PC developers and the new school of Web Java and .NET developers who are whingeing the loudest. They've been allowed to chuck their toys around and splash code up the walls for twenty years and now we have to get them in line. This is made harder in New Zealand because we have banned smacking.

Comments

Sounds familiar

I agree, but management are culpable for letting the cowboy culture flourish. Especially those managers who have been promoted from that very culture.

Relegating all creativity to Silicon Valley

Rob,

I agree with you for 95%of the work that we have to do. However, relegating all creativity to Silicon Valley, as you tweet (Um, don't think so: "All this folderol about creativity! If that's what you want, go work in Silicon Valley" 6:32pm PDT, Mar 22) implies is literal, is ludicrous. There are insurance companies that do come up with innovative products that need innovative IT solutions to support. It is rare but it does happen. Keeping that team in the constraints of a strict overburdening process designed for a maintenance team will not meet the business goals. Hence my point, creativity needs minimal process, leadership (not managers) and the right team that has the capability (implied in my article).

Of course, living in New Zealand, you have some experience I do. Maybe you need to ship all creativity to Silicon Valley. :-) I am not sure your mates would agree.

Cheers,
Todd C. Williams

a recipe for disaster

Letting the cowboys loose without restraints on the 95% just so the poor darlings won't have their creativity stifled on the other 5% seems to me a recipe for disaster.

that isn't how engineers do it. In the rare % of cases where something creative has to be done outside standard models and processes, the most senior international experts are brought in to nut out something new, under peer review by other consulting engineers.

Give it up. IT is becoming Information Engineering and we're gonna do it professionally to rules, controls and standards.

(For readers: here is Todd's post "Process Stifles Creativity" which set off my tweet )

Building roads can be VERY exciting

OK, maybe I am a geek, but the very things you deride as boring are exactly what I get excited about because these are the things that make an organization function. Businesses run on IT and they run efficiently if IT supports a enterprise architecture, addresses business cases, uses common off the shelf software, etc.

What is boring about this? Technology has advanced to the point where you can [http://www.enterprisewizard.com/flash/Building-a-custom-application.html build a custom application in 25 minutes] and it is not some hacked together script, but a full blown enterprise app, that supports thousands of concurrent users, with full web services support, automated backups, fully audit capable, etc. Further, it is built on off the shelf software and addresses the issues that some apparently find "boring". Building an application like this is an act of pure creation.

I guess the "artists in code" may be unhappy because there is no coding involved, but was hand-coding ever really fun or just a necessary evil when it was only way to create something new?

In any event, unless you work for a software company, the days of hand-coding are over and there are plenty of other ways of having fun - for example one morning you might chat with a VP about some urgent need in the organization, then swing by his office that afternoon to demo a custom application that solves it and watch his mouth drop open.

Of course, you would have to call it a prototype unless you had a formal spec to start from and emphasize that you need an un-interrupted week of work at your home office to build the "official" app. So you polish the app over the weekend and spend the week in Hawaii learning how to kite-surf if you need some excitement. Meanwhile, the cowboy code-artists take 3 months to build anything and another 6 months to debug it.

you miss my point I think

Hi Colin

Two points: I too find road building interesting (maybe not exciting exactly but it doesn't drive me away either). My point is that those who call it boring had better get used to it.

But I disagree that you can build an app in 25 minutes. It takes weeks or months or years. Why? user requirements, busienss case, financial approval, enterprise architecture and other reviews, support planning and training, user training, documentation, change control, service evaluation, testing (remember testing?), deployment planning and execution, warranty support.... When you say things like "you polish the app over the weekend" it makes me suspect you miss my point entirely and also wear spurs :)

Building an app in 25 minutes

I fully agree with your point about user requirements, which is why I called this a prototype in the last paragraph, but I would like to push back a bit on some of your other points:

The link in my first response actually demonstrates building a simple application for travel expense management in 25 minutes so if someone else has done the hard work of writing up the user requirements, it is not totally unrealistic

Financial Approval: Spending 25 minutes to build an application hardly needs financial approval, any more than you need formal approval to linger over coffee at lunch.

Testing: If you are not writing code, you are not writing bugs. Of course, you need testing, but it now means "Does the application do what the user wants or not?" and the best way to answer this is to actually show them. I have never seen a spec that proved to be 100% correct first time, whe the app is actually used, some refinements are always needed. Specifications are of course still essential to make sure that the first iteration is reasonably close to what the user wants.

Warranty Support: The [http://www.enterprisewizard.com/adaptive-software-platform.htm platform] on which the application is built certainly needs a warranty, just as you need a warranty for your word processor, but does it make sense to talk about having a warranty for every document that you write with it?

Enterprise Architecture: Every application built on the platform conforms to the architecture of the application, so web services support, [http://www.enterprisewizard.com/adaptive-software-platform.htm security], [http://www.enterprisewizard.com/enterprisewizard-scalability-and-redundancy.pdf scalability], etc is covered. Someone in IT needs to vet the platform before the first deployment, but there's no need to vet the architecture of every application built on it because they are all the same.

I could go on, but for complex applications, you are right. It does take more than 25 minutes. It takes about as long to build the application as it does to write up the user requirements. But this is typically a matter of weeks, rather than years. By way of example, ManuLogic was developed in 2 weeks and we built a global [http://www.enterprisewizard.com/chevron-case-study.pdf Sarbanes Oxley] application for Chevron in 8 weeks

As for wearing spurs..... well, I used to gallop as fast as anyone, but those days are long gone and I do not miss them.

the last one is the easy bit

I see your POV. I understand that development times have fallen. I just don't see development time as a large part of the cost.

Having dealt with a series of clients whose IT operations are drowning in a wave of projects, I'd say as an industry we do portfolio management very badly and in particular we don't budget for ongoing cost of ownership. it's all very well to bang up an app. Who determines the impact on existing business processes? Who designs the new processes and trains the users in changes to work procedures? Who modifies monitoring and backup and DR? Who trains the helpdesk and writes support documentation? Who provides level 2 and 3 support? And most of all a new system should be subjected to unit, sociability, user acceptance and service evaluation testing before being unleashed.

People, Process, Technology - the last one is the easy bit.

The last bit is the easy bit

Much of the time, the existing "business process" barely deserves such an elevated name - its a matter of Excel files, Emails and Post-It notes, held together by some information gatekeeper who "knows how it's done". And God help the organization when she leaves..... At least with an automated [http://www.enterprisewizard.com/reducing-costs-with-bpa.pdf workflow], you have a process diagram.

I have also seen IT operations that are drowning in a wave of projects, but this is usually because they are hand-coding the damn things on a POS technology that some IT manager is familiar with because that is what he grew up 20 years ago. If it take more than a few months to complete a project, it may -never- get finished because requirements will have changed by the time that the spec has been implemented. And IT wonders why the business managers hate them?

I also agree that the long term cost of ownership for custom code exceeds the initial development cost by a factor of 4 to 1, which is why IT needs to get away from writing custom code. If you don't write custom code, you don't have to maintain it. New browsers to support? New release of the server OS? The platform supplier should address all such headaches

But as you said: People, Process, Technology. The last part is the easy one. I would add that the second part is not too hard if it is easy to modify the process to meet changing needs. But the first part.... well that's a problem that no one has ever really solved.

Creativity is the mother of all evil ...

Agree - IT should start acting like an engineering profession - using innovation by others to build usefull stuff in an acceptable timeframe.

You can be as innovative as you want if you are a C++ programmer but in the end you'll be forced to conform by the rules and regulations making IT an engineering profession. Build it to last, be maintainable and deliver the funcionality asked for and by the way, do that as quick as possible. If you can't - I will just buy some COTS software which meets 80% of my needs.

And it is not just old-school - it is pervasive - all the young geeks think they are employed to be clever - rather than they are here to build business functions, using leggo blocks and clear rules. IT is actually not hard, we have been doing it long enough.

PS: ... and if I wanted somebody clever, I would get a $200 dollar an hour consultant - I would not trust my employees to think outside the box and be clever.

While I agree with the gist

While I agree with the gist behind your comments this last bit just... wow

"PS: ... and if I wanted somebody clever, I would get a $200 dollar an hour consultant - I would not trust my employees to think outside the box and be clever."

I can't decide if I want to work for you or get you to staff a typical service desk. The only reason your current employees don't love you so much already is that they must be too stupid to do so. Stupid employees eh? If only they were are clever and as trust worthy as you.

/rant

Road builders

Ha, rant on my friend...;)

My 2c

Innovation doesn't necessarily equal cowboy, in the same way that daring architectural projects don't fall down, they just require balance of professionalism and creativity.

We can't all be Frank Lloyd Wright

For every daring architectural project, a million basic houses and commercial building are built to simple standard rules and materials. For every stunning viaduct there are a hundred thousand boring old culverts and girder-bridges.

We can't all be Frank Lloyd Wright. Most of us are employed to implement services at lowest cost and risk - innovation has no place in that.

Simple standard rules & material

There you have it. How do you think these simple & standard materials came to be such? By innovation! By trying out new things and finding out that one way is better than the other.

So has every improvement already been thought of (for these standard buildings)? No.
In IT? Definitly not!

Have a look at successfull companies, they invest in innovation, even when they are producing commodities (I have seen some good examples from Henkel, producing house hold products to the gazillions and they still invest in improvement).

By the way, you are contradicting yourself a little. In a reply to my comment above you said: "We create bespoke services." ... "We don't produce hundreds of thousands of identical services for a mass consumer market."

So what do we do, create "bespoke services" (with innovation, sind it is custom build) or do we build a "hundred thousand boring old culverts"? The answer is: IT does both. That is why it is so difficult to get a standard in place. That is why all frameworks say : "It depends on the business". You may (above) announce that the car manufacturer comparison is dangerous, but have a look at the Volkswagen "empire". Today they build the following brands (Seite „Volkswagen AG“. In: Wikipedia, Die freie Enzyklopädie. Bearbeitungsstand: 25. August 2009, 19:35 UTC. URL: http://de.wikipedia.org/w/index.php?title=Volkswagen_AG&oldid=63767757 (Abgerufen: 28. August 2009, 13:18 UTC), sorry for the German, no time to translate):
Volkswagen (Pkw) 100 % 3.662.595
Audi 99,55 % an Audi AG 964.151
Škoda Auto 100 % an Škoda Auto a.s. 630.032
Seat 100 % an SEAT S.A. 431.024
Bentley 100 % an Bentley Motors, Ltd. 10.014
Lamborghini Audi AG hält 100% der Automobil Lamborghini Holding S.p.A. 2.406
Bugatti 100% der Markenrechte 81
Volkswagen Nutzfahrzeuge 100 % 489.000
Scania (LKW und Busse)

You would think a Lamporghini to be your bespoke service and the Škoda or VW be on the other end the old culvert or girder-bridge. Still there is not only the Frank Lloyd Wright being innovative, but how about all those people that add to a bridge? Find the better route to deliver concrete to the building site, adding ice to the concrete to keep it at the right temprature as to not make it brittle, the idea of wearing a safety helmet and a million other things. Would the Guggenheim be there without all these innovations? Maybe, but it would probably be different. Would it still be great? Probably, but less so, would be much more expensive and maybe would have cost a few lives to build it.

Sorry skep, but I am passionate about innovation. I do not see any rekless innovation around, most people I see pour concrete. Sometime they invent something and since the road builder is not prepared to manage innovation they either produce crappy solutions since they have seen the light (and all the others did not) or they take their energy somewhere else. Both is bad for the road builder. If this company would work with the innovation, it could be led to the right place. Not reinventing the weel a few times, but inventing weels, wings, flippers and the babelfish and maybe even a better way to build a road. I could go on with this for hours (probably boring you ;-), but I got to call a client.

Marc (http://buzina.wordpress.com/)

P.S.: Are you Frank Lloyd Wright or one of the unnamed and unknown road builders?

Innovation should be tightly controlled and rigorously tested

You are missing my point.

I never said there should be NO innovators in IT. i said there is a school of thought that every IT organisation should innovate, that innovation is ther thing to do. And there is a desire by every IT person to be an innovator - to invent, to create, to show how clever they are. This is wrong and dangerous. Innovation should be tightly controlled and rigorously tested.

Every few hundred years someone invents a better culvert. In the last century innovation was faster and every decade or so someone improved the design.

Every culvert that is built is different, slightly. You can tell the one you built if you see it in a photo. But the materials are standard, the thicknesses and angles and diameters are standard, the shape is standard. Nothing is invented on site, except in a tiny percentage of cases where the site forces innovation, in which case an expert engineer is brought in to design a one-off. He/she will still stick to as many stadards as possible and is almost certainly NOT going to make an engineering breakthrough such as inventing a new concrete. Hundreds of people will be involved in a culvert. The number of innovators will vary between none and one, averaging 0.05.

there are untold millions of people building bridges around the world. every one is different. The number of innovators worldwide is in the hundreds. At Volkswagen it would be in the dozens.

No discussion on control & testing

And you are missing my point (on purpose?)

I have never said that innovation means to change your work immediatly (without consent, testing, etc.) and continuously just because someone has a new idea! That is redicolous, and has nothing to do with proper innovation. Since when did we say:
"abandon all logic, common sense and processes, let us all start innovating NOW"?

But your description of the 0,05 innovators is just as crazy. To come up with one usefull and aiding idea you will need many (many, many, many) raw ideas to find the brilliant one. Most organizations can not rely on the one bright individual that will be their innovator (as you are describing) but innovations are created as a team effort. If you just put innovation into your ivory R&D tower, you will get a few (well thought out) innovations after the rest of the world already put them into place.

If your last sentence would be true, this really is a sad world. You do seem to have a low appreciation of your fellow humans.

Marc
http://buzina.wordpress.com

P.S.: You did not answer my question: Do you believe yourself to be one of the few hundred innovators? If yes, you obviously hold yourself in quite high esteem (prove you are on of a few 100s!), if no, then why am I reading your blog ?

the miracle of innovation

I dunno, why are you reading it ? :) perhaps because I take a stimulatingly different view of ITSM. Does that make me an innovator? I don't think so but even I'm not egotistical enough to sit in judgement of myself. Maybe I'll come up with an idea that is innovative one day - I try hard. Don't think i have yet - most of my ideas are just common sense. If you only read innovative blogs I think you are in the wrong place. Of the two million practitioners of ITSM in the world, the number of innovators in the sense of truly inventing something new is tiny, really tiny. Less than 0.05% LOL

Am I an innovator in that I introduce fresh ideas to my clients? Absolutely - that's one of the things many of them pay me for. But that wasn't what you meant.

Yes ideas rise from the shop floor. Yes that should be encouraged. Should employees spend all day thinking of innovative ideas? No. Should we be telling them they aren't doing their jobs if they can't be innovative about it? No. 99% of the time 99% of them are not innovating. Is the only good IT department an innovative IT department? No.

innovation is inspiration. it happens rarely and unpredictably. Nurture it when it does, but get on with work when it doesn't. I think it is cheap to say but almost miraculous to achieve.

Who are we to judge the "size" of an innovation

Innovation never appears by itself. Innovation can best be described as combining tried methods in a new and yet untried way.

In my opinion you have a twisted perception of innovation. The time that a single genius sits in their solitary cell and comes up with a bright new invention (that is then turned into a weapon of mass-destruction by the establishment) is long gone. Innovation and improvement occur constantly when people get together and the environment enables it. Talking like you do is one of the best innovation killers and gets you back to the dark ages of disrespecting employees.

With respect to innovation as a duty of every employee, there is a company which particaptes (quite successfully) in the Great Place to Work awards (http://www.greatplacetowork.com/) which requires each employee (and each managing employee as well) to come up with one improvement idea per month at least (their bonus depends on it!). This company is not only very succesfull as an employee, but also as an enterprise and earns above average within it's sector (as do almost all great places to work).

I have good news for you, even if you yourself may doubt it: By fusing discussion you (and this blog) are driving innovation. By bringing fresh ideas to your clients you innovate (have you ever implemented an idea from a different source without adapting it to your client?) and by giving your employees a channel to focus their creativity on (INNOVATION MANAGEMENT) you get the benefit of it, without the hazards of untested new ideas for bridges.

If you have time I would like to invite you to our 3rd innovation & future management symposium (27th of October in Münster, Germany), this would give you some thoughts to be skeptical about (http://www.noventum.de/).

P.S.: Before I meant triggering of course.... no way to edit the title

back the truck up

Innovation as one duty does not make someone an innovator. Assembly line workers are not innovators. their job is not to innovate - it is to bolt the doors on. One idea a month does not change the description of their role. that kind of innovation is a minor (but extremely positive) activity happening over and above the day job.

Sysprogs are not innovators. We don't want them writing a shonky Perl script that nobody else can read or support just to show how clever they are.

Programmers are not innovators. We don 't wan thrm using clever constructs nobody else can debug.

Even architects should seldom be innovators. Most of the time innovation is too risky or expensive.

As i said, production line analogies break down dangerously if not used with care. I prefer road building. If a road or bridge or culvert is in a particularly challenging location, or if we just want a set piece to show off our innovation skills, they we need to invent new ways to do certain parts of the job, but the rest of the job will still be done the same old way. We don't need to invent a new kind of asphalt or concrete every time we lay a new road. We don't want to do anything new. We want to do it the same proven way, we want to do it the best we can as cheaply as we can. If the road crew innovate in the way they back the truck up or park the roller, good on them. That doesn't make them innovators, and telling them that's what they are would only encourage counterproductive behaviour.

Another perfect example: New Zealand's post-modernist new age primary teachers are screaming blue murder because the government wants to measure whether they are actually teaching the children anything and == GASP == tell people the results!!! One school principal, in charge of our children, condemned this because teachers would focus on basics and not do anythign creative. Quel horreur!

I for one would rather the teachers teach my kids to read and write than be trying new methods at my son's expense. If a school is utterly dysfunctional and a teacher invents a new way of getting to the kids - as heartwarmingly portrayed from time to time in the media - then good on them. If a school specifically designed as a research establishment develops new techniques, good on them. But I'm paying teachers, and I want them at a minimum to teach Jack maths and literacy. There are many other things we - the teachers and I - can teach him but I'd be pleased to measure that set.

shonky Perl script = innovation?

Somehow I have the feeling that you are using the term innovation not meaning: "Creating something new from existing components or methods which improves the current situation" but meaning "doing something in a way which noone has done before and probably no one with a brain of his own would do".

According to your comment above the following equations are true:

  • Innovation = "shonky Perl script that nobody else can read or support"
  • Innovation = "clever constructs nobody else can debug"
  • Innvation = "...too risky or expensive"
  • Innovation = stop working towards a goal

In addition to that you use unverified and unproven figures (see the chokey comment above) to back your statement. Rob, this is below your standard. Usually you are right on with a skeptic view and you use common sense and real figures (and good sarcasm, I can appreciate that). But in this case you are "guilty" of the errors you usually blame software manufacturers for.

Or maybe, you have a different definition of the term innovation (which maybe many people share, according to the comments on this post). What do you mean when you are talking about innovation?

Marc

whatever people want it to mean

See here's the disconnect. I'm talking about innovation to mean whatever people want it to mean. I'm talking about innovation as an excuse to ignore the professional standards of accountability and quality and consistency and good practice. I'm talking about how encouraging IT peope to be innovators can be taken as carte blanche to ignore the rules we're trying ot introduce and do their own thing. About how change control and enterprise architecture control and other formalisms such as ITIL process and COTS and... are apparently stifling their flexibility and productivity and CREATIVITY.

I understand the definitions of innovation - we discussed it way back in this thread. There is innovation as invention and there is innovation as cross-pollination of fresh ideas. The meaning isn't relevant - people are not paid to be innovators. Innovation is a value add. innovation is a part of continual improvement. Innovation is something you do after you get the basics right. If people keep tinkering with the servers or SAN or network because they consider change control to be impugning their integrity, if programmers ignore coding standards and toss out slapdash documentation, if DBAs can't see the problem with knocking up embedded database procedures to provide core operational functions, if business analysts want to pass critical data across hosted collaboration tools.... if you can't get basic levels of professionalism and control, the LAST thing you should be doing is trying to introduce a "culture of innovation" or slagging off IT because they don't "lead the business".

It's like walking into a dysfunctional concrete-jungle high school and encouraging them all to express their inner selves. You'd be better off by starting with haircuts and no drugs in lockers and be here for class.

The first thing you do...

... is to become professional. To become professional you stick to your promises and you do your job. Yes. But you will not make your organization more professional by hammering on "innovation" as a lousy thing. If you do that, you will become less professional. Your key people (professional & creative at the same time) will start to feel unappreciated and think about leaving. All the mediocre people will start to assume you are making their jobs boring, they will put less effort in and lousy people will be happy, because they can hide pretty well in your formalistic approach. Result: Productivity & professionalism goes down.

To do it right you emphasis the importance of innovation and focus it on becoming more professional! That is hitting both nails with 1 hammer (quite hard, true). Let them be creative about standardizing their work! Let them be creative in defining the common coding standards and let them be creative in defining ways to share critical data.

If making a "culture of innovation" is the last thing you do, it may very well be the last thing you do (pun intended).

So Rob, why are you bickering on the word innovation, while you should be complaining about the tremendous lack of professionalism? Or, even better, boast about the advantages of being professional! A skeptic may still be creative ;-)

EDIT: Forgot to answer your high-scool example. In that case you may need the tough schoolmaster first. But you would have to really be the schoolmaster, the janitor wouldn't cut it. And neither would the english teacher.

Edit 2: Changed would to wouldn't

a wake-up call

Like any good debate we're actually on the same page.

I think any past staff of mine will tell you I encourage innovation (and I innovate). At the level of an individual organisation who have their act together I'm all for it.

At the industry level I took an extreme position here (something I've done once or twice before) to balance what i see as a nutty extreme on the other side (democracy is the balance of opposing positions). As a profession we do indeed lack professionalism and that is the solution is as you rightly point out. But folk complain publicly about how professional disciplines stifle innovation, and it is that position that this blog article attacks. Other well meaning folk promote thet idea that "IT must be innovative" without pointing out (or indeed understanding, sometimes) that innovation is a good thing after you have the basics under control. This is a wake-up call to them. "Innovation" is one of those motherhood terms that is becoming an unthinking assumed given, like "best practice".

Treggering a heated discussion?

Hi Skep,

A good article to trigger a heated discussion, but right now you are talking about IT to turn into a Ford production line from 1910 (incl. the Ford-Face). I do believe IT should work hard to become more standardized and more orientated towards the industrial production, but that does not cut out creativity nor innovation out of the process. To the opposite. The IT even HAS TO reinvent the mass production (amazons e2 service someone?), otherwise you will just have the NIH (not invented here syndrome).

If you look at modern producers you will find that they invest a lot (and I really mean a LOT) into innovation. So you can either try to go the long way, from Ford in the 1910s to modern production environment (1960) to quality management, KAIZEN, BPR and others (80s) to lean (90s, incl. early participation of employees) and innovation management (now?). Or you can try to catch up and start with modern management immediatly. It may be harder, but it will be fruitfull.

Regards,
Marc

P.S.: No claims on completeness on the management methodologies are made ;-)

http://buzina.wordpress.com

manufacturing is not a good analogy for IT

Unless we work in the software industry, no-one in IT is manufacturing. We create bespoke services. The manufacturing analogy, especially the car industry, is a very bad one for IT. They taught us a lot about some processes, but their models are very often not applicable to IT, either to those building software products or - even more so - to those implementing IT in end-user organisations. We don't produce hundreds of thousands of identical services for a mass consumer market. Their innovation is irrelevant those tasked with assembling commercial services within an organisation

No mass customized products?

Hi Skep,

I am consulting a large service provider which provides services to >500 similar companies. They do mass production and that is good that they do. The same will apply to many other service providers. Maybe the car analogy is a little too single minded, but it still has much to teach us and is not too far away. I do not claim that the car equivalant to IT, but there way of handling the manufacturing process. Too many IT shops believe they are artists (in that area your innovation critique is still not OK but understandable).

The best comparable model (in my opinion) is manufacturing system engineering. They us a a large set of standardized components (standard production) to build a customized environment. The result is e.g. a production line, which (in the case of IT) is not sold but rented along with service to a company. So lets look there for comparison.

And what do you see: They rely (in Germany, somewhere else they copy ideas, true) heavily on innovation. To build the best machines is their important claim and they still do this using standards and fixed processes.

Innovation is anathema to service providers

A service provider "mass produces" in the sense that they try to drive all clients to a standard lowest common denominator of process, reporting, server builds, service levels etc in order to achieve economies of scale. In that sense they mass produce yes. And NONE of their staff are allowed to be innovators - they are production line workers.

they only mass produce one part of their product though: server builds, hardware, contraxcts, SLAs. They build only one process model, only a small number of standard builds/SOEs, only one organisation or reporting system or or IT operations etc etc The automobile analogy for IT would work only if everyone bought their own seat but rented time in the same car.

they also depend on being low risk and high dependability. Innovation is anathema to service providers. Service providers adopt good practice which is the opposite of innovation. Good practice is proven and widely adopted. You can build the best product using good practice if best is measured by quality, dependability, affordability etc etc

Even if a service provider decides to launch out into innovative new products - and most don't - they have a small research team who test the innovation, then they standardise it and put it on the production line just like an automobile manufacturer. Google and Amazon spring to mind.

So 90% of service providers don't innovate at all. 10% differentiate by having innovative products, which are created by innovators who are less than 5% of their staff. So 10% of 5% of service provider staff are innovators. The rest are production line workers, abeit highly skilled ones. And they need to get used to that idea - that's the point of my article.

Chokey the Chimp!

Your coneception of the production line is so 30 years ago.

Today a production line is devided into groups of people that form a team and that will manage their own work. They will innovate on their own methods and see themselves as service providers to the rest of the production line. And in contrast to your text, this does not reduce quality nor does it increase the variance. These people all work towards a same goal and they use all the resources they have (and that includes their creativity!)

I just have to assume you are ranting, since your claims could trigger chokey the chimp with a crap factoid (high I would guess, did you make the criteria catalog public yet).

Again (and again and again) innovation is and should never be confined to a small and elite group of R&D staff. i do not mind having an R&D team to TEST innovation, but they should never be the (only) ones regarded to create innovation. They are basically there to filter innovation to select the more usefull ideas.

Almost right :-)

Service providers have two sets of services, core services and supporting services. Core services tend to be standardized according to the model in your post. Supporting services is where the innovation and differentiation typically occurs. Typically 20 to 30 percent of staff are assigned to the supporting services and one of the requirements is that they be capable innovators.

I have seen the reverse, standardized supporting services and innovation at the core level, but it's not as common and staff innovators typically are in the 10% range.

David

Depends how you define "Innovation"

...and I'm not talking about a pure dictionary definition. Rather, in context, I prefer the view expressed by Peter F Drucker in Innovation and Entrepreneurship.

He suggests that "Innovation creates a resource. There is no such thing as a 'resource' until a man finds a use for something in nature and thus endows it with economic value."

I agree with your premise if you're talking about a technical solution to a problem devoid of a business driver or a technical invention without a business purpose. However, if IT maintains contact with and elicits feedback from customers, then innovation, in the economic sense that Drucker uses it throughout the book, is almost a requirement for survival.

David

the probablility that IT will on its own initiative invent

I understand what you are saying. In the event that the business has a strategic need for innovation and that innovation has an IT component, IT can work to help deliver thant innovation. That is one part of our job (the other part is to keep the lights on). That doesn't happen that often but it happens and IT takes a role.

In order to fulfull that requirement to support a business innovation, IT should in general still respond by assembling standard components using controlled engineering disciplines. The probability that IT will need to invent something new (approach, process or technology) as part of a business innovation is exceedingly small. Even the probability that IT will need to introduce something they don't already have is small - business innovation less often implies IT innovation.

And the probablility that IT will on its own initiative invent a valuable innovation and take it to the business is so small that talking about it is just silly.

Yes there are fun new innovations that come out like wikis and Twitter and yes they should be looked at for their potential to add to the business and the business should be told about their potential so as to help stimulate innovation. That is the job of one person in the Enterprise Architecture team. The rest of you get the **** back to work!

Innovator Definition

I agree with many parts of what you are describing, but I think there is a little bit of a disconnect between how people are describing being an "Innovator". Sure, there are a lot of immature IT "professionals" that believe that driving the business involves dramatic and ad-hoc expirimentaton, but there are also those that see this Innovation trend as simply IT facilitating business change instead of just reacting to it. To facilitate business change one does not need and should not dump convention, standardization, and process. True business innovation requires all of these for any real change can be enacted.

The difference comes, in my view, when IT leaders have setup highly optimized IT service structures with robust CSI processes and then can contribute to the business future strategy state by working with other business leaders to drive Innovation in their areas utilizing IT-centeric solutions that do not exist in the current marketspace. If all of this exists, we are creating much more value than simple cost control.

Syndicate content