The pillars of the effective IT enabled organisation

I just want to come back on the subject of the divide between IT and the business. In order for an organisation to use IT effectively, I belief the organisation should address the following key items to be of mutual responsibility. There is much more to effective IT management, but these are the key issues to work effectively together.

Integrated leadership
IT should be integrated within the organisation and that starts at the top. It is on the one hand setting the example but on the other hand to make sure that business and IT issues are addressed through an holistic approach.

Integrated project management
IT projects are always part of a business project. If you address IT projects in isolation, you run the risk that the associated business aspects of the project are not addressed timely and correctly, that the business changes differently than expected by the IT team or that it does not change at all. Or that simply business and IT staff feel frustrated because they feel that they work too much in isolation. Having a business project manager without associated IT project management runs the risk that the IT team feels that they are not appropriately managed. The same story applies the other way around. An integrated approach is according to me the best option.

Business process redesign / requirements and system design
I discussed this in more detail in my post “Why business requirements don’t work” but in essence the introduction of a new system and the change of the business usually come hand in hand. Again, the holistic approach is essential to obtain the envisaged benefits and to avoid that you build a system based upon old and ineffective business procedures. You don’t want to build for the past but for the future.

Skills to use IT / support the business
Using IT is not easy. Unless we talk about a few modern commercially available tools that are mass produced such as iPhones or iPods, the majority is custom build based upon constant changing business needs and the ongoing advancement of technology itself. We need to accept that IT is not perfect and that the business need to learn to deal with that. IT on the other hand has the responsibility to hold the business by the hand and guide them through the stormy waters of the world of technology. We need to provide sturdy vessels and make sure that systems are at least stable and that we deliver as we have promised. The integrated leadership will set then the right course based upon informed business strategies and technology capabilities.

Speak the language of IT / speak the language of the business
Underpinning the holistic approach to IT governance, we must make sure we communicate well with each other. IT is too important for the success of the organisation that it is too simple to say that IT should speak the language of the business. Yes, they should, but you will simply be much more successful if you are able to speak the language of IT.

Money must roll, information must flow

Just like money put away in an old sock loses its value, information that is locked in a database also loses its value. It is more valuable to use the money to improve your position or at least to put it in a bank account to earn interest. Information should flow from one business process or department to another and if the operational use has past, when stored in a data warehouse you still earn interest on it.

When we build systems we tend to build them for a single purpose only or within the context of a single department of the business. The effect is that the data in the systems don’t follow the complete sequence of processes since a department or process never stands on its own. Even if you would consider the odd scenario that a department has little to do with the rest of the business, there would be at least the Finance department that one way or the other is involved to get the paid for the provided products and services or to pay contracts and salaries.

When I say that information should flow, it does not mean that the exact set of data should be passed on from one system to another. It could very well be a subset or an aggregate. The concept is not much different as within the boundary of a single high level business process supported by a system where various sub-processes pass on information to other sub-processes.

Within the context of a single system, the information is usually stored in a single database and therefore readily available for all functions within that system. When we want to realise the information flow between systems, this becomes more complicated. It is not always possible to retrieve data from the other system for various reasons. It could be that the database cannot be accessed directly because it is a closed or remote system, it could be that the other system does not provide interfaces to achieve this or simply because the other systems technical architecture is very complex.

The old fashioned way by providing the user in the one system export the data into a file and in the other system to upload the file. When interfacing with banking systems this is still common practice. API’s or web services are more modern ways of implementing interfaces between systems. But those are not always available and if you want to make them yourself you can be confronted with unclear technical documentation and technical structures within the existing systems.

Specifically when you want to interface with ERP and COTS systems, you too often need to rely on customisations that become expensive to maintain in the context upgrades. No wonder that systems integration have become a specialised area of expertise within IT.

It is not always easy to achieve integration between systems and to let the information flow. Due to the cost and associated risks in relation to maintenance (you easily forget to include the implication for the other systems in your projects) and risks in relation to upgrades, you need to carefully consider how and when you want to integrate systems.

But I found it always very rewarding once you have achieved the end result. So often you experience that information that needs to be passed on from one business group or function to another goes with many complexities. Not the right information is passed on, insufficient information is passed on or it is passed on too late. Segregation in areas of responsibility and an attitude of “not my responsibility what happens over there” can make these situations very persistent. Even when you as IT person can identify a solution and the benefit of the automated flow, the distributed ownership can make it difficult to find the funding and business commitment to make the improvement. And let’s not talk about the complexities to achieve automated information flows across organizations.

As an IT department you should always consider carefully how you build your system and information infrastructure. If you implement a system, you should consider what your next project could be. Will you be able to extend easily and can you integrate the solution with other systems? Sometimes a quick solution for the problem at hand can be found with a simple off-the-shelf or externally hosted system. But if that means that you are limited to append future modules and or to link other systems, you might want to consider options that allow for future expansion to or to consider in-house development.

For in-housed solutions, I try to assure that data is always stored in only single place. New systems will need to access the database of the existing systems such that the software applications might look to the users as distinct systems, they all work in harmony and operate as a single integrated solution. If this is impractical, you’ll need to use interfaces such as web services to obtain the ‘other’ data in real time without the need to store a copy in the application’s own database (you would need to store a reference to it though).

With the advancements of technology, we use more and more large data objects for sound, image and video. The requirements for data storage has jumped significantly in the recent period and this will continue for a while. In combination with the increased opportunities for communication we’ll see that a plethora of copies of those objects will exist within the organisation and around the globe. Just like in the real life where we should not litter, we should not do this in cyberspace either. In the context of green IT both users and IT have a responsibility avoiding too many copies of the same data.

Just consider the fact when you send an email with an attachment and how many copies this will create. If you send an image, you probably have this stored in a special environment where you develop and maintain images. Then you will have a final copy stored in a location from where you attach it to the email. If you send it to 5 people, they all receive a copy in their mailbox plus your own copy in the “send items” folder. If they store it then again in their file systems, you have another copy. This could result into 13 copies and if all this is backed up daily and you keep backups for at least 30 days, think about how many copies you have created here. We might say that disk space is cheap, but don’t forget that the disks still need to spin.

In this context, I would not be surprised that email solutions soon will emerge where you only add a reference to the object in the email. When the recipient wants to open the attachment, he will do this from the location of the sender. The recipient then has the option to store a local copy or to leave it remotely. The cloud and the Internet contribute significantly to all this littering and I think the cloud and the Internet should also bring solutions to minimise it. Information should flow, but use a single copy of the data where possible.

The issue of the flow of information is foremost an issue to be addressed during the business analysis phase. This is the best moment when you can identify in what other business areas the information could or should be used and what future opportunities there might be. It is also the moment where the difficult issues around business ownership of data should be addressed. When this cannot be resolved, it is best to escalate this up into the hierarchy to see if you can get a resolution. Awareness of senior management around the relevance is a prerequisite. Even when you might not want to implement the integration immediately, the understanding for the choice of the technology solution is important.

I always enjoy it very much if I see when information flows and that systems and business processes work in unison, even though some of those integration points can sometimes be a pain to maintain. As an analyst, consultant and architect, I follow the information.

We should stop talking about ‘the business’ versus ‘IT'

I have been reading lately more and more about the divide between IT and the business while even the word “hate” is being used. Proper IT Governance is the solution to the answer. In my simple words IT Governance means integral management of business and IT. Work side by side at all levels of the organisation.

(see also the blog post from the IT Governance Evangelist)

Issues that business managers have with IT range from problematic communication, bureaucratic processes, lack of understanding of the business, too expensive, does not deliver and does not deliver on time and so forth.

The key problem is that from the top onwards, it is considered that IT should be a commodity. It is considered a cost center and not an enabler. You just ask, the solution should come quickly, easily and it should just work.

Unfortunately that is not the case. The number one reason is that IT simply is not a commodity. Bad luck for Nicholas Carr, but most of IT simply is tailor made for the enterprise and that whatever we could call a commodity changes almost daily. The parts that these days could be considered a commodity (e.g. networking, hosting, devices) still require expert management. If you lack this, you run a high risk that you don’t get the quality or price you could get. (You’ve spend so much effort to earn the money. Then why just waste on unnecessary expenses?)

Most business systems need to be tailor made to the uniqueness of each business. It simply means that there is much business analysis and much engineering required. It also simply means that knowledge about the solution is scarce. If systems change every day, how do you expect the helpdesk to keep up? And there is so much of it. What would be a bigger job? Engineering a new car or a new word processor? But through our desktop we don’t drive only the word processor, we want to drive 30 aeroplanes, 6 space shuttles, 3 submarines and 45 different cars. (Maybe I’m going just a bit too far, but you get the point – how many helpdesk staff would you need for that?).

IT solutions must be unique to the business because the business wants to use it to distinguish itself from its competitors and have that unique advantage. As a business you need to understand IT in order to get the most out of it and leverage from the opportunities. If you don’t, you simply have higher cost, are less productive and just don’t have that competitive edge. So I would think that it simply makes sense to make sure that your business managers get IT.

Now, IT comes with a few intricacies. It changes all the time. Every day there is new technology that you can use. And we want to use it. We want use it before it is robust enough that there are almost guaranteed no stability issues. It is getting better these days. Just compare Windows XP or Windows 7 with the previous versions. But still… And when you use it, you use quite often uniquely engineered solutions. And that means that by definition it is not as rigorously tested and completed as it would be with something that is mass produced. That would be too expensive. And it is already expensive due to its unique engineering. Besides this vendors and new technology make that every system has a different user interface. That's not making life easer either.

So does IT matter? Yes, otherwise you wouldn’t make such a big deal about it. The frustration wouldn’t be that high. You wouldn’t be so reliant on it.

Are IT processes bureaucratic? Don’t know. If you want to build a new 60 story office, it has to go through a certain process as well. However most of that building and engineering effort is hidden from you as a business; simply because it is not unique for you as an organisation. If you would create a new factory floor, it would be unique for your business and again, that has to go through strict processes. That is not considered to be bureaucratic? The difference is that you wouldn’t want to change your mind every day of how the factory floor would need to be set up. But when it comes down to our business systems we want to be able to change our mind daily. Then any process will be experienced as a bureaucracy, the project will take longer than planned and the results will not be exactly as expected.

Yes, the quality should go up. Within IT we change our ways of working, the tools and raw material we use constantly. This does not help either to come with robust results. Why we do this? Because we can do so much more. 20 years ago our information was locked within the boundaries of our organisation, 10 years ago we were able to bring this to any place in the world via the Internet and these days you can get it on any device wherever you go.

We simply want to use this non-robust technology. We all know that there are high risks with Internet banking. Translate this risk to an aeroplane and nobody would fly anymore. As a bank you don’t have to provide Internet banking services to clients. Wait another 20 years until the technology is save enough. But since your competitors are doing it, you want to do it as well. Your customers are willing to take the risk, so you have too.

Just because your IT is not a commodity, because it is so important to you and because there is nothing anymore you do that does not go through IT systems, you better make sure you get IT. You better work very closely with your IT department to get the best out of it.

IT skills are important these days for any business manager and in fact basically for all staff in the organisation. It is not much different as the need to have people management and financial management skills. Businesses that are less successful in governing their IT and leveraging from the opportunities are simply less successful businesses.

Governing and managing IT, defining IT strategies in alignment with business strategies is not easy. It is not easy to get IT for the same reasons as mentioned above. There is no formula that guarantees success just as there isn’t one for managing your people or for managing your enterprise. It means you need to work together as a team, have IT on the strategic agenda and accept that things won’t be predictable. Just as much as the sales and marketing teams will never be able to guarantee that they will meet their predictions.

The level to which this needs to happen can vary from organisation to organisation. For a wide variety of small business I can see that IT does not have too much of a strategic enabler. It is just required to do your accounting. But still, and this applies regardless of the size, you need to be savvy enough to assure that don’t underspend and are not very productive or that you make yourself fully reliant on a service provider without knowing whether you get value for money.

Where the IT department has the responsibility to ensure that the IT department matures in their processes and services, it is a general business responsibility, including that of the IT department, to ensure that IT governance within the organisation matures. IT needs to speak the language of the business and the business needs to speak the language of IT.

Luckily the problems are not as black and white as all those discussions make you belief. Though in my experience the management of IT on the top is a difficult issue, I have experienced in various occasions that the business team and the IT team can work perfectly in tandem to achieve fantastic results. I don't belief that is limited to my personal experience and that there are many more success stories. Though I do envy the guys at CVS Caremark. They don't have IT projects, just business projects. Notice the following statement: "That type of IT governance awareness comes from the top, he says, and is ingrained into every technology-related discussion".

Proper IT Governance is just good business management practice and we should stop talking about ‘the business’ versus ‘IT’.

Read all about WAR and their magnificent album "Why can't we be friends?" on Wikipedia or Amazon.com.

Why Business Requirements don’t work.

The key to a successful system implementation is to have solid business requirements. However in reality this is hard to come by, besides the fact that we too often think that requirements are sufficient to pass on to an implementation team.

As I wrote in an earlier post in my blog, business analysis is an ambiguous term. It covers two different but strongly related and even overlapping disciplines. The first is to analyse the business, its practices and objects to come to a model of the business and improvements of the business. The second is to analyse the need for a system and to model the required system.

This post is particularly about businesses where the maturity of IT governance within the organization is not mature; where there is a divide between the business and IT or where the IT organization or even the business in general does not have a high maturity level. Mid-sized and smaller organisations have additional challenges. They will not have elaborate project management offices or business analysis teams.

The perception is that when you do an IT project, you create business requirements and give these to the implementation team. And that’s where the problem lies. If you would look at one of the better known methodologies such as IBM’s Rational Unified Process (RUP), it says that you should (could) start with business modeling, then to perform the requirements analysis and then do a design phase. The problem is that business modeling and potential business change modeling is quite often skipped and that the design phase is insufficiently performed.

The key issue for smaller and mid-sized organisations is that the concept of business (process) modeling and business process improvement is too often not something that the relevant managers and business staff see the need for. They think they know how they operate and also know what the target process will be. Could very well be the case, but in my experience too often they missed critical aspects. Even if you explain the concepts and benefits of business process modelling as a starting point, they might not relate to the concepts. Managers are often the more experienced experts in their fields and seldom have a Masters in Business Administration. They much prefer to start building straight away and skip any requirements or design phase to save time and money.

The fact that there are many IT services firms out there that are willing to take on projects based upon a flimsy set of requirements does not help either. Why does the internal IT department want to overcomplicate things while you can get the job done quickly and cheaply outside?

Any qualified business analysts understands the concepts of business modelling. However when it comes down to bringing business change, either on a more strategic level or just on some practical processes, you need someone with sufficient experience in what it means to run a business. In the end you are dealing with people’s jobs. Not only that, but also quickly have a fair idea what processes potentially can be supported through automated systems. Someone just coming from Uni simply can’t do this. As a business consultant you need to be able to come into a settled organisation and explain how they can do things differently. The business team needs to trust the business consultant. Therefore it is best that the business owns this part of the project. In most organizations that relationship is insufficiently there with the IT department. In the end business process redesign is not an IT responsibility.

Skipping the business modeling phase brings the risk that you develop for the past or simply develop the wrong system. The business requirements then become too much a shopping list. If you’re not careful it becomes a passive activity and the business analysts has no means to value the individual requirements on their merits. The project might deliver what the business asked for but not what the business needed. If the requirements are collected over a larger group of users, you run the risk to get a rather incoherent wish list; something you better pass on to Santa.

Take an example outside IT. For example a sales rep can have the requirement: “I need a Porsche to visit my clients”. And he’s got a business case: “If I spend less time traveling then I can increase revenue.” Now you can go out and buy the Porsche for him. But business process analysis could identify that there are speed limits and that just a faster car does not help.

However the sales rep does not come with the issue just like that. There is something else hidden behind the requirement. Additional business process analysis could show that the sales rep uses his own car to visit clients and the company gives him a fixed rebate on the driven kilometers. To get the most out of his money, he adapts his route depending on petrol prices at the gas stations. This means he spends more time traveling than necessary.

A solution can be found by changing the financial construction. For example changing the business process by paying him for the actual costs spent. Or still give him a company car but just not a Porsche.

So once you know what the business needs and you understand the target business environment in which the system should operate, the system requirements can be detailed and subsequently you can work on the design of the system. And here we hit another painful element. Designing the system requires two primary things.

Firstly, you need to have a good idea how the users of the system work and how they would work with the system. For example, if they use a certain feature once a year you might implement something like a wizard and guide the user through the process. But if they would need to enter a large amount of data 50 times per day, then you would try to reduce the number of steps and place as much as possible input fields on a single form.

Secondly, you need to know what technical options there are. What are the existing components of systems? How would you normally model user interaction in a classical windows environment, how would you do that with a HTML based system and what are the options with more modern technologies? What will the user experience be and how does that support the users needs?

We hit the border between the applications architect and the business analyst. I see a weakness in the process where we just let the business analyst do the use cases and have the architect do the user interface design. The problem is that you already need to have built up a mental picture of the target system when you model the use cases. If you, as a business analyst, do not have sufficient experience in designing applications, you will not be able to make the optimal use cases. The architect on the other hand, usually does not have had the intensive exposure to the end users and their needs and will also not be able to come to an optimal design.

I managed projects where the architect and the business analyst teamed up and worked intensively together with the business users on requirements and design of the system. This can lead to very good results. That luxury does not always exist for many reasons. You might want to hand over the architecture and build work to an external party. Or the architect is still heavily involved in another project. Or the business users simply do not have the time.

Specifically in smaller projects you easily fall in the trap of oversimplifying the approach. “We all know what needs to be created, so lets write down the requirements and start building. Save time and money.” As a manager I always find this temptation very difficult to deal with. You see the value of the solution. You also see that if you want to take the right approach, the solution becomes more expensive and will be canned. For those smaller projects it usually will go reasonably well as long as you can stay focused, have qualified and experienced people and do not get any disturbances in the project. But if there are too many disturbances or you have less experienced people, the end result is usually not what you had hoped for. You pay the costs later through additional enhancements and a higher level of support.

My ideal business analyst has some years experience as a developer and as applications architect, is up to scratch with modern technology options, has quite some years experience as a business analyst and has good experience dealing with senior management in relation to decisions of how to organise and structure an organization. Unfortunately this limits the number of candidates in the marketplace.

Since the whole issue of business analysis does not only apply to custom development but also for implementation of off-the-shelf solutions and even for infrastructure systems, we just need lots of them. In the past the normal career would be from programmer to designer to analyst to project manager. Those days are over and people pursue careers much more within the same discipline. Maybe from developer to architect but the cross over to business analyst does not seem to happen too often anymore. Business analysts come straight from university and need to build up the required experience.

What I see is that we have foremost an industry problem. The best answer that I see for those cases where you are not in the position to run the project according to the book, is to bring the architect (or the lead developer) into the picture as early as possible and let him work closely with the business analyst during the early stages. Where possible let them both work as closely as possible with the business users. Use an iterative approach of development and test intermediate results with business users and business analyst as soon and as frequently as possible. This gives the architect and the developers early feedback on design and usability. (I am not promoting agile development here; neither do I say not to use it.)

And then there is the last nasty little problem with business process models, requirements and design documentation that I’d like to bring forward. Not always does the relevant business staff read the documentation thoroughly or do they really comprehend what is meant with it. Even if they will sign off on it. It is very difficult to go to someone and say: “You signed off on this documentation, but I don’t think you took the time to really read through it and I don’t think you understand what we are going to build for you”.

The answer to all problems is to have IT management properly embedded in the business responsibility. When you don’t have that luxury (and I guess that is in the majority of organizations), the best option is make sure your analysts and architects have the understanding of what the business needs. Not just what they have asked for.

One way to resolve the problem that I can recommend is through Service Delivery Managers. They stand with one foot in the business and with another foot in IT. They take care of day to day support to the business and manage small projects. With their in-depth knowledge of the business they are in a good position to vet the requirements and design on their merits. They have a fair idea of what the business needs, not just what they want.

Project management can help as well. A project manager might be able to force active participation from the business and therefore come to better results. It is the mechanism to control the inevitable scope changes and deal with issues of budget and time overrun. Horribly enough, project management is also the final protection mechanism against any blame for failure.

Never give up to challenge the business on their requirements and to understand the business processes. Try to identify the target business model and what the benefit of the new system would be in that context. The industry problem that we have is still too much that IT is not seen as an integral part of the business and that IT and project management are not embedded in the normal business processes. As long is this is not the case, it is our job to take the business by the hand and guide them on their journey through IT-world.

Business requirements too often stand on their own; not backed up by thorough business process analysis, insufficiently scrutinised and thrown over the wall to an implementation team. But if used as part of an integral analysis and design process, they are a key to success.