In April I wrote a blog post on what books I highly recommend reading. It was because I just had a great session at Fontys Hogeschool about Software Development and Business Alignment. Last Saturday, I had an awesome talk to some very creative people about what really does thrive Business & IT Alignment. (And if it actually exists, as a profession). During this conversation, we also mentioned books. And now I realized that I’ve never shared them with you.

Enterprise Architecture As Strategy, Ross, Weill, Robertson. During the Oracle Enterprise Architecture Executive Summit, Jeanne W. Ross explained how Enterprise Architecture could create a more sustainable and agile business environment. The MIT scientist explains how the Business and IT parts can move together and actually add value to the complete organization. A few things that I’m really glad about is the fact that the books states that Enterprise Architecture is a journey, not something that gets implemented overnight. As well as the fact that EA isn’t about risk and documentation, it’s about facilitating agility within the organization.

Business Model Generation, Pigneur, Ostenwalder. Co-created with over 470 professionals all over the world Business Model Generation provides us with a simple, yet effective, method on how to design a new business model. A few things in this book apply to everything we do in the IT field. It basically is the complete reference we need to build our Business Architecture. When taking a look at the way the business models are generated in this book, there’s a lot of conjunction with my own method to create a ‘talking picture’ (anyone: is this the correct phrase?) on IT projects. A lot of visualisation to help communication and outlining the needs of the project.

SPIN Selling, Rackham. I like simplicity, and this book offers it to us. Looking at the SPIN selling method, written down by Neil Rackham, it gives us a simple, yet effective method in knowing where the ‘Why’ is in the projects we do. Situation, Problem, Implication and Need Pay-off are the basics in information analysis. I’ve written a post about it.

Business / IT Fusion, Hinssen. The best book written about the concepts of alignment. (Although Peter Hinssen shows us the concept is non-existing). This book gives us completely new insights in the way IT has changed, or should change. Will not go further in the matter here, but it definitely is a must-read.

Enterprise 2.0, McAffee. When we take an in-depth look at one of the most common challenges in IT and Business these days, we look at user collaboration. In this book Andrew McAffee gives us insights in the benefits large enterprises can gain using this technology boost. A fun read and shares what new technologies and principles can actually give us.

And then there is, of course, the brilliant book Oracle Application Express Forms Converter, van den Bos.

Are there any other books that you recently read (or a long time ago) that would give us new insights in Business and IT?

“show me the money…”. One of the best films ever made. But what does it have to do with IT? Or with Business and IT alignment? To be completely frank, everything. One of the main things that grasp me every day in my line of job is the total neglect of Business Case value in the projects I encounter.

Is measuring the value of a solution essential for the path that we choose? Yes it is. In the modern days, say somewhere since 2008, we have no choice but to have a clear view on the expenses and gain on every project and IT solution we offer towards the business. Although some organizations gained a tunnel vision on cutting costs. They actually have a point. But they shouldn’t look to just the costs of the project. But also to what the organization will gain from it. Where’s the value?

Measurement is everything. You might not agree. But it’s the most simple thing on earth to know if you’re doing a good job. In IT projects it’s not different. And the most global understood and recognized measurement of all is money. It’s that simple.

Terms like ROI, Business Case and TCO suddenly jump to my mind. But I think it’s more simple than that. When looking at IT projects and the way we govern them we should look into the gains versus costs of the project. Within the iterations that we work in. 

What does the performance of our system cost us in lost revenue? How many customers do we loose if we don’t get ahead of competition? How much money is to be gained in the clear objective of this project?

And more if you think about it. 

Now to the quote you can all kick at: “If we can’t measure it in hard nickel, we will never be able to get it done.”

What do you think? Is money everything? 

Last week I wrote an article for one of the large Dutch newspapers following the news about a 12 million euro project gotten killed . Unfortunately the article was too specialistic to be actually placed in the paper. But that also means that I now have the opportunity to publish it here on Ome-B.nl. I will publish the original, Dutch, text and the translated, English, version below. The English version is translated using Google Translate and might not be that good.

An Opinion.

Dutch:

ICT verspilling bij de overheid.
Hoe kunnen ICT projecten bij de overheid wél succesvol?

ICT projecten bij de overheid gaan geregeld mis en verschijnen steeds vaker in het nieuws. Zo was er afgelopen week de bekendmaking dat de stekker uit een 12 miljoen euro kostend project is getrokken bij het Ministerie van Justitie. Dit is niet een losstaand incident. Het komt veel vaker voor.

De geschiedenis wijst uit dat meer dan zeventig procent van de ICT projecten meer kosten dan begroot. Een niet misstaand getal. Dit zijn echter nog steeds succesvolle projecten. Ze zijn namelijk in productie genomen. Maar wat kost dat nu eigenlijk?

Exacte cijfers zijn niet bekend. Schattingen geven aan dat er per jaar zo’n 4 á 5 miljard euro over de balk wordt gesmeten door mislukte overheidsprojecten op ICT gebied. Hierdoor wordt er flink gespeculeerd over de mogelijkheden om dit te voorkomen. Op een verkeerde manier.

De vinger wijst naar de wijzigende politiek en nieuwe inzichten. Deze zorgen ervoor dat complexiteit en omvang van de te ontwikkelen systemen toeneemt. Wet- en regelgeving veranderd gedurende het project, het systeem groeit en de complexiteit neemt toe. Maar moeten we nu deze veranderingen accepteren of tegengaan?

Tegengaan, stelt Jan Friso Groote. In de uitzending van het televisieprogramma 1Vandaag vertelt de hoogleraar informatica aan de Technische Universiteit Eindhoven dat veranderingen in inzichten de reden zijn voor de uit de hand lopende kosten van automatiseringssystemen. We schijnen te moeten voorspellen en de risico’s dekken.

Voorspellen houdt het tot in de puntjes beschrijven van de functionaliteit in. Dit ontwerp zal dan getoetst worden door een commissie die gedurende het project in de gaten houdt of het project zich aan het plan houdt. De risico’s dekken. Het project blijft groot en complex. Door controle en risico dekking zelfs complexer. Veranderingen in inzicht zijn niet langer mogelijk. Ook niet als het iets toevoegt.

Veranderlijkheid in de omgeving, zeker in een politieke, is echter een vaststaand feit. We hebben dus twee mogelijkheden. Veranderingen niet toestaan om risico’s te vermijden, of budget vastleggen om veranderingen te faciliteren. Om uiteindelijk waarde te creëren.

Doordat de totale kosten van ICT projecten hoog uitvallen zijn de eisen die aan het op te leveren product worden gesteld erg hoog. Er is de wens om alle gewenste functionaliteiten in het systeem te plaatsen. We willen, als het ware, de wereld automatiseren. Alles doen wat we willen. Hierdoor streven we vaak tijdens projecten naar een onrealistische perfectie.

Om deze perfectie te benaderen rijzen de kosten, die moeilijk zijn te voorspellen, uit de pan.

Bij de meeste ICT projecten is het merendeel van het budget gereserveerd voor voorspellen en risico’s dekken. Deze activiteiten, hoe belangrijk ook, zorgen echter niet voor enige waarde aan het uiteindelijk op te leveren product. Alleen het product voegt waarde toe aan een organisatie, documentatie en sturing niet.

Hoe zorgen we ervoor dat we wel de meeste kosten kwijt zijn aan het automatiseringssysteem zelf? Het antwoord hierin zit in twee elementen. Snel opleveren en sturen op budget. We gaan niet de risico’s dekken, maar voorkomen.

Het snel in productie nemen van een systeem houdt in dat we meerdere malen kleine stukjes functionaliteit beschikbaar maken. Niet veel in een keer, maar vaak weinig functionaliteit. Hierdoor kunnen we snel binnen de organisatie toetsen welke elementen nog moeten worden toegevoegd.

De organisatie kan daarnaast direct profiteren van de waarde, hoe summier ook, die het systeem toevoegt. Doordat de betrokkenen direct in aanraking komen met de functionaliteit is het ook mogelijk om voortschrijdend inzicht te faciliteren.

Sturen op budget houdt simpelweg in dat we sturen op de vraag wat het waard is. In plaats van wat de kosten zijn. Deze benadering zorgt ervoor dat we niet langer alles in een willen doen, maar gaan sturen op wat echt van belang is. We hebben, tijdens het ontwikkelen, altijd te maken met lastige wensen die weinig tot niets toevoegen en veel tijd en geld kosten. Deze kunnen nu makkelijker worden geïdentificeerd.

De uitingen die de laatste dagen in de media zijn gedaan over het vastleggen van functionaliteit voor het eigenlijke ontwikkelen is dus een achterhaalde materie. Het voorstel van hoogleraar Groote zal dan ook zorgen voor toenemende kosten en uitlopende doorlooptijd van ICT projecten. Daarnaast zal dit beslissingen in de politiek stilleggen.

Dit kan er alleen voor zorgen dat projecten nog meer uit de hand lopen en kosten hoger worden. De veranderlijkheid van een politieke omgeving is van essentie in ICT projecten bij de overheid en dienen juist omarmt te worden in plaats van tegengehouden. Anders leveren we alleen maar producten op met niet langer gewenste functionaliteit.

English (using Google Translate):

ICT waste in government.
How can ICT projects in government are successful?

ICT projects in government go wrong regularly and appear increasingly in the news. So there was the announcement last week that the plug from a 12 million euro project is costing drawn at the Ministry of Justice. This is not an isolated incident. It is much more common.

History shows that more than seventy percent of IT projects cost more than budgeted. A non misstaand number. These are still successful projects. Because they are in production. But what does it cost actually?

Exact figures are unknown. Estimates indicate that each year about 4 to 5 billion euros over the bar is thrown by failed government projects in the ICT field. This is significant speculation about the possibilities to prevent this. In a wrong way.

The finger points to the changing politics and new insights. These ensure that the complexity and scale of development systems is increasing. Legislative and regulatory changes over the project, the system grows and the complexity increases. But should we accept these changes or to go?

Inhibiting, Jan Friso Groote. The broadcast of the television tells 1Vandaag science professor at the Technical University Eindhoven, changes in understanding the reason for the runaway costs of automation. We seem to have to predict the risks.

Prediction takes it to the last detail describing the functionality. This draft will be reviewed by a committee during the project monitors issues or the project is to keep the plan. The risks. The project remains large and complex. Through control and risk cover even more complex. Changes in knowledge are no longer possible. Even if it adds.

Variability in the environment, especially in a political, is an established fact. So we have two possibilities. Not allow changes to avoid risk, or budget to capture changes to facilitate. Ultimately create value.

Because the total cost of IT projects fail, the high demands on the product set to deliver very high. There is the desire for all the desired functionality into the system to place. We want, as it were, the world automate. Do whatever we want. We aim at projects to an often unrealistic perfection.

For this perfection to approach raises the costs that are difficult to predict, from the pan.

For most IT projects, most of the budget reserved for predicting and risks. These activities, while important, does not provide for any value to the final product to be delivered. Only the product adds value to an organization, documentation and guidance not.

How do we ensure that we have lost most of the costs to the automation system itself? The answer lies in this two elements. Fast forward and deliver on budget. We do not cover these risks, but avoid.

The speed of production of a system means that we repeatedly make small pieces of functionality available. Not much at once, but often little functionality. This enables us to quickly review what elements within the organization must be added.

The organization may also directly benefit from the value, even briefly, the system adds. Because those involved in direct contact with the functionality it is also possible to facilitate progressive insight.

Focus on budget means that we simply send the question of what it’s worth. Instead of what the cost. This approach ensures that we no longer want to do everything in one, but going forward on what really matters. We have, during development, always difficult to deal with demands that have little or nothing to add, and much time and money. These can now be easily identified.

The statements in recent days in the media are made on the recording functionality for the actual development is an outdated material. Great professor’s proposal will also provide for increasing costs and turnaround time leading ICT projects. In addition, the decisions in politics halt.

This can only make more projects out of hand and cost increase. The volatility of a political environment is essential in ICT projects in government and should be properly embraces rather than stopped. Otherwise, we only supply products with functionality no longer required.

If you believe a lot of marketing around Enterprise Architecture it is. But in the practice the overkill of EA strategies and implementation really brings a lot to mind when it comes to solutions on Business and IT misfits. IT doesn’t support Business as much as it should. IT doesn’t push Business as hard as it could.

But where does the problem lie? Probably in the simple fact that, although, Enterprise Architecture tends to focus on infrastructural issues and application challenges instead of focusing on Business Architecture and the goals and challenges of organizations.

Besides this, there is a bigger issue at hand. Enterprise Architecture’s main implementation within organizations is to avoid and address risk within large enterprise IT projects. To make sure the project will have the right focus and responsibility is taken in account. Not to support Business / IT Alignment. Because of this, EA has the tendency of becoming nothing more than a ‘must have’ documentation strategy. Instead of real added value.

Too bad, because the right implementation of Enterprise Architecture, using a creative, pragmatic and agile approach, really can be a solution for non-performing Business and IT strategies. The proper way of looking at EA is, in this case, not a risk manager, but a facilitator to change.

On Monday September 20th, I will attend Oracle’s Enterprise Architecture Executive Summit (gee, that’s a long name…). One of the breakout streams is on the topic of ‘EA and Business Alignment’. I really do hope that we (finally) start talking about agility in Enterprise Architecture instead of control and management of pre-defined outcomes.

In my humble opinion (which everything in this blog is actually about, my opinion) Enterprise Architecture has the possibility to drive Business goals and facilitate change and agility. But the main question remains: are the present Architects able to change themselves?

(Disclaimer: It’s not my intention, nor is it ever, to offend or make fun of anyone. The above simply states the notions I have during my work. If, in any way, you disagree or feel offended, please let me know.)

In most Enterprise Architecture frameworks the Business Architecture drives the Information Architecture.

But is this completely accurate? Didn’t we gain some new insights over the past few years. Information, and especially technology (or IT) Architecture can drive the Business Architecture, creating new and previously unimagined possibilities for organizations.

Modern IT isn’t anymore about offering the structure businesses can build upon, but more and more about offering insights in the way new technologies can create opportunities and thrive business. We talked about this principle before, it’s the ‘new CTO’ versus the ‘old CIO’. Both approaches are necessary in the modern organization. IT is helpful, but it also can actually push business.

This is exactly why IT and Business Alignment is a necessary, but outdated thought. It is time we start thinking with one, common goal in mind: the values set in the Business Architecture, the why, what, who and how of the organization.

T minus 6 weeks. The anticipation for this years Oracle OpenWorld is kicking in. What can we expect? Are there things we cannot participate? What is the great unknown and which sessions are a must? All these questions for one great week in San Francisco.

Like all OpenWorlds before this one, there will be loads of sessions to attend (1800 and counting). Various dinner parties to attend. Open bars. And sailing trips on the bay (hopefully this year I won’t fill up my agenda that much, so I can finally actually go on the Oracle Catamaran… ). Let’s face it, I got a Blogger Pass and I’m an Oracle ACE, so I can attend pretty much everything. But it just might be too much. What’s worth the visit?

There are some promising sessions about Oracle Application Express 4.0, like one on JavaFX in combination with APEX and a session on Large APEX projects. Service Oriented Architecture is bigger than ever with sessions like one by my colleague Edwin Biemond about migrating from Forms to SOA.

Are there any sessions you think I really shouldn’t miss out on? I’m really looking forward to learn more about Enterprise 2.0, Architecture principles and more on this years Oracle OpenWorld.

Opening up all cliches on Business and IT alignment. Yesterday, I had a discussion on how IT really could solve business problems. One of the statements that came by was that we simply needed to listen to the business in order to understand what IT has to do. This is, in my opinion, a bit too simplistic.

In the past few years we learned that IT and Business aren’t two different parts of an enterprise. Business processes are not just supported by Information Technology, but IT became part of the workflow of most organizations. Therefore the ‘you ask, we deliver’ mentality is not effective anymore. And therefore Business and IT ‘alignment’ is not a goal anymore. We need to entangle, fuse and combine.

Alignment still gives us the thought that Business and IT are two completely different things. This is no longer the case. IT became part of the Business. And only when this principle is understood, IT can become a driving force within (and not behind) any organization. As discussed in previous posts, this is the new vision of the CTO.

New technologies like BPM, SOA and other middleware solutions are based on this principle. But not always implemented. When integration of different ‘silos’ in organizations becomes pure technical, success is a guess. Determining the success factors for the entire organization (both for the Business as well as IT) is critical.

What do you think? And can you give me an example of projects in the IT domain where the success factor is a lottery?

Today Oracle will release it’s next generation in Business Process Management, the BPM Suite 11g. One of the things that stand out, at least in buzz words, is the fact that it supports something called ‘Social BPM’. So what is this and what will it do for the business?

In one of the Oracle BPM WebCasts, Dan Tortorici and Peggy Chen, respectively responsible for BPM and Enterprise 2.0 Product Marketing, tell us where the bridge is to be found between Enterprise Collaboration and Process Modeling. The new approach shows us how to create an Agile framework to facilitate fast changes within the organization while effectively combining formal workflows with informal collaboration.

In traditional application environments, we think in ‘silos’: separated departmental systems that contain specific information. Business Process Management and SOA approaches to architecture helps us to combine those data and effectively create a flow that supports business processes that depend on multiple silos. Using this approach we can steer on the process, instead of information and data. When we take a deeper look inside these processes, we learn that there is one more element missing: ad-hoc changes to the process, human interaction.

In the ‘classic’ approach to BPM human interaction is merely a task, what the people do behind the buttons is merely described as an action, not a process. And this is where collaboration and user interaction comes in. Using the possibilities of the Oracle WebCenter Suite, Social BPM focusses on combining business processes and user interaction.

Working from a user centric design model, Social BPM offers the possibilities for the end-user to create, monitor and participate in business processes, al within the WebLogic Collaboration Suite. This new element in the Enterprise 2.0 philosophy adds an enormous, in my opinion, breakthrough: we stop using information statically but combine the dynamic of user interaction with the structure of Business Process Modeling.

The User Experience is now total: we have insight in our dashboard on the complete process, which participants we have, what information needs to be combined and where our process is headed. This gives us, possibly, the ultimate user interface on business applications. All data needed to effectively proceed in the business can be combined with the process, which can be modeled within the same user interface.

Today at 19.00 CET is the official launch of the Oracle BPM Suite 11g.

“Fear and Complexity within a project, can be an explosive mixture that makes sure any project can fail.” According to the experienced agile project manager Martin van Borselaer Fear and Complexity are the main project killers. “Fear restrains us from doing or saying the things we know are right”, Martin says during a great session he gave the company last week. “It is, in combination with complexity, the main reason projects fail.”

Fear, from the different actors within the project, can have different sources. The customer can be afraid that the project will cost too much, the quality will be bad or that he works with the wrong requirements. The supplier has it’s own fears. Under budgeting the project, dissatisfied clients, damage to his reputation or unsatisfied co-workers. A project manager can have fears like a bad functioning customer organization, team or technology he has to work with. And the team member is possibly afraid that the balance between his private live and job comes into question.

“There are also deeper fears to consider within a project” Martin tells, “you can think about things like the livelihood of the employee, loosing his job, not making promotion”. ”Or more emotionally based fears like the ego or status of actors in the project” Martin explains. “Fear is a very bad advisor in a project situation. It can offer a excessive reaction by making problems larger than they really are, or no reaction at all by denying the existence of a problem.”

In projects this can mean that we work with fixed date, price unknown scope projects, excessive analysis and design or not being able to grasp reality and therefore sticking to the original plans without necessary adjustments. Martin explains that most of these examples are based upon actors being afraid, offering false hope. Working together, not looking at the team in terms of heroes and losers, is an essential part of the solution. Transparency in the project team will facilitate mutual trust and therefore a real team where fears can be tackled.

Another project killer is complexity. “Simple is Stupid and Smart Sells are main criteria these days in IT projects. Or, at least, it seems to look that way” Martin says. “The assumption lives that we can control and predict this complexity, but the reality is that we can’t.” Martin explains that, during the start of a project we don’t know what we want and that we don’t know how to get there. Working together and steering on new insights is the only way of getting on a point where we want to be.

Working together, small steps and learning and improving are essentials to tackle both fear and complexity within a project. Organizations that know that change is to be expected and understand that steering constantly is normal will have the competitive edge. It’s essential that scope is put together on functionality, not by expertise. Bringing together expertises will reduce fear and complexity. Or at least make them more understandable. In this way we can actually manage them.

Martin van Borselaers blog is a very interesting place of knowledge on Agile project management, you should read it.

UPDATE: Martin now offers a once in a lifetime opportunity: you can get his advise, for one day, for free! So if you want to have a fresh look at this project of yours or more information on how you can do things different or even better, look on the (Dutch) Whitehorses website for more information.

In recent times, everything changes. Less money available, more functionality required and competition in most markets gets harder because of pricing competition and tougher selection by customers. This can also be seen as a challenge.

Since the early 1980’s Iterative Software Development is evangelised, but still the most widely used approach is the waterfall model. Technology has taken a quantum leap in the past years, but most technology implementations are still using tech from decades ago. Software design is still done in the IT department. And the list goes on.

In the 2008 and 2009 IBM CEO Study’s Change has been identified as the mayor challenge for IT related organizations. Only to be overtaken in the 2010 CEO Study by complexity of systems. Today’s market space challenges us to create more complex and innovating solutions, in a short timeframe.

When markets get tough, creativity is the one part that can separate businesses, making sure gaining market is achieved, even in stressful times. The time to change IT strategies is right now, especially now.