“If driven by IT, the decision is more focused on operational and architectural considerations than business requirements.”

This is a comment that seems to have been doing the rounds recently in one form or another. Lets examine more closely to see who should be responsible for project decision making.

Actually the information technology department must always take into consideration a variety of views when making a decision to purchase any software; including:

◊ Business needs

◊ Business processes

◊ Functionality offered

◊ The technology architecture

◊ Cost

◊ ROI

When a decision is made entirely by the business community then this can lead to inconsistencies in the corporate architecture, which can increase operational costs, particularly in solutions where data integration is required, for example the BI solution.

Having worked on a large number of projects over the years there is one one consistent part of any successful project – the views of the business. The author has much experience delivering projects, on one occasion he worked on two simultaneous projects to deliver the same type of solution run at two different corporations having a similar technology architecture. The results of the selection process led to the selection of two different products, all because of the business focus of the selection process.

Tough times do call for strategic decision making, but that does need to be a balanced decision considering all of the factors involved. Purchasing of solutions is never simple, but too many companies fail to perform a comprehensive business process review – the make a sweeping assumption that they must replace their ailing ERP solution. All too often it is the business process itself that is broken, not the system that supports it. Simply replacing the system without fixing the business process will only give short term gratification, within five years that corporation will be changing systems yet again; more dissatisfied than ever before with the level of service offered by their IT department. Yet the basic problem is not an IT one.

Deployments should always be executed in the best interests of the business. The way to ensure this occurs is having business boards control the spending of project budgets. It is through the partnership of business and technology management that there is the right level of sponsorship and intervention. It is not about inter-departmental turf wars, but synergy and achieving broader business goals.

Inter-systems integration can often one of the greatest challenges faced for any specific deployment. Business intelligence is always a crucial factor to consider. BI solutions must be ongoing within any corporation; every new system brings new data, which is required to continue developing the analytical capabilities. Of course any business analytics capability must grow even if there are no new systems being added.

The net result of all this change should always be a leaner and more focused organisation that is able to make intelligent, fact based decisions across the business.

Irrespective of the business challenge it is wrong to enter solution mode before defining the scope of the problem that must be resolved.

There are two aspects to business process engineering: identifying the existing process and seeking to understand the proposed new solution. As the team works through this process there will be several options that will normally present themselves. Key at this point is to avoid the tendency to go into solution mode. Knowing which direction the business is heading in will ultimately assist the decision making process. Assessing vendors before knowing the fullest extent of the business problem faced can lead to serious errors during the implementation.

Normally completing the process review will naturally identify the most likely solution providers. The scope of the capability required can also eliminate some vendors as well.

This advice applies irrespective of the type of solution implemented. In fact starting out by having a senior manager, such as the CEO dictate that the solution MUST be SaaS based can in fact mean that a wrong application is selected. Please be clear this writer is not against cloud based solutions it is simply a matter of ensuring that corporate funds are not wasted in deploying just any old solution.

When it comes to selecting the appropriate vendor it is always important to perform the right amount of due diligence on the corporation, its financial stability, security capability etc. Again this is also important when talking to SaaS vendors the selectors should remember that some of these vendors do not have longevity of some of the traditional software vendors.

-

Other Reading on Due Diligence:

Due Diligence Check list

Consulting Due Diligence

Strategic Due Diligence

On possible Legal Definition and another.

The last article in this series covered “The Corporate Architecture and Complexity of Data Links“. This builds on out business understanding that impacts the selected solution. You should walk away from this series with an impression the selecting a BI solution is not merely about software selection, but about a whole range of factors that require a more holistic vision about how the corporation will be leveraging its business intelligence capability. Yes we do need to measure profitability, but ultimately we also need to measure a range of other factors.

So, what makes our business unique?

Each business has a set of products or services. Many of these may also sold by the company’s competitors, at a similar price in a similar format. There however is always some distinguishing feature that ensures customers buy our product or service rather than our competitor’s. This may be as simple as undercutting the competition’s price or may be some unusual aesthetic feature. Knowing the factors of uniqueness is essential for each business. This has been described as many things over the years, but it is generally known as the unique selling proposition, or USP.

Each business, of course, has its competitors. One of the reasons for implementing business intelligence solutions is to identify ways to take advantage of prevailing market conditions. Thus it necessary to understand the ebb and flow of the marketplace; how this industry sector(s) function. Marketplace goals will also be a driving factor.

One of the major reasons for introducing Data Warehousing technology is to identify and measure factors that distinguish this business from all of its competitors. Pre-packaged solutions are rarely capable of doing this. They concentrate on general business goals, or maybe that of the market sector. Uniqueness will always need to be added to any pre-packaged solution.

Note: the author has identified two factors that need to be considered:

►  Factors that are common within the particular industry sector. This may be all insurance companies, or alternatively may be insurance companies operating in the life and pensions sector, where specific rules have to be met.

►  Factors that make our specific business unique. E.g. the brand name – Coca Cola, the reputation for quality workmanship – Rolls Royce.

When I work with corporations to deploy BI solutions I have created an assessment form that allows these factors to be both defined and assessed for your corporation. If we take an example of a corporation involved in the travel sector some of the generic industry factors may be:

◊ Declining corporate travel market

◊ Buoyant executive travel market

◊ Growth of no-frills airlines

◊ Growth of on-line sales

◊ Reducing costs

◊ The impact of terrorism on the marketplace

Factors making our specific business unique may include:

◊ Guaranteed lowest price whether booked on-line of in store

◊ Value customer service and retention (follow up call after trip)

◊ Wide variety of sales channels, even active on Social Media

◊ Active in all areas of the world

◊ International free-call help line

◊ Links airlines and corporate customers.

Understanding these factors and classifying both their mission criticality and their complexity are both important to the financial decision making process. Some factors here may be regarded as complex because such data is not currently recorded within the company.

As a general observation the more unique the business the less likely it will be a candidate for using a pre-packaged Data Warehousing solution and the more likelihood that the corporation will have to define their own database model or make changes to an ‘industry focused template’.

Next “Suitable Analytical Applications”

1. A full data model, usually linked closely with an operational application. SAP, Peoplesoft, Siebel and other software suppliers provide Data Warehouses linked with their ERP and CRM applications.
2. An industry ‘template’ that provides a basic model Data Warehouse relating to the industry sector that the business is trading in.

Remember this section is talking purely about the supporting database, the Data Warehouse, rather that the overall BI solution.

Additionally there are Cloud based BI, or BI as a Service, solutions that tend to have their own internal database, most are linked to cloud based solutions. Generally you should consider these to be included with the first choice here as they are normally related to other operational applications. However some cloud based solutions are not extendible, which may be a factor in the decision making.

This is a continuing article based upon: Financing the Business Intelligence Project (Buy or Build?)…

Full Data Warehouse Model:

Many software companies claim to provide pre-built, fully configurable and extensible Data Warehousing solutions. Few, if any, actually provide an ‘out-of-the-box’ solution for the Data Warehouse that is not linked to another application. Most are linked with other operational software, such as Enterprise Resource Planning or Customer Relationship Management, where the business will have committed a significant investment such technology and associated change programmes.

Solutions are likely to be tailored to industry specific business analysis needs and will probably include pre-configured ETL components that may include extraction software for other commonly used software packages. This can act as a considerable advantage as it can reduce Data Integration efforts.

The advantage offered is that where a business uses the supplier’s solution it can have a ready-made business intelligence offering ‘for a few dollars per head more’. The final solution is still customisable, but is linked into key enterprise systems. This is an excellent goal, but whether it is achievable is a question that must be factored into the decision process.

Industry Templates:

Bill Inmon, used to be a great believer in the use of industry templates, or generic data models. Other companies also provide customisable data models, focused on specific marketplaces. The general aim of these templates is to act as a teaser for a subsequent engagement of the supplier’s consultancy services in order to have that organisation complete the full Data Warehouse and Business Intelligence implementation.

Templates or generic data models are therefore an aid, or kick-start, to custom development rather than a full blown ready-made solution. They are discussed here because generic data models are sometimes seen as a solution rather than a step-up on the development process. The template, or generic data model, can provide a boost to the initial Data Warehouse development project. They can be used to:

♦  Provide a foundation that can be built upon

♦  Identify major data classes

♦  Identify common relationships

♦  Identify some common attributes within the data

♦  Identify some common keys and unique identifiers

♦  Get the modelling exercise off to a fast start

In other words, the generic data model is a good starting point for the creation of a corporate data model, upon which the Data Warehouse will be founded. Using the template or generic data model as the corporate data model is inevitably a mistake. They do not alleviate the need to think about the design of any solution; they simply provide a way to jump-start the data modelling exercise.

The template or generic data model is not really a ready-made solution it is really a short-cut to providing a custom solution. Such a model will not include any pre-configured ETL components so these factors have to enter into any decision made.

The Decision:

At the end of the day having a customisable model is important because the Business Intelligence capability should be able to map onto the organisation’s USP. These are factors that you need to use in order to make your purchase decision. The best models are visible and expansible.

It is easy to assume that there is a ready made solution available and today’s choices are becoming increasingly complex, because vendors are learning the lessons from work they have completed for customers in the past and they have therefore extended their models to include a large array of new capabilities. Some vendors have simply extended default models over time others make these capabilities available only for extra cost. Make sure you know all the cost factors before making any decision.

The Next Decision Factor: Your Corporate Architecture and the complexity of data

1. Whether to use a ready-made solution or have it custom built
2. What degree of external staffing resources are required

This is the first part in a series about financing your BI deployment.

In addition project costs will be impacted by:

◊ The focus of the solution; operational or strategic

◊ The type of architecture selected

◊ The development methodology

These are all issues that the decision maker needs to be aware of whilst working with the business to initiate the project. Financial justification is of-course vital to this process. It is essential that agreement is reached by the project board based upon the holistic needs of the business. How the business interacts with the project and the resulting solution will in the end determine the success of the implementation. This is a corporate-wide decision to make.

Some of the decision may differ in scale when extending an existing Business Intelligence solution, but on the whole the various aspects of this article all have to be considered.

Ready-Made or Custom Built?

This is a decision that impacts the structure of the underlying database, the Data Warehouse. In the past it was a relatively clear-cut decision that few if any solutions provided alongside new operational applications could offer anywhere near the complexity necessary to support strategic decision making. Their only contribution was in respect of operational decision making. The strategic decision making required more data to be aggregated from multiple systems in order to provide the right results.

Each packaged solution requires some customised data and user interfaces to ensure it fits each end-user business. The business is also expected to change its processes in order to work with certain applications. The use of ready-made OLTP solutions has made the task of hiring business community staff and training them easier. E.g. Job advertisements for an Accounts Administrator can specify SAP experience.

So can this experience be applied to the implementation of the Business Intelligence solution? Much depend on the factors making each business unique and the range of applications that will continue to be used within the organisation. Few, if any, of the true BI focused applications feature highly in any business community staff resumes, so training is always essential.

From the systems side a changing IT landscape during the past twenty-odd years where we prefer to buy rather than build encompasses the possible use of packaged solutions for both the Data Warehouse and the BI tool-kit. In order to make such a decision it is necessary to consider the impact of:

◊ The corporate architecture including the complexity of data links

◊ The degree of integration of existing systems

◊ Factors of uniqueness for the business

◊ The suitability of analytical applications

All of which can assist in assessing the suitability of potential ready-made solutions. In all cases it is important to understand the general goals of the business’s market sector, for example in some statutory controls will have a large impact and in others none. It is always necessary to consider what your corporation’s principle competitors are measuring, if only to ensure that you exceed those minimums. It would be great to have a sneak peek at the competitor’s solution, but often industry journals give an expose on what they are doing – these can be analysed to identify the factors being measured.

Another impact is the factors of uniqueness, e.g. what your corporation brings to the marketplace – each company has them, make sure you identify them.

The third factor that need to be considered is the existing legacy IT architecture. Many corporations have already purchased some of the technology that is intended to be used for the solution. Many systems come with data integration elements. From a pure cost effectiveness standpoint you should look at re-use instead of purchasing a new ETL solution. Most companies have them – it is a matter of whether they are fit for the new intended use. Another area to consider is pre-existing and spare licenses for existing analytical tools – many corporations complain about the cost of licensing, yet do not effectively utilise the licenses they already have.

The next article in this series: “Types of Ready Made BI Solutions”

This short walk down the corridor often speaks volumes more than the weekly project meeting. To me this signals a time when a one-to-one meeting is required, in order to get to the bottom of the problem.

With remote team members this type of reaction seeking or non-verbal communication is not evident. It is possible to hear fear when a person speaks, yet in a teleconference it is possible to hide – simply by remaining silent. When you are in a teleconference with your remote team members do you ever ask for personal feedback from every person present? Trouble is that it is all too easy to forget the silent ones even in a face-to-face meeting.

Generally speaking in any meeting there are two reasons to be silent. Firstly shyness, and secondly because that individual has something to hide.

Shyness is a symptom of managing comfort zones. We can all be shy when confronted with something new, and perhaps a little intimidated particularly when we understand very little about it. It can normally be managed by coaxing that person out of their existing comfort zone and expanding that comfort zone to include the new working environment.

Having something to hide is a different matter. These team members are the onces who are most likely to bring bad results on a project, irrespective of the circumstances. Projects are always limited by time and resources, whenever there are problems it is always vital to share. Managing projects via Agile methods does allow problem areas to be ring-fenced and focused on more thoroughly at a later stage. I am always more concerned about those who hide away because they have a problem than I am the shy person.

Despite sayings like “a problem shared is a problem halved” having entered the main-flow of society, people tend to be concerned that when a problem is identified then it is their personal challenge to solve it. They hide the problem in the hope that no-one finds out about the problem. Sadly this is the point when it starts to have a negative impact on everything that you do. Project working is not generally the place for heroics. That person who focuses on the problem and tends to lose sight of their deliverables.  Here we are back at the team member who rushes back the other way when when they see you, their manager, in the corridor. Something is wrong here and needs to be solved.

BUT how do you do this when the person is working remotely? Many project managers believe that having remote workers is too risky. Yet it is the things we do not wish to do that we are often forced to do.  There is a certain amount that can be achieved by regular visits to remote sites, yet at all times you remain a stranger at that remote location – so there is a psychology to managing remote visits. Remote project workers are a fact of life, as are constrained project budgets. The latter reduces out ability to complete regular remote-site visits, so it is essential to identify remoteness challenges of virtual teams in other ways.

It is vital all virtual team members are a part of developing and following the team plan – this must be lived and breathed. Knowing each remote worker is important – you probably need to spend a disproportionately high amount of time developing this relationship. You need to stay in touch, daily is best; set and follow an agenda for all meetings – ensure it is business focused. Leverage technology where appropriate – particularly collaboration tools.

Maximizing resources and aggressively planing for the future are likely to continue to be the expenditure themes for the coming months. Improvements to business effectiveness are more important than ever before, yet projects still need to be delivered. Today on-time and in-budget is increasingly important, yet it is still possible to deliver radical change to the business condition. Technology must not be seen as a “necessary evil” in the eyes of the business owner, it is a key enabler that adds value, yet the modern company does not have to invest in mega systems to get results.

With every project is important to identify a return on investment, and seeking some positive return during the first full year of operation is increasingly important. During the tough times it was necessary to stretch projects out, with a commitment to deliver fewer major projects. You business has to be ready for the economic upturn. Investment in marketing, communications and Social Media are a must have over the coming months, bust the spending must be cost effective. A clear picture of spending and expected benefits must be available to the executive team.

It is important to be making the right decisions at the right time, delaying growth can have negative consequences. Development projects, when correctly timed can have a dramatic effect on the growth we experience. Remember too many project fail because of our desire to fix the world in one massive step. Business is in a state of continuous improvement. If you could look at the oldest corporation in the world, it is unlikely to be run the same way today as it was when it first started. Business improvement will continue to be needed as long as we have business and where there is a culture of improvement there will be projects to facilitate change.

We should always remember that one of the keys to success is that projects are always limited by time and resources, it has always been true that more progress can be made through a series of small steps. As humans we frequently chase after the impossible. If we succeed then we are heroes but failure can carry with it dire consequences. Every business change project needs to be broken down into bite-sized pieces. This way we are better able to understand the scope and goals. It is important to look out for the signs of project failure, yet plan for success.  We should look to solve those problems that can be easily solved first. With each problem we need to:

■ Define it

■ Identify any barriers to success

■ Know how serious the problem is

■ Identify options that can assist us

■ Look at the outline costs involved

Fundamentally businesses should look to change its processes before it looks to change its systems. IT system processes are always more complex and more costly to fix than the associated business process. It is not about being opposed to a major systems change, but it is essential to go through the right level of thinking before making any decision to replace applications. The problem is largely one of strategic thinking. Strategic problem solving requires the definition of corporate goals and plans against which all projects are tied. Generally speaking these should be long term goals, yet we must always respond to changing priorities and be able to define new goals when necessary. Yet short term changes should not end up dictating long-term policy.

The business executive today needs to tread carefully over the next few months, yet at the same time plan for growth, then be prepared to aggressively execute against a growth plan at the right time.

• 80 percent of time and effort goes into deploying the 20 percent requiring the most customisation.
• Developers spend 80% of their time debugging applications and 20% writing new code.
• Getting 80% competent as a developer isn’t really hard — but that last 20% to go from competent to great is really, really tough

Even the business world has its versions of this rule e.g. “80% of your sales come from 20% of your customers.” Each of these has a certain element of truth in it, but they should be seen as a guideline rather than as a hard rule. In the old days when I used to cut code my own version was that I spent 80% of my time on the toughest 20% of functionality. Now there is is a new rule in the operational computing world. When it comes to running a computer program 90% of the execution time is spent executing just 10% of the code.

So is this all just a bunch of stats dreamed up by academics and management to justify the amount of time taken to deliver solutions?

It could be argued that IT leaders have been leveraging the 80-20 rule in order to maintain budgetary control. I would argue the reverse. Because IT spends more effort making things 100% perfect, would it not be better to live with 80% of the functionality and minimise unnecessary expenditure?

It is my belief that the type of deployment or development will aid cost saving. There is a law of diminishing returns that applies in all circumstances. Agile deployment, for example, is the 80-20 Rule at work. It emphasizes speed and adaptation to changing business realities, including the option to decide when the delivery is good enough. It is important to deliver the features of most value to the bottom line of business, other functions can be axed or delayed till later stages. Also project delivery is not about being fast, but about the quality & effectiveness of the delivery to the business.

Agile delivery will also allow the option to stretch out all delivery timelines for the current period. To acheive this you reduce the number of active projects and the size of the teams.

Today’s CIO’s role is more than simply managing IT staff and ensure that systems and networks are up and running. They need to serve as integral members of the senior management team within the corporation. They need to take part in strategic development, organizational planning, and enable financial planning and decision-making. They have largely become the Chief Change Officer by leading their organization’s strategic business change initiatives.

Maximizing your current technology resources and aggressively plan for the future with the business in mind. In addition to this is the dimension of Business Intelligence that will allow a corporation to make informed business decisions. The role of  the CIO should increasingly be one of leveraging the technical services in order to truly empower the business. Business today is increasingly needing to optimise their IT investments.

It is after the challenges of 2008 that many USA business is coming to a realisation that IT implementations have to be done on a tighter budget and mega-projects must come under scrutiny. Ironically IT developments in Canada, UK, and Europe have already been performed on a shoestring budget. A new learning is necessary. The important message here is that it is still possible to deploy solutions, but cost effectiveness is key.

Further Reading

Information Technology Must be Integrated into the Core of Business! by Peter Giblett

Leadership for Extraordinary Performance by Joseph J. DiStefano

Within an end-user organisation there is increasing pressure to deliver more complex budgets to a tighter time-line. It can be argued that IT must shoulder blame for bad communication – incorrect people at presentations, not asking the right questions, etc. This is one of the reasons why when I go to such a presentation I may take on the role of asking the dumb question (and this may not be out of ignorance, but because a message needs to be conveyed to the business).

We are still facing the same problem of vendors not living up to their promises. In fact this is one of the worst delivery faults in the history of IT. In my past career have been technical liaison for pre-sales and have spoent some time following salespeople around, and beleive me they promise some complete bull to the prospect with the hope of making the sale. My job was to tell the truth about product capability. All too often sales folks are selling next version capability for a product that will not be in beta for at least 6 months and in unlikely to hit the streets for at least a year.

From an IT perspective it is necessary to take a carving knife and get to the real picture of capability based on existing product. This is where the IT manager needs to ask questions regarding capability on reference calls.

Vendors need to be up-front about how their product meets the requirement at the RFI or RFQ stage. Your product will not be discounted because it does not have a 100% capability match. Few products can deliver 100% of the requirements. I have managed projects where none of the vendors acheived 60% of the functional requirements – we still selected a solution and implemented it successfully.

One of the key areas for project deployment today is integration. Data movement between systems is increasingly important and sometimes this is the only was a requirement can be delivered. Software vendors need to show what data they feel their product is the master of and what data should be supplied for a successful implementation. This goes back to vendors taking the time to understand the requirements of the system they are expected to deliver. It is important to understand the data integration resources that the customer has to call on when they are providing a deployment estimate. Many corporations do not have adequate data integration specialists on the team.

The watchword for vendors is don’t over-promise and do understand your customer.