Thursday, April 10, 2014

Case Studies in IT

Most of my posts are related to IT, knowledge management, or project management. However, today I'm sharing an academic topic but it is still related to IT.

This week I discovered a great resources for my graduate courses. The Journal of Information Technology Teaching Cases is a great online journal providing descriptive case studies. These cases are are perfect for exercises in my classes where students get to see the topics we cover applied to a business setting and are required to develop a response to the presented case.

I'm very excited to use a few of these cases in my next class. I though I would share this resource so others may get a chance to use these cases too.

Monday, April 7, 2014

We are not Ready for Big Data

Organizations are investing in big data. While the benefits can be promising, many organizations are not able to realize these benefits. These organizations are not able to effectively analyze and apply the data to make meaningful changes to yield the improved performance. In other words, these organizations are trying to run before they can walk.

I came across another good article on big data that provided some insight into the challenges organizations face in using data. The key is that before even attempting to adopt big data practices, organizations must first be able to use data. There are plenty of benefits to using existing data. Organizations that are able to successfully apply evidence-based decision making tend to be more profitable and follow a few best practices. These practices include:
  • Use a single and agreed upon data source across the organization
  • Provide ALL decision makers near real-time information to make changes at all levels of the organization
  • Define business rules and use data to continually evaluate and redefine business rules
  • Include coaching as part of the transition to a data-centric decision making approach to help decision makers effectively use data and develop new data-centered habits
This is not to say that big data won't deliver results. Rather, organizations must first become proficient in analyzing and applying data before investing in larger data practices. If the organization cannot make changes based on existing business intelligence tools and data warehouses, they certainly won't be able to extract value from the big data investments.

Organizations must first adopt evidence-based decision making practices before investing further in decision making systems like big data initiatives.

Wednesday, April 2, 2014

Scope Exchange Approach to Managing the Project Scope

Over the past few months I presented workshops on project change management. I made note of this workshop here and here. In this workshop I discuss strategies for dealing with change in the project environment. One of the types of change we encounter is change to the project scope. These changes may be significant changes or smaller changes realized through scope creep or feature creep.

Today, I read an article in PMNework discussing the value proposition of our projects. The author pointed out that, as project managers, we must understand how the deliverables within the scope of the project enable the organization to realize value. Similar to what I explain in my workshops, the author argued that the project scope at the end of the project rarely resembles the scope at the beginning of the project; change happens and a new or revised scope is adopted.

While changes to project scope is nothing new, what I found interesting is the author's take on the other side of scope change. We typically view scope change as adding new requirements or deliverables to the project and this change typically results in increased budget and schedule. However, we also need to look at the value of the previous scope to see if any of the previous scope no longer offers value to the organization. We shouldn't always simply add to the project scope but, perhaps look to exchange project scope so that we can maintain our baseline budget and schedule.

If we truly understand the value offered by our project we can better help our stakeholders evaluate new scope as it is introduced as well as the existing scope. Using the scope exchange approach we can better assess the project to remove or replace scope rather than always adding to the scope. We are still able to offer flexibility to our stakeholders by accommodating change but we better absorb this change if we look at opportunities to reduce or remove scope in other areas of the project.

Monday, March 31, 2014

Outsourcing Data Analytics - Proceed with Caution

I read a recent article describing how organizations are beginning to outsource some of their data analytics functions. Given the tight market for data specialists, outsourcing this function may seem like a good idea. While there are certainly benefits to outsourcing data analytics, organizations must be care and determine when outsourcing is advantageous and when analytics should remain in-house.

Outsourcing part or all of a data analytics process can make sense. For instance, organizations may wish to outsource part of the data analytics process in order to gain access to large sets of external data that may be combined with their own data. Or, an organization may choose to outsource an entire data analytics process to support routine operational processes like fraud detection, customer purchase predictions, etc. These data analytics practices are more common and, while very advantageous, do not really offer much differentiation since most organizations are likely to have a similar practice. Also, outsourcing may make sense when these functions can be easily segmented from internal process, moved outside of the organization, and integrated with the rest of the business processes.

Where I have issue over outsourcing data analystics is when either unique and strategic business data and knowledge is required in the analysis or anytime organization-specific knowledge is needed to design, conduct, and interpret the data analysis. First of all, organizations risk losing competitive advantage if they move strategic data or knowledge outside of the organization. The outsourcing agency may be able to learn from these proprietary methods or data and apply it to your competitors analytics practices. Even with confidentiality agreements, some knowledge may leak and find its way to your competitors. It is best to keep these more strategic analysis practices in-house.

Secondly, data analytics requires knowledge of the organization's business processes, business rules, data dictionary, and other insights. This knowledge is often specific to the organization and gained through experience and applied through contextualization. Outsourcing agencies will not be able to apply the same level of wisdom available through in-house analysis by experienced analysts.

Organizations should consider outsourcing as a means to gain greater access to data and expertise while carefully determining when it is more appropriate to keep the data analytics processes in-house.

Wednesday, March 26, 2014

Project Change Management Workshop

Yesterday I presented a project management workshop at our Brainerd campus on the topic of Project Change Management. This is the same workshop I presented earlier this year at our St. Cloud campus.

When we discuss this topic at the workshops it is clear organizations are encountering issues with project change and are challenged in renegotiating the project variables (scope, budget, and schedule). One of the goals of this workshop is to help the participants develop a small-scale change management practice to facilitate the renegotiation of the project variables as change occurs.

The project change management process we cover may not address all change issues but it is a start in improving the flexibility of the project team to address change while still meeting the scope, schedule and budget expectations. We can use this change management process as a means to monitor for change and make adjustments to accommodate change.

Monday, March 24, 2014

Small-Scale Project Management Practice

Last Friday a colleague and I presented at the 2014 Minnesota Social Services Association conference in Minneapolis. In this presentation I introduced a small-scale project management practice for the audience to adopt in their own work. The purpose of this small-scale practice is to encourage people to begin using project management to help make them more effective in their work without having to incur a lot of overhead managing their project documentation.

Here is a copy of our presentation...

Wednesday, February 19, 2014

Enterprise Resource Planning's Role in Intellectual Captial

While teaching an intellectual capital management course I noticed some confusion are having over the role of enterprise resource planning (ERP) systems in intellectual capital. Some students are incorrectly categorizing ERP systems as a type of intellectual capital system; more specifically, a type of business intelligence (BI) system. In this post I will explain the relationship of ERP systems to intellectual capital systems in terms of the organization's processes as intellectual capital and as a type of BI system.

First, the role of ERP systems as an intellectual capital system for managing the organization's processes. One form of an organization's intellectual capital assets is its processes. The knowledge of these processes can be a strategic asset for the organization. ERP systems are used to standardize processes across the organization and this is where some confusion may exist. While ERP systems facilitate process standardization, these systems require adoption of more generic processes rather than unique processes organizations use to gain strategic advantage. The ERP systems are not used to develop innovative processes but rather the adoption of common processes and therefore are not contributing to the strategic process intellectual capital of the organization.

Secondly, the role of ERP systems as a type of BI system for supporting the development of new knowledge within the organization. ERP systems are transaction processing systems (TPS) used to conduct operational business in the organization. These systems yield large quantities of transactional data and this data can be used as an input source to enterprise data warehouses. However, the ERP systems themselves are not classified as a BI system since their primary role is transactional rather than informational. Additional tools can be used to make use of the transactional data but ERP systems are considered transactional systems with the potential of supporting BI practices.

It is clear that ERP systems contribute to developing an organization's intellectual capital but these systems are not intellectual capital systems by themselves. Organizational knowledge is very much associated with the development and implementation of these systems but, once in production, these systems primarily serve as transactional systems.

Wednesday, February 12, 2014

Differences between Business Intelligence and Knowledge Management

I'm teaching a course where we discuss different forms of managing and applying an organization's intellectual capital. Over the past two weeks I noticed the students experiencing some confusion over the difference between knowledge management (KM) systems and business intelligence (BI) systems. Although I have previously posted my mind mind map depicting an ontology for intellectual capital, it is not sufficiently clear how we differentiate between KM and BI. The two concepts are a part of the intellectual capital ontology and related but are also different.

While both KM and BI are used to support decision making they differ in the type of raw materials used, the processes to develop knowledge, and the type of knowledge developed. I like the models Sabherwal and Becerra-Fernandez presented to illustrate each of these. The diagram below is my adaptation of these models.

Viewing these diagrams we can see that both KM and BI use data to develop knowledge and this knowledge is applied to decision making. However, BI systems primarily use data to generate information which can be applied to generate knowledge and this knowledge is primarily developed as explicit knowledge. KM on the other hand, uses both data and information to develop knowledge and this knowledge is further developed to create new knowledge. The knowledge developed in KM applications consists of both tacit and explicit knowledge.

It can also be argued that BI is a component of KM. Looking at the knowledge management lifecycle of knowledge capture/creation, sharing, and application, we can consider BI applications used primarily in knowledge capture/creation activities. This means that we apply BI applications to capture or create information leading to knowledge but the knowledge sharing and application is outside of the scope of these systems. Whereas a KM system addresses the entire knowledge management lifecycle.

So, while both KM and BI systems are used to capture or create knowledge, KM systems address the entire lifecycle and result in tacit and explicit knowledge while BI systems are primarily used for knowledge capture and result in explicit knowledge.

This is my method of differentiating between the two concepts. Others may disagree or have alternative methods of defining these two concepts. I welcome your insight in the comments.

Friday, February 7, 2014

Too Much Data or the Wrong Type of Data?

Last November I wrote a post to my blog about a new perspective on IT. In this post I discussed my reaction to an article explaining that IT needs to pay more attention to the value of the data rather than only delivering the information system. Today, I came across an article that embodies this problem.

The article discussed the issue of data overload at a call center. Apparently, this call center collected a large amount of historical data and provided a complete portfolio of reports to their staff and the staff was overwhelmed by the volume of data available. The data and reports primary supported analysis of call center efficiency and did not provide information about customer interactions. The call center collects a large amount of data but is not using a majority of this data and does not collect data on the type of information that is currently needed to make decisions.

Now, back to my point about the need to focus on data. In this call center case, the call center data, applications, and reports provided a robust amount of information for the staff but these reports did not support the current need of understanding customer interactions. Rather than building systems and reports based on a large bucket of easily collected data, organizations need to determine where decisions are made and the type of information needed for these decisions. This will help the organizations identify the data needed to support decisions and allow them to build or purchase information systems to deliver this valued information.

By focusing on the end needs of business intelligence applications, these systems can be constructed so that the correct information is available for timely decisions. This is the value the end users and knowledge workers are looking for from the business intelligence applications.

Wednesday, February 5, 2014

Better Definition of Business Value

In my classes and my project management workshops I try to urge people to look beyond the variables (scope, budget, schedule) of project management. In the project management field we typically assign success to projects that complete the specified deliverables (scope) on time (schedule) within the allocated resources (budget). My argument to this mindset is that this is only the operational perspective of project management and we are missing the bigger picture.

Project managers need to look outside of the project variables to consider value. As project managers we need to associate the success of the project with the value the deliverables offer the organization. In this discussion of value we typically look at the long-term financial benefits provided as a result of the project. However, after reading a recent blog post I see that even the concept of value I had been using is shortsighted.

Certainly value can, and should, be associated with the long-term financial gains resulting from a project. However, value can also be realized by our relationships with our stakeholders through our availability to meet with them, our willingness to listen and respond to their needs, and our ability to understand their function within the organization and how the project can enhance this function.

Project managers must reach way beyond the operational perspective of project management and truly partner with stakeholders to deliver organizational value as well as stakeholder value. Think about your projects and your stakeholders; how are you offering value to them and how are you making sure they are realizing the value you wish to add?