Business requirements are discretionary

Business requirements are not set in stone. We know that they can change during a project but quite often they are a personal preference of stakeholders. You would expect that they are logically derived from the business processes. But often the definition of the business processes allow for much freedom while there is much debate about what the right process for the organisation is.

Every employee in every organization will have complained at some stage of their career about inefficiencies in their organisation and asked themselves why "they" could not have designed this better. If you take over a job from someone else, you are bound to do things in a different way than your predecessor. And the same thing applies to managers. When a new manager comes in, he will guaranteed change the operations to improve it.

Business processes change as regular as the weather, wether it be small tweaks or major overhauls of the business.

You hope that changes of the business processes are to be improvements. In essence you still have the same business objectives but you just want to do things better. Every organisation will constantly go through these changes. However, sometimes you wonder whether these are actually improvements and that it is just a change for change sake. Sometimes when there are disagreements, you feel that either way could be right and that it does not really matter.

For example, our organisation has chosen not to use purchase orders. We have some other mechanisms in place to cater for the authorisation of purchases. The consequence is that we have an invoice processing system where we approve the payments of invoices. There are however a few strong proponents for a purchase order system and with such a system we probably would not have needed the invoice processing system. Without going into the details, there are good arguments for either approach. But given that you have made choices in the past, it is difficult to change later.

In the past I was involved in the development of the various incarnations of the website of our consultancy company. Of course there were as many opinions about the design, information architecture and content as there were people in our organization. The ones that were directly involved with the building and writing of the texts got their way most of the time.

When we implemented SharePoint for our document management, there were also as many opinions of how this should be done as there were people involved in the project. Specifically because we as IT people would also be using the system, we considered ourselves subject matter experts and tried to drive the requirements and design as much as possible. We probably should have tried harder.

These examples just indicate that there is not one set of right business requirements and that they often easily can be interchanged. They can easily be changed and they do. And that is why I prefer to look at the the data first before I build new systems.

I was educated to do an information analysis as one of the first tasks to come to a new system.

This does not mean that processes are ignored but it gives a different perspective. Actually, modeling the processes would be the second step before going into requirements. These first two steps are what I call the real business analysis (see this post) and also serve the purpose of looking for ways to improve the business. Doing an information analysis and business process analysis upfront, gives better insight in the data involved and how and when it is used. It however implies that this phase must be driven by the business owner.

These days we usually start with business requirements which will result in a system design and a data model. It means that a overview of the data only comes much later to light in the process of custom development. However before you would come to that, you will have made decisions about off-the-shelf solutions versus custom development. The problem is that business owners usually come with an idea of a solution and you just need to write down the requirements. The consequence is that the broader context is ignored.

The data structures in an organisation are much more stable over time than the processes and the required application functionality. When you can come to a clear definition of the required information and preferably through a single access layer, it is easier to build varying application functionality on top of this.

If you drive your application architectures from individual requirements, you will have a higher risk that this will lead to more fragmented data structures which will mean that it is more complex and expensive to change the requirements later. For example you will be more inclined to come to a series of standalone off-the-shelf applications where there is no data flow between those applications. At first sight it might seem a cost efficient solution but when the requirements change, you might have to build costly integration software or you might have to redo some of the work. And you will probably run into cases that the actual data cannot be linked between the systems.

And then I like to come back to what I mentioned before. You will define your processes depending on the current situation and depending on systems already in place. 

That is one of the challenges of IT. When we implement business systems, we have direct influence over the business processes and the business requirements. If you do it right, you can participate in improvement of the business and that can go all the way to assisting with the business strategy. But it is also a cause of conflict and confusion about the role of IT within an organisation.

Meta data versus folders in MS SharePoint

Somewhere in the 90's when we were building our Intranet, one of my colleagues pushed for the concept of removing folders for the management of documents and to replace this with meta-data. The idea was that folders are one dimensional and have a strict hierarchy, but with meta-data you can create a multi-dimensional structure.

For example you have a folder structure as displayed to the right. With a folder structure you cannot list all documents in all "Analysis" folders. You can do this with only one folder at the time. Using meta-data, you would be able to do this without specifying a value for a project name.

Microsoft implemented this concept in SharePoint in the form of "columns". SharePoint consultants are adamant that folders should not be used anymore (or much less) and should be replaced with meta-data. The concept sounds very appealing but has some limitations (you might want to translate some of them into strengths, but I look at this from the perspective of the lazy end-user):

• The concept of multiple dimensions eludes many people. It might be that Gen-Y people over time pick this concept up easier since they have not worked in the strict folder world for that long. However I like to warn against comparing this with the easy uptake of social networking by Gen-Y and the fact that they have replaced email with Facebook, Twitter and SMS. The use there is free and for the moment only. In a business context you need to have more structure and need to keep data for a longer period of time. Note that folders are a concept that we understand from the real life. We have folders in boxes on shelves. When we lose this concept, people are a bit lost in where the document really is. We do not always need to know this. My blog is somewhere in the cloud and I am not too worried about where it physically resides. But I think SharePoint should come with a better user interface for navigation and management to give the users a better sense of control.

• In SharePoint users cannot freely create new columns. Where a folder impacts only the folder in which it is created as a sub-folder, a column impacts the whole site. 

• It requires to have the right permissions. If people can't make their own columns (folders) they will feel too much locked in and will resort to using alternative places to store their documents.

• With columns you need to think ahead and define values and the required use beforehand. While many people have a document or a few documents and just want to place it somewhere that makes sense for that moment in time. If it becomes too much work, they will place it on the local C drive. If you could create columns on the fly and as easy as creating a folder and add values to columns on the fly, it might make more sense.

• When specifying in which folder and where in the hierarchy you want to create a document, you can do that using mouse-clicks. It works via a drill down mechanism and each time the number of options are limited. With columns, the selection of a value for the first column does not reduce the number of options for the second column.

• The way SharePoint works now, it is not easy to navigate using the multi-dimensional features. You need to define views for that.

Though more and more organisations are implementing SharePoint, Microsoft should improve the ease of use in order to improve the uptake. It is disappointing that after more than 10 years, I haven't seen a good easy to use commercially available implementation of the concept.

IT does not always need to be a partner in strategic change

We have read and wrote enough about the IT-Business divide and that IT should take more initiative in business improvement. I find it difficult to actually drive business improvement pure through IT initiatives, but in cooperation with business teams over the years I have been able to contribute to business improvements.
I don't say that there aren't options to do so. But in the end you need support from upper hand and need to get buy in from your business stakeholders. If you don't get this, you will find resistance and will be told to focus on the tasks given to you.

In my previous role as consultant I was able to contribute to strategic initiatives and coming up with ideas to improve the organisation structure and business processes that were implemented successfully.

In the more recent period I have been able to work with our Finance and Procurement teams where we as IT had a direct input in ideas for improvement. As a combined business and IT team we implemented a series of systems to improve operational efficiency and corporate governance. For example, years ago I identified potential improvements in the way we processed our invoices. Once we had the context in terms of systems and processes right, we came to a full automated solution for Invoice Processing. We selected the Basware technology and Basware was effective in implementing their solution. As a result Finance has earlier insight in outstanding payments and improved its cash management.

In another example we were able to transform a set of disparate online learning solutions for our customers into a single global web application. The result so far is that this website won an award for the best online training program by the German trade magazine ‘touristik aktuell’.

And that is where I think the role of IT should be: participating in operational and strategic initiatives and driving as such business improvements. I don’t think, bar some exceptions, that IT really will ever in the position to take the lead.

IT will always respond to possibilities. What we see now for example with strong growth in consumer technology that is being brought into the organisation, that it still is a response to new technology in the market. The business is strongly driving the demand for iPads, iPhones or the use of Twitter or Facebook, simply because they already know it from private use. Even if IT is first on the ball, it is still bringing it as an idea to the business and together with the business teams to define the business case or just to try things out. Even if we talk about all the possibilities in the cloud, we might talk about strategic choices for IT but from business perspective it is much operational efficiency. Only in exceptional cases IT might be able to drive strategic change and we should not want to try too much more.

When I look where our organisation was 5 years ago and where it is now in relation to finance and procurement, I am proud with this silent revolution to which we had a major contribution, not only for the implementation but also for idea development.

This can happen anywhere in the business as long as both parties are open to work together and see each other as equal partners.

Louie Ehrlich, President, Chevron Information Technology Company, and CIO, Chevron Corp might explain it a bit better here. But it comes down to the simple statement that if the business is not ready for IT being a strategic partner, don't try to push it.

The IT Evengalist addresses it from the angle of innovation and states that every innovation within IT (within that organisation) automatically is an innovation for the business. His complaint is the same as mine: " I have lost count of the number of the experts and pundits who are forecasting the demise of every CIO who doesn't "step up" and contribute to if not drive business innovation."

He also postulates that we as IT might be wanting too much to be the strategic partner: "So while IT is waiting for all of those business leaders to read the articles on the "IT organizations of the future," IT can prepare itself for the day the business actually looks to IT to help drive business innovation."

As an enabler for te business, you automatically assist with business innovation and support strategic develoment. In order to be a good enabler, you first of all need to have your house in order and not spend all your time fire fighting. Often the business will come with a new idea that needs to be done yesterday. To avoid that this results in a fire fighting situation, you need to understand where the business is heading to and be ready for the next challenge. It does not mean you will live up to the expectation of having the work done by yesterday. You simply need to accept that there will always be a conflict between expectations and the reality of getting things done.

But that is different than driving strategy or driving innovation.

Who is steering the car? The person behind the wheel or the person on the backseat telling the driver where to go? Does it really matter? As long as you get where you need to be in an efficient way.

The problem is in my opion more that due to the lack of partnering, opportunities are lost and efficiency is compromised. The driver and the passenger need to work together to make sure you get to the right address via the quickest route (and that is definetely true when using a taxi in Sydney!).