Bob Lambert

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

Before starting the Business Intelligence business case, the BI advocate should do the homework required to ensure its success, including these essential steps:

1. Know the organization’s goals and objectives.
2. Identify a BI champion.
3. Identify and work with BI stakeholders.
4. Identify an application with tangible business value.
5. Define and quantify a quick win prototype project.

Know the organization’s goals and objectives. It is human nature for any of us, including executives, to be receptive to help with our own goals and objectives but less receptive to new ideas that aren’t related to our own goals. Furthermore, senior executives facilitate intensive strategic planning processes to set the right corporate goals and objectives. A proposed BI initiative should clearly and tangibly help achieve strategic objectives already in place.

Identify a BI champion. BI is in a unique position within the application stack. Most organizations can operate without a BI strategy. However, most companies would greatly improve their market position with a comprehensive BI solution. The impetus for deploying such a solution needs to come from a leader within the corporation who champions the value that BI brings to the organization as a whole. Often, this champion is someone at the top level of the business chain of command with a solid grasp of the BI’s potential.

Identify and work with BI stakeholders. BI projects should be driven by BI stakeholders, those who will see direct effects (good or bad) from the BI project. Some stakeholders look to benefit from BI-based solutions to concrete problems. Other stakeholders will have to be convinced about the potential value of BI. Both types of stakeholder must be involved in defining and supporting the goals of a BI project.

Identify an application with tangible business value. Again, in order for the BI application to return value, it must focus on achieving business goals. These goals should be measurable so that the value of the BI application can be determined, and the application should contribute to overall organizational strategy.  Scroll down to “Business Value Examples” here for more.

Define and quantify a quick win prototype project. Businesses must quickly see the value that BI brings in order for it to catch fire in the organization. A prototype project is often the best way to showcase BI’s value proposition. These projects should typically produce tangible results in a matter of weeks and target a well-defined business area. The prototype should have a well-defined goal and ROI metric, and produce data or case studies that show progress toward, if not achievement of, that goal.

- Thanks to co-author Tri Truong for assistance with this post.

History is littered with IT application projects that end late, go way over budget, or abandoned altogether.  I was fortunate enough to see one work out really well (almost – please read on).  It was no mistake.  It came down to a simple method advocated by a gentleman named named John Carpenter.

The project was an HR management software conversion from one commercial off-the-shelf software (COTS) package to another.  The company concerned was conservative about spending money.  A previous business case had proposed a similar project.  The problem with that business case was that the benefits were really tough to conceptualize, so the cost/benefit analysis relied on soft benefits like “improved access to information” and “more consistent reporting data”.  The folklore was that the CFO had physically thrown that business case out of his office.

Mr. Carpenter’s method was to divide requirements definition and implementation into two distinct projects, with a different business case for each.  Under his direction, we wrote a ~1m business case for requirements definition only.  We proposed that this first project would result in another business case precisely specifying the schedule, method, cost, and benefits of the implementation project.

According to John, “the approach we used would not be considered a textbook approach for an ERP (enterprise resource planning) implementation.  What we did was more of a strategy to address the the CFO’s concerns.  The company was very risk-averse so we needed a way to take out as much risk as we could.  This was a large project because it involved four major modules affecting the three main areas of HR, and the company wanted to know costs and benefits at each step.  Complicating matters, HR business processes and therefore requirements were not clearly understood – the HR department seemed to rely on on the job training rather than documented procedures.  So we presented the first phase as an investment into understanding HR processes, as well a precise roadmap for implementation.”

This first business case was accepted by that same CFO and we got started on the 7-month effort. We brought in a consulting team experienced in the proposed COTS package, and followed their lead in requirements definition and prototyping.  During the prototyping step they walked HR staff through each relevant function in the software package, detailing how to configure the package for their specific needs and where we’d need to customize it.   The result was a definitive, detailed document that showed how the package fit HR process and how it would need to be customized.  Then, we used those results to build a business case that included specific configuration, customization, hardware, and software costs, as well as the process and organizational changes that would be required, not to mention the benefits that would accrue.  The business case showed substantial improvement, predicting real financial benefits within 4 years.  Even better, on a depreciated basis the project literally was almost free, costing only $1,800 in the first year and returning benefits thereafter.

The business case was accepted by the company’s executive committee and the project started.  It ran exactly as outlined by the results of the requirements effort, with very few of the nasty surprises often typical of large projects, and it tracked to forecast schedule and budget.

Proving that no good deed goes unpunished, the company, whose core business was real estate, in effect folded in the financial crash of last autumn ’09 , one month from implementation.

At any rate, the lesson I took away from the effort was that dividing requirements and development into separate projects gives business visibility into a project, helps manage financial risk, and enables the project to ground predictions rather than guessing at costs and benefits before they can be known.

Excerpt from "Illusions, Allusions – Let’s Get Real about Database Design", October 4, 2002

Much of today’s IT application development – custom or off-the-shelf – involves integrating data from legacy systems, third- party software products and external data sources such as demographics or mail lists.  More often than not, data integration is unexpectedly complex, either due to data quality issues or the nature of the data integration itself.

Here are some typical examples:

• One ERP package uses the same table for both Sales Quotes and Sales Orders. Columns that mean one thing for Quotes mean quite something else Orders. One team extracting data from this ERP package continually mixed up, for example, Date Received on the Quote with Date Prepared for the Order. The designer who blindly copies data from input systems can propagate these issues. In this case, the correct solution is to extract the two documents into separate tables in the destination system, making each column describe either a quote or an order, not both.
• Marketing databases often store data purchased from several third parties on the same set of customers. These sources usually include overlapping columns with different values. For the same customer, different sources might store different values for the person’s address, credit scores or even name. It is sometimes important to preserve all of the columns from all of the sources and to maintain the information on where the data came from as well as what its value was. This can result in a messy database design, where columns again carry dual meaning: their value and their source.
• Codes from legacy databases tend to evolve into complex forms, embedding more and more information into a single field. This is perhaps a natural reaction to the slow evolution of the system relative to changes in business, as users shoehorn information into the system that it was not designed to store. For instance, in a legacy system a one- character code might classify customers by “customer category,” with values 1 for small business, 2 for mid-size, and 3 for Fortune 5000. Users might add codes 4, 5 and 6 for corresponding values for aerospace customers, then 7 for federal government, and so on. The database designer must know the data well to extract each embedded concept into a different destination column.

When data integration is part of a project, expect complexity and leave room in interface development estimates for devils in the details of source system analysis and integration design.

Not everyone gets to be a leader, and most leaders are also followers in their own right.  The project manager follows instructions from the project sponsor, the CEO from the board, the politicians from the polls, and so on.

Followership is the yang to leadership’s yin, and according to many interesting sources following can be as fulfilling and important as leadership. For example, check out this site: http://www.exe-coach.com/followerPartnership.html.  Quoting: “When both the leader and follower are focused on the common purpose a new relationship between them arises. This new relationship is candid, respectful, supportive and challenging. It is a relationship that honors open communication, honesty and trust from both parties.“  The article argues that effective followership is the key to making today’s flat organizational models successful and mitigating risk of corporate malfeasance and scandal.

Think about it: more people are followers than leaders, so isn’t it more important to cultivate effective followership than effective leadership?

Recently I was asked for a high level requirements plan for a large IT conversion.  I googled around a little for something standard.  I found some good references (see links at the bottom of this post), but not exactly what I was looking for: a simple, method-agnostic layout of the high level steps and checkpoints in requirements for a big project, emphasizing interactions with business people.   I then rifled my files to find the example below.

This summary plan frames up interactions with business subject matter experts and their review of results.  The table lays out the steps, “granularity” (meaning how often each step is carried out), what comes out of each step, who does the work, and offers a few notes.

Before the table, here are two important definitions:

• Sponsor: Very early on in your project you should identify the one person who you need to make happy in order to succeed.   The bigger the project, the higher up the sponsor.  Keep in touch to make sure they know what’s going on, keep them happy, and if something happens that will make them not happy don’t keep it secret.  Maintain a vibrant risk/issue process so that you can give them early warning of bad possibilities and they can help early.
• Stakeholder: A stakeholder is anyone who will benefit from or be harmed by your project.  Requirements come from stakeholders.  Be sure to build support even with the latter group if at all possible, and at least make the adjustments that will keep them from working to prevent you from succeeding.

Careful, this is just an empty vessel.  Within this high level framework a team can apply whatever requirements techniques they want.  (In fact, I highly recommend structured analysis techniques like use cases or process models, but that’s for the requirements team and this framework is for the PM).  Of course a smaller effort suitable for agile techniques wouldn’t need something like this.  This is for big transitions like conversion to a new COTS package, for example, where it is easy to get lost in the detail.

Hopefully if you’re a PM on a big project you’ll find this framework as useful as I did.

 Here are some of the other references I found along the way, caveat emptor:

• http://www.outsource2india.com/software/RequirementAnalysis.asp
• http://en.wikipedia.org/wiki/Requirements_analysis
• http://www.jiludwig.com/HCI_Journal_article.html

I’ve heard that “A good project manager can manage any project, as long as they’ve got good people on the project”. In the perfect world, maybe. In the real world, no way.

Those promoting project management focus on characteristics of PMs that are common across all disciplines: interpersonal skills, organizational skills, communication skills, and problem-solving skills.  These are necessary but not sufficient qualities.  Good project managers also have interest and depth in the subject matter of the project.

It seems that the world has forgotten about history’s great project managers. They were overwhelmingly individuals with abiding interests in their fields.  Werner von Braun led the massively successful development of the Saturn moon rocket. General Bernard Schriever, the man cited as “The Father of Project Management” (here), who led the Air Force’s space and missile programs in the 1950s, was a long time pilot with an engineering degree.  Frederick Brooks, with a PhD in Mathematics from Harvard, led development of IBM’s OS/360 operating system, fundamental to IBM’s dominance 0f commercial computing during the 70s and 80s. “As of 2008^[update] he is still engaged in active research there, primarily in virtual worlds and molecular graphics.” (Wikipedia)

I recently witnessed two IT projects, both multimillion dollar efforts and both business-critical.  Project A, a migration to a commercial-off-the-shelf (COTS) human resources system, tracked to budget and schedule and met business objectives with almost no customization.  Project B, another COTS effort for core business operations, suffered huge budget and schedule overruns associated with frequent changes in direction and scope expansions.

Project A was outsourced to an outside consulting firm, who brought in a PM with deep technical experience configuring and customizing the COTS package.  Project B was run by an internal Project Management Office, staffed by project managers who did not have technical or business analysis backgrounds.

Project A’s leadership had the background to understand the road ahead, and spent six months of a two year project in definition, completing detailed business requirements, business process design, and system architecture deliverables.  On Project B, a senior IT manager decreed that the team skip requirements definition, since future business processes would be dictated by the COTS application: a critical early mistake.  Project B’s management did not have the IT background needed to recognize the mistake, which would have been obvious to the Project A team.

For a PM to be effective he or she needs sufficient knowledge to envision the end product in a scope and objectives document, create a work breakdown structure that makes sense to business and technical team members, and know which risks are pivotal and which don’t matter.

In spite of stereotypes about IT folks, many are experienced, articulate, well organized, have great interpersonal and problem-solving skills, technically curious, and would welcome an opportunity to lead an ambitious project.  Make one of them your project manager, provide strong organizational support, and you’ll be more likely to achieve objectives on budget and on schedule.

An architectural template is a generalized architecture that illustrates features common to all examples of a given type of system. A template may be thought of as a “fill in the blanks” form for a project lead, identifying typical components, good analysis and design techniques, general project planning guidelines, staffing skill needs, and more. The data warehouse model is a good example (check out the Wikipedia article on data warehousing). It identifies distinct components and interfaces that make up a data warehouse, and defines the quality and performance characteristics that make them work well.
Most importantly, the template gives rules for deciding whether or not a system is an example of the given architectural type. With a good template, it is possible for a systems architect to compare the template with the general functions and objectives of a planned system. If the problem matches the template, then the architect has a head start on planning and definition.