🚧Project Management: Lessons Learned (Definitions)

"The learning gained from the process of performing the project. Lessons learned may be identified at any point. Also considered a project record." (Timothy J  Kloppenborg et al, "Project Leadership", 2003)

"The systematic capturing of experiences to learn for the future and to avoid mistakes. Lessons learned sessions can, for instance, be held at completion of a project or project phase." (Lars Dittmann et al, "Automotive SPICE in Practice", 2008)

"The learning gained from the process of performing the project. Lessons learned may be identified at any point. Also considered a project record, to be included in the lessons learned knowledge base." (Project Management Institute, "Practice Standard for Project Estimating", 2010)

"An important step in wrapping up management of any implementation process, this step documents successes and failures in each systems development phase as well as the project as a whole." (Linda Volonino & Efraim Turban, "Information Technology for Management 8th Ed", 2011)

"Information from past projects, such as problems that occurred and risks that were encountered, that can inform future projects." (Gina Abudi & Brandon Toropov, "The Complete Idiot's Guide to Best Practices for Small Business", 2011)

"Information provided by team members and other stakeholders about how aspects of the project can be repeated or enhanced and how problems and issues can be prevented or resolved. This information can be used to improve the performance of future projects. Lessons learned are collected in a knowledge base or report." (Bonnie Biafore & Teresa Stover, "Your Project Management Coach: Best Practices for Managing Projects in the Real World", 2012)

"The knowledge gained during a project which shows how project events were addressed or should be addressed in the future with the purpose of improving future performance. |" (For Dummies, "PMP Certification All-in-One For Dummies, 2nd Ed.", 2013)

📦Data Migrations (DM): What is Data Migration?

Data Migrations Series

If you are working in a data-centric business it’s almost impossible for the average worker not to have heard this term, even tangentially. Considering the meaning of “migration” - the act or process of moving from one place to another - the intuition might even tell what data migration is about: the process of moving data from one place to another. It’s pretty basic, isn’t it? Now as data are moved over and over again between various places, for example the various layers of an applications, between databases, between media storage devices, and so on, we need some precision in defining the term because not all these can be considered as data migration examples. Actually we can talk about data copying or data movement without speaking of data migration. So, what is data migration? Here are a few takes on defining data migration:

“process of transferring data from one platform or operating system to another” (Babylon)

"Data migration is the process of transferring data between storage types, formats, or computer systems." (Wikipedia)

 "Data migration is the movement of legacy data to new media and technologies as the older ones are displaced." (Toolbox)

 “The purpose of data migration is to transfer existing data to the new environment.” (Talend)

 “Data Migration is the process of moving data from one or more sources into a target application” (Utopia Inc.)

 “[…] is the one off selection, preparation and transportation of appropriate data, of the right quality, to the right place, at the right time.” (J. Morris)

Resuming the above definitions, data migration can be defined as “the process of selecting, assessing, converting, preparing, validating and moving data from one or more information systems to another system”. The definition isn’t at all perfect, first of all because some of the terms need further explanation, secondly because any of the steps may be skip or other important steps can be identified in the process, and thirdly because further clarifications are needed. Anyway, it offers some precision, and at least for this reason, could be preferred to the above definitions.

So, resuming, data migration supposes the movement of data from one or more information systems, referred as source systems, to another one, the target system. Typically the new system replaces the old systems, they being retired, or they can continue to be used with reduced scope, for example for reporting purposes or . Even if performed in stages, the movement is typically one time activity, so everything has to be perfect. That’s the purpose of the other steps – to minimize the risks of something going wrong. The choice of steps and their complexity depends on the type of information systems involved, on the degree of resemblance between source and target, business needs, etc.

As mentioned above, not everything that involves data movement can be considered as data migration. For example data integration involves the movement and combination of data from various information systems in order to provide a unified view. Data synchronization involves the movement of data in order to reflect the changes of data in one information system into another, when data from the two systems need to be consistent. Data mirroring involves the synchronization of data, though it involves an exact copy of the data, the mirroring occurring continuously in real time. Data backup involves the movement/copy of data at a given point in time for eventual restore in case of data loss. Data transfer refers to the movement of row data between the layers of information systems. To make things even fuzzier, these types of data movements can be considered in a data migration too, as data need to be locally integrated, synchronized, transferred, mirrored or back up. Data migration is overall a complex thematic.

Previous Post <<||>> Next Post

🚧Project Management: Business Case (Definitions)

"The business reason or value for undertaking the project." (Timothy J  Kloppenborg et al, "Project Leadership", 2003)

"A “needs assessment” or justification to show why an endeavor is necessary to an organization." (Margaret Y Chu, "Blissful Data ", 2004)

"A business problem, situation, or opportunity that justifies the pursuit of a technology project." (Sharon Allen & Evan Terry, "Beginning Relational Data Modeling" 2nd Ed., 2005)

"[...] a formal document used to justify investments in new products, product enhancements, and marketing expenditures." (Steven Haines, "The Product Manager's Desk Reference", 2008)

"The process that documents the customer's justification for their investments in products and services." (Steven Haines, "The Product Manager's Desk Reference", 2008)

"A document that provides a justification for a business investment, often used in terms of technology investments. Business cases can be built by identifying financial (hard-dollar) benefits and intangible benefits, including mitigation of risk." (Janice M Roehl-Anderson, "IT Best Practices for Financial Managers", 2010)

"A structured format for organizing the reasons, benefits, and estimated costs for initiating a project or program." (DAMA International, "The DAMA Dictionary of Data Management", 2011)

"A written document that is used by managers to justify funding for a specific investment and also to provide the bridge between the initial plan and its execution." (Linda Volonino & Efraim Turban, "Information Technology for Management 8th Ed", 2011)

"An analysis of the benefits and costs of making a change to the way things are done." (Mike Clayton, "Brilliant Project Leader", 2012)

"The justification for a project or program, against which performance is compared throughout the life cycle. Typically, the business case contains costs, benefits, risks, and timescales." (Paul C Dinsmore et al, "Enterprise Project Governance", 2012)

"Framework for making decisions, explanation of benefits and costs, anticipated outcomes, and project factors associated with a performance improvement effort." (Joan C Dessinger, "Fundamentals of Performance Improvement" 3rd Ed, 2012)

"A documented economic feasibility study used to establish validity of the benefits to be delivered by a program." (Project Management Institute, "The Standard for Program Management" 3rd Ed., 2013)

"A documented economic feasibility study used to establish validity of the benefits of a selected component lacking sufficient definition and that is used as a basis for the authorization of further project management activities." (For Dummies, "PMP Certification All-in-One For Dummies, 2nd Ed.", 2013)

"Information necessary to enable approval, authorisation and policy-making bodies to assess a project proposal and reach a reasoned decision." (Chartered Institute of Building, "Code of Practice for Project Management for Construction and Development, 5th Ed", 2014)

"A written analysis of the financial, productivity, auditability, and other factors to justify the investment in software and hardware systems, implementation, and training." (Robert F Smallwood, "Information Governance: Concepts, Strategies, and Best Practices", 2014)

"A compilation of costs and benefits associated with a planned project or investment." (Gregory Lampshire, "The Data and Analytics Playbook", 2016)

"A business case captures the reasoning for initiating a project or task. The business case justifies the investment." (by Brian Johnson & Leon-Paul de Rouw, "Collaborative Business Design", 2017)

"A documented evaluation (pre-project) of the potential impact a problem or an opportunity has on the organization to determine if it is worthwhile investing the resources to correct the problem or take advantage of the opportunity for improvement. It captures the reason for initiating a potential project or program." (H James Harrington & William S Ruggles, "Project Management for Performance Improvement Teams", 2018)

"Documentation of the rationale for making a business investment, used both to support a business decision on whether to proceed with the investment and as an operational tool to support management of the investment through its full economic life cycle." (ISACA)

🚧Project Management: Performance [Measurement] Baseline (Definitions)

"The original approved plan for work such as a project. Usually used with a modifier, e.g., cost baseline, schedule baseline, performance measurement baseline." (Margaret Y Chu, "Blissful Data ", 2004)

"An approved integrated scope-schedule-cost plan for the project work against which project execution is compared to measure and manage performance. Technical and quality parameters may also be included." (Cynthia Stackpole, "PMP® Certification All-in-One For Dummies®", 2011)

"An approved plan for a project, plus or minus approved changes. It is compared to actual performance to determine if performance is within acceptable variance thresholds. Generally refers to the current baseline, but may refer to the original or some other baseline. Usually used with a modifier (e.g., cost performance baseline, schedule baseline, performance measurement baseline, technical baseline). |" (Cynthia Stackpole, "PMP Certification All-in-One For Dummies", 2011)

"An approved, integrated scope-schedule-cost plan for the project work against which project execution is compared to measure and manage performance. The PMB includes contingency reserve, but excludes management reserve." (For Dummies, "PMP Certification All-in-One For Dummies" 2nd Ed., 2013)

"Integrated scope, schedule, and cost baselines used for comparison to manage, measure, and control project execution." (Project Management Institute, "A Guide to the Project Management Body of Knowledge (PMBOK Guide)", 2017)

"Integrated scope, schedule, and cost baselines used for comparison to manage, measure, and control project execution." (Project Management Institute, "A Guide to the Project Management Body of Knowledge (PMBOK Guide)" 6th Ed., 2017)

"An approved set of integrated plans for the project’s Scope, Schedule, and Budget against which project execution will be compared to measure and manage performance. They include 'contingency reserve' but not 'management reserve' allocations." (H James Harrington & William S Ruggles, "Project Management for Performance Improvement Teams", 2018)

"The approved version of a work product that can be changed using formal change control procedures, and is used as the basis for comparison to actual results." (Project Management Institute, "Practice Standard for Scheduling" 3rd Ed., 2019)

🚧Project Management: Variance (Definitions)

"The difference of revenues, costs, and profit from the planned amounts. One of the most important phases of responsibility accounting is establishing standards in costs, revenues, and profit and establishing performance by comparing actual amounts with the standard amounts. The differences (variances) are calculated for each responsibility center, analyzed, and unfavorable variances are investigated for possible remedial action." (Jae K Shim & Joel G Siegel, "Budgeting Basics and Beyond", 2008)

"A quantifiable deviation, departure, or divergence away from a known baseline or expected value. " (Cynthia Stackpole, "PMP® Certification All-in-One For Dummies®", 2011)

"The difference between the baseline and estimated dates, work, or cost in a project." (Bonnie Biafore, "Successful Project Management: Applying Best Practices and Real-World Techniques with Microsoft® Project", 2011)

"The difference between planned or baseline schedule or cost data and the actual schedule or cost data." (Bonnie Biafore & Teresa Stover, "Your Project Management Coach: Best Practices for Managing Projects in the Real World", 2012)

"Deviation or difference between an estimated value and the actual value." (Tom Klammer, "Statement of Cash Flows: Preparation, Presentation, and Use", 2018)

"The difference between a planned value and the actual measured value" (ITIL)

🚧Project Management: Change Control (Definitions)

"Identifying, documenting, approving or rejecting, and controlling changes to the project baselines." (Project Management Institute, "Practice Standard for Project Estimating", 2010)

"A process for managing requests for change in an auditable way, to ensure that only appropriate changes to the project are undertaken once it has received approval. Also ensures that where changes are authorised, appropriate additional resources are allocated. " (Mike Clayton, "Brilliant Project Leader", 2012)

"A formal procedure that is used to approve and manage all modifications to software and hardware running on the network. Change control is usually coordinated by a change control board (CCB)." (Mark Rhodes-Ousley, "Information Security: The Complete Reference" 2nd Ed., 2013)

"A process whereby modifications to documents, deliverables, or baselines associated with the project are identified, documented, approved, or rejected." (For Dummies, "PMP Certification All-in-One For Dummies" 2nd Ed., 2013)

"A process that ensures potential changes to the deliverables of a project or the sequence of work in a project, are recorded, evaluated, authorised and managed." (Chartered Institute of Building, "Code of Practice for Project Management for Construction and Development" 5th Ed, 2014)

"The process of controlling the changes that take place during the life cycle of a system and documenting the necessary change control activities." (Adam Gordon, "Official (ISC)2 Guide to the CISSP CBK" 4th Ed., 2015)

"A systematic approach to managing all changes made to a product or system. The purpose is to ensure that no unnecessary changes are made, that all changes are documented, that services are not unnecessarily disrupted, and that resources are used efficiently." (William Stallings, "Effective Cybersecurity: A Guide to Using Best Practices and Standards", 2018)

🚧Project Management: Program Evaluation and Review Technique (Definitions)

"A method of depicting, scheduling, and prioritizing a complex set of activities in a way that supports effective project management. This method provides excellent visibility into a project's progress and potential obstacles and risks." (Steven Haines, "The Product Manager's Desk Reference", 2008)

"A technique for estimating that applies as weighted average of optimistic, pessimistic, and most likely estimates when there is uncertainty with the individual activity estimates." (Project Management Institute, "Practice Standard for Project Estimating", 2010)

"A model for project or process management to evaluate tasks involved in the project or process in order to find the shortest duration possible." (DAMA International, "The DAMA Dictionary of Data Management", 2011)

"Evaluates the probable duration of a project by calculating a weighted average of the best-case estimate, most likely case estimate, and worst-case estimate." (Bonnie Biafore, "Successful Project Management: Applying Best Practices and Real-World Techniques with Microsoft® Project", 2011)

"A statistical approach to estimating that uses a weighted average of three values: optimistic, pessimistic, and most likely." (Bonnie Biafore & Teresa Stover, "Your Project Management Coach: Best Practices for Managing Projects in the Real World", 2012)

"An estimating technique that starts with a network chart and combines optimistic, best estimate and pessimistic estimates to produce an overall estimate of the most likely duration and standard deviation (spread of likely durations) for a project activity." (Mike Clayton, "Brilliant Project Leader", 2012)

"An event-oriented network analysis technique used to estimate project duration when there is a high degree of uncertainty with individual activity duration estimates. PERT applies the critical path method to a weighted average duration estimate. It is considered a probabilistic method." (Peter Oakander et al, "CPM Scheduling for Construction: Best Practices and Guidelines", 2014)

🚧Project Management: Residual Risk (Definitions)

"A risk that remains after risk responses have been implemented." (Cynthia Stackpole, "PMP Certification All-in-One For Dummies", 2011)

"The remaining possibility and impact of a future uncertain event or condition after response to the original risk has been planned." (Bonnie Biafore & Teresa Stover, "Your Project Management Coach: Best Practices for Managing Projects in the Real World", 2012)

"The risk remaining after risk treatment." (David Sutton, "Information Risk Management: A practitioner’s guide", 2014)

"The risk that remains after implementing security controls to mitigate risk. Senior management is responsible for deciding what security controls to implement, and for any losses related to residual risk." (Darril Gibson, "Effective Help Desk Specialist Skills", 2014)

"Risk that remains after implementing a control. Threats × vulnerabilities × assets × (control gap) = residual risk." (Adam Gordon, "Official (ISC)2 Guide to the CISSP CBK" 4th Ed., 2015)

"Once all other risk treatment options have been explored, it is often the case that some (usually small) risk remains. It is normal to accept or tolerate this, since further treatment might either have no effect, or might be prohibitively expensive. Because residual risks are often very small, they are occasionally (incorrectly) overlooked." (David Sutton, "Information Risk Management: A practitioner’s guide", 2014)

"The risk remaining after risk treatment." (ISO 73:2009)

🚧Project Management: Risk assessment (Definitions)

"Describes risks under the initial project plan and may indicate areas of needed risk management." (Timothy J  Kloppenborg et al, "Project Leadership", 2003)

"A process to identify potential situations that could cause change to an effort from both internal and external forces, assign severity and priority ranks in order to determine overall risk, managing a situation or project to mitigate or minimize the occurrence of risk, and if the risk materializes, to minimize loss or damage." (DAMA International, "The DAMA Dictionary of Data Management", 2011)

[Qualitative risk assessment:] "Mostly entirely subjective and therefore less accurate than quantitative risk assessments. However, their benefit is that they are much quicker to produce than the quantitative kind" (David Sutton, "Information Risk Management: A practitioner’s guide", 2014)

[Qualitative risk assessments:] "these are subjective in nature, and are generally expressed in verbal terms such as ‘high’, ‘medium’ and ‘low’. This is not an ideal state of affairs, as it renders risk assessments unreliable, and should be grounded in more rigorously." (David Sutton, "Information Risk Management: A practitioner’s guide", 2014)

"An analysis of threats and vulnerabilities against assets. A risk assessment allows the risks to be prioritized." (Weiss, "Auditing IT Infrastructures for Compliance" 2nd Ed., 2015)

"A process used to quantitatively or qualitatively determine the risk associated with an actual or hypothesized system." (O Sami Saydjari, "Engineering Trustworthy Systems: Get Cybersecurity Design Right the First Time", 2018)

"The overall process of risk identification, risk analysis, and risk evaluation." (William Stallings, "Effective Cybersecurity: A Guide to Using Best Practices and Standards", 2018)

"'analyze assets’ value, identify threats and evaluate their vulnerability to those threats" (ITIL)

"the overall process of risk identification, risk analysis and risk evaluation" (ISO Guide 73:2009) 

"The process of identifying and subsequently analyzing the identified project or product risk to determine its level of risk, typically by assigning likelihood and impact ratings."  (ISTQB)

🧭Business Intelligence: Enterprise Reporting (Part XI: Between Products, Partners, People and Processes)

Business Intelligence Series

In the previous post, “BI between Potential, Reality, Quality and Stories”, I was commenting five of the important findings of a study led by KPMG in respect to the state of art in BI initiatives. My comments were centered mainly on the first 3 of the 4Ps (Products, People, Partners, respectively Processes) considered in ITSM (IT Service Management). The connection to IT Service Management isn’t accidental, BI being also an organizational capability. Many of the aspects related to the 4Ps perspectives, reveal the maturity of an organization in leveraging its BI infrastructure.  In this post I would like to consider BI landscape from these 4 perspectives.

Products

Products or technology perspective has within BI context a dual nature. First of all we have to consider the BI infrastructure – the whole set of BI tools we have at disposal for our shiny reports. Secondly, because the BI infrastructure doesn’t stand on itself, we have to consider also IT infrastructure on which BI infrastructure is based upon – a full range of ISs (Information Systems) in which data are entered, processed, transported and consumed before they are used by the BI tools. For Data Quality issues, we often have to consider the broader perspective, and tackle the problems at the source. Otherwise we might arrive to treat the symptoms and not the causes. It’s important to note that the two layers or perspectives are interconnected, the consequences being bidirectional.

A typical BI infrastructure revolves around several databases, maybe one or more data warehouses and data marts, and one or more reporting systems. Within the most basic scenario, the data flow is unidirectional from databases to data warehouse/marts, reports being built on top of the data warehouse/marts or directly on the IS’ databases. In more complex scenarios, the data can flow between the various ISs when they were integrated, and even between data warehouses/marts, within a unidirectional or bidirectional flow.  Unless the reports are based directly on the ISs’ databases, such architectures lead to data duplication, conversions between complex schemas, delays between the various layers, to mention just a few of the most important implications. In some point in time the complexity falls down on you.

One of the problems I met is that a considerable percent of the IS are not developed to address BI requirements. It starts with data validation, with the way data are modeled, structured, formatted and made available for BI consumption. If you want to increase the quality of your data, you have sooner or later to address them. It’s important thus the degree to which the systems are designed to cover the BI needs in particular, and decision making in general. This presumes that BI requirements need to be addressed in early phases of implementations, software design or when tools are consider for purchase.

In addition many ISs come with their own (standard) reports or reporting frameworks, becoming thus part of your BI infrastructure, intended or unintended. Even if such reports are intended to cover basic immediate reporting requirements, they not always so easy to consume, the logic behind them is not visible, are hard to extend, are not always tested, the additional reports built in other tools need to be synchronized with them, etc.

Partners

We gather huge volumes of data, we are drowning in it; we want to take decision rooted in data and get visibility into the past, actual and future state of business. How can we achieve that if we don’t have the knowledge and human resources to achieve that? “Partners” is the magic word – external suppliers specialized, in theory, to provide this kind of services: BI analysts and developers, business analysts, data miners, and other IT professionals work together in order to build your BI infrastructure. One detail many people forget is that BI tools provide potentiality; are the skills and knowledge of those working with them that transforms that potentiality into success. On their capabilities depends the success of such projects. Not to forget that BI projects are similar to other IT projects, falling under same type of fallacies plus a few other fallacies of their own derived from exploratory and complex nature of BI projects.

There is a dual nature also in “partners” perspective – except the external perspective which concerns the external partners and the IT department or the business as a whole, there is also the internal perspective in which the IT department plays again a central role. I heard it often loudly affirmed that the other departments are customers of the IT department, or the reciprocal. I have seen also this conception brought to extreme, in which the IT had no word to say in what concerns the IT infrastructure in general, respectively the BI infrastructure in particular. As long the IT department isn’t treated as a business partner, an organization will be more likely sabotaged from inside. Sabotage it’s a word too strong maybe, though it kind of reflects the state of art.

People

Same as partners, people perspective includes a considerable variety of types: IT staff, executives, managers, end-users and other types of stakeholders, each of them with a word to say, grouped in various groups of interests that don’t always converge, situations in which politics plays a major role. It’s actually interesting to see how the decision for a given BI solution is made, how the solution takes its place into the landscape, how it’s used and misused, how personalities and knowledge harness it or stand in the way. I feel that there are organizations (people) which do BI just for the sake of doing something, copying sometimes recipes of success, without uniting the dots, without clear goals and strategy. There are people who juggle with numbers and BI concepts without knowing their meaning and what they involve. This aspect is reflected in how BI tools are selected, implemented and used.

Having the best tools, consultants and highest data quality, won’t guarantee the success of BI initiative without users’ acceptance, without teaching them how to make constructive use of tools and data, on how to use and built models in order to solve the problems the business is confronted with, on how to address strategic, tactical and operational requirements. The transformation from a robot to a knowledge worker doesn’t happen over night. Is needed to make people aware of the various aspects of BI – data quality, process and data ownership, on how models can be used and misused, on how models evolve or become obsolete, how the BI infrastructure has to evolve with the business’ dynamics. There are so many aspects that need to be considered. It’s a continuous learning process.

Processes

In processes' perspective can be depicted a dual nature too. First of all we have to consider the processes which are used to manage efficiently and effectively the whole BI infrastructure. They are widely discussed in various methodologies like ITIL, whose implementation is thoroughly documented. Secondly, it’s the reflection of departmental processes within the various data perspectives – how they are measured, and how the measurements are further used for continuous improvement. 

Considering that this aspect is correlated with an organization’s capability model, I don’t think that many organizations go/rich that far. Sure the trend is to define meaningful KPIs, growth, health and other type of metrics, but the question is – are you using those metrics constructively, are you aligning them with your strategic, tactic and operational goals? I think there is lot of potential in this, though in order to measure processes accordingly is imperative to have also the system designed for this purpose. Back to technological perspective…

 

Previous Post <<||>> Next Post

🚧Project Management: Project Risk (Definitions)

"An undesirable event which, if it occurs, can jeopardize the success of the project. These risks may affect cost or schedule." (Richard D Stutzke, "Estimating Software-Intensive Systems: Projects, Products, and Processes", 2005)

"A quantitative measure of the possibility of an accident, the product of the likelihood of the accident and its severity; in project management, an unwelcome impact on cost, effort, functionality, or schedule." (Bruce P Douglass, "Real-Time Agility", 2009)

"Threats to the management of equipment, finances, resources, technology, time frames, and people associated with specific projects." (Annetta Cortez & Bob Yehling, "The Complete Idiot's Guide To Risk Management", 2010)

"A risk related to management and control of the project." (Requirements Engineering Qualifications Board, "Standard glossary of terms used in Requirements Engineering", 2011)

"An uncertain event or condition that, if it occurs, has a positive or negative effect on a project's objectives." (Cynthia Stackpole, "PMP Certification All-in-One For Dummies", 2011) 

"Refers to the possibility of occurrence of an event, whether uncertain or of undetermined term, which is not entirely under the control of the people involved and is contrary to their expectations or interest. Risk can be voluntary, when a person acts despite being aware of that possibility." (Humbert Lesca & Nicolas Lesca, "Weak Signals for Strategic Intelligence: Anticipation Tool for Managers", 2011)

"Project risk is uncertainty that can affect outcomes. Risk can introduce a positive (opportunity) or negative (threat) change." (Mike Clayton, "Brilliant Project Leader", 2012)

"In the context of business decisions, the cost of a particular outcome. When a set of outcomes are possible, this cost is often weighted by the probability, if known, of that particular outcome occurring. Not to be confused with uncertainty, a term often used incorrectly to communicate the level of risk." (Kenneth A Shaw, "Integrated Management of Processes and Information", 2013)

"Combination of the probability or frequency of occurrence of a defined threat or opportunity and the magnitude of the consequences of the occurrence." (Chartered Institute of Building, "Code of Practice for Project Management for Construction and Development" 5th Ed., 2014)

"An uncertain event that, if it occurs, has a positive or negative effect on one or more objectives." (Paul H Barshop, "Capital Projects", 2016)

"The chance of a negative thing happening." (Pamela Schure & Brian Lawley, "Product Management For Dummies", 2017)

🧭Business Intelligence: Enterprise Reporting (Part X: Between Potential, Reality, Quality and Stories)

Business Intelligence Series

Have you ever felt that you are investing quite a lot of time, effort, money and other resources into your BI infrastructure, and in the end you don’t meet your expectations? As it seems you’re not the only one. The “Does your business intelligence tell you the whole story” paper released in 2009 by KPMG provides some interesting numbers to support that:

1. “More than 50% of business intelligence projects fail to deliver the expected benefit” (BI projects failure)
2. “Two thirds of executives feel that the quality of and timely access to data is poor and inconsistent” (reports and data quality)
3. “Seven out of ten executives do not get the right information to make business decisions.” (BI value)
4. “Fewer than 10% of organizations have successfully used business intelligence to enhance their organizational and technological infrastructures”  (BI alignment)
5. “those with effective business intelligence outperform the market by more than 5% in terms of return on equity” (competitive advantage)

The numbers reflect to some degree also my expectations, though they seem more pessimistic than I expected. That’s not a surprise, considering that such studies can be strongly biased, especially because in them are reflected expectations, presumptions and personal views over the state of art within an organization.

KPMG builds on the above numbers and several other aspects that revolve around the use of governance and alignment in order to increase the value provided by BI to the business, though I feel that they are hardly scratching the surface. Governance and alignment look great into studies and academic work, though they alone can’t bring success, no matter how much their importance and usage is accentuated. Sometimes I feel that people hide behind big words without even grasping the facts. The importance of governance and alignment can’t be neglected, though the argumentation provided by KPMG isn’t flawless. There are statements I can agree with, and many which are circumstantial. Anyway, let’s look a little deeper at the above numbers.

I suppose there is no surprise concerning the huge rate of BI projects’ failure. The value is somewhat close to the rate of software projects’ failure. Why would make a BI project an exception from a typical software project, considering that they are facing almost the same environments and challenges?  In fact, given the role played by BI in decision making, I would say that BI projects are more sensitive to the various factors than a typical software project.  

It doesn’t make sense to retake the motives for which software projects fail, but some particular aspects need to be mentioned. KPMG insists on the poor quality of data, on the relevance and volume of reports and metrics used, the lack of reflecting organization’s objectives, the inflexibility of data models, lack of standardization, all of them reflecting in a degree or other on the success of a BI project. There is much more to it!

KPMG refers to a holistic approach concentrated on the change of focus from technology to the actual needs, a change of process and funding.  A reflection of the holistic approach is also the view of the BI infrastructure from the point of view of the entire IT infrastructure, of the organization, network of partners and of the end-products – mainly models and reports. Many of the problems BI initiatives are confronted with refer to the quality of data and its many dimensions (duplicates, conformity, consistency, integrity, accuracy, availability, timeliness, etc.) , problems which could be in theory solved in the source systems, mainly through design. Other problems, like dealing with complex infrastructures based on more or less compatible IS or BI tools, might involve virtualization, consolidation or harmonization of such solutions, plus the addition of other tools.

Looking at the whole organization, other problems appear: the use of reports and models without understanding the whole luggage of meaning hiding behind them, the different views within the same data and models, the difference of language, problems, requirements and objectives, the departmental and organizational politics, the lack of communication, the lack of trust in the existing models and reports, and so on. What all these points have in common are people! The people are the maybe the most important factor in the adoption and effective usage of BI solutions. It starts with them – identifying their needs, and it ends with them – as end users. Making them aware of all contextual requirements, actually making them knowledge workers and not considering them just simple machines could give a boost to your BI strategy.

Partners doesn’t encompass just software vendors, service providers or consultants, but also the internal organizational structures – teams, departments, sites or any other similar structure. Many problems in BI can be tracked down to partners and the ways a partnership is understood, on how resources are managed, how different goals and strategies are harmonized, on how people collaborate and coordinate. Maybe the most problematic is the partnership between IT and the other departments on one side, and between IT and external partners on the other side. As long IT is not seen as a partner, as long IT is skip from the important decisions or isn’t acting as a mediator between its internal and external partners, there are few chances of succeeding. There are so many aspects and lot of material written on this topic, there are models and methodologies supposed to make things work, but often between theory and practice there is a long distance.

How many of the people you met were blaming the poor quality of the data without actually doing something to improve anything? If the quality of your data in one of your major problems then why aren’t you doing something to improve that?  Taking the ownership over your data is a major step on the way to better data quality, though a data management strategy is needed. This involve the design of a framework that facilitates data quality and data consumption, the design and use of policies, practices and procedures to properly manage the full data lifecycle. Also this can be considered as part of your BI infrastructure, and given the huge volume, the complexity and diversity of data, is nowadays a must for an organization.

The “right information” is an evasive construct. In order to get the right information you must be capable to define what you want, to design your infrastructure with that in mind and to learn how to harness your data. You don’t have to look only at your data and information but also at the whole DIKW pyramid. The bottom line is that you don’t have to build only a BI infrastructure but a knowledge management infrastructure, and methodologies like ITIL can help you achieve that, though they are not sufficient. Sooner or later you’ll arrive to blame the whole DIKW pyramid - the difficulty of extracting information from data, knowledge from information, and the ultimate translation into wisdom. Actually that’s also what the third and fourth of the above statements are screaming out loud – it’s not so easy to get information from the silos of data, same as it’s not easy to align the transformation process with organizations’ strategy.

Also timeliness has a relative meaning. It’s true that nowadays’ business dynamics requires faster access to data, though it requires also to be proactive, many organizations lacking this level of maturity. In order to be proactive it’s necessary to understand your business’ dynamics thoroughly, that being routed primarily in your data, in the tools you are using and the skill set your employees acquired in order to move between the DIKW layers. I would say that the understanding of DIKW is essential in harnessing your BI infrastructure.

KPMG considers that the 5% increase in return on equity associated with the effective usage of BI is a positive sign, not necessarily. The increase can be associated with hazard or other factors as well, even if it’s unlikely probable to be so. The increase it’s quite small when considered with the huge amount of resources spent on BI infrastructure. I believe that BI can do much more for organizations when harnessed adequately. It’s just a belief that needs to be backed up by numbers, hopefully that will happen someday, soon.

Previous Post <<||>> Next Post

🚧Project Management: Cost Performance Index (Definitions)

"A measure of cost efficiency on a project. It is the ratio of earned value (EV) to actual costs (AC). CPI = EV divided by AC. " (Cynthia Stackpole, "PMP® Certification All-in-One For Dummies®", 2011)

"The ratio of budgeted costs to actual costs (BCWP/ACWP). To forecast the cost at completion, multiply the original cost baseline by CPI." (Bonnie Biafore, "Successful Project Management: Applying Best Practices and Real-World Techniques with Microsoft® Project", 2011)

"The ratio of earned value to actual cost, indicating how close the planned cost for completed work is to the actual cost. A CPI greater than 1 means the project is under budget. A CPI less than 1 means the project is over budget." (Bonnie Biafore & Teresa Stover, "Your Project Management Coach: Best Practices for Managing Projects in the Real World", 2012)

"A measure of the cost efficiency of budgeted resources expressed as the ratio of earned value to actual cost." (For Dummies, "PMP Certification All-in-One For Dummies" 2nd Ed., 2013)

"The ratio of Earned Value of an activity to its Actual Cost. CPI = BCWP/ACWP or CPI = EV/AC." (Christopher Carson et al, "CPM Scheduling for Construction: Best Practices and Guidelines", 2014)

"A measure of cost efficiency on a project. It is the ratio of earned value (EV) to actual costs (AC). CPI=EV divided by AC." (Jeffrey K Pinto, "Project Management: Achieving Competitive Advantage 5th Ed.", 2018)

"Ratio of earned value to actual cost to measure efficiency of budgeted resources." (Cate McCoy & James L Haner, "CAPM Certified Associate in Project Management Practice Exams", 2018)

"A measure of the cost efficiency of budgeted resources expressed as the ratio of earned value to actual cost. See also schedule performance index (SPI)." (Project Management Institute, "Practice Standard for Scheduling" 3rd Ed., 2019)

🚧Project Management: RACI Matrix

"A two-dimensional table that lists tasks or deliverables as the row headings, and roles (or people’s names) as the column headings. The cell data contains the responsibility by task and by role (or person): R = Responsible; A = Accountable; C = Consulted; I = Informed." (Clyde M Creveling, "Six Sigma for Technical Processes: An Overview for R Executives, Technical Leaders, and Engineering Managers", 2006)

"A matrix used to describe classes of involved parties and their impact on a situation by role." (DAMA International, "The DAMA Dictionary of Data Management", 2011)

"A table used to document tasks and the personnel responsible for the assignments. RACI stands for responsible, accountable, consulted, and informed." (Weiss, "Auditing IT Infrastructures for Compliance" 2nd Ed., 2015)

"A matrix describing the participation by various roles in completing tasks or deliverables for a project or process. It is especially useful in clarifying roles and responsibilities. RACI is an acronym derived from the four key responsibilities most typically used: Responsible, Accountable, Consulted, and Informed." (ISTQB)

🚧Project Management: Schedule (Definitions)

"The planned dates for performing activities and the planned dates for meeting milestones." (Timothy J  Kloppenborg et al, "Project Leadership", 2003)

"(1) A document showing the tasks for a project and specific calendar dates when each task will be started and completed. (2) The total time elapsed to build a product (calendar days)." (Richard D Stutzke, "Estimating Software-Intensive Systems: Projects, Products, and Processes", 2005)

"The set of project milestones and their planned dates of accomplishment. The actual dates of accomplishment are also usually recorded as the project proceeds." (Richard D Stutzke, "Estimating Software-Intensive Systems: Projects, Products, and Processes", 2005)

"The schedule contains all the activities that need to be performed, including their sequence and interdependencies, milestones, duration, estimated effort, start and end dates, as well as resource assignment. In addition, it should detail the critical path or paths." (Lars Dittmann et al, "Automotive SPICE in Practice", 2008)

"An ordered set of tasks characterized by duration and loading onto resources. For project management, this is the plan that specifies which people should perform what tasks when. For a concurrent system, this is a statement of what tasks should be executed by the scheduler and when." (Bruce P Douglass, "Real-Time Agility", 2009)

"The planned dates for performing schedule activities and the planned dates for meeting schedule milestones." (Project Management Institute, "Practice Standard for Project Estimating", 2010)

"The overall timeline for a project including task dates, durations, relationships, costs, and resource assignments." (Bonnie Biafore, "Successful Project Management: Applying Best Practices and Real-World Techniques with Microsoft Project", 2011)

"The planned dates for performing schedule activities and the planned dates for meeting schedule milestones." (Cynthia Stackpole, "PMP® Certification All-in-One For Dummies", 2011)

"An output of a schedule model that presents linked activities with planned dates, durations, milestones, and resources." (For Dummies, "PMP Certification All-in-One For Dummies" 2nd Ed., 2013)

"A listing of project tasks, subtasks, and estimated completion times." (Robert F Smallwood, "Information Governance: Concepts, Strategies, and Best Practices", 2014)

"Time plan for a project or process. Note: on a construction project this is usually referred to as a 'project programme'. The construction industry tends to refer to programmes rather than schedules. Indeed the term schedule tends to mean a schedule of items in tabular form, e.g. door schedule, ironmongery schedule, etc." (Chartered Institute of Building, "Code of Practice for Project Management for Construction and Development" 5th Ed., 2014)