Lessons in IT Alignment

In my MBA class we begin with a discussion of a model called the Strategy Triangle. This model illustrates the formation of an organization's strategy through the convergence of a business strategy, organization strategy, and information strategy. The point of this model is that strategy is not simply developed from the business strategy but rather it must be developed using opportunities and limitations of the organizational strategy (people, structures, and processes) and the information strategy (data, information, and supporting systems).

Today I read a great article describing the turmoil at J.C. Penny's and the toll taken on their information technology projects. Reading this article from an IT leader's perspective and using the lens of the Strategy Triangle model it is easy to see, in hindsight, that this turmoil was bound to happen. I see two main issues: frequent changes in leadership and the inability to collaborate to develop a cohesive strategy.

First of all there were frequent changes. The CEO was replaced by a new CEO who lead the firm for 17 months only to be replaced by the previous CEO on an interim bases until the next CEO can start next August. Wow! That is overwhelming change! In addition to this, and perhaps as a result of these changes, there have been three CIOs and three e-commerce leaders transitioning in and out of the organization. Each of these changes represent new directions in IT projects, cancellation of projects, and restarting projects that were placed on hold. The unfortunate IT department had no clear direction and, as a result, was not able to successfully accomplish their strategic objectives.

Secondly, the CEO that was brought in to make changes was very aggressive but appeared to try to drive through his vision rather than observe and listen to find out how to best fit his plan into the organization. The article provided a great example of this. The CEO wanted to rip-out the check out stations and replace these with employees roaming the store equipped with iPods and iPads. These employees would checkout customers using RFID tags attached to the clothing items. It may have been a sound idea but the CEO failed to understand the organizational strategy of the checkout processes where the roaming staff would not be able to remove the RFID tags since they were not able to carry the tools to remove the tags. The CEO was focused so much on the business strategy that he failed to acknowledge the organizational strategy of the checkout processes.

This case further proves the value of the Strategy Triangle. Organizations must understand the opportunities and limitations of the people, structure, processes, and information when developing a strategy. The alignment of business, organization, and information must take place to not only identify the best strategy but to also ensure the strategy can be realized.

Project Management Presentation

Next week I'm giving a presentation titled "The Value of Project Management" for the Duluth Area Chamber of Commerce. This presentation is open to the public and is aimed at individuals and organizations who wish to become more familiar with project management and want to introduce a project management practice scaled to fit their needs. Here is a brief description of the presentation:

Any industry and every organization experiencing change has a need for projects. Projects are used to drive change and innovation initiatives in an organization. Over the years, practices for leading these projects have evolved into an increasingly mature field of project management. In this workshop the purpose and value of project management is discussed and common project management practices are reviewed. Based on an understanding of modern project management practices a plan to introduce more formalized project management practices is developed.

If you are interested in attending for free you can register at http://duluthmncoc.weblinkconnect.com/cwt/External/WCPages/WCEvents/EventDetail.aspx?EventID=1042

Building and Managing Effective Virtual Teams

In my MBA class tonight I plan to discuss virtual teams and how information and communication technologies enable organizations to create a virtual team of people who work together on a project without working at the same location. Through the use of web conferencing, instant messaging, collaborative office automation tools (ie. Google docs), and the emergence of so many other collaborative tools or collaborative features in our tools we are now able to work as effectively as if we were co-located. Members of our teams can work in any location across the world where an Internet connection is available. We can form collaborative teams and have these teams work effectively as if they were located in the same office space.

However, just because technology has provided us with tools it doesn't mean that we are now instantly granted the ability to effectively work as virtual teams. There are many challenges in correctly applying these tools, building the trust needed to work effectively, and providing leadership for these virtual teams. While these challenges exist in co-located teams, the solution to these challenges are different in the virtual team environment.

I came across two articles (here and here) providing some simple advice for developing and managing effective virtual teams. The main point is that building and managing virtual teams is different than managing traditional teams; especially if these team members originate from different cultures. One example is the formalization of roles and processes. In the virtual team environment, the roles of each team member must clearly defined as well as the processes the team will follow. This formalization is different than the more loosely defined rolls and ad-hoc processes we can use with the traditional team. The virtual team members are not able to intuitively grasp the shifting roles or processes as if they were interacting in-person.

Since the virtual team works with more limited communication among the team members it is important to establish norms for the mode of communication, the expectations for behavior in the communications (no background noise or interruptions, etc.), the frequency and timing of communication, and the ability to have one-on-one contact with team members. Establishing these norms early on the in the team formation allows the team members to know what to expect and to figure out how the team will work together. The ability to have one-on-one interactions and spontaneous interactions will help build trust and understanding among the team members.

The commonality between these two articles is the formalization needed to support virtual teams. We need to formalize the roles of the team members, formalize how decisions are made, and formalize how and when the team interacts with each other. This formalization helps to establish the guidelines for operating as a team. Co-located teams do not require such formalization but they are offered the luxury (or disadvantage; depending how you look at it) of having immediate and frequent interactions with each other.

So, if you plan work work as a virtual team or if you plan to lead a virtual team, be sure to first spend time formalizing the guidelines which the team will operate under. This formalization helps the team become more effective by allowing them to focus on the objectives rather than figuring out how to work together.

The Human Economy?

I just finished reading a Harvard Business Review article where the author argued that, just as we previously moved from an agricultural economy to a industrial economy and from the industrial economy to the knowledge economy, we are now moving to a new type of economy. This new economy is the human economy where our own humanity is what makes workers valued. In this new economy, the ability to apply our analytical skills is no longer valued but rather value is derived from our ability to demonstrate compassion toward the stakeholders and make decisions that may contradict our typical business goals.

Valuing compassion and our ability to be connected to humanity certainly sounds noble but I don't agree that this is now the new economy. Organizations are currently focused on realizing the value of the data they collected for the past two decades (or more) and found value mining this data for valuable insight and improved decision making. We also currently value employees who are able to turn information into knowledge to improve the organization's performance. This value of the employee's knowledge attributes will remain valued. In other words, I argue the knowledge economy is not going anywhere.

Having said this, I must admit that there is some merit to the human economy the author describes. The results from our in-depth analysis of our vast amounts of data may lead to incredible insight into business patterns and give use the ability to predict future patterns. These analytics practices are intended to help us make better decisions. However, we have to acknowledge that we cannot rely solely on the results of our data analysis but rather use this data as input into our decision making. This is where the influence of the human economy may be needed. We sometimes need to make decisions that fly in the face of the data in order to make decisions that may be incorrect through short-term metrics but are the right decisions when looking at the bigger and longer-term picture.

While I appreciate the author's perspective on the importance of humanity in the future economy, I argue against any notion that we are moving out of the knowledge economy. We are simply balancing the insight our data-driven knowledge provides with our compassion and bigger-picture thinking that only humans are able to provide.

Beyond Business Process Reengineering

I'm preparing a lecture for my MBA students on information systems and the support of business processes. The purpose of this lecture is to illustrate how information systems have enabled the organization to move from siloed departmental information systems to integrated systems that support the entire business process across departments. This transformation really took hold in the 1990s and was associated with the act of business process re-engineering (BPR). This BPR effort served as a means to reconceptualize the firm from departments into processes and to recognized the value of having information stored in a single and centralized location.

I conducted a little research to support the material from the book in order to find the next step; to determine what happens when organizations no longer find ways to continue to increase efficiencies through BPR. In search of the next step I came across a Harvard Business Review article describing a potential next step for moving beyond BPR. One potential solution is the service-oriented architecture (SOA) approach. Using this approach, organizations reconceptulize the firm into a set of loosely coupled services that form the business processes. A service is a specific outcome that can be reused across the organization and, if implemented properly, can be reused by any part of the organization rather than replicated.

Rather than having a tightly integrated business process that is unique to the firm, organizations can now create more generic services that can be combined as building blocks to be used and reused as needed across the organization. These individual services can be developed internally or purchased externally. The reusability and the ease of decoupling the services and recombining them as the organizational needs change make this a much more flexible and efficient method compared to the inflexible architecture of the enterprise systems we constructed as a result of the BPR efforts.

I need to look into this further. I'm more familiar with BPR than with SOA as a means to increase organizational efficiency. This service-oriented method is intriguing but seems a little harder to grasp right now. I wonder if firms are able to quickly grasp and adopt this new method or if there are other methods emerging as the next step beyond BPR.

Technology and the Work/Life Balance

I'm teaching an MBA class on information technology this term. During our next session one of the topics we will discuss is the effect information technology has on the design of work and work processes in an organization. While preparing for this next class, I came across a recent Wall Street Journal article on the use of IT to develop a work/life balance. The author of the article explained how technology has enabled us to increase the number of hours connected to our work and that technology can also help us regain a proper work/life balance.

The author argued that increased meetings, inefficient meetings, improper use of reply all email responses, and managers seeing employee time as less finite as the reasons we are now spending more time outside of work on our work. This, of course, is aided through the use of our smart phones and other connected devices. Through these technologies, we can easily remain available to respond to email and get our work done outside of the normal working hours. The author provided a few suggestions for using technology (software settings) to better manage communications so that we are less likely to feel the need to work during our personal time.

The author focused on technology as a means to manage productivity inefficiencies to free us up from our off hour work time. However, if you look more closely at the efficiency problems, technology is not the root cause to the problem and should not be the main factor in any solution. The problem is not that we all have access to each other's electronic calendar or the reply all button on our email message. The real problem is organizational culture, governance, and our work processes.

While the technology provides the ability to remain connected to work, it is the organizational culture that creates the expectation or the pressure for employees to stay connected to work during off hours. Organizations may be able to place a hold on email messages during off hours but this intervention is not needed if the expectation or pressure for constant connection is not made in the first place. Likewise,  our need to keep up with work after hours is not due to technology making our calendars available for scheduling during the day. We don't need to have technology (software settings) to limit our calendars if we have proper work processes and governance in place to better streamline our work and simplify decision making.

While I may be oversimplifying some of the problems and solutions here (this is only a blog; not a book so my scope is limited), my point is that technology is not the cause or complete solution to the work/life balance. Technology is the tool we use to enable and support our business processes and communications. However, these technology tools should be applied thoughtfully with consideration to the affects on not only the work but the people doing the work.

Project Management Career Paths

In my last blog post I mentioned attending the PMI North America Congress last week. During this conference I facilitated two round table discussions on careers in project management. During these two discussions I engaged project managers in a conversation of career paths within the project management field. I thought I would share the outcome of these discussions.

First of all, the groups noted that there are three categories of career paths associated with the project management field: entry into project management, movement within project management, and movement outside of project management. After establishing these categorizations we then discussed our experiences with each of these categories.

Entry into the Project Management Field
The groups agreed that project management is not an entry-level position. Most project managers begin their career in another role and many are not aware of the project management profession. Once in their career, these individuals eventually move into a project management position either by choice or by accident. The groups found that some people seek out this role once in the workplace while others are placed into this role by necessity based on the organization's needs. Regardless of how project managers begin their career in the field, most do not initially seek the position before beginning their career.

Movement within the Project Management Field
The groups also agreed that, once in the project management field, there is no clear path for advancement. Some noted titles of Senior Project Manager or Executive Project Manager but these titles were closely associated with the types of projects managed and a few project managers noted migration from these higher titles to lower titles when taking roles on other projects. In other words, advancement in the project management field is not the same in functional areas but rather associated with the type of projects they are assigned to.

It was also noted the emerging roles of Program Manager and Portfolio Manager as potential options for advancement in the project management field. The individuals in these discussions were aware of program and portfolio roles and thought of them as opportunities for project managers but had not observed or experienced project managers moving into these roles. It was also noted that most organizations do not have a clear advancement path for project managers but the participants were aware of some firms beginning to have a Chief Project Officer or having a Portfolio Manager at the executive level of the organization.

Advancement out of the Project Management Field
The final career path category we discussed was advancement out of the project management field. All participants agreed there is no one uniform way to advance outside of the project management field. Experienced project managers develop many skills and become known as a person who gets things done. Also, project managers, through their projects, possess a breadth of knowledge of the organization and have a better understanding of how the organization works compared to managers of any single functional areas. As a result, project managers are in a good position to move to functional roles outside of the project management field.

It was also noted that some project managers choose to return to their functional roles they held prior to becoming a project manager. This can be difficult after time since the technical skills wane when project managers leave the field and become more focused on the project planning and leadership.

Summary
The two groups consisted of project managers from a wide variety of industries and from professionals with the IT field and outside of the IT field. It was interesting to note the common experiences people shared. Our observations were, by and large, uniform. Additionally, we found common challenges in the profession and we all expressed our passion for the field.

These were useful discussions and it was enlightening to find my own experiences echoed by other project managers in different fields. What is your experience? Is it similar to what we found or have you experienced or observed different career paths?

Experience at PMI Congress 2014

I just returned from the Project Management Institute's North America Congress in Phoenix this week. This was my first time attending this conference so I thought I would share a few observations about the congress and about the project management profession.

The conference was a large event that took place across the stunningly beautiful Phoenix Convention Center. The three days of the conference were filled with presentations but there was still plenty of time to network with other project managers or visit with the vendors in the exhibit hall. Most of the presentations provided excellent perspectives into current project management issues and practices. Although some of the presenters could have been more engaging (especially after a full day of listening to presentations) all of the presenters understood their audience and focused their presentations on a set of outcomes. Since the project management field covers so many areas (leadership, communications, risk, strategy, scheduling, etc) there were many topics to choose from throughout the event.

Attending the conference presentations and speaking with many project managers from around the world I gained additional insight into the project management profession. Project managers from all industries and all regions of the world share common issues and are looking for solutions or ways to improve their project management practice. I noticed many project managers are interested in learning more about designing and building effective project teams, becoming better leaders, improving stakeholder communications, developing better project plans, and dealing with challenges (risk) that occur during the project. In addition to these operational interests I also found many project managers interested in program management, portfolio management, and agile approaches to project management.

During two of the mornings I led discussions in project management career paths and founds some common concerns and observations from the attendees. I'll share these findings in my next blog post. My experience at PMI's North America Congress was a good one. I may not attend the PMI Congress every year but I certainly see this as a valuable event for project managers and encourage others to attend a congress in the near future.

The Solution to Automation

I just finished reading Nicolas Carr's The Glass Cage. This is Carr's most recent book in his series of books dealing with the influence of technology on society. In this book, Carr discusses automation with a thesis that automation removes us from the processes, dulls our skills and knowledge, and reduces our role in our work. Carr argues that, through automation, humans are relegating to monitoring processes and stepping in to handle exceptions; both of which we are not very good at doing.

Throughout the book Carr makes compelling argument for the need to understand the downside of automation. While we often focus on the benefits of efficiency, accuracy, and cost savings of automation, we tend to ignore or downplay the role automation has on changing the nature of work and our role in work. He offers plenty of examples of automation changing the nature of work and makes a particularly strong case for airline pilots.

Carr provided many insightful reflections on automation but offered little in terms of specific solutions. The approach of human-centered automation rather than technology-centered automation was suggested and the author pointed to video games as a better model for automation. In this approach, technology is used to enhance our skills and help us accomplish our goals rather than taking over the process and having us step aside and monitor the work.

In a brief section of the book Carr described his experience with the game Red Dead Redemption and how he, as the user, was coached by the software to perform a task, provided with feedback (death of his video game character) and allowed to reattempt the task until it was mastered. This example helped illuminate the human-centered design but I would have liked to see him apply this concept to examples of automation of work. Although I appreciate this example (and Carr's admission of playing Red Dead Redemption which helps me justify my affinity for Assassins Creed) I would have liked to see more of the book dedicated to applying this human-centered model.

If human-centered design is the solution to better apply automation to our work, we must develop a better vision of what this looks like and strategies for how we can apply this to our work. This is not an easy task since technology-centered automation promotes efficiency, accuracy, and cost savings while human cannot make these same claims. Do we offer enough value to work for organizations to abandon the benefits of technology-centered automation? We must first answer this value proposition before we can hope for change.

A New Role for the IT Department

I'm preparing to teach an IT management course for our MBA program next term and I want to begin the course by showing what the modern IT organization looks like. When I was reviewing articles on IT organizations I came across a great article explaining how some IT organizations are becoming sources of revenue for the firm. This is quite different than the typical cost center role the IT department played in the past.

Thanks to the Internet and the emergence of cloud computing as a viable option for enterprise applications, distribution of centralized software and hardware services has never been easier. IT departments are now able to partition their data to sell extra capacity and their proprietary software to other firms. This means that an IT department in a small insurance firm is now able to create new sources of revenue for the organization by selling access to in-house developed software. In some cases, organizations are able to sell access to purchased software as well.

Over the past few decades, in-house developed applications have taken a backseat to purchased "off the shelf" applications from software vendors. Perhaps, as more entrepreneurial IT departments continue to find profit in selling their own software, we will see more organizations move to developing their own software again. This will result in more software options and software more closely integrated with specific industries.

It will be exciting to see the trend of renting out in-house developed applications and services continue. However, I have concerns over these organizations' ability to provide adequate support and the willingness to offer ongoing enhancements or customizations.

MVP Process in Knowledge Management Systems

Today I read David Weinberger's article on the MVP process in this month's issue of KM World. In the article Mr. Weinberger described the use of minimum viable product (MVP) and how this approach is applied today (think Apple products) and early on (Ford Model T). The point of the article was that both of these companies developed simple products for a small set of early adopters and then allowed the product to mature as the desired features for the product emerged. This allowed the product to be produced while limiting the unwanted features and using the market to determine future features.

I enjoyed the article but found the MVP concept was not applied to the context of knowledge management systems. This was a knowledge management magazine so I was looking for insight into the application to the KM field. Since this application was not included in the article I thought I would build on Mr. Weinberger's article by applying MVP to the KM field.

The MVP concept can be applied to knowledge management systems but, if applied incorrectly, it may result failure. If the product, in this case a KM system, is designed with a minimum set of features or a minimum set of content, the early adopters of this information system will be frustrated by the lack of ability to locate and add knowledge or by the quality or quantity of content available in the system. We can't build a KM system based on a small set of content and functionality and then simply allow it to mature over time as we see the needs emerge. This initial offering must provide value in order for it to attract users and for users to continue to rely on the system.

The MVP approach to KM systems can still be used but this initial system offering must be focused on specific value. Perhaps it is the scope of the value proposition that can be minimized for the initial offering. Beginning with a specific scope for the KM system and then providing all functionality and content needed to achieve the goals within the scope should be the objective.

Viewing the MVP approach for KM systems only makes sense if we shift the perspective of product functions to product scope. Offering a minimal viable product scope (MVPS) allows an organization to produce a valuable KM system to satisfy a narrow purpose and then, over time, this scope can grow along with the functions and content needed to fulfill the growing scope. So, lets apply the MVPS approach to KM systems rather than the MVP approach.

Project Management Conference Presenters

A few weeks ago I wrote a blog post about the new project management conference The College of St. Scholastica is co-sponsoring. This conference will take place October 16th and 17th at Central Lakes College in Brainerd, Minnesota. The conference features presentations from project managers across the area.

Now that I recruited the presenters for the conference I thought I would share the lineup of the conference presenters. Below is a list of presenters (myself included) that will present at the Central Minnesota Conference on Project Management. If you would like to attend the conference, you can register on our conference website.

• Becoming a Better Project Manager - Brandon Olson, Ph.D., PMPAn overview of project management competencies and preparing a professional development plan.
• Optimizing Stakeholder Management - Beth Olson, M.Ed.
  Fostering relationships with even the most challenging project stakeholders and the value of these relationships bring to the project.
• Effective Time Management - Chad McCoy, M.A.
  Techniques for improving your team's time management capabilities.
• Organizational Transformation to Agile - Hasnain Somji, M.S., PMP
  Experiences and outcome of moving from traditional to agile project management.
• Dictator to Coach - Kathleen Bartels, M.A.
  Discussion on the differences of the traditional project managers and a scrum coach.
• Designing, Evaluating, and Maintaining Effective Project Teams - Kathy Modin, M.A.
  Hands-on experience with several techniques and tools for effective and cohesive project teams.
• Effective Team Building - David Swenson, Ph.D., LP
  Review of the team factors related to project team success and failure and a model for team building.
• Preparing People for Change - Kent Lacy, Ed.D., PMP
  Project management solutions and tools for understanding, planning, managing, and implementing change in the organization.

Passed My PMP

It has been awhile since I last posted to the blog and there is a reason for this. Over the past few weeks I have been spending my free time preparing to sit for my Project Management Professional (PMP) exam. This past Monday I completed the exam and passed! I am now a certified Project Management Professional.

In preparing to take the exam I decided to use a book rather than the training/boot camp courses offered by many firms. In addition to reading through the Project Management Body of Knowledge (PMBOK) book I also purchased a copy of Rita Mulcahy's PMP Exam Prep book. Between these two sources I was able to feel prepared to take the examination.

When conversing with other individuals with a PMP I found that each of us used a different means to prepare for the exam. Some, like me, used a type of training book, others attended classes, and others used training materials offered through their workplace. So there are many ways to prepare for the exam and it seems that it is best to pick the resources that you feel will best prepare you for the exam.

Learning from Government Projects

In one of my project management workshops I lead the attendees through several examples of failed projects. The point was to understand a few of the common sources of project failure and to develop risk plans to address these sources. As I prepared the workshop I noticed that almost all of the examples of failed projects were government funded. These failed projects include the Denver International Airport baggage handling system, the FBI Virtual Case File/Sentinal project, and the Sydney Opera House construction.

Due to the public-nature of these projects (versus confidential information on private sector projects) government projects are more accessible and, as a result, are more visible and make headlines when they fail. Unfortunately, the successful government-related projects don't make the headlines. Surely a large percentage of government-funded projects are successfully delivered and many aspects of project management are derived from government-funded projects. So, there must be some positive things we can learn from these government-funded projects and their corresponding practices.

Today I came across a brief but valuable article pointing out some of the excellent project practices we can learn from the government projects. I found the arguments over project requirements processes to be very enlightening. Since the project requirements drive the final deliverables and can determine the success of the project it does pay to improve how we consider and filter these requirements. Tips such as sunset clauses and testable requirements make sense.

While we see spectacular project failures in government projects, we also must realize there are some very good practices embedded in their processes. The project management field has benefited from these practices but we can also learn a lot from their failures too. So let's keep an eye on these government-funded projects, learn from these projects, and improve our own project management practices.

CMCPM 2014 Call for Presenters

Earlier this summer I announced that we are offering a new project management conference. As of today we are now actively looking for conference presenters. If you have knowledge or experience you would like to share with our attendees please let us know. Check out our Call for Presenters page at  http://www.css.edu/Graduate/Masters-Doctoral-and-Professional-Programs/Areas-of-Study/MS-Project-Management/Central-Minnesota-Conference/Call-for-Presenters--Central-Minnesota-Conference.html and submit your presentation description.

The Central Minnesota Conference on Project Management is a joint venture between The College of St. Scholastica and Central Lakes College. The conference takes place October 16-17 at Central Lakes College in Brainerd, Minnesota. We will have more information on our conference website as it becomes available:  http://www.css.edu/Graduate/Masters-Doctoral-and-Professional-Programs/Areas-of-Study/MS-Project-Management/Central-Minnesota-Conference.html

Project Manager - Assessing Organization Expertise

Earlier this month I presented a conceptual model that I referred to as the project manager building blocks. This model was based on the Project Management Institute's Project Manager Competency Development (PMCD) framework. The framework covered the project competencies but did not address the details behind the industry and organization expertise needed to develop project manager competency. In my previous post I outlined the attributes of the industry expertise and today I will describe the attributes of organization expertise.

Organization expertise is the awareness of the organization providing that provides the proper context of the project. The expertise can be broken down into knowledge of the organizational structure, mission and values, the experts and leaders in the organization, the workflows and processes, professional expectations, appetite for change, and communication styles across different groups.

Having an understanding of the organizational structure, what is important to the organization, and the organizational culture allow the project manager to better understand some of the politics of the organization. Insight into the subject matter experts, influential people, overall workflows, and individual processes enable the project manager to recognize how the organization operates and identify the key people and trigger points. Finally, the social norms, organizations tolerance for change and new ideas, and the types and channels of communications provide the project manager an appreciation of the basic ground rules for working in the environment and moving the project forward.

These organization attributes are by no means inclusive of everything a project manager must know about the organization. However, many of these appear to be key drivers leading to project success. Developing greater awareness and understanding of these seven areas, a project manager should become more effective in navigating the organization to remove roadblocks for the project team.

Project Manager - Assessing Industry Expertise

Two weeks ago I wrote about the industry expertise project manager building block. In this post I argued the role industry experience plays in developing competency as a project manager. This was a part of the project manager building block model. In this earlier post I simply described the industry expertise building block. I will now provide more detail on this building block.

The Project Management Institute's Project Manager Competency Development (PMCD) framework covers project management-specific competencies but the framework does not include any attributes of industry expertise. In my model I build on the PMCD framework to include attributes of industry expertise that are relevant to effective project managers.

Project managers build competency in project management through their expertise in the industry. This expertise is derived from industry language and terminology, workflows and processes, process performance, history and change, professional ethics, and external constraints. The project manager is more effective when able to speak the language of the industry specialists, understand their workflow and work processes, and appreciate the amount of work and skills required to perform industry processes.

Project managers also need to have a historical context of the industry, understand the origins of change on the industry, and how the industry responded to change. Project managers should have a good understanding of the industry's code of ethics and the type of ethical issues that arise in the industry. Finally, the project manager must be aware of the governing bodies in the industry and any legal or regulatory constraints these agencies may place on the industry and any projects executed within the industry.

Each of these six attributes of industry expertise contribute to the project managers proficiency and should improve the project manager's ability to be successful leading projects within the industry.

Strategy and Big Data

Early this year I wrote a post arguing that business strategy and business needs must drive data collection. In this post I explained that the data and information available in a business intelligence (BI) solution must be the right type of data; the data and information needed to make informed decisions. The BI solution should be based on the information needs rather than simply reporting on the data from the existing information systems.

This week I read another article that reminded me of this issue. This article discussed the technical challenges of developing a Big Data solution. Just like big data is an extension of BI but with new problems to solve, the data issue I described associated with BI solutions is further extended compounded in a big data solution.

The issue of business needs driving big data solutions is far grater in big data solutions than for BI solutions. Both big data and BI solutions require the right type of data to yield systems that provide meaningful results and lead to improved decision making. The data issues with Big data solutions are compounded due to significantly larger volume of data, significantly wider scope of data collected, and the mixed type of data collected (structured and unstructured). Big data solutions require more processing horsepower than traditional BI solutions.

It is the processing horsepower and storage limitation issues that further require a focus on the end result when designing and implementing big data solutions. The volumes of data can be reduced if only data contributing to the decision making for strategic efforts are collected. The reduced data collection also leads to reduction in the data compression and filtering, data storage, data cleaning and integration, and data representation needed to process all of the data in the big data solution.

If we allow our business strategies to determine the types of decisions we need to make we will then be able to better focus our big data efforts. With focused efforts we reduce the data and processing needed to yield meaningful outcomes. This results in improved decision making in areas that are strategically important to the organization. The strategic focus reduces the big data load and improves the value derived by the organization.

Project Manager - Professional Behavior

This post is the final post on the discussion of my conceptual model for project manager competency building blocks. I have previously explained the foundational building blocks of industry experience and organizational experience and described the process knowledge building block and the project performance building block as two of the three project management-specific competency building blocks. In this post I'll explain the third and final project-specific building blocks - professional behavior.

The professional behavior is based on the personal competencies in the Project Manager Competency Development framework. This building block consists of the ability to manage the project resources, guide a team through motivation and goal setting, communicate effectively with all project stakeholders, understand the project complexities as well as the external environments affecting the project, applying good judgement in evaluation the project environment leading to good decisions, and demonstrating ethical and professional behaviors to achieve the desired project results.

The professional behavior is developed outside of the project management skills and knowledge. The professional behaviors must be developed through experience, education, and mentoring. A project manager may be technically sound in the knowledge and application of the processes and tools but, without developed professional behaviors, the project manager will struggle in leading the team and stakeholders to achieve the desired results.

The professional behaviors building block along with all of the project manager building blocks require continual development. The project environment is always changing and we can always find ways to learn new techniques or improve our existing practices. These building blocks are simply a way to view the different types of skills and knowledge needed to be a successful project manager. Use these building blocks to begin evaluating and improving your own project management competency.

Project Manager - Project Performance

This post is a continuation of my discussion from a previous posting about my conceptual model for project manager competency building blocks. I have explained the foundational building blocks of industry experience and organizational experience and described the process knowledge building block as the first of the three project management-specific competency building blocks. In this post I'll explain the second of these project management-specific building blocks - project performance.

The project performance competency building block represents the project manager's ability to apply the project process knowledge and technical skills to the project environment. Project managers must not only know the project management processes and tools but also must be able to apply them to real projects. The project performance competency is developed by identifying the performance elements, determining target performance criteria, evaluating the individuals project performance competencies, identifying gaps between performance and target criteria, establishing a development plan, engaging in performance competency development activities, and re-evaluating the performance. The evaluation, gap analysis, development plan, and development steps are continually iterated as the project manager continues to develop project performance competency. This cycle of performance competency development should continue throughout the career as the project manager constantly learns and improves in applying project management process knowledge.

There is a lot more to the project performance competency building block that what I covered in this brief explanation. A project manager needs to determine the elements of project management that are important to evaluate, determine how to measure the performance for each of the elements, define a target goal for each element, and discover ways to improve in the lower performing elements. I'll try dive into this further in a future post on this blog site.

Project Manager - Process Knowledge

In previous posts I explained my conceptual model of the project manager building blocks and have described the foundational building blocks of industry experience and organizational experience. In this post I will describe the first of the three project management-specific building blocks - process knowledge.

Anyone new to the project management field will begin developing project manager competencies in the process knowledge building block. The process knowledge competency is developed by identifying and understanding all of the processes used across a one or more project management methodologies. For instance, becoming familiar with the Project Management Institute's Project Management Body of Knowledge (PMBOK), reading project management textbooks, discovering project management tools and resources (ie projectmanagement.com and pmi.org), and other resources.

Understanding the common processes and tools successful project managers use is an important step in developing as a project manager. Although the project management field is fairly new, there is a growing body of best practices available and these best practices help a project manager understand and adopt proven project management practices.

In developing the process knowledge building block, a project manager becomes familiar with common and unique processes and tools and understands how they are applied to the project setting. While process knowledge building block is primarily developed when new to the project management field, a project manager should continually refine their process knowledge to discover new and changing tools and processes in order to improve their own project management practice.

Project Manager - Organization Building Block

A few days ago I posted an introduction to the project manager competency building blocks. These are the categories of skills and knowledge project managers should possess in order to be effective. I also previously posted a description of the industry building block that is one of the foundational project manager competencies. Today I will describe the next competency; the organizational building block.

Similar to industry experience, organizational experience is a foundational competency for project managers. These skills and knowledge are not directly related to project management but provide the background needed for a contextual understanding of the project environment. The industry experience building block I previously described represented the industry-specific experience that help project managers understand how projects are successfully executed within a specific industry. The organizational experience, on the other hand, provides the project manager with an understanding of how projects are executed within the context of the organization.

Organizational experience is gained from developing an understanding of the processes an organization follows, recognizing the power structures that exist within and outside of the organization and realizing who has the authority to make things happen, and observation of the unwritten rules and expectations the organization has for its employees and supervisors. These organizational factors may be unique in each organization and it is beneficial for the project manager to understand these characteristics before initiating a project.

Organizational experience is an especially important competency for project management consultants who may be experts in the project management field but may be at risk in the role due to insufficient experience with the organization. People unfamiliar with the organization will need to quickly understand the organizational context and apply it to the project.

Project Manager - Industry Building Block

I recently shared my conceptual model for the building blocks for project managers. This model is based on the PMCD framework published by the Project Management Institute. The building block model includes the project manager competencies of industry experience, organizational experience, professional behaviors, process knowledge, and project performance. In this post I'm going to describe the first of these building blocks; industry experience.

Industry experience is a supporting competency for project managers. Competent project managers should have a solid foundational knowledge of the industry and some technical skills, or at least an appreciation of the technical skills required in the industry. The industry knowledge includes awareness of regulatory and legal requirements, past and future trends within the industry, and experience with projects in the industry. For example, a project manager within the construction field should be familiar with OSHA and local building requirements, history and trends in construction materials, and possess the insight gained from previous construction projects to understand the sources of project risk in a construction project (like weather, fuel costs, transportation logistics, etc.).

In addition to the industry knowledge, a project manager must also posses the technical skills or at least an understanding and appreciation for the skills needed and the work to be carried out in a project within the industry. For example, in an IT project, the project manager should understand the level of difficulty for writing the code for a piece of software and understand the amount of time it takes to design, code, and test the software. The technical experience or technical skill appreciation helps the project manager assign the work to the properly skilled team member and evaluate the schedule needed to complete the work.

Industry experience is not required to meet the basic requirements for a project manager. Project managers may still succeed managing a project outside of their industry expertise. However, the knowledge of the industry and the technical skills within the industry are beneficial in understanding projects within the context of the industry. This contextual understanding of the industry enables the project manager to better communicate with the project stakeholders, better understand the sources and solutions to project risk within the industry, and improve project decision making.

Project Manager Building Blocks

Project Manager Building Blocks

I'm beginning to prepare for a project management workshop I'm leading in Brainerd and St. Cloud. In this workshop I plan discuss the skills and knowledge that project managers must possess and help attendees inventory their own skills and knowledge to prepare a professional development plan. I plan to use the Project Management Institute's Project Manager Competency Development (PMCD) framework as the foundation for this workshop.

As I began to dive into the PMCD framework I found a useful model but wanted to re-conceptualize the model to better differentiate the project management and supporting skill sets. What I came up with is what I refer to as Project Manager Building Blocks. These blocks represents the different types of knowledge and skills required to serve in the project manager role. The individual blocks are personal behaviors, (project) process knowledge, project performance, industry expertise, and organizational expertise.

The diagram at the top of this posting is my model for these building blocks. Granted, these categories are directly based on the PMCD complementary framework but in my model I am separating direct PM skills and knowledge from supporting skills and knowledge. The industry experience and organizational experience are needed to value the nuances of the industry and organization so that the project context is better understood. This industry and organizational experience provides the foundational building blocks for the project management-specific blocks.

I plan to further develop this model and extend it to include skill and knowledge assessment to support building professional development plans. I'll share more about model as I continue to work on the workshop over the month.

Growth of Project Management Professionals

Each month when the Project Management Institute (PMI) publishes their PMI Today newsletter magazine I look at the Fact File page where they provide the number of members, published copies of the PMBOK Guide, and active credential holders (CAPM, PMP, PgMP, PMI-RMP, PMI-SP, AND PMI-ACP). Noting these numbers we can see the size of the project management profession and the credentials these professionals possess.

Over the past 18 months I have been capturing these PMI-reported numbers in a spreadsheet in order to make observations on trends in the project management profession. For instance, this month there were 3,490 more active certified PMP professionals than the previous month and 13.55% more than this time in 2013. What really caught my attention was when I compared the number of active PMI members in June to this time in 2013. PMI membership actually dropped from 451,871 to 449,769 (a decline of 2,102 members).

Looking at this closer I see a trend in both PMI membership as well as PMP certifications. While both membership and PMP certifications continue to grow from this time in 2013. The growth has slowed throughout 2014. The image at the top of this posting summarizes the % change each moth from the same time the in 2013 (ex. percent increase from January 2013 to January 2014).

Why do we see a slowdown in the growth of PMI members and PMP credential holders? Is it the time of the year were members forget to renew or are there environmental factors leading to a slowdown in the number of project managers becoming active in the professional organization? I have not yet captured the numbers before 2013 but it will be interesting to see if this growth pattern occurs each year or if this is a new trend. For the sake of the profession, let's hope this is not a new trend.

Social Value Identification and Knowledge Sharing

In an earlier post I noted the influence of organizational culture on knowledge sharing and the dimensions of organizational culture contributing to knowledge sharing behaviors. I later expanded on the managerial prompting and group identification dimensions. In this post, I will describe the third dimension of social value orientation.

Social value orientation is a personal attribute indicating a person's interaction with others. There are three profiles of social value orientation: competitors, individuals, and collectivists. Competitors seek to increase their return in order to maximize the distance between themselves and their competitors while individualists seek to maximize their own return regardless of the return of others. These two types are referred to as proself contributors. At the other end of the contribution spectrum are prosocial people with a social value orientation of collectivists. Collectivists are more interested in maximizing the group's return with less of a concern over their own personal return.

Since prosocial collectivist employees value the benefits of the group over their own benefits they are more likely to share knowledge than proself competitor and individualist employees who are more likely to hoard knowledge to improve their own benefits. Organizations employing or developing people with prosocial behaviors are more likely to see higher levels of knowledge sharing. While some employees may tend to be more competitive or individualist in their social value attributes, organizations emphasizing group value can influence proself workers to exhibit more prosocial social value behaviors and be more likely to contribute to sharing knowledge.

Group Identification and Knowledge Sharing

A few days ago I noted the three dimensions of organizational culture that influence knowledge sharing. These dimensions include managerial prompting, group identification, and social value orientation. In my previous post I further described the managerial prompting dimension so now in this post I will expand on my description of group identification.

Group identification is the degree to which people associate with a particular group. Individuals are a part of many groups such as religions, fans of a sports team, book clubs, college alumni, professional organizations, families or any other collection of people with a common interest or connection. A person belongs to many groups and the level of affinity for the group varies. This can be seen by the amount of time and energy people are willing to commit to any particular group. The higher affinity one has for a group the more likely they are to volunteer or spend time working toward the group's success. This affinity for a group is the driver of group identification.

Organizations or project teams that are able to develop cultures where employees have a strong affinity for the group are more likely to share knowledge with the group. The individuals value the success of the group and are more willing to contribute their own knowledge and expertise to help the group reach its goals. An organizational culture encouraging group identification will be more successful in knowledge sharing because its members are invested in the group's success and are willing to contribute knowledge to help the group succeed.

Managerial Prompting and Knowledge Sharing

In my previous post I noted that organizational culture influences knowledge sharing in knowledge management system (KMS) implementations. The right type of organizational culture will foster knowledge sharing while the wrong mix of cultural attributes will reduce knowledge sharing. One of the dimensions of the organizational culture that strongly influences employees' willingness to share knowledge is managerial prompting.

It has been previously argued that managerial prompting is related to the willingness of employees to share knowledge. Managerial prompting are the cues managers use to influence workers to work toward a particular goal by articulating expectations, refocusing the employees on the goal, and other methods to influence the workers' drive toward the common goal.

In the context of KMS implementations, managerial prompting is used to remind employees of the value of knowledge, articulate expectations that knowledge should be shared and re-used, and influence the workflows to better integrate knowledge sharing. Managerial prompting is needed to remind and refocus employees on the value of knowledge sharing but misapplied prompting can also reduce knowledge sharing.

It has been shown that managerial prompting that attempts to force employees to share knowledge results in decreased knowledge sharing. Rather than exerting force and control over the employees, managers must try to positively facilitate knowledge sharing and gently remind workers how the organization values knowledge sharing and how knowledge sharing makes their work more effective.

Managerial prompting is an important factor in establishing a successful KMS implementation by increasing knowledge sharing. However, the prompting must be done to increase trust and the employees' desire to share knowledge. Heavy-handed prompting will backfire and result in reduced knowledge sharing and ineffective KMS implementations.

Organizational Culture and Knowledge Sharing

Today I'm working on revisions to a chapter in a new knowledge management book. As part of this chapter I'm discussing the importance of organizational culture in knowledge management system (KMS) implementations. Today I'm looking at a few of the main issues with the organizational culture for organizations unable to realize KMS success.

As I noted in earlier posts, challenges with KMS implementations generally fall into three categories: technical challenges, people challenges, and organizational challenges. When looking into organizational challenges we see that organizational culture plays a significant role in the success of a KMS implementation. Looking at a few knowledge management articles (here, here, and here) I found a few key factors in the organizational culture leading to effective KMS implementations.

The organizational culture supporting knowledge sharing must include managerial prompting, group identification, and proper social value orientation. This means that managers need to support knowledge sharing, the organization must work to create a common goal for the workers, and the firm must hire people inclined to collaborate and share.

Over the next few posts I'll discuss each of these cultural attributes further.

Importance of Project Status Reports

The June 2014 issue of PM Network included an article on the project status report and provided some good advice on what to do and what not to do when preparing a status report. The article noted that status reports should consider the needs of the audience, provide the content and content structure to meet the audience's information needs, and be delivered in a manner (timing and media) to provide the information where and when the audience needs it. The article also included some useful examples and advice for this project deliverable.

The project status report is a critical project deliverable. When we think of project deliverables we typically think about the physical or electronic products that are produced at the end of a project. These primary outputs are indeed important but may not be realized if the project is not properly executed.

Project communications is an important contributor to project success. According to the 2013 PMI Pulse of the Profession report, 20% of projects fail as a result of poor communications. Successful project teams communicate within the team as well as with the project stakeholders. Without sufficient communications, it becomes difficult to coordinate work and ensure the project deliverables meet the stakeholder expectations.

Improving project communications is where the status report contributes to project success. The project status report provides an opportunity for the project team to engage the project stakeholders in the project and stakeholder engagement results in stakeholders that both support and collaborate with the project team. The status report provides the opportunity to remind the stakeholders of the project and its importance to the organization which in turn allows them to continue to provide the needed support and resources to the project team. Additionally, engaged stakeholders are also prepared to collaborate with the project team to coordinate the needed inputs into the project and receive the scheduled outputs from the project team.

The project status report may seem like another administrative task for the project manager but this form of communications is essential to increasing the success of the project. The status report offers an opportunity to frequently engage the project stakeholders throughout the life of the project. Given the importance of this project document, project managers must carefully design these reports to provide the most meaningful and timely information to the project stakeholders. Engaged project stakeholders increase the likelihood of meeting the project objectives.

Scope of Knowledge Management

I received my copy of KMWorld today and read the article on surveillance. Before I began reading the article I wondered why surveillance would be a topic in a knowledge management magazine but I quickly began seeing applicability to the KM field. The example of Tacit Software's ability to conduct an email network analysis to identify subject matter experts based on incoming email messages appears to be a good example of using employee monitoring as a means to capture tacit organizational knowledge. While this application seems to be useful and applicable to KM initiatives, the idea of surveillance as a KM tool is a little unsettling.

I view knowledge management as a way to engage people to share what they know and learn from each other. To me, the field encourages collaboration, trust, and just being a good person and a valuable employee. Although I may have somewhat of an idealistic perspective, the knowledge management field has an overall positive connotation. Typically, knowledge management requires active participation and acknowledgement that people are participating in knowledge sharing and reuse. Surveillance as a KM practice makes me a little uncomfortable since the participants are not actively engaged and may not be aware of how their actions are leading to organizational knowledge.

Organizations must conduct certain levels of employee monitoring to address compliance requirements, mitigate legal risk, and other reasons. However, I prefer to classify these activities as part of risk mitigation or compliance rather than a component of knowledge management. Knowledge requires people and should be a people-centric practice that benefits both the organization and its employees (as well as individuals applying a personal knowledge management practice). Employee surveillance does not engage people to develop knowledge. Rather, it uses people to develop knowledge for the organization without direct benefit to the employee. Without awareness and engagement by the contributors, I cannot consider surveillance as a form of knowledge management.

Top Evaluation Models for Project Management Maturity

In my previous post, I discussed the use of project management maturity models (PMMM) as a means to evaluate an organization's project management practices. The article I referred to in this post provided an evaluation of the top PMMM models. I thought I would share these with you.

Using criteria of alignment with a methodology, scope of the model, level of inclusion in publications, degree of industry independence, clarity of calculations, level of tool independence, longevity, and ease of use, many PMMM frameworks were evaluated. The top five PMMM models are:

• Organizational Project Management Maturity Model (OPM3)
• Capability Maturity Model Integration (CMMI-DEV)
• Kerzner Project Management Maturity Model (PMMM)
• Project, Program, Portfolio Management Maturity Model (P3M3)
• Maturity Increments IN Controlled Environments (MINCE2)