Abstract
Whether you say business intelligence, data warehousing, analytics or just plain reporting, projects whose main deliverable is providing better, faster, and more insightful information to executive decision makers are unique. They are also the key to unlocking the vast wealth of data created from the implementation of ERP, CRM and other applications and are becoming an increasingly important part of every organization’s IT project portfolio. Yet, many project managers continue to apply the same project management approaches that are used for classic IT projects with frequently disastrous results.
This paper examines the characteristics of information projects, explains how they differ from traditional IT application projects, and outlines their benefits and value proposition. The second half addresses challenges and risks across the process groups and provides readers with tips and recommendations to help ensure a successful project. Finally, this paper presents to project managers the positive aspects of information projects for their ongoing professional growth and for their career.
Overview of Information Projects
“Many organizations believe that if they put their most experienced project manager on a data warehouse project, nothing can go wrong. Yet we find the most experienced project managers struggling … because they treat a data warehouse like a traditional system, which it is not” (Adelman & Moss, 2000, p. 1).
“A staggering 60 percent of Bí projects end in abandonment or failure because of inadequate planning, missed tasks, missed deadlines, poor project management, undelivered business requirements, or poor quality deliverables” (Moss & Atre, 2003, p. 5).
These sobering statistics give pause to any project manager who undertakes to deliver an information project. This paper is designed to provide project managers with the information they need to identify and avoid the risks and to successfully address the challenges of these projects in order to help ensure their project does not end in a similar fashion.
Characteristics of Information Projects
What exactly is an information project? For purposes of this paper, I have chosen the term to describe a series of project types that despite different titles share the following common attributes that differentiate them from application-oriented IT projects:
Exhibit 1 – Differences between Application Projects and Information Projects
Perhaps the most important and distinguishing characteristic of an information project is that its key deliverable is to provide decision makers with the ability to ask and answer strategic questions. A true information project as opposed to operations such as basic reporting from an application module is that it answers questions that can’t be answered from canned reports. Just a few of the types of questions an information project can address are listed below:
- What is a true run-rate trend versus a one-time or seasonal anomaly?
- Where do new customers come from, and how to they contribute to profitability over time?
- Where should we expand based on economic and demographic trends?
In summary, the underlying value proposition of information projects is that they facilitate and decrease the time it takes to turn data into information. That in turn helps decision-makers translate information into knowledge and knowledge into action. Successfully executed, information projects can dramatically improve the effectiveness of knowledge workers as they seek ways to increase revenues, cut costs, improve performance and quality and seek competitive advantage.
Key Terminology
As with any domain, it is important to understand some of the terminology. Next are definitions of some of the most common terms associated with information projects. It should be noted that various experts may offer slightly different definitions for the same thing, depending on whether they approach the topic from a technical or a business perspective. The author has selected the definitions that seem most appropriate for a project manager new to the subject area.
Each of the first four project types below has been used almost interchangeably in the literature. The reader need not concern themselves with the nuances between variant definitions. Each of these project types is an information project, sharing the attributes described above and the challenges to be explored later in this paper.
Business Intelligence—Business Intelligence has the widest variation in definitions. “In fact, the concept of business intelligence is so poorly defined that a manager’s expectations are set based on what that manager is told by the last software tool vendor” (Loshin, 2003, p. 3). One definition that transcends the vendor debate is that business intelligence is “an architecture and a collection of integrated operational as well as decision-support applications and databases that provide the business community easy access to business data” (Moss & Atre, 2003, p. 4).
Data Warehouse—A data warehouse is perhaps the most “classic” implementation of an information project. Data warehouses, particularly those designed on the enterprise level, integrate data from numerous disparate systems in a way that makes it accessible for reporting and analysis by different stakeholder groups. William Inmon, considered by many as the father of data warehousing, defines a data warehouse as “a subject-oriented, nonvolatile, integrated, time variant collection of data in support of management’s decisions” (Inmon, 2011, para. 1).
Data Mart—A data mart is focused on the needs of a single department or subject area. Data marts may be fed from a data warehouse (Inmon, 2002, p. 389) or may exist separately. People often use the terms data mart and data warehouse interchangeably. There are differences, but for the project manager the concepts, challenges and risks are quite similar.
Analytics—Davenport and Harris (2007) defined analytics as “the extensive use of data, statistical and quantitative analysis, explanatory and predictive models, and fact-based management to drive decisions and actions” (p. 7). Analytics projects are often not the first information project for an organization, but some aspect of analytics may be included in any one of the other project types.
Data Governance—Data governance is not an IT project as are the other four above, but it is critical to the success of each. “Data Governance is a system of decision rights and accountabilities for information-related processes, executed according to agreed-upon models which describe who can take what actions with what information, and when, under what circumstances, using what methods” (Thomas, para. 4, n.d.). Data governance is a business function, not an IT function. However, data governance does provide IT with the priorities to be executed and the policies to be complied with as data-oriented capabilities are implemented across the organization. Organizations often invest these decision rights in a Data Governance Committee made up of management representatives across the various functional groups. This group, if established, can be a great help to the project manager in setting priorities among competing requirements, driving cross-functional collaboration and resolving conflicts that may arise during the project.
Components and Process Flow of a Typical Project
Using a data warehouse as an example, following is a brief overview of the primary components of an information project solution:
Exhibit 2 – Components and Process Flow of a Data Warehouse
For simplicity, it can be helpful to consider an information project solution as being comprised of three major frameworks through which raw data flows and is turned into information for knowledge workers and decision-makers.
Data Capture
All information projects start with raw data from source systems. Stakeholder requirements for analysis and reports drives the identification of the raw data needed. The data analyst on the project will locate the appropriate source for each data element, obtain a sense of data quality and create the initial map between the source system and the target database. The developers will then develop the code to extract the data and load it into the target databases using an extract/transform/load (ETL) application and processes.
Data Transformation and Storage
Information projects are about transforming data into information and storing it in a format that allows for it to be rapidly retrieved for reporting and analysis. In addition to the ETL, which is used to move and transform the data as it flows through the solution, database models optimized for retrieval and reporting are required. There are three primary types of storage mechanisms that can be used within an information project, although not all are required.
The data warehouse and data marts have been described under key terminology above, and represent the two most common project types as well as databases within an information project. In addition, the solution may include an Operational Data Store (ODS). An ODS is a database designed for queries on transactional data. It is often an interim or staging area for a data warehouse, but differs in that its contents are updated in the course of business, whereas a data warehouse contains static data. An ODS is designed for performance and numerous queries on small amounts of data such as an account balance. A data warehouse is generally designed for elaborate queries on large amounts of data (“Definition of ODS,” n.d., ¶.1).
Metadata is often defined as “data about data.” A metadata repository captures details about the raw data as it is captured and moves through the solution to end users—where and when it was captured and how it was transformed during each step. Metadata allows for traceability of data from original source to report and is an important component for validation of the solution.
Master Data can be considered the key reference files of an organization (e.g., customer, product, location). Master data objects are those core data used in the different applications across the organization and are those key “things” that matter the most – the things that are logged in our transaction systems, measured and reported in our reporting systems, and analysed in our analytical systems (Loshin, 2009, p. 6).
During an information project, building the tools and processes for data transformation and storage is primarily the focus of the technical team. However, as data is loaded it should be verified by the source system owners and other stakeholders as appropriate.
Data Delivery
Data delivery is the segment of the framework most stakeholders associate with an information project and the most familiar to all users. This is where they receive their reports, dashboards and data extracts. This is where they decide whether the project is a success.
Project Management of an Information Project
What makes an information project so different and challenging for a project manager? First, it’s important to note some of the primary reasons these projects have failed in the past:
- Project outcomes not linked to strategic objectives
- Unrealistic stakeholder expectations
- Incomplete requirements
- Weak or non-existent sponsorship
- Failure to manage the change process
- Inadequate staffing
- Project manager who is inexperienced in managing information projects
Looking at the above, a project manager may say that these reasons for project failure are the same as for any other project. The difference with information projects is that there is less opportunity for workarounds and recovery from these common issues than there is for other projects.
Challenges and Tips by Process Group and Knowledge Area
In this section, we will examine some of the unique challenges for information projects by process group. Each of these challenges have been personally experienced by the author many times over fifteen years of managing information projects, and the author provides tips and recommendations that project managers can use when they encounter similar challenges, which they invariably will.
Initiating
Identify stakeholders
Because information projects bring together data from a variety of sources, they invariably have multiple stakeholders and constituencies. For enterprise data warehouses, the key stakeholders are often the top executives and managers across the major functional groups. However, even projects with a more bounded focus, such as a finance or customer data mart, often require cross-functional collaboration.
One unique aspect of information projects is that the stakeholders are not all immediately obvious, even to the project sponsor. As the capabilities of the solution evolve, new data sources held by other departments may be required or potential new beneficiaries may surface, bringing their own requirements that may not have been factored into the initial scope.
The project manager can play an important role in helping sponsors identify stakeholders at project initiation. Knowing that sponsors often fail to identify all who may be involved or benefit from their information project solution, the PM should dedicate additional time to this activity. One approach is to facilitate a session with the sponsor and known stakeholders specifically for this purpose. Another is to embrace the formation of a Data Governance council, which is chartered with, among other things, the prioritization of new requirements that arise after the original project scope is defined.
Planning
Collect requirements and define scope
Defining project scope in order to estimate resources, duration and to develop the schedule depends to a great extent on complete and accurate requirements. However, with information projects, this can be extremely difficult. It is not uncommon for such projects to be the first time the stakeholders will have timely access to data joined together from multiple sources and the first opportunity to use sophisticated reporting and analysis tools. It can be difficult for them to articulate needs for what to them is new and unknown. As a manager of one stakeholder group once told me, “If all I’ve ever known is a horse and buggy, how can I tell you what I want in a sports car?” It is inevitable that some requirements will be missed, and that additional requirements will surface as the project progresses and the stakeholders learn more about the benefits available to them from the completed solution.
There are a number of ways to mitigate the risks that arise from inadequate requirements by addressing it in the project plan and schedule. Build additional stakeholder education activities into the early phase of the project, rather than leave user training to the end. Provide demonstrations of the end user software. Introduce the stakeholders to the benefits of the solution via prototypes using the reporting/analytical tools and examples relevant to the organization and industry. Ensure your resource plan includes adequate time for a subject matter expert to participate in the requirements gathering and guide the stakeholders by using their knowledge of the industry.
Finally, ensure your plan allows for some amount of additional scope, typically in the form of additional reports, to be added midway through the project. Once users see what’s possible, they will ask for more.
Estimate activity resource needs and durations and develop schedule
Knowing the requirements are likely incomplete is only one impediment to accurately estimating resources needs and duration. Data is at the heart of any information project and “is the raw material from which information is derived” (English, 1999, p. 19). Yet until the project starts there is no way of knowing its quality. According to Adelman and Moss (2000), quality data is correct, accurate, consistent, complete, integrated and follows the business rules defined for it (p. 261-263).
Between 50% and 80% of any information project time is spent readying data for use by stakeholders, most often it the form of ETL work (Mrazak, 2003, para. 5). Therefore, if the time required to understand, “clean” and otherwise prepare the data is estimated incorrectly, it will have a significant impact on the overall project schedule and budget. According to Gartner (2005), “through 2007, more than 50 percent of data warehouse projects will have limited acceptance, or will be outright failures, as a result of a lack of attention to data quality issues” (para. 1).
Every information project WBS will include work packages relating to Source System and Data Quality Analysis. As a project manager, you should avoid any temptation and pressure to reduce time in this area. Without knowledge of the quality of your raw material (data), any estimates for data capture and transformation will be guesses at best.
Another way to mitigate risk related to “dirty data” is to factor in some management reserve for this area. In addition, the Data Governance council, if one has been established, can play an important role by establishing the criteria for data quality in order to be included in the solution. This provides the groups providing data with the opportunity and the directive to ensure quality data is available in time to meet key project milestones.
Finally, include assumptions in the estimates relating to the data quality and anticipated preparation time based on this assumption. Ideally, insert a checkpoint in the plan following the activities relating to source system analysis and data quality profiling. If the assumptions prove to be wrong, a replanning effort may be necessary.
Executing
Acquire, develop, and manage project team
Specialized skills are required for information projects, but that in itself is not unique to technology projects in general. A representative project team for a data warehouse or data mart project would include, among others, such specialized skills as:
- Business analyst/subject matter expert (SME) with knowledge of industry and an understanding its data and relationships to gather stakeholder requirements and verify the logic of reports and other output
- Data analyst to decompose the requirements into data needs; locate the source system and assess the quality and availability of each required data element for each data element
- Data architect/data modeler to design the overall solution and create the data models
- ETL Developer to write the processes to capture, transform and move data through the system
- Report developer to create reports and analysis
- Project manager with experience in information projects.
What makes staffing an information project challenging is that some level of industry knowledge is required of even the most technical positions. Using healthcare as an example, a data analyst must have some knowledge of the primary applications in a hospital in order to identify and analyse source systems and an understanding of the myriad coding structures to translate reporting requirements into data elements to be captured and loaded into the database for reporting. The data modelers, ETL and report developers need to understand enough about healthcare and its data to avoid critical mistakes in design logic. The same holds true for any other industry.
Individuals with the right combination of technical and industry expertise can be difficult to find, requiring the project manager to start the staffing process early. Lack of industry experience is often the biggest issue, the risks from which can be mitigated by adding additional SME time to check development progress and serve as a resource to the technical team. Technical skills are transferable from application-oriented projects. The project manager needs to be aware, however, that is not always an easy transition for all. Information projects don’t build things like input screens and modules. Instead they use specialized tools, and some coding, to capture and transform data. Some technical resource personnel simply don’t care for this and the project manager should watch for signs of boredom or disinterest that may impact team morale or the project deliverables and timeline.
Manage stakeholder expectations
With information projects, particularly those that are attached to or come on the heels of application projects such as an ERP or CRM application implementation, stakeholder expectations often exceed the ability of the project to deliver. Consider an organization that has just invested millions in an implementation of SAP only to find that they now need a data mart or warehouse to fully leverage all the data being collected. All the unmet goals from the original project, in addition to the new ones, get transferred to the information project. The wide variety of stakeholders frequently results in competing requirements. And finally, since information solutions are built on an iterative basis, for many stakeholders there should always be time to add more.
The project manager should ensure the plan allows time for validation of requirements early and often. Play back needs in draft report form and iterate. Use demonstrations and prototypes to show exactly what the solution will and will not deliver. Periodically reiterate the goals and objectives of the project—not just progress.
As the benefits become apparent over the course of the project, stakeholders will invariably want to add additional scope and new stakeholders will surface with requirements of their own. As addressed under Planning above, this is to be anticipated and some allowance should have been included in the project schedule to accommodate some additional scope as the needs emerge.
However, not all needs can be met within the charter and scope of the project. Here there is actually an advantage of being the project manager of an information solution such as a data warehouse or data mart as opposed to an application.
Information solutions are not one-time implementations. They are designed to be expanded upon over time. One way to manage stakeholder expectations and increase the probability of acceptance of and satisfaction with the original scope is to establish a formal “futures log.” Stakeholders will know their needs have been documented and will not be forgotten. If the organization has an established data governance council, these needs will be prioritized using the approved criteria, further adding to stakeholders’ comfort that their requirements will be given evaluation during the next phase.
Monitoring & Controlling
Monitor and manage risks
A critical component of a project manager’s role in managing expectations is to proactively identify and address issues and risks before they become problems for the project. One of the biggest risks that every project manager of an information project will face is resistance from stakeholders that may occur as the project progresses.
Control over data and information equals power, and when data is available in a centrally managed resource instead of controlled by individuals or departments, a power shift occurs. For groups that own the source systems that will be feeding the data warehouse or mart, there may be a concern that underlying data errors and process deficiencies that have been handled within the group will now be exposed.
Information projects often have development and implementation of common metrics as one of their objectives. Common metrics are designed to drive behavioral change and performance toward enterprise goals. However, they may also play a role in an individual’s compensation. Common metrics force a transparency that is not necessarily welcomed by all stakeholders. The project manager needs to proactively try to identify who may be impacted adversely and work with the project sponsor to ensure fairness and ensure any resistance to the project is managed effectively.
Finally, one of the benefits of a successful information project is that it can dramatically free up knowledge workers’ time and transform their role from one of gathering data to one of sophisticated analysis. The shift from being a “data chaser” who provides reports to an analyst expected to provide insight can be frightening for some. There may be others who simply do not have the capacity to make the change. Some of these individuals, positioned as beneficiaries of the project, will come to view it as a threat to their job. It is the role of the project manager to be aware of this risk not only to the project, but also to organization for which the project is being delivered. The resolution is not always within the ability of the project manager to solve. But by knowing this can happen and working with the sponsor and human resources where appropriate, the project manager can play an important role in the success of the project and provide a beneficial service for the individuals within the organization.
In summary, the manager of an information project should anticipate some level of stakeholder resistance to arise during the course of the project. Strong change management skills such as facilitation and negotiation, as well as honesty, are necessary to gain and retain the trust of stakeholders and ensure a successful implementation.
Closing
Close project or phase
Information projects are unique in that the solution is intended to be expanded upon over time. As a project manager, you should be aware that your project, however large, is likely considered as only one phase within a long term program to grow analytical capabilities within the organization. As a result, as the project or phase nears its end, the list of new requirements will be long. This can make it challenging to gain acceptance of the project by the sponsor to enable project closure.
The best solution to ensure a smooth project close is to have established a clear charter during project initiation and to have managed the challenges, particularly those related to managing stakeholder expectations, using the recommendations outlined in this paper. By knowing what you will be facing as you enter and navigate the project, and applying these techniques in conjunction with your core project management skills, you will be able to close and celebrate a successful project—hopefully one that is rewarding for you and your team.
So Why Would a Project Manager Ever Want to Manage an Information Project?
As discussed throughout this paper, the challenges involved with successfully implementing an information project are many and the risks can be substantial. So why would any project manager want to do such a project?
First, managing an information project is a fabulous way to learn about an organization and industry. In order to provide the information that management needs for decision making, a project manager needs to truly understand the strategic goals of the organization as well as the trends and challenges of the industry in which it operates. This provides the project manager of information projects insight into their organization and industry not always available to managers of other project types.
Because they are (or should be) linked to the highest strategic goals of the organization, information projects provide project managers with exposure to senior management and thought leaders. These projects often have a very direct link to some of the most important personal objectives of executives and other decision makers and these individuals are often more than willing to engage with you at a level not often available to project managers of other IT projects.
Finally, career opportunities in this area are solid. In difficult economic times, investments in information projects are often the last to be cut. There are those who believe that such periods are the best time to invest in these types of projects in order to better manage costs or gain a competitive advantage. While some of the ETL work can be outsourced or sent offshore, the role of the project manager needs to remain close to the sponsors and stakeholders. And while specific technology and software may go out of fashion, the need for information along with the insight and competitive advantage it can bring remains constant.
Managing information projects, while challenging, can be extremely rewarding to the right project manager. Each project provides new opportunities to deepen and/or broaden your knowledge, and enhance the value you bring to your sponsor, stakeholders and to your team. And that can only enhance your overall career as a project manager.
