It is an old story: about 30% of IT application projects succeed, 45% are “challenged,” and the other quarter fail altogether.   That’s the consistent result over the years of the Standish Group Study of Project Outcomes.  Jorge Dominguez, here, displays a chart of the remarkably similar results since 1994.  Not a pretty picture, right?  Some question the validity of the Standish studies, but Scott Ambler parallels the Standish story in a recent Dr Dobbs column called “Lies, Great Lies, and Software Development Project Plans,” which itemizes the strategies commonly used by IT project managers to “stay out of trouble” when schedule/budget results don’t match initial estimates.  For example, “18% change the original schedule to reflect the actual results”.

The frequent reaction to stats like these is to scapegoat the IT folks by finding fault with their tools, processes, or skills.  If we just had a more efficient methodology, or a slick development suite, or a more highly skilled team, or a better project process, were more agile, or whatever, then application projects would be on time, resulting systems would be faultless, and we could drive down outrageous IT costs.

Mr. Ambler plays out the IT perspective in this column about Agile project estimation.  Here’s how I paraphrase the gist of his logic: you can’t accurately estimate early on due to normal uncertainty of high level requirements; you will get new requirements that will expand scope.  If you offer a range of predicted outcomes, management will hold you to the most optimistic, which will turn out to be a gross underestimate. Your best strategy is to use an accurate estimation method (net or average velocity, described in the article), and be straight with management even if they “don’t like what they are hearing”.

Based on my experience that sequence of events can be distressingly true to life.  But I’ve been on the other kind of IT project as well, the kind that ends on time, stays on budget, and satisfies the business. The scope of Mr. Ambler’s article doesn’t include asking why the requirements are changing so drastically, but if it had, maybe he would have asked questions like these:

• Does the business unit involved have defined objectives and processes?
• Are strategic and tactical business objectives of the project defined, and do they support the business unit’s objectives?
• Are the critical business success factors of the project defined?
• Does the new project change business processes and if so have the new ones been defined yet?
• Are there documented business requirements and a process for evaluating/approving changes?

Based on what I’ve seen requirements shifts that nearly double the cost of an IT project, like the ones Mr. Ambler describes, result from inadequate business definition and business requirements analysis.  Of course it is true that the “initial high-level requirements and architecture envisioning” early in a typical project only enables an estimate “in the +/- 30% range”.  But effective requirements and architecture definition, when based on effective business definition, can enable a much closer estimate.  Further, it is possible to accurately estimate how long it will take to provide the more accurate estimate.

In some cases the business definition prerequisites clearly don’t yet exist at the outset of an application development effort.  One thing I’ve seen work in such cases is to divide the project into two separate projects: one to closely define the effort, and if needed make up for any lacking business definition, and another to build, test, and install the application. In between the two phases management will have the opportunity to review the costs/benefits of the project and evaluate whether to continue or not.  This post describes one project that successfully used that strategy.

Please don’t read this as repudiation of Agile methods and advocation of “big requirements up front”.  Agile methods work well whether or not business prerequisites are defined, but they seem not to work well when (1) the project’s goals shift with evolving business definition and (2) the plan and budget aren’t adjusted accordingly.

Business definition, completed as part of a discrete requirements phase, that leads to a management decision to continue or not, gives the team the opportunity to build on a solid business foundation.  It also gives management a reasonable estimate and a chance to bail if the project isn’t worth it.

According to Mr. Inmon, virtual data warehousing reminds him of the carnival game called whac-a-mole.  He says “just when you think this incredibly inane idea has died and just when someone has delivered what should have been a deathly blow, out it pops again from another hole.” There’s just a very informal definition of virtual DW in Mr. Inmon’s post (remember, he says he’s whacked this mole before), but, as I interpret, he’s talking about a system built after a decision to avoid all the expense of building a data warehouse by just having a query engine that pulls the data from wherever it lives. Mr. Inmon argues that a query accessing diverse databases would leave data integration to the user, and there’s no guarantee that two users would integrate data the same way.  He cites virtual database query inefficiency risks and, on the assumption that the query is trolling operations focused databases, says that source data would be “tuned” to operational rather than informational specifications for history retention and completeness.

Mr. Inmon’s ideas drew quick reaction from Mr. Kobelius and Neil Raden.  Each in his own measured way stresses that integration can be compatible with distributed architectures, and that there is a DW solution architected for efficiency that includes effective data integration from diverse sources: the Federated Data Warehouse.

Experience and emerging tools reinforce their point.  According to a colleague at CapTech, for smaller organizations “you can deal with this issue using a BI tool with a metadata layer that has joins predefined: the data integration is done by the BI metadata modeler.”  Another CapTech’er cites mashup as a potential quick and dirty approach.  Check out “7 Mashups Every Company Needs” here.

A well-architected federated warehouse certainly can integrate and deliver data, maintain history, and enable a “single version of the truth”, perhaps in a more timely manner than a “traditional” DW architecture.  On this question the devil is in the specifics of the situation.  It is difficult to argue one way or another out of the context of a real project in a real organization.

However, even though it certainly has a technical side, data integration is first a business activity.  Sometimes when we apply terms like “semantic rationalization” to software components, we in IT start believing you can actually build a machine that does the things you need to do to rationalize data semantics, like figure out the corporate definition of a customer.  Of course all we can do in IT is to build the empty shell.  The real work happens when business people from departments whose data is being integrated sit down and decide how they are going to define “staff member”, “customer”, and so on.  Only business professionals can say, for example, whether they want to include contractors in staffing reports or whether the term “customer” includes homebuyers under contract but not yet closed.

Integration tools that support data warehouses, whether centralized or federated, are only as good as the business consensus behind them. The consensus behind integrated data is arguably more rewarding to the business that the tools because with consensus on critical objects and events come non-IT-specific improvements like reduction of repetitive and conflicting business processes, reduced communication breakdown due to terminology disconnects, and more.

To me the beauty of the Inmon DW model is that it provides a mechanism that can assist an organization in evolving toward improved information maturity.  Organizations achieve some benefit by simply integrating data into a single data warehouse.  However, the data warehouse also makes source data quality problems obvious and blatantly reveals differences in data meaning from one operational source to another.  So the warehouse delivers some benefit early and also shows how much better it would be if data were integrated.  It therefore becomes a tool for identifying, assessing, prioritizing, and motivating correction of data deficiencies.

For organizations not so far along on the maturity curve, the additional complexity of the federated warehouse tends to obscure this data quality feedback loop. Federation based on drawing from operational sources integrates data from a set of different databases built toward different architectural goals.  On the other hand, the logical data model for the enterprise warehouse is the enterprise data model, and its architectural objective is to integrate enterprise data to provide a single source of truth.  Therefore, the enterprise data warehouse provides an architectural focal point for integration.  It isolates responsibility for improving data integration crisply at either the source or the warehouse, and — within the framework of solid information management strategy, management, and facilitation — motivates diverse business players to work toward consensus definition of enterprise data.

Federation, or virtual data warehousing if you will, can be the best strategy for the mature organization that has already integrated business data to a consistent enterprise view.  For the rest of us, the single centralized warehouse with its unambiguous architectural goals and borders seems the shortest distance to achieving the business benefits of data integration.

Many see IT as application of technology to solve business problems. 

Of course, this is true but it leaves out the third element, which is to apply the right architectural pattern to solve the problem.  For example, when the business problem is that reporting is slow and reports from different departments don’t match, the astute IT professional immediately thinks in terms of a data warehousing pattern employing technologies like databases, extract-transform-load (ETL) tools, and multi-dimensional reporting suites.

A strategy based on the tools alone may solve the immediate problem, but understanding the solution-pattern enables the IT professional to bring to the business the additional benefits that come with the pattern, organizational and IT support impacts, and any risks that might emerge by applying the pattern.  In the data warehousing case the informed architect might cite improved executive dashboards and ability to drill down to root causes from summary reports, the need for data stewardship, and potential long term increase in data storage capacity needs.

Beyond that, when the architect lacks the pattern approach he or she seems to the business person like Bob Dylan’s debutante: “Your debutante just knows what you need, but I know what you want.” On the projects I’ve been on where designers lacked a pattern-based perspective the technical team did exactly what the business folks said they wanted, but for the most part didn’t contribute to the business value of the solution.  On projects like this developers slavishly ensure the solution matches each and every requirement, rarely bring to the table new business requirements that are logical consequences of the design, and tend to avoid questioning defined requirements even if they are contradictory or counterproductive.

Sure, patterns aren’t strictly necessary.  An outstanding architect can design from whole cloth an original solution that precisely matches business need.  However, that’s not how outstanding architects do business, at least the ones I’ve known.  In my experience the best IT architects know patterns, like data warehousing, SOA, and others, well enough to match the business problem to the right pattern and then evolve the architecture from the generalized pattern into a problem-specific architecture based on the particulars of the business problem at hand.

Some examples of common solution patterns in the world of business IT are Data Warehousing, Master Data Management, and Service Oriented Architecture (the Wikipedia article on this one is preliminary at this writing but still a good intro for the uninitiated).   Those interested in a more technical introduction to patterns might start with Avel Avram’s quick intro at InfoQ (Membership at InfoQ is required but free and worthwhile).

And of course, apologies to Mr. Dylan for the title…

Some claim that the relational dbms may be out of style very soon.  Cool new “cloud computing” and “SaaS” apps and services  delivered over the internet seem to be popping up everywhere – just look at Salesforce.com, the well-established Customer Relations Manager vendor, and the many cloud-based PC backup sites.  As part of that trend, Amazon, Google, Microsoft and others offer database services over the internet that don’t look much like relational dbms’s.  Some supporters of the cloud-db options seek alternatives to the standard relational DBMS (note this widely read article).  Of these, many are OO developers.  There’s a fundamental dissonance between OO and relational approaches, requiring an intermediate object/relational mapping (ORM) layer for OO systems to operate effectively with relational DBMSs.  Many of the new cloud-db options are open source, lightly structured data services provided via the internet, capable of storing and delivering large data stores for high availability, fast response applications.

The convenient thing about relational databases is that they pretty much match the business view of data, and therefore give business people and developers common ground.  A well thought out relational data model is one way to express the inherent structure of business rules (see this previous post).  A relational model at the back end of a custom-built system means that both developers and business people can talk about the real guts of a system in ways that make sense to both, like this:

• Developer to business person: “Should we allow a part_order to include items from only one division”
• Business person to developer: “After a call from our shipping department, I ran a query on the part_order table and found a that there is a part_order with null shipper_phone_number. I thought it was a required column, what’s up?

How’s it going to be when those comments don’t reflect the underlying structure of the database?  Today’s cloud db offerings vary in structure, but tend to favor highly efficient and flexible models like name-value pairs, and avoid the overhead required by semantic layers like the relational model.  According to the MongoDB site, “by reducing transactional semantics the db provides, one can solve an interesting set of problems where performance is very important.”

In such databases the structure of the data will be hidden from business people; there will be no shared business/IT view.  Rather than talking with business people about the actual database structure we’ll talk about its custom abstraction, and when things go poorly with performance and functionality the developer will in effect say “trust me on this one” to the business person rather than explaining what’s up.

For a long time cloud databases will be another option alongside the relational model, but the more prominent cloud databases become the more difficult it will be for developers and business people to communicate about business data in IT applications, and it could be a serious challenge for developers to learn to cross that communications gap without the bridge provided by the relational model.

Excerpt from "Show Me the Money: A DM/BI Business Value Primer", Bob Lambert and Tri Truong, Information Management Special Reports, March 24, 2009

1. Intangible benefits don’t count.
2. BI has no inherent value.
3. Senior managers often make decisions about future outcomes with insufficient data.

Intangible Benefits Don’t Count: An effective business case communicates tangible future value in a convincing way.  An argument has a chance of convincing a skeptical reader if the reader agrees that the argument’s assumptions are reasonable and that the conclusion follows logically from the assumptions.  Quantifying financial metrics like Return on Investment (ROI) or Net Present Value (NPV) help build the case, but such measures are credible only if readers agree with the underlying assumptions and the logic built upon them.

BI has no inherent value: We in the BI field believe that any organization’s fortunes would improve if it rationalized its data stewardship, integrated its data, and applied analytics creatively in management and operations.  However true, that view must ring hollow to senior business managers.  Without a compelling and motivating story about how a new system contributes to revenue or reduces costs, that system’s business case stops dead in its tracks.  Of course sometimes “someone at a high level” just wants BI, but organizations don’t often embark on BI efforts without first evaluating tangible costs and benefits.

Senior Managers Make Decisions about Future Outcomes with Insufficient Data: Although BI practitioners must make a convincing case for future business value, there’s room for uncertainty.  Executives and senior managers aren’t highly compensated for playing it safe, but rather for understanding current conditions and setting direction based on educated but sometimes courageous predictions of future conditions.  A successful BI business case matches or extends the executive’s knowledge of current conditions and expands his or her view of potential future outcomes of near term actions.

That said, it seems to me that there’s something missing.  Consider one BI manager I know who has fractious relations with his business customers.  I won’t go into detail, but trust me, relations have been rocky, and reviews from key business players poor.  What this person does extremely well is to build rock-solid, reliable systems, deliver on time, meet business needs, and ensure that the solution meets regulatory and audit concerns.  This BI group is essentially unchanged after many years, enduring even the recent recession in a devastated industry segment, and outlasting many of its critics.

To me, building a good relationships is important, but execution is the sine qua non of IT/business alignment.  Think about it.  Say you hire a really nice contractor to fix a leaky roof.  However personable he is, you won’t hire him to replace your windows if the roof still leaks after you’ve paid the bill.

My view: if you want to do it right adopt Villar’s and Kushner’s excellent suggestions but the fundamentals remain the same:

1. Either (a) present a robust business case that all accept, or (b) pay attention to what you’ve been asked to do
2. Deliver what was requested/promised in 1
3. When things change go to 1

Whatever project management approach a team uses, sometimes everything falls apart, commonly due to work piling up at the end, but sometimes due to a key individual leaving, or a pivotal assumption no longer holding true, or many other reasons.  When that happens, the project can become like a whack-a-mole game, with leads working from issue to issue as they pop up faster and faster.

I served as one of many workstream PMs on one very large project where this didn’t happen.  Out of the seeming chaos the multi-million dollar IT project came in on time.  Here’s my view of what we did to succeed:

• Had very clear interim milestones that were generally known and served as reference points for discussion.  I’d characterize them as a milestone per workstream per month.
• Held seemingly interminable weekly risk/issue discussions.  These were open, no holds barred reviews of anything at all that could endanger achieving milestones.  Often risk/issue discussions are polite exercises in avoiding the fact that the emperor has no clothes, with team members carefully avoiding forbidden topics.  On this project everything was open for discussion.
• The program manager excelled at visibly not sweating the small stuff, directing workstream leadership to handle their localized risks and issues themselves, and focusing program energy only on those he judged to have overall impact.
• Each of the many workstreams had its own project schedule; the program insisted on detail where it mattered but not where the detail was irrelevant.  For example, there was a minutely detailed cutover plan for production migration.

Many of us were surprised when the chaos all came together on time with surprisingly few glitches. I attribute this program’s success to the program manager’s unflappable focus on milestones, encouragement of unfettered group risk/issue analysis, and ability to parse program from project concerns.

In his book Money Mischief Milton Friedman made the point that money has no intrinsic value: “The value of money is the value people attribute to what they want to exchange, no more, no less.” Likewise, data has no value in itself.  Its value is derived from people’s desire to know about the things the data describes, and how reliably and accurately it describes those things.  So an organization’s data, like its money, is not a resource in itself.  It is an asset that represents the resources that an organization manages and controls.  It follows then that data management should look a lot like money management.

A cornerstone of our economic stability is consensus that organizations must manage money well and make their internal money management visible to investors, regulators, and independent standards groups.  We’ve evolved a standard for money management where a department represented by a C-level executive administers formal accounting, budgeting, planning, and financial reporting.  The organization evaluates every manager’s compliance to money management policies, and independent auditors evaluate the organization’s soundness in terms of its money management.  Accounting professionals meet rigorous, generally respected certification standards.

Overall, our volume of online purchases and use of FDA-approved drugs, for example, attest to our general confidence in current data management practices.  But still, data  professionals know that it could be a lot better.  Scarcely a week goes by without another scandal involving lost customer data, and consider these snafus:

• This article cites multiple non-compliant databases as a significant contributor to the chaos in reuniting families in the wake of the Katrina disaster
• “The Mars Climate Orbiter, a key part of NASA’s program to explore the planet Mars, vanished in September 1999 after rockets were fired to bring it into orbit of the planet. An investigative board later discovered that NASA engineers failed to convert English measures of rocket thrusts to newtons, a metric system measuring rocket force, and that was the root cause of the loss of the spacecraft. The orbiter smashed into the planet instead of reaching a safe orbit.” (cited here)
• One Fortune 1000 services company carried separate customer records in each of its operating units resulting in a number of anomalies visible to the customers.  For example, the same customer would receive separate invoices with different terms for each of the services purchased from the company.

In parallel with emergence of these types of issues, regulators and industry associations have set data management standards for many industries and practice areas.   Food and consumer product safety rests on a regulatory foundation of correctly recording and managing results of inspections.  The International Air Transport Association sets standards for safety data collection and management.  Likewise, the US Food and Drug Administration and other governing bodies set clinical safety data management and reporting standards.

It is just a matter of time before the many separate externally imposed data management guidelines congeal into a a set of general best practices that apply across the organization.  Then investors, regulators, and standards groups will hold organizations responsible for effective data management in the same way they are held to account for effectively managing money. An internal department represented by a C-level executive will administer formal data management standards and procedures.  The organization will evaluate every manager’s compliance with data management policies, independent auditors will evaluate the organization’s soundness in terms of the quality of its data management, and data management professionals will be held to rigorous, generally respected certification standards.

Farfetched? Maybe.  But it isn’t farfetched to think that as a society we’ll begin to recognize what data professionals have known for a long time: that the quality of an organization’s products, its care of and protection of its customers, workforce, resources, stewardship of the environment, and even its financial health depend to a significant degree on sound data management practices.

—

Here are some resources on data management:

DAMA, the organization for data management.

The Wikipedia page quotes this definition: “Data management is the development, execution and supervision of plans, policies, programs and practices that control, protect, deliver and enhance the value of data and information assets.”

Data Stewardship Strategy: 6 Keys to Success by Jill Dyché: “As executives increasingly agree that data is a corporate asset, they are also funding data governance and data quality efforts more willingly. But … entrenched organizational behaviors are much more difficult to shift. Many companies have introduced the role of data steward before fully defining the role. In these cases, the beleaguered data stewards are doomed before they even begin. ”

Leverage Data Quality to Build an Effective Enterprise Architecture by Mark Amspoker.  “It might be time to rethink the notion that effective information architecture development will solve the data quality problem.”

Guidelines for Responsible Data Management in Scientific Research from the Office of Research Integrity, US Department of Health and Human Services.   “Data management is one of the essential areas of responsible conduct of research, as outlined by the Office of Research Integrity. This educational course will educate new investigators about conducting responsible data management in scientific research.”

I’ve cited here the need to start data interface analysis early to avoid budget and schedule blow-ups when, as a result of not thinking early about interface complexity, data integration work turns out to be bigger and nastier than anticipated.

Early data study also helps business analysts elicit more detailed and accurate business requirements.  Say a mid-level football (soccer) team in the UK is looking to recruit a couple of strikers who can reliably punch home goals for the club.  The obvious data they seek is (1) the number of goals scored per game by each prospect, and (2) over their careers how much time have they spent on the bench due to injury.  At the same time, this club is building a strategic recruiting system to support growth into the higher echelons of English football.  A process-oriented requirements strategy (like the one described here) asks the team’s recruiters what they need to in order to get good people into the club, and often emerges with a list of statements about what the system will do (”The system shall provide an interface enabling entry of the following player statistics” or “The system shall provide a report ranking players by the following criteria:…”).

It isn’t necessarily wrong to start with process analysis, especially when backed up with formal techniques like use cases, data flow diagramming, or others, but addition of data analysis early provides ability to be far more perceptive into the real business needs.  Without interviewing anyone a data analyst can know that there are many goals in a game of soccer (OK, to some not nearly enough, but that’s another story), that the attributes of a game include location, weather conditions, date and time, whether it’s regular season or playoff, and more.  Attributes of a goal: time during the game; left foot, right foot, or head; did it come from a set play or in the run of play; from the left or right side of the field, and much more.

The analyst who knows the data and understands its structure can probe with questions like whether a player tends to score at the end of games, or would it be useful to find one striker who tends to score from the left side of the field and another who scores from the right?  By understanding the data an analyst can understand the business problem more deeply, build better rapport with business people  by asking more informed questions, and cross the business/IT communications gap to define the right requirements so that the right system gets built.

It may be just the organizations I’ve been exposed to, but in my experience data analysis isn’t typically part of the requirements effort.  Supporting this point, the author of the wikipedia page on business analysis entirely omits data analysis, apparently favoring a process-only approach.  On the other hand, object-based techniques offer a balanced approach, studying both data and process by representing things like goals, games, and players as objects with their own attributes and behaviors.  In addition, the International Institute of Business Analysts (IIBA) includes data-oriented along with process-oriented techniques in its Business Analysis Body of Knowledge (BABOK).

As process/data balance early on in the application lifecycle becomes more widespread analysts should generate more insightful requirements and, other things being equal, the success rate of IT application projects should improve.

Here’s Paul’s description of the Sancho Panza test:

Think of Don Quixote [DQ] as the data-quality specialist or even the data management specialist or software vendor, bringing to the world his specialist’s perspective and vocabulary and enthusiasm, influenced by the books he’s read, visioning everyday business practices, with his value added, as goldmines for the organization.  Meanwhile Sancho Panza represents the person who does a practical job every day, who knows what works around here and what doesn’t.

I advocate to Data Quality (let’s call it DQ) consultants that they listen to this Sancho Panza, and consider themselves as Don Quixote.  Sancho doesn’t know much about data, but he knows what he likes… He’s open to listening, but slow to change, and he’ll tell you what he thinks.

Paul’s article reminded me that as a child I thought the problem with Don Quixote was that he tilted at windmills and attempted to ambush acting troupes because of his bad eyesight.  Of course this is not the case, but to me it provides a relevant perspective on data quality in many organizations.

Here’s the problem I’ve seen play out on a number of IT application projects:

1. A high level business study recommends replacement or improvement of a current application.
2. The organization approves the project described in a business case citing benefits named in the business study and costs detailed for infrastructure, package software, and application development, but data-related costs are glossed over or left out entirely.
3. The project begins with a requirements phase that collects hundreds of imperative statements (“The system shall…”)  from business people who will use the system.
4. Late in the requirements phase, the team finds that data integration work in system interfaces will be more complex than expected.  A common example: the project requires changes to a feeder application with no documentation and no in-house support expertise.
5. Project leadership goes back to the sponsor seeking more money.

In these situations the business case was incorrect because it did not account for all of the costs of data integration.  I’ve seen projects weather steps four and five well, but often discovery of previously unseen data complexity starts a disruptive chain of events.  (Sadly for the project manager, such situations are often seen as a failure of project management and corrected accordingly, but that’s a topic for another post.)

In my view the root cause of unforeseen data complexity on projects is the lack of a data constituency in current IT. It is only recently that success of companies like Google and Amazon have motivated emergence of data as a key business resource in the collective consciousness. Famous success stories notwithstanding (see this link), there are relatively few senior IT managers with data quality backgrounds.  Conversely, many rose through the ranks of the infrastructure, application development, or business (process) analysis groups.

It will be a while before, for example, a Mobil CIO’s predecessor jobs include definition of a metadata repository or elimination of multipurpose data, but in the meantime here’s what we can do:  add a business case to the application lifecycle as the last step in requirements.  Stop the project when the real costs are known, recalculate the cost/benefit, and ask the sponsors if the project should continue.  Give Sancho (in this case the project team) a chance to speak to the reality of the situation, and hand to Don Quixote (project sponsors) the eyeglasses of in-depth visibility into real costs. If the decision is to move ahead with the project, then all share the same vision and the sponsors have endorsed the actual project, not the fuzzy image from earlier on that might have been a windmill.