Importance of Emotional Intelligence for IT Leaders

I started reading an IT leadership book this week.  This book uses a fictitious case study to highlight many issues that arise for IT leaders.  What I like about this book is that it does not focus on the technical issues but rather the strategic planning, execution, and relationship missteps that frequently occur in the IT department.  IT professionals are very good at identifying and dealing with technical issues but may mishandle the people issues along the way.  The people-side of leadership is important and one that cannot be stressed enough.

Today I came across an article in the PM Network magazine (see reference below) about the importance of emotional intelligence (EI).  EI is an individual's ability to recognize and respond to emotions; personal emotions or the emotions of others.  This EI characteristic is needed to effectively manage personal interactions.  In IT we often collaborate with professionals from across the organization and need to have good relationships in order to accomplish our goals.  In order to be effective in these relationships, among other skills, we need to exhibit a high degree of EI.

The article's author noted three key personal EI attributes to look for when hiring potential project managers.  These attributes are:

• Self-restraint: the ability to control one's own negative feelings in a calm and sensible manner
• Empathy: the ability to sense other's emotions and reactions
• Communication Skills: the ability to build and foster personal and professional relationships

Although the article was written specifically for project managers it applies to anyone in leadership roles or individuals working in a team environment.  This emotional sensitivity is particularly beneficial for IT leaders since we often work in change initiatives where negative emotions are frequently experienced.

Reference:

Alkhatib, S. (2013). Intangible assets. PM Network, 27(11), 24.

Managing Client Expectations

Later today in my MBA course I'm giving a lecture on project management.  As part of this lecture we will cover the topic of project change management.  In preparing for this lecture I came across an expectations management tool published in a systems analysis textbook I used in a different course.

This tool, the expectations management matrix, is used to understand the client's expectations for a project.  As changes are introduced in a project, the project manager must know how to adjust the project to accommodate the changes.  Using this tool, the project manager can determine which of the project variables (scope, budget, schedule) is more flexible than the other variables.  Below is a example of this matrix:

The project manager shares this matrix with the client to determine which of the three project variables must be minimized or maximized, which variable the project team must try to maintain, and which variable can be adjusted.  For example, a new student union on our campus must fit within the anticipated budget for the college (a check mark in the cost and Min/Max cell), the schedule for when the new building will be ready should try to be maintained (a check mark in the schedule and constrain cell), and the scope (features) of the building can be negotiated in order to meet the budget and schedule (a check in the scope and accept cell).  As a result, any new changes to the cost or schedule will influence the scope of the new building.

Using this tool with the client can help the project manager know which variables can be adjusted when the client asks for changes to the project.  However, we need to keep in mind the premise for this tool is that any change to one of the project variables influences the other two project variables.

Although this tool may not be required to make this expectations determination with the client, this framework is beneficial for the project manager.  The framework can guide the project manager when preparing to carry out the expectations management conversation with the client.  As part of this conversation the client must also be made aware of the influence of changes to any one of these variables.  Having this expectations conversation early on in the project makes the change request process much easier for all stakeholders.

New Perspective on IT Projects

I just finished reading a great article from the Harvard Business Review.  The authors of this article make a convincing case that, while IT projects are mostly successful in implementing information systems, these projects often fail in delivering value from the data.  The value of these projects is typically derived from the improved processes rather than the data generated from the new system.  Our IT projects implement information systems that are great at capturing data but the extraction and learning from this data is not a major consideration for our projects.

We must continue to invest and deliver IT projects but we need additional projects that focus on identifying the data and information needed to increase the business value from the new data generated from the information systems.  This data must must be easily accessible, support the types of information needed to make decisions, and help the managers and knowledge workers in the organization prepare to interact with the data.

Rather than simply focusing on implementing the information systems our projects should first look at what data is needed and how the resulting information can be applied to solve business problems.

RFP Red Flags and Opportunities

During class the other night I discussed the process for preparing and evaluating requests for proposals (RFP).  These RFPs are sent to potential vendor partners asking them to respond to a business need by proposing a solution they can provide to the firm.  During our class we also discussed a formal and semi-quantitative method we can use to evaluate these proposals.

In preparing for this lecture I came across an article describing several red flags when reviewing and evaluating the vendor proposals.  These red flags highlighted some important considerations for evaluating vendors and their proposals and most of them signal issues that must be addressed before accepting a proposal.  However, not all of these red flags indicate a proposal that should be rejected.

One of the red flags mentioned in the article cautioned against proposals where the vendor seeks to create a partnership with the organization to share in the profits or revenue resulting from the service provided.  While this proposal should raise awareness that more thought and planning is required if this proposal is accepted, we should not disregard these types of vendor proposals.

There is benefit to these partnership proposals.  When dealing with vendors I prefer to use the term vendor partner and this term needs to be applied as we evaluate the proposals.  We need to look at these proposals through the lens of potential partners for the firm and evaluate our perception of the vendor's ability to add value to the relationship and satisfy the scope of the proposal.  In this RFP we are not looking to simply purchase something but rather looking to establish a productive partnership.

Although partnership gainsharing models are more complex, these forms of partnerships may provide the incentive for both the vendor and the firm to take advantage of and build on each other's expertise.  The resulting outcome may produce a new innovative product, process, or service difficult replicate by other competitors and will result in a competitive advantage for the firm and increased profit margin for the vendor partner.

New Outsourcing Pricing Models

In the traditional outsourcing agreement between a firm and vendor partner, the vendor is paid based on either a fix pricing model or a time and materials model.  In the fixed pricing contract, the firm pays the vendor a predefined amount for a defined service.  This amount is set regardless of the costs incurred by the vendor.  In this model, the vendor assumes some level of risk if unknown variables exist that may increase the costs associated with providing the service.  On the other hand, the time and materials removes some risk from the vendor by basing the contract on the amount of time required to fulfill the service request as well as the cost of the materials required for fulfillment.  Each of these models are quite common and each has benefits and challenges.

Overby wrote an article describing four new models for outsourcing contracts.  These are newer models emerging designed to create new opportunities for the firm to gain greater value from the vendor partner and allow the vendor to find ways to increase its profit margin.  These four new approaches seek to capitalize on the partnership between the firm and the vendor to extract value for each party.

Gain-Sharing - In this model the vendor partner is paid based on the performance of the firm.  The vendor is compensated more as the firm realizes greater performance.  For example, a college may engage a marketing consulting partner and this vendor is paid based on any increases to the number of students enrolled during the year.

Incentive-Based Pricing - Although this model is not new, it may be increasing in use as firms try to find more ways to increase value delivered from vendor partners.  In this model, the vendor earns additional incentive compensation as they reach service target goals.  For instance, a firm may outsource telephone support with incentive pricing for hold time.  If the vendor partner is able to bring the hold time below a threshold (like one minute) the partner receives compensation beyond the base fixed or time and materials budget.

Consumption-Based Pricing - This is the pay for what you use model and very similar to your electric bill.  Using this model, the firm pays the vendor partner based on the quantity of service units provided during a period of time.  For instance, a firm may outsource payroll processing and pay the vendor partner a fixed amount for each paycheck processed.

Shared Risk-Reward - This is a true partnership model where both the firm and the vendor develop a new product or service and each benefits from the new offering.  For instance, an automobile manufacturer could partner with a supplier to jointly develop a new technology for car batteries and each would share in the profit for sales of the battery or automobile.

I am currently consulting for a local Catholic diocese to negotiate a shared risk-reward outsourcing model with on of its vendors.  This new form of agreement has the potential to create fantastic value for both the diocese as well as the vendor.  This model requires some creative thinking, trust between the partners, a long-term strategy, and a willingness to try a new approach.

It is exciting to see these new outsourcing models.  These have a potential to foster great collaboration between these partners, increase the performance for each, and provide new innovations by building upon the strengths of each partner.

Explaining Cloud Computing

In my class next week I plan to discuss cloud computing options.  Cloud computing is not new but unfortunately, the terminology associated with cloud computing has not yet been consistently applied.  In previous years I noticed the students struggling to understand the different cloud computing options based on the inconsistent terminology used in publications.

The textbook we use in this class defines cloud computing as a type of Internet-delivered service, application, and capacity infrastructure provided by third-party providers (Pearlson & Saunders, 2013).  This description gives our students a good general description and the authors go into greater detail in the chapter but the students are not exposed to an overall view of cloud computing.

As I noted in a earlier post, I'm pretty excited about using ontology diagrams as a form of knowledge visualization.  So I thought I would use this approach to help my students.  In order to help better explain cloud computing to my students I'm going to use a diagram to depict the forms of cloud computing (converting tacit knowledge into explicit knowledge for the creation of tacit knowledge).

Below is a brief mind map I created to explain cloud computing.

I hope to use this mind map in class to help the students categorize the forms of cloud computing and work with them do provide examples of each of these types of cloud computing.  With this better understanding we will be able to discuss the benefits and challenges of this infrastructure option.

New Diagramming Tool - LucidChart

Tonight in my MBA course I'm planning to discuss business processes and their role in information systems design.  During our class we will learn how to develop and read process flow diagrams to map business processes and their interactions with information systems.

In order to practice process flow diagrams our students need to have access to a software tool that supports process flows.  I typically use Microsoft Visio for my process flows but I can't be certain all of the students will have access to this software.  I needed to find equivalent software for the students to use.

This past weekend I found an online software service that offers functionality similar to Visio.  The software is LucidChart (https://www.lucidchart.com/).  While the software may not cover exactly all of the same functions as Visio, it comes pretty close.  I found the software very easy to use and I'm hopefully they will too.

New Use for Ontologies

Today I presented at the 2013 Taxonomy Boot Camp in Washington DC.  My presentation, Ontology Diagrams for Successful Knowledge Capture and Transfer, covered the use of ontologies as a means to understand and communicate a new topic.  Using an ontology engineering approach I discussed how ontology diagrams are effective in developing knowledge and sharing this knowledge.  In this approach, the ontology is used as a method for learning rather than as an end product.

During the conference I learned a lot about the importance of taxonomies in organizing information in knowledge management applications.  It was a good conference and I now know a lot about the issues of developing and maintaining a formal enterprise-wide taxonomy.  I also realized I do a little taxonomy work when I work on data models.

Ethical Decision Making for Project Managers

Someone recently posted a comment to my last blog post about the top 20 topics in IT.  This person pointed out the importance of ethics as a topic and how ethics related to many of the topics I listed.  This is correct, ethics is an important topic within the IT field as well as most (if not all) other fields.

Today I came across an ethical decision making framework published by the Project Management Institute.  This framework is used to define a process to help project managers make decisions when confronted with dilemma.  The framework is provided to help project managers act in a manner consistent with the Code of Ethics and Professional Conduct.  Although the framework is published in the context of project management, it can also be applied to other professions where ethical decision making is needed.

The PMI framework is very similar to other ethical decision frameworks I have seen in that it encourages decision makers to identify and evaluate potential decisions.  However, there is one step I see missing from this framework.  The decision maker must also reflect back on a decision to evaluate the results of the decision.  This reflection serves as a feedback loop to better improve decision making in the future.  Without the reflective feedback loop we may end up repeating poor decisions.

Top 20 IT Topics

This term I'm teaching an MBA course on information technology.  In this course my students will research and prepare a presentation on an IT-related topic.  Wanting to make sure the students invest their research efforts in meaningful knowledge, I prepared a list of topics that are frequently covered in the IT professional magazines.

Here is my list of the top twenty IT-related topics (in no particular order):

• Enterprise Resource Planning Systems
• Customer Relationship Management Systems
• Cloud Computing
• Bring Your Own Device
• Software as a Service
• Business Intelligence
• Web Services
• Tablet Computers
• Data Analytics
• Chromebook Computers
• Business Process Reengineering
• Knowledge Management Systems
• Big Data
• Electronic Medical Record Systems
• Supply Chain Management Systems
• Crowdsourcing
• Radio Frequency ID
• Hadoop and MapReduce
• Telemedicine
• Internet of Things

My guess is that if you made a list you would have some of these topics on your list too but I bet your list would not look the same as mine.  What topics are missing from my list?  What topics shouldn't be on this list?

India Trip

This week and next I am participating in an international education experience with fourteen of our MBA and Master's in Management students.  During this trip our students are meeting with several multinational firms and some local firms to better understand business in India.  We are learning what it takes to be sucessful in the India market, the support offered by the US government to expand our businesses in India, how US firms are able to offshore some of their bussiness procsses, and how local firms operate.

The students are having a great appreciation for the differences in cultures and businesses and insight into how to better build relationships with international partners and customers.  Some of our students are having the opportunity to actually meet their work colleages who are located in Dehli and Bangalore.  It has been a great experience so far.

I particularly found value in our visit to a business process outsourcing firm (BPO).  The BPO is a form of offshoring and outsourcing where a business processes is moved to a location outside of the country.  In this case the BPO was owned by the parent company and serves as lower cost and process specialization option.  Offshoring and outsourcing are common practices in the IT field so I found it facinating to see an example of how these firms operate and the value they bring to their partner organizations.  After this visit to the BPO I have so many ideas to bring to my Managerial Applications of Technology course later this fall.

{please note this post was made from my iPad so spelling was not verified; my apologies for any spelling errors}

New Certificates in Project Management

Earlier this week I received approval to begin offering new certificate programs in project management!  This is very exciting since it provides us with the opportunity to offer our project management curriculum to professionals looking for continued education in project management but may not be interested in a full master's degree.

We will now have a Master Certificate in Project Management and a Master Certificate in Advanced Project Management.  Each certificate consists of four courses.  Below are the requirements for each certificate:

Master Certificate in Project Management

• CIS 6101 Leadership Communications
• PRM 6110 Project Management Essentials I
• PRM 6115 Project Management Essentials II
• PRM 6119 Strategic Decision Making

Master Certificate in Advanced Project Management

• CIS 6101 Leadership Communications
• PRM 6225 Procurement and Budget Management
• PRM 6234 Project Risk and Quality Management
• PRM 6242 Emerging Topics in Project Management

Later this fall our website will be updated to reflect these new certificates.  Very exciting!!!

Mind Map vs Concept Map

I came across a white paper written by a software vendor explaining the differences between a mind map and a concept map.  The white paper provides a good delineation between these two terms and provides examples of when to use each type of model.

Using a knowledge management perspective, the difference between a mind map and a concept map is very important.  A mind map is used to diagram concepts within a domain and typically involve identifying connections between the main topic and contributing ideas to the main topic.  For example, I could develop a mind map where I diagram the components of an automobile.  I would begin with the automobile topic then break it down into transmission, breaking, electrical, etc components.  Each of these components could then be further broken into sub-components and so on.  This more hierarchical modeling illustrates the connections between ideas.  This is a good tool to illustrate information and many students follow this approach when taking notes or preparing for a paper.

The concept map closely resembles the mind map but includes more cross-connectivity between sub-components to create a less hierarchical structure.  Additionally, and this is important, the concept map also describes the relationships between the elements in the model.  Rather than simply drawing the relationships in the mind map, the concept map describes the relationships.  This provides the contextual insight into the model and removes any reliance on individual interpretation of these relationships.  The more complex structure and the explicit definitions of the relationships illustrates knowledge of the domain.

While both models provide benefit, the concept map provides a much more complete description of the topic and unambiguous definitions of the relations between elements in the model.  The mind map is used to convey information while the concept map is used to convey knowledge.

Visualizing Table Joins

I used to teach a data modeling class in our undergraduate Computer Information Systems program.  In this class we developed data models for relational databases and prepared SQL code to interact with our databases.  One of the topics we covered in this class was the different ways to join tables in a SQL query.  The join command is a valuable command and can produce vastly different results if the join is not properly applied.  As a result, it is important to have good understanding of the outcome for each type of join.

Earlier this week one of my former students sent me a link to a great webpage that uses Venn diagrams to illustrate the different forms of table joins.  While textbooks sometimes include some diagrams to make this illustration the books are often incomplete.

Here is a link to the website.  This site not only includes the Venn diagrams but also associates the diagram with the corresponding SQL needed to apply the join and realize the visualized result.

Elements of a Successful Project

I started reading a new project management book by Rechenthin titled Project Intelligence.  In the first chapter of the book the author established several concepts of projects and project management.  One of these concepts is what the the author refers to as The Elements of a Successful Project.  These ten elements may not be a complete listing of important project characteristics but all ten appear to have an influence on the outcome of a project.  I thought this was a valuable list so I thought I would share them with you.

Here is my paraphrased summary of the ten elements a project should have in order to expect a successful outcome:

1. Defined Objectives: The team must be able to understand and clearly communicate the project scope to all stakeholders
2. Work Breakdowns Structure (WBS): A project's scope is broken down into the individual work packages needed to produce the deliverables and each work package has assigned responsibilities
3. Defined Risks: Risks associated with each work package of the WBS is identified and understood
4. Project Plan: Project planning takes place and is scaled to fit the size and complexity of the project
5. Committed and Co-located Team: The team is located together and are committed to the project success or the team may be distributed but communication channels exist that sufficiently support effective collaboration
6. Team Building: An intentional team building process is applied to create a motivated and effective team
7. Communications:  Communications are developed, organized, and planned across all stakeholders
8. Representation: Recipients of the project deliverables have input on the project objectives
9. Applying Past Experience: The team learns from past project experiences and applies these learnings
10. Training: Targeted training opportunities are employed to build the team's experience and knowledge

Reference

Rechenthin, D. (2013). Project intelligence. Newtown Square, PA: Project Management Institute.

Expanding the Reach of Analytics - HR Analytics

There is no doubt that analytics is expanding its reach in the organization.  With hot topics of business intelligence and big data along with the growing demand for data scientists there is certainly a lot going on in this field.

Last week during our school meeting representatives from the college's careers services group shared with us the different ways they can help our students prepare for the job market.  During this conversation one of our faculty asked about hiring trends they noticed.  The career services staff mentioned a growing need for students with knowledge and skills in both human resources and computer information systems.  Due to the heavy reliance on information systems to manage and develop human resources this combined knowledge does make sense.  However, this combination will become even more important in the near future.

After the meeting I did a little research and found many application of information systems in the field of human resources.  In addition to simply applying information systems to HR business there is also a growing trend to apply data analytics to HR.  This trend can be seen by Overby's recent article in CIO Magazine on talent analytics and Waber's book on people analytics.

Considering that human resources are commonly one of the most expensive and valuable resource in the organization, it makes perfect sense to apply data analytics to predict future behaviors and to maximize the value employees can bring to the organization.

Keys to KM Success - Strategy & Integration

In a recent article, Rao (2013) listed and described 15 tips to increase the success of knowledge management initiatives.  After reading these suggestions it is clear that knowledge management efforts cannot exist as a stand alone initiative and require both strategy and integration.

As organizations apply knowledge management (KM) practices there must be a considerable amount of strategy involved in selecting the knowledge that will be collected and disseminated.  The KM practices should target knowledge that is valued by the organization.  In addition to focusing the practices on high-value knowledge, organizations should also integrate KM practices into existing work patterns.  Knowledge associated with key processes and activities should be targeted and the knowledge must be made available to employees as they need it in a form that is easiest to find and apply.

The author also provided recommendations about growing the organization's KM practices.  Organizations should not feel the need to term these initiatives as knowledge management if the term is not meaningful to the employees or welcomed (bad experiences in previous efforts).  Rather, organizations should use application-specific names to provide more meaning and acceptance.  Additionally, and I really like this one, communicating successful KM practices in the organization should not just focus on the more innovative applications but should also showcase more basic practices in order to show how departments can begin to develop KM practices.

All of these recommendations require the organization to develop strategies to identify key knowledge areas, design methods to best optimize the organization's intellectual capital, integrate the knowledge capture and dissemination processes into existing workflows, and communicate successful KM efforts.  A strategic KM plan is needed and the KM processes must be integrated.

Reference

Rao, M. (2013, July/August). 15 tips ensure KM's success. KMWorld, 22(7), 1, 20.

Planning for Project Communications

In my most recent to posts I introduced the importance of communications in global projects and the impact effective communication has on project success.  Today, I'm going to push this point even further by relating this important project management skill to our standard for project management processes; the Project Management Institute's (PMI) Project Management Body of Knowledge.

This year PMI released the fifth edition to A Guide to the Project Management Body of Knowledge (PMBOK).  This latest edition includes a new knowledge area referred to as Project Stakeholder Management.  This new knowledge area supplements the existing knowledge area of Project Communications Management.  In this new edition, two of ten knowledge areas (20%) are closely related to stakeholder communications.  Clearly, project communications is increasingly important to PMI and the project management profession.

According to the PMBOK, as we plan our projects, we integrate the Project Stakeholder Management knowledge area with the Project Communications Management area.  By including both of these knowledge areas we are able to identify and study our project stakeholders, determine the stakeholders' interests and needs in the project, identify the stakeholder communication needs and preferences, prepare and deliver project communications to the stakeholders, and ensure the stakeholders are engaged and satisfied with the project processes and deliverables.

One of the central roles of a project manager is to facilitate communications across all project stakeholders.  As demonstrated in the most recent PMI Pulse of the Profession research, project communications is a key success factor.  Therefore, we must establish and execute a plan to ensure our project stakeholders are engaged and our communications with these groups are clear, consistent, and meaningful to support stakeholder engagement.  This communications plan is so much tied to the project success that we have to consider the communications planning as the same level of importance as our work breakdown structures and task scheduling.

Communications and Project Management

Yesterday I posted a summary of a Project Management Institute (PMI) blog post describing important considerations for managers of global projects.  These considerations addressed global project scope, schedule, and budget issues.  However, these considerations did not include a critically important factor; communications.

Project management is more than guiding the project and managing the project variables (scope, budget, and schedule).  In fact, PMI (as cited by Frehsee,2013) reported that 50% of projects unable to meet business goals fail as a result of ineffective communications.  Communications is so important that organizations with effective communications are able to deliver 80% or more successful projects (on time, within budget, and achieving business goals).

Fortunately, many project managers consider themselves communicators.  An informal PMI (2013) poll of self-identified project management styles revealed that 35% of the management styles identified were "communicative".  This was by far the most commonly reported management style.  So this means that project managers proclaim they are capable of communications.  Unfortunately, as Frehsee indicated, this self-proclaimed attribute is not always exhibited.

In future posts I will look at some of the ways project managers can be more effective communicators.

References
Frehsee, N. (2103). Loud and clear. PM Network, 27(7), 16-17.
Project Management Institute (2013).  Word play. PM Network, 27(8), 7.

Basic Tips for Global Project Managers

A few weeks ago Kevin Korterud submitted a post to the Project Management Institute's Voices on Project Management blog.  In this post he outlined a few basic challenges for global project managers.  These challenges included location-specific project requirements, additional communications and transportation costs, and scheduling issues such as location-specific holidays, government regulatory lags, and weather delays.

Korterud's tips for global requirements, costs, and scheduling are rather basic but perfectly aligned to our project variables (scope, budget, and schedule).  Project managers leading a global project must still adhere to proven methodologies and processes but these processes must be amended to consider the effects the individual locations have on the project's budget, schedule, and scope.

Project and Organizational Change Management

In my previous post I discussed the correlation between effective change management practices and project success.  After reading this post again, I think I need to be more clear regarding the concept of change management.  This clarity is especially important in the project environment.

In the project environment, change management typically refers to the process of handling requests for modifications to the original scope.  We develop processes to manage these change requests to ensure the stakeholders agree on the change, are willing to fund the change, and also permit the additional time required to include the change.  This process is referred to as a change management process.  Making this language even more confusing is when working on an software development project where change management also refers to the process of controlling the introduction of changes to a software product.

The diverse meanings for change management is rather unfortunate.  Project teams often focus on the more operations-based view of change management rather than including the more tactical and strategic view of change management.  In addition to governing the process for requesting scope changes and controlling changes to the software environment, project teams must also consider guiding the stakeholder adoption of the project deliverables.  Project teams, particularly software development teams, must address all three forms of change management.

Since project teams must deal with multiple types of change management, perhaps it is best that we are more clear about the form of the change we are managing.  In my courses I often introduce the terms of software change management, project change management, and organizational change management.  By providing the scope of the change in the term, we offer more clarity to the intended form of change management.

By the way, my previous post referred to the organizational form of change management.

The Importance of Change Management

I came across an article from PMI Today associating project success with change management abilities.  According to PMI, organizations with effective change management practices report 117% higher success rates than organizations with less effective change management practices.  This is a very significant difference.

Why are some organizations better at change management than others?  Certainly there can be cultural differences in the organization that affect their ability and willingness to adopt change.  However, the organizational culture of change resistance only considers the recipients of the change.  What about those groups introducing change into the organization?  We need to take a closer look at project management practices.

Keep in mind that projects are synonymous with change.  Almost each project results in some form of change to the organization.  These changes come in the form of a new or modified, products, services, or processes.  Since projects are so closely related to change, why isn't there more thought put into change in our project management practices?  We can see some change management effort sprinkled in our project planning but, in reality, change is often a secondary or tertiary concern.  We tend to focus on our project variables of budget, scope, and schedule.  We need to pay closer attention to change.

Change, and managing change is critical to successful project management.  Rather than having projects focus on the delivery of the change, our projects must also continue on to ensure the change is adopted and enduring change is realized.  This may require further process changes with our project management practices but with a 117% increase in success rates, a new, change-centric, approach to project management should be justified.

Reference:

Project Management Institute (2013, August). Change management is an essential capability for project managers. PMI Today.

Success Factors for Knowledge Management System Implementations

In my previous posts I outlined the technology, people, and organization challenges facing knowledge management system (KMS) implementations.  With an understanding of the issues affecting our KMS implementations, we need to look at what we can to to address these challenges and increase the success rate for KMS implementations.

First of all, the entire organization must develop a unified definition of knowledge and knowledge management and must also have a common appreciation for the firm's knowledge assets.  This ensures everyone has a consistent view of knowledge and its contributions to the organization.  The tactical and strategic leaders of the organization must also integrate the development and application of the knowledge assets into plans for growth and performance improvement efforts.

In addition to understanding knowledge, organizations must also ensure current workflows are aligned with the development and application of the knowledge assets.  The work processes should be conducive to making contributions to the knowledge repositories as well as learning, building, and applying existing knowledge.

Keeping in mind that much of the knowledge resides within the experiences and expertise of other knowledge workers.  As a result, organizations must identify subject matter experts (SMEs) and find ways to connect these experts to other individuals in need of the knowledge.  These connections can be made through subject-oriented support groups or through technology-driven communities.

The knowledge workforce must be made aware of the individual and organizational value of the knowledge and must be encouraged, and recognized and rewarded (very important), for participation in knowledge sharing and knowledge building activities.  The knowledge value conversation and reward practice will build a culture of knowledge sharing and minimize knowledge hording.

Finally, the KMS implementation project should be carried out in phases to slowly migrate to a complete knowledge management practice.  This will help mitigate the risks of a KMS implementation and will also allow the organization to learn from the previous phases.  In other words, by opting for an iterative implementation path, organizations are able to build and apply knowledge about KMS implementations and improve future KMS implementations (what a good example of practical knowledge management!).

Keep in mind that recent research indicated a 50% success rate for KMS implementations.  We need to consider these factors when implementing a KMS so that we can increase the likelihood that the system will be implemented in a manner that will optimize the intellectual capital of the knowledge workforce.

References

• Bishop, J., Matsumoto, I., Glass, J., & Bouchlaghem, D. (2008). Ensuring the effectiveness of a knowledge management initiative. Journal of Knowledge Management, 12(4), 16.
• du Plessis, M. (2007). Knowledge management: What makes complex implementations successful? Journal of Knowledge Management, 11(2), 91.
• Rathor, N., Thapliyal, M.P, Gupta, V.K., & Gupta, A. (2011). Knowledge management systems & it's failure factors. VSRD International Journal of Computers Science and Information Technology, 1(5), 321-327.

Organizational Challenges for Knowledge Management System Projects

This post is a continuation of the main challenges with knowledge management system (KMS) implementations.  In my previous postings I discussed the technology and people challenges of KMS implementations.  The final category of challenges, organizational challenges, is the most influential in a KMS project.

As noted in the people challenges posting, a knowledge management effort is hampered when the knowledge workers are not willing to share their knowledge.  This knowledge hoarding is due to their perceived personal value of possessing proprietary knowledge and fear that sharing this knowledge lowers their value in the organization.  The knowledge hoarding issue is at the heart of the organizational issues of KMS implementations.

Organizations that lack a culture of trust between the employees and management will struggle in a KMS implementation.  These implementations require collaboration and sharing of knowledge in order to succeed.  Organizational cultures lacking trust, collaboration, and recognition for individual contributions are less likely to be successful in their KMS efforts.

The culture of the organization plays a significant role in determining the outcome of a KMS implementation.

In my next post I will discuss the factors that lead to successful KMS implementations.

References

• Edwards, J., Shaw, D., & Collier, P. (2005). Knowledge management systems: Finding a way with technology. Journal of Knowledge Management, 9(1), 113.
• Riege, A. (2005). Three-dozen knowledge-sharing barriers managers must consider. Journal of Knowledge Management, 9(3), 18.

People Challenges for Knowledge Management System Projects

In my previous post I wrote about the technology challenges for knowledge management system (KMS) projects.  These technology challenges are the most visible of the issues facing KMS implementations.  However, they are not necessarily the most important.  The people challenges are the most important of the three categories of KMS implementation projects.

Before going into the details of people challenges we must first acknowledge the role people play in knowledge management.  We must remember that people are essential in creating knowledge.  Creating new knowledge cannot be automated but rather requires individuals to take existing knowledge and information, frame it within their own experiences and values and the environmental context, and conceptualize or codify the new knowledge.  The process of knowledge creation is a people-driven process.  Therefore, individuals should be the primary consideration for any knowledge management system project.

One of the people challenges of KMS implementations is the knowledge workers perceptions of the KMS.  The knowledge workers may not be aware of the value the KMS has to their own work as well as the value the system provides to the organization.  Additionally, the knowledge workers may not have sufficient time in their work processes to identify knowledge needs and interact with others to disseminate knowledge and learn from each other.

The more significant challenge with people in KMS implementations is the willingness of knowledge workers to participate in the knowledge management initiative.  Knowledge workers who see their value to the organization tied to the proprietary knowledge they possess are less likely to share this knowledge.  These employees perceive shared knowledge reduces their value to the organization and makes their employment less certain.  As a result, some knowledge workers will hoard their knowledge in order to stay valued and employed by the organization.

Knowledge hoarding results in KMS implementations lacking contributions to the knowledge repositories.  With this lack of knowledge contributions, the KMS knowledge repositories are less valuable and fewer knowledge workers will use the system to discover and apply existing knowledge.  The KMS will be unable serve its purpose to build and apply new knowledge for the organization.

People are central to the developing the organization's knowledge so the KMS implementation project must carefully consider the knowledge worker when designing and rolling out the KMS.

Next: Organizational Challenges for Knowledge Management System Projects

References

• Butler, T. (2003). From data to knowledge and back again: Understanding the limitations of KMS. Knowledge and Process Management, 10(3), 144.
• Gupta, K.S. (2008). A comparative analysis of knowledge sharing climate. Knowledge and Process Management, 15, 186-195.
• Marks, P., Polak, P., McCoy, S., & Galletta, D. (2008). Sharing knowledge. Communications of the ACM, 51(2), 60-65.
• Riege, A. (2005). Three-dozen knowledge-sharing barriers managers must consider. Journal of Knowledge Management, 9(3), 18.

Technology Challenges for Knowledge Management System Projects

Yesterday I wrote about the high rate of failure for knowledge management system (KMS) failures and the categorization of these failures into technical, people, and organizational issues.  In today's post I will explain the different technology-related issues affecting KMS projects.

One of the challenges with KMS projects is that these systems are relatively new.  Organizations and the knowledge workers don't have a lot of experience in working with integrated knowledge management systems or even integrating smaller knowledge management systems into their workflow.  As a result of our lack of understanding of these systems and their application to our work, we often have unrealistic expectations of what these systems are capable of doing for us.  As a result, we find the system cannot support all of our needs.

The relative lack of experience with these type of systems also affects the level of acceptance by the knowledge workers.  Due to the higher level of complexity for these systems and inexperience in using these type of systems, knowledge workers are less likely to begin applying these systems to the existing work processes.

In addition to the unfamiliarity of these system, we also struggle with integration challenges.  Application of these systems to the existing individual work processes is also a key challenge with KMS implementations.  Organizations also struggle sharing data between existing systems and the KMS and also integrating the KMS with existing workflows.  With the lack of integration of existing data and workflows, knowledge workers are less likely to use these systems to contribute or discover knowledge in the KMS repositories.

Finally, organizations often fail to plan for the type of knowledge, the quality of knowledge, and the quantity of knowledge managed by the KMS.  The insufficient planning also includes a lack of system architecture (centralized or distributed) and a plan to help knowledge workers interact with others to diffuse knowledge.  Without this planning, the KMS may not contain the type, quality, and volume of knowledge needed by the knowledge workforce and may not provide sufficient access to the knowledge in a manner that is conducive to the work processes.

Next: People Challenges for Knowledge Management System Projects

References

• Edwards, J., Shaw, D., & Collier, P. (2005). Knowledge management systems: Finding a way with technology. Journal of Knowledge Management, 9(1), 113.
• Riege, A. (2005). Three-dozen knowledge-sharing barriers managers must consider. Journal of Knowledge Management, 9(3), 18.

Sources of Knowledge Management Project Failures

Knowledge management system (KMS) projects have historically resulted in high levels of failures. Back in 2003 KMS failure rates were around 80%. Even those that were successful were still limited due to lack of captured knowledge. Over time however, reported KMS project failures have improved to 70% in 2005 and 50% in 2011.  Even with significant improvements to KMS implementations, we are only likely to be successful half of the time.

Given such a poor performance of KMS implementations, it would be wise to determine where we failed in the past to ensure we don't replicate these issues in future implementations.  Fortunately, there has been research done in this area to determine the common sources of KMS implementation failures.  The sources of these failures can be categorized as technology, people, and organization issues.

Over the next few days I will post more details about the issues for each of these three categories of KMS project failures and the steps that can be taken to mitigate these issues.

References

• Akhavan, P., Jafari, M., & Fathian, M. (2005). Exploring failure factors of implementing knowledge management systems in organization. Journal of Knowledge Management Practice, 6. Retrieved from http://www.tlainc.com/jkmp.htm.
• Bishop, J., Matsumoto, I., Glass, J., & Bouchlaghem, D. (2008). Ensuring the effectiveness of a knowledge management initiative. Journal of Knowledge Management, 12(4), 16.
• Butler, T. (2003). From data to knowledge and back again: Understanding the limitations of KMS. Knowledge and Process Management, 10(3), 144.
• Mason, D., & Pauleen, D. (2003). Perceptions of knowledge management: A qualitative analysis. Journal of Knowledge Management, 7(4), 38.
• Rathor, N., Thapliyal, M.P, Gupta, V.K., & Gupta, A. (2011). Knowledge management systems & it's failure factors. VSRD International Journal of Computers Science and Information Technology, 1(5), 321-327.
• Riege, A. (2005). Three-dozen knowledge-sharing barriers managers must consider. Journal of Knowledge Management, 9(3), 18.

Advice for Data Analytics Implementations

A recent article by Mitchell (2013) discussed the top twelve mistakes organizations make when implementing a predictive analyics project.  The mistakes are as follows:

1. Begin without the end in mind
2. Define the project around a foundation that your data cannot support
3. Don't proceed until your data is the best it can be
4. When reviewing data quality, don't bother to take out the garbage
5. Use data from the future to predict the future
6. Don't just proceed, but rush the process because you know your data is perfect
7. Start big, with a high-profile project
8. Ignore the subject matter experts when building your model
9. Just assume that keepers of the data will be fully on board and cooperative
10. If you build it they will come: don't worry about how to serve it up
11. If the results look obvious, throw out the model
12. Don't define clearly and precisely within the business context what the models are supposed to be doing

Reading the article and looking at these twelve mistakes, it is clear the same considerations we give most information system implementations apply to analytics projects too.  We need to have a plan, involve the end users, practice iterative implementations, ensure we are using and applying good data, use risk-mitigating staged or pilot implementations, and evaluate our results.

I still think this is a very good article but we need to keep in mind that this advice is the same type of advice we should heed for all of our system projects.  If we apply the same mature IT implementation practices to our analytics projects, we will have an increased rate of success.  The article provides us with a good reminder of what we should do in all of our projects.

Benefits of Knowledge Management

Preparing for a new class in intellectual capital I have been studying the benefits of knowledge management.  Below is a summary of my findings.

Mature knowledge management practices provide many advantages to the organization.  These advantages include effectiveness, innovation, performance and growth, diversification, agility, and quality.

Effectiveness:

First of all, organizations that establish quality knowledge management practices tend to be able to acquire and respond to new information and knowledge more quickly (Darroch, 2005). This means that these organizations make better use of their knowledge workforce and knowledge assets and are better able to build new knowledge. This also leads to increased innovation.

Innovation:
Organizations with effective knowledge management practices that are able to quickly acquire, build, and respond to new knowledge are more innovative. These organizations can quickly and frequently design and deploy new products and services to respond to changing demand (Darroch, 2005).

Performance & Growth:
The effective and innovative firms possessing solid knowledge management practices realize higher performance. These organizations, through their application of knowledge to deliver innovative products and services, experience higher profits, increased growth, and a greater market share than organizations that are not able to leverage their knowledge assets (Huang, Shih, Huang, & Liu, 2006).

Diversification:
Additional diversification occurs as a result of the organization’s capacity to build expertise in multiple areas. This leads to the ability to expand to into multiple domain areas and is observed through formalization of additional business units. Each business unit represents an area of expertise for the firm. Effective knowledge management practices enable the organization to develop expertise in new domain areas and therefore grow the firm’s expertise into additional business units (Huang, Shih, Huang, & Liu, 2006). 

Agility:
The effective knowledge management practices also results in increased agility. This agility is related to the firm’s ability to quickly acquire and apply new knowledge (Khalifa, Yu, & Shen, 2008). This can come from discovering and applying existing knowledge found in the knowledge repositories. The agility may also be derived from strongly supported collaboration efforts where employees build new knowledge from the knowledge acquired from other specialists in the firm. 

Quality:
The final benefit is improved quality. Using knowledge of current processes, best practices, customer needs, and processes of other departments, the organization is able to implement improvements to the design and delivery processes as well as to create and deliver new products and services that better meet customer needs (Lee, Yang, & Yu, 2001; Stewart & Wadell, 2008). This increase in quality is a direct result of knowledge management practices because the knowledge is leveraged to build innovation into the existing processes and support customization for changing needs. 

While knowledge management supports the needs of the knowledge worker, the results are very apparent and measurable to the organization. These benefits must be identified and measured in order to help the firm justify the costs of knowledge management initiatives as well as the ongoing effort to support and improve the knowledge management practices.

References

• Darroch, J. (2005). Knowledge management, innovation and firm performance. Journal of Knowledge Management, 9(3), 101. 

• Huang, H.W., Shih, H.Y., Huang, H.W., & Liu, C.H. (2006). Can knowledge management crate firm value? Empirical evidence from the United States and Taiwan. The Business Review, 5(1), 178. 
• Khalifa, M., Yu, A., & Shen, K. (2008). Knowledge management system success: A contingency perspective. Journal of Knowledge Management, 12(1), 119. 

• Lee, Yang, & Yu. (2001). The knowledge value of customers and employees in product quality. Journal of Management Development, 20(7/8), 691-704. 

• Stewart, D., & Wadell, D. (2008). Knowledge management: The fundamental component for delivery of quality. Total Quality Management, 19(9), 987-996.

Evaluating the Value of Knowledge Management

Past experiences have proven knowledge management KM systems to be costly, difficult to deploy with meaningful knowledge, and challenging to achieve satisfactory levels of adoption.  Organizations struggle to properly evaluate KM initiatives and may be somewhat hesitant to pursue initiatives when past efforts failed to deliver the desired benefits.

Justifying a KM initiative can be tricky.  We need to have a sound method to determine the effectiveness of a KM solution for the organization.  While a magical ROI algorithm may not exist yet there are other methods to evaluate the benefits of a KM solution.

I recently came across an article that included a quantitative method for evaluating the relative effectiveness of social business and collaboration solutions.  This model uses rated evaluation factors to determine a relative scores for business value and strategic alignment.  This relative rating system is then applied to each functional area in the organization to determine which areas benefit the most from this type of KM solution.

Although this proposed evaluation criteria does not provide any insight into the actual savings or new revenue from the KM solution it does help prioritize KM efforts for organizations that see value in social and collaborative systems.  While this method helps provide some structure in determining a focus for the KM efforts, I'm not satisfied with the premise for using social and collaborative systems.

I can buy into the benefits of collaborative systems but the author of the article did not help me appreciate tangible benefits to the organization.  The author acknowledged the challenges in measuring success and then tried to use the logic that everyone is doing it so you should too.  This competitive disadvantage argument is only valid if it is proven that competitors adopting social/collaborative systems have an appreciative competitive advantage.

The article provides evidence that we need still need to find a way to demonstrate, quantitatively, the benefits of KM solutions.  By doing so, we can better justify the expense and then we can use this new model to determine the priority for our KM efforts.

Project Management Workshops

Over the past several weeks I gave a three-part workshop on project management topics.  These workshops were held at The College of St. Scholastica's Brainerd and St. Cloud campuses.  Below are the three sets of slides from the workshops:

The Value of Project Management

Value of Project Management from Brandon Olson

10 Ways to Increase Your Project's Success

10 Ways to Increase Your Project's Success from Brandon Olson

Maximizing the Impact of Your Projects

Maximizing the Impact of Your Projects from Brandon Olson

Project Failure Source 10 - Insufficient Resources

Note: This posting is the final contribution to the topic posted on June 24th and relates to my project management workshop titled "10 Ways to Increase Your Project's Success". In this post I discuss one of the sources of project failure and how we may mitigate this risk to our projects.

Source 10 - Insufficient Resources
This final source of project failure addresses an issue that every project manager faces; insufficient resources. While we will always complain of the lack of resources given to our project, at some point this shortage does indeed prevent us from meeting our project goals. This shortage may be due to lack of adherence to the initial project estimates and commitments or may due to some organizational changes that result in budget cuts, more urgent need for the project deliverables, or availability of project team members. This may also be caused by lack of commitment from the functional managers in making their staff available for the project, providing individuals without sufficient experience, or providing individuals without the needed skill set.

Effect on Project
Without sufficient resources or improper resources, the project is at risk of failing to deliver the expected scope, completing on time, and staying within the financial budget. Additionally, the project team members experience added pressure to achieve unrealistic goals with the lack of resources.

Actions Taken by the Project Manager
If the lack of resources is going to significantly restrict the project performance, the project manager must engage the stakeholders. The project manager should immediately communicate the issues and the influence the issues have on the project outcomes. Working with the functional managers and project owner to gain sufficient resources or redefine the project scope is where the conversation should begin. If the project manager is not able to negotiate with the functional manager or project owner, the project manager must then escalate the issue to the project champion to seek assistance in resolving the resource issue. The project manage must focus on balancing the change with the project variables. Don't seek to remove the change but rather seek to be provided the opportunity to adjust the remaining project variables to react to the change. We must welcome change and be able to negotiate the project variables to adopt the new changes.

Conclusion
While this list of the 10 sources of project failures is not an exhaustive list, it does represent a common set of project issues and how we can address these issues. We can see communications, balancing the project variables, and proactive planning address many of these issues.

Project Failure Source 9 - Adapting to Change

Note: This posting is a continuation to the topic posted on June 24th and relates to my project management workshop titled "10 Ways to Increase Your Project's Success". In this post I discuss one of the sources of project failure and how we may mitigate this risk to our projects.

Source 9 - Adapting to Change
The project variables (scope, schedule, budget) and the project environment are almost never consistent throughout the project. Almost every project will experience changes in organizational priorities, organizational processes, or changes to the initial project variables. In fact, the one thing we can count on as project managers is change occurring in our projects.

Effect on Project
Changes to the project environment often influence our ability to deliver the project scope and may also impact our ability to continue to hit the target date and stay within the project budget. These changes may make us alter our processes, transition new project team members, or completely redefine the project goals.

Actions Taken by the Project Manager

Project managers need to acknowledge change occurs and must be diligent in recognizing changes that influence the project. As potential changes are recognized, the project manager must be able to respond and develop plans to address the new changes. Keep in mind these changes may be challenges to the project such as budget cuts or requirement changes or these changes may be new opportunities such as scope expansion or new optimizations. The project manager must respond to change and guide the project through the changes by adjusting the project variables to accommodate the change. Also, the project manager must be sure to proactively communicate the influence new changes may have on the project and the new plans the project will apply to respond to the change. All of this can be accomplished through effective risk management techniques and tools.


Next Source: Insufficient Resources

Project Failure Source 8 - People Management

Note: This posting is a continuation to the topic posted on June 24th and relates to my project management workshop titled "10 Ways to Increase Your Project's Success". In this post I discuss one of the sources of project failure and how we may mitigate this risk to our projects.

Source 8 - People Management
Project managers are often promoted within the organization and are commonly former engineers, programmers, or other technical professionals. This progression provides plenty of project experience before becoming a project manager but it creates a dilemma for the new project manager. As a former technical professional, the project manager may have a tendency to revert back to their former experiences and get involved in solving the technical problems that occur in the project. Interests in solving technical problems come at the expense of guiding the project, removing organizational hurdles, and leading the project team.

Effect on Project
If the project manager spends too much time engaged on the technical side of the project the project manager will then neglect the project leadership role and the project suffers. Communications with stakeholders, navigating organizational hurdles, evaluating and reacting to risk and change, and providing guidance to the project members are neglected. As a result, the project spins out of control and fails to deliver the defined scope, meet the target dates, and stay within budget.

Actions Taken by the Project Manager

First of all, the project manager needs to realize the project manager role does not provide sufficient opportunity to be deeply engaged in solving technical issues. Delegation must take place so the project manager may focus on leading the project. Secondly, the organization must be sure to develop new project managers so they may appreciate the role of the project manager and the value project leadership has on the project and the organization. In other words, a new frame of reference needs to be developed for the project manager and adopted by the project manager.


Next Source: Adapting to Change

Project Failure Source 7 - Resource Assumptions

Note: This posting is a continuation to the topic posted on June 24th and relates to my project management workshop titled "10 Ways to Increase Your Project's Success". In this post I discuss one of the sources of project failure and how we may mitigate this risk to our projects.

Source 7 - Resource Assumptions
Believe it or not I have been faced with this issue many times (fortunately, I knew better). This source of project failure is based on the concept articulated by Brooks (1975) of the Mythical Man Month. This is the assumption that adding additional people to the project will directly result in a shorter schedule. For instance, if a project of 10 team members is scheduled to take 6 months to complete, adding another 10 people should reduce the schedule to 3 months. This of course is false. In fact, sometimes adding project members may actually result in longer schedules.

Effect on Project
If a project team is under the assumption that adding additional team members directly results in an equal decrease in schedule, the project will inevitably not meet the target schedule. The additional team members may reduce the project schedule but not to the same extent as anticipated. The new project members may require further training, project orientation, and the work may not be able to be divided sufficiently to take advantage of the additional team members.

Actions Taken by the Project Manager

Anytime the project manager is faced with a situation where a schedule reduction is proposed with the solution of adding additional resources, the project manager must assume this is not an equivalent relationship. A careful analysis of the project plan must be made to determine the actual impact adding additional resources will have on the schedule. We cannot assume this is a 1:1 ratio.


Next Source: People Management

Project Failure Source 6 - Optimism

Note: This posting is a continuation to the topic posted on June 24th and relates to my project management workshop titled "10 Ways to Increase Your Project's Success". In this post I discuss one of the sources of project failure and how we may mitigate this risk to our projects.

Source 6 - Optimism
Optimism is a tricky challenge. In order to make it through each day, project managers need to be optimistic. Projects always seem impossible to complete with the resources and schedule allocated. However, using the project management approach these projects end up getting done. As a result, project managers tend to be more optimistic. However, problems arise when this optimism clouds perceptions of reality. Project managers and the project team need to be sure to acknowledge risk in the project an observe the true impact of the risk on the project without assuming the risk will go away or can simply be absorbed by the project.

Effect on Project
Being blinded by optimism results in a project that will take on too much scope, will end up over budget, and will extend beyond the target completion date. Too much optimism creates a project environment where risk is ignored and results in the project team needing to react to many environmental changes and take on additional work. This additional work then extends the project timelines and consumes more budget. The project team does not have time to plan for the changes and negotiate changes to scope, schedule, and budget and therefore must absorb these changes.

Actions Taken by the Project Manager
Project managers and the project team must be aware of their optimism and take risk seriously. A risk management plan must be in place and risk continually monitored. While maintaining optimism is very important for the project team, the optimism should never influence risk evaluation.

Next Source: Resource Assumptions

Project Failure Source 5 - Estimating Techniques

Note: This posting is a continuation to the topic posted on June 24th and relates to my project management workshop titled "10 Ways to Increase Your Project's Success". In this post I discuss one of the sources of project failure and how we may mitigate this risk to our projects.

Source 5 - Estimating Techniques
Estimating technique errors arise when the project time estimates are based on guesses rather than experience with the activities and techniques used in the project or by actual results from similar projects. Issues arise when these estimates are not based on some prior experience. Additionally, issues arise when individual task estimates include padding to make sure each task includes contingency time and the entire project schedule is then based on these padded task estimates.

Effect on Project
Poor estimating techniques result in a project schedule that is unrealistic. Either optimistic guessing is used and the project does not have sufficient time to execute or padded estimates are used and the project is given too much time to execute. While the latter does not sound like an issue it actually is. If projects include too much, the resource estimates and schedule may be too large for the project to be approved.

Actions Taken by the Project Manager
All project estimates should be based on some type of educated guess. The educated guess uses experience in previous projects extrapolated to the proposed project environment. While this results in a guess, the guess is based on some form of reality and will be much closer to the actual times than simply throwing out an estimate that sounds good. Another very important aspect of estimates is to delegate this activity. Estimates should be formulated by the individuals doing the work. First of all, these estimates are more likely to be based on experience and also, the individuals will be more likely own to these estimates and therefore will work in a manner that ensures the work is completed within the estimates they provided. If the project manager provides the task estimates, they may not be based on experience and the individuals completing the work will not feel as committed to meeting the schedule than if they provided the estimates themselves.

Next Source: Optimism

Project Failure Source 4 - Variable Lock-In

Note: This posting is a continuation to the topic posted on June 24th and relates to my project management workshop titled "10 Ways to Increase Your Project's Success". In this post I discuss one of the sources of project failure and how we may mitigate this risk to our projects.

Source 4 - Variable Lock-In
Variable lock-in is closely related to the previous issue of expectations management but addresses issues that occur early on in the project. When projects are first evaluated and approved these projects are commonly based upon very rough estimates for the scope, budget, and schedule. The project stakeholders do not know enough details to provide a refined estimate early on in the project and must rely on approximations. The project variables (scope, budget, and schedule) may appear on the project charter or statement of work and become visible to all stakeholders. As result of this visibility, these initial variables are often used as the baseline expectations for evaluating the project's success.

Effect on Project
Quite often the initial scope and level of effort required for a project are underestimated during the initial project definition. The initial budget and schedule are based on the scope and level of effort estimated and therefore, if the scope and level of effort are underestimated, the corresponding budget and schedule are also underestimated. This initial lock-in leaves the project team to complete more work without sufficient resources or enough time. While the project may still execute successfully and deliver the project variables, these projects will most likely be deemed as over budget and late.

Actions Taken by the Project Manager
There are two approaches that should be taken to deal with variable lock-in. The first is to have the organization come to an understanding that the variables defined in the statement of work or project charter are simply approximations. These variable approximations allow the organization to compare projects using relative variable values but the organization should not accept these variables as final. The project team should be required to conduct a more detailed analysis to provide more accurate estimates of the scope and level of effort and the corresponding budget and schedule. The second approach should use the same further analysis concept but rather approve the project based on the initial approximations, provide only approval to conduct the detailed analysis to formulate a more accurate scope, budget and schedule. The results of this analysis can then be evaluated for full approval of the project. Either approach considers the first estimates as guesses and require further analysis. The second approach allows the organization a creeping commitment to the project in order to understand the needs before fully funding and approving the project.

Next Source: Estimating Techniques

Note: This posting is a continuation to the topic posted on June 24th and relates to my project management workshop titled "10 Ways to Increase Your Project's Success". In this post I discuss one of the sources of project failure and how we may mitigate this risk to our projects.

Source 3 - Expectations Management
I believe this is the most common source of project failures. Expectations management is the effort where the project team tries to ensure their perceptions of the scope and scale of the project deliverables align with the project owners. In addition to understanding the initial scope this also entails tracking changes to the scope. Expectations management becomes challenging when the requirements are not know, ambiguous, or fluid. We must acknowledge the the scope of any project changes over time through either significant changes or minor changes. The minor changes over time (scope creep) can be difficult to manage and product tweaks implemented by the project team (feature creep) can be both difficult to detect and manage.

Effect on Project
Since the schedule and budget are directly related to the project's scope, any change to the scope most likely has an effect on the schedule and budget. Minor changes in project scope may be absorbed with the existing budget and schedule but as these changes add up (scope creep) the budget and schedule need to be adjusted. Failure to adjust the budget and schedule to accommodate changes to the project scope put the project at risk for being over budget and behind schedule.

Actions Taken by the Project Manager

The most important action a project manager can take is to be aware and track the defined project scope and any changes to the scope. Quite often project teams will use a change order process to formally recognize changes to the project scope in order to calculate the additional time and budget needed to include the change. The changes are then introduced as a proposal and presented to the project owner for review and approval. Using the change order process, changes to the project scope are not actionable until the change order is approved and the new budget and schedule are adopted. A part of making the change order process work is to educate the project owner about the association of scope with schedule and budget and also explain that the change order ensures the project will be more likely to stay on track for the planned budget and schedule. We should expect change and be happy to welcome these requested changes to our project but we must insist that we are able to reevaluate the project budget and schedule so that we may ensure the project can remain successful.

Next Source: Process Shortcuts

Project Failure Source 2 - Process Shortcuts

Note: This posting is a continuation to the topic posted on June 24th and relates to my project management workshop titled "10 Ways to Increase Your Project's Success". In this post I discuss one of the sources of project failure and how we may mitigate this risk to our projects.

Source 2 - Process ShortcutsProcess shortcuts are when the project manager, the project team, or the organization does not adhere to established standards and processes. This may include skipping steps in a project management methodology or software development methodology, partially completing steps, or ignoring the process altogether. These shortcuts typically occur when the level of project effort or time constraints add further pressure on the project team or if the team is unaware or not accountable for following the process or methodology.

Effect on Project
Basically, shortcuts are counter productive. The shortcuts are taken to reduce work and time but often lead to rework. The rework creates additional work for the project team, takes additional time, and may impact the overall quality of the project deliverables.

Actions Taken by the Project Manager
If the shortcuts occur as a result of either a perceived or real concerns over the value of the process steps the project manager should either educate the project team and stakeholders or work with the stakeholders to evaluate the value of the process and make revisions. The project manager, project team, and all stakeholders must appreciate the process to ensure it is followed. However, if it is determined that the processes are adding value but compliance is not observed, the project manager needs to encourage compliance with the team directly or through the support of the functional managers.

Next Source: Process Shortcuts

Project Failure Source 1 - Project Champion

Note: This posting is a continuation to the topic posted on June 24th and relates to my project management workshop titled "10 Ways to Increase Your Project's Success".  In this post I discuss one of the sources of project failure and how we may mitigate this risk to our projects.

Source 1 - Project Champion

The project champion is the strategic or executive-level project stakeholder supporting the project.  The project champion buys into the project benefits and is willing to help the project team clear hurdles, obtain the required resources, and navigate the political environment at higher levels of management.  The issue with the project champion is not with the individual themselves but rather the absence of a project champion.  A project may be left without a project champion if a champion is not assigned early on in the project lifecycle, if the champion leaves the firm, or if the champion loses interest in the project.

Effect on the Project

Without a project champion, the project is at risk for securing or retaining the needed funding, human resources, and other project resources.  The project may not be able to maintain the resources needed and fall behind or may be cancelled altogether.  The absence of a project champion may also result delays due to challenges in obtaining approvals and achieving cooperation from the organizational units and layers of management within the organization.

Actions Taken by the Project Manager

The project manager can proactively ensure a project champion exists by insisting the organization follow a project management methodology where a project champion is assigned before the project is approved.  The early assignment of a project champion is also beneficial to the project evaluation process to ensure organizational support exists for the project and the support is sufficient to ensure the project gains the resources needed to succeed.  Also, the project manager should sell the project to the current champion to ensure the champion stays engaged and supports the project.  The selling of the project to executives also increases support beyond a single champion and allows other champions to emerge in the event the current champion leaves the organization.

Addressing the risk of losing a project champion increases the project's success by securing executive or strategic support to ensure resources are available as they are needed.

Next Source: Process Shortcuts

10 Ways to to Increase Your Project's Success

This week I'm presenting project management workshops at The College of St. Scholastica's Brainerd and St. Clound (MN) campuses.  The workshops are titled "10 Ways to Increase Your Project's Success".  In these workshops I discuss the importance of Risk Management in managing projects and identify the most common sources of project failures.  As part of this workshop we discuss how these sources of project failure affect our projects and then we develop plans to mitigate these failure sources.

There are many websites, articles, and other publications discussing the top sources of project failures but I found the Whitten and Bentley (2007) text best articulates these sources of failure.  Below is my adaptation of the authors' list of sources of project failure:

1. Missing Project Champion
2. Process Shortcuts
3. Expectations Management
4. Variable Lock-In
5. Estimating Techniques
6. Optimism
7. Resource Assumptions
8. People Management
9. Adapting to Change
10. Insufficient Resources

Over the next several posts I will discuss each of these sources and describe how participants at the workshops view the impact of these sources of failure on the project and how we plan to mitigate these issues in future projects.

More to come...

Reference

Whitten, J.L., & Bentley, L.D. (2007). System analysis and design methods (7th ed.). Boston, MA: McGrawHill/Irwin.

The Value of Project Management

This week I traveled to Brainerd and St. Cloud (Minnesota) to give a project management workshop.  This workshop titled "The Value of Project Management" provided an introduction to projects, why projects are important, the purpose of project management, and the project management process.  As part of this workshop I provided a set of project management templates to serve as a rudimentary project management methodology.  I posted the slides for the workshop here and the project templates here.

This was the first of a three part workshop series on project management topics.  June 24th (Brainerd) and 25th (St. Cloud) I plan the same trip to present a workshop titled "10 Ways to Increase Your Project's Success" followed by "Maximizing the Impact of Your Projects" on July 8th (Brainerd) and 9th (St. Cloud).  You can register for these free workshops by clicking the hyperlinks above for the corresponding date and location.

The Good News about IT Project Failures

While reading the April 2013 issue of PM Network magazine today I came across an article summarizing the PMI 2013 Pulse of the Profession report (Gale, 2013).  The author noted an overall decline of 10% for project success rates over the past four years.  This is different than the findings reported by the same author (Gale, 2011) from the 2011 Chaos report which showed an increases in success rates.

The difference between these two findings is that the Chaos report is based on IT projects while the PMI report is based on ALL industries.  The author suggested the Chaos report may have included higher success rates since ERP projects were not attempted during the recession and the PMI decrease in project success rates were due to organizations trying to cut costs and taking shortcuts.

These two trends and corresponding analysis appear to provide evidence that the low success rate of IT projects is due to higher-risk projects than any issues with project management practices.  The relationship with risk and success rates indicated in the Chaos report shows that IT project must have a risk plan in place; risk management is critical in IT projects.

References:

Gale, S. (2013, April). Finding the competitive edge. PM Network, 27(4), 39-43.

Gale, S. (2011, May). Failure rates finally drop. PM Network, 25(5), 10-11.

I'm Back

After almost a half a year I'm moving back to my blog.  Last December I attempted to shift my time from the blog to other forms of social media (LinkedIn, Google+, etc.).  My thought was to move to other forms of media where information could be shared through conversations rather than through a one way message.  This idea still seems appealing but the issue with these other forms of communications is that they support only brief dialog; we can' really offer sufficient analysis on a topic.  For this reason, I'm moving back to my blog.  I hope to provide more in-depth thoughts on topics and welcome a conversation through the comments feature (I will respond to comments).

Postings in this blog will align with my areas of research where I hope to use the blog to think through some of the readings I come across.  My research interests fall within project management, knowledge management, analytics, business intelligence, databases, technology and society, and systems thinking.  My posts will typically fall into these domain areas.