During good times and bad, selecting the proper projects to undertake is an extremely important activity for organizations.  Selecting the right projects  (or wrong ones) can be the difference between success and failure for most organizations.  The process of selecting projects and managing the project portfolio, formally called Project Portfolio Management, can help organizations get a grasp on their projects and the risk & benefits associated with those projects [1].

Project Portfolio management and selection has become an important part of most organization’s project management activities. By managing their project portfolio’s correctly, organizations can gather information about all projects, prioritize those projects and manage the selected projects throughout the project lifecycle.

The remainder of this paper provides an overview on project selection and describes a prototype system that can be used to optimize the selection of projects.  The project selection prototype uses optimization techniques to select the optimal number of projects based on given criteria.

Problem Description

The act of prioritizing projects can be daunting, especially when confronted with a large number of projects with multiple constraints on project resources.  In an ideal world, with unlimited budget and personnel and the ability to take on any risk, the project selection process would be very straightforward.

In order to manage project portfolio’s, organizations must have a method of prioritizing and selecting projects [2].  This selection process can be as simple as a ranking method or more complex criteria like return on investment, strategic value or some other criteria.  Choosing the proper selection criteria is beyond the scope of this paper, but many of these criteria allow for linear programming models for decision support systems to be utilized.

The challenge for many organizations lies within the act of prioritizing and selecting projects in their portfolio [3].   There has been considerable research and reporting on selecting projects based on ranking, strategic value, risk levels and other factors [2-7].  The problem with many of these methods is that they rely more on human decisions, which can lead to project bias and favoritism rather than an optimal selection of projects [8].

The project selection problem facing organizations cannot be completely overcome using optimization techniques, but the effect that human bias has can be minimized during some steps of the selection process.  This can be accomplished using decision support tools to provide optimal project portfolio selection using inputs such as budget, risk level, strategic value, number of projects or other requirements [9].

Project selection is very much an ‘in’ or ‘out’ process since a project is either selected or not.  This “yes or no” selection process lends itself well to using a binary linear programming method [10].   A review of existing research shows the use of a zero-one integer linear programming model developed by Ghasemzadeh and Archer to assist in the project selection process [11]. This zero-one model provides for accurate and optimal solutions for project portfolio selections due to the discrete nature of the inputs and outputs [11].

As an example of the project selection problem, let’s assume there are 26 projects with the same priority level listed on an organization’s project portfolio. If there is no constraint (i.e., enough budget to do them all), the selection process is easy…the organization would undertake all 26 projects.    In the real world though, there are always constraints such as budget, strategic value, personnel requirements and many more.

Back to the example: Assume that a budgetary constraint exists that prevents the organization from undertaking all projects.   This constraint forces the organization’s leadership to select a set number of projects so the overall budget isn’t exceeded.  How should this organization select the projects that are undertaken?  What criteria (other than budget) should be used?  Should forced ranking be used or would strategic value be a better option?  How about project risk levels or Return on Investment?    All of these criteria are correct and plausible choices and can be used to select projects in a one-constraint environment, but the project selection solution space is larger than most realize.

In the above example with one constraint, there are 2 to the power of 26 (67,108,864) possible project selection possibilities.  Of course, most of these possibilities aren’t optimal (e.g., select only one project even though the project cost is much less than the budget constraint) so they aren’t necessarily viable solutions.

When there are two constraints placed on the project selection process, the solution space gets to be so large as to not allow for optimal solutions without help from a computer system. Using optimization tools and techniques to assist with the selection process can provide a great deal of benefit to an organization.  These tools can help an organization select the optimal project portfolio mixture to gain the maximum benefit from project resources (budgets, personnel, etc).

A Real World Project Selection Problem

The project selection problem described above exists in every organization.  Assume that you are the head of the project management office at your organization.  Your company has just started a project portfolio management initiative and is having difficulties with the project selection phase of portfolio management.  Specifically, your team is having trouble choosing the optimal project selection mixture.

Your boss has requested a report that outlines which projects will be selected and the methodology used to select these projects.  In addition, the Chief Information Officer (CIO) has asked for special consideration to be given to three high profile projects to ensure that they are selected.   The Chief Executive Officer (CEO) has given his approval for these high profile projects to have a higher priority, but has asked for a project selection report with and without special consideration for these higher priority projects.

Needless to say, your project portfolio management team is in a quandary.  The project portfolio shows twenty-six projects that are considered ‘high priority’.   The portfolio does not take project risk into account as this has been considered prior to being listed as ‘high priority’.  Each project has a level of effort estimate, and thereby an estimate for cost to complete the project and each project has a statement of work and personnel associated with it.

The organization has stated that the budget for all projects for the upcoming half-year is $750,000, which must cover all internal and external costs associated with the projects.  In addition, the amount of work that can be accomplished by the organization’s personnel is limited to 7,750 hours for the half-year. The projects within the project portfolio are all scheduled to start and end within the upcoming six-month period and each has a different cost structure and level of effort.  In addition, the leadership team has mandated that the project selection process provide a project mix that allows for the maximum number of projects to be undertaken within the budgetary constraints.

Implementation

To address the issues outlined above, a decision support system was built using a combination of excel and the LINGO optimization modeling software package. A zero-one integer linear programming model is used to select the optimal project portfolio.  This model, based on Ghasemzadeh’s work described in the Literature Review section above, attempts to maximize the number of projects undertaken while keeping total cost and number of hours below the constraint levels. 

Excel has been used to gather the appropriate information about the projects in the portfolio. The excel spreadsheet contains a list of all high priority projects along with their costs, level of effort estimates, other relevant project information and the cost and hour limits.  An excel macro is run to provide an automated method of gathering the relevant pieces of information and storing the data into a text file for use with the LINGO optimization software platform.

The solutions provided by the LINGO optimization platform were quite interesting. The optimal project selection output maximizes the number of projects based solely on staying under the budget and hour constraint.

Model #1 shows 18 projects being undertaken with a budget of selected projects of $715,995 and 7,630 hours.  Model # 2, with the three projects given special consideration, shows 17 projects selected with a budget of $713,445 and 7,380 hours. Reviewing the project selection mixture shows that these solutions appear to be the optimal solution.

Conclusion

The model and decision support system described above has provided a quick and easy method of project selection.   The ability to select an optimal mix of projects when constrained by budget (or any other constraints) provides a significant improvement to the project selection process.

There are some limitations to this project selection decision support model.   The current implementation assumes that the list of projects have the same priority.  The zero-one model does allow for a weighting to be applied to each project (the ai factor) but this weighting factor must be selected prior to setting up the LINGO model.  This might cause confusion with some users when creating the project portfolio for use in the selection decision support model.

Future improvements are planned for this model to make it more robust.  The current model assumes that the money is spent during the time frame considered and all projects are started and ended within the same period.  In addition, the model assumes that the priority of the projects will not change throughout the time period.  Making changes in these areas would provide for a more robust model to assist in project selection.

REFERENCES

[1]    M. Greer, “What’s Project Portfolio Management (PPM) & Why Should Project Managers Care About It?,” 2006.
[2]    R. D. Snee and W. F. Rodenbaugh, Jr., “The project selection process,” Quality Progress, vol. 35, p. 78, Sep 2002.
[3]    K. M. Rosacker and D. L. Olson, “An Empirical Assessment of IT Project Selection and Evaluation Methods in State Government,” Project Management Journal, vol. 39, p. 49, Mar 2008.
[4]    “Managing the innovation portfolio,” Strategic Direction, vol. 23, p. 35, 2007.
[5]    M. Enea and T. Piazza, “Project Selection by Constrained Fuzzy AHP,” Fuzzy Optimization and Decision Making, vol. 3, p. 39, Mar 2004.
[6]    D. A. Gels, “Hoshin Planning for Project Selection,” ASQ World Conference on Quality and Improvement Proceedings, vol. 59, p. 273, 2005.
[7]    T. E. Say, A. R. Fusfeld, and T. D. Parish, “Is your firm’s tech portfolio aligned with its business strategy?,” Research Technology Management, vol. 46, p. 32, Jan/Feb 2003.
[8]    F. Lefley, “Can a project champion bias project selection and, if so, how can we avoid it?,” Management Research News, vol. 29, p. 174, 2006.
[9]    F. Ghasemzadeh and N. P. Archer, “Project portfolio selection through decision support,” Decision Support Systems, vol. 29, pp. 73-88, 2000.
[10]    R. Hemaida, “A zero-one programming model for internal audit planning,” Managerial Auditing Journal, vol. 12, p. 331, 1997.
[11]    F. Ghasemzadeh, N. Archer, and P. Iyogun, “A zero-one model for project portfolio selection and scheduling,” The Journal of the Operational Research Society, vol. 50, p. 745, Jul 1999.

In the project management world, a considerable amount of research exists to describe the reasons behind the success or failure of projects in the information technology space. Most of this research focuses on failures being caused lack of executive sponsorship, lack of project management methods, lack of change management processes, project scope size and/or project duration (Reich, 2007).

While these causes of failure are quite common, a large and overlooked stumbling block that causes failure in IT projects is the lack of proper knowledge management methodologies throughout the project management lifecycle.

This paper provides a brief review of the literature within the knowledge management space, and more specifically, how to manage knowledge transfer, sharing and application in projects. The main question that is initially asked (but not really answered) in this paper is that following: Can a framework containing “best practices” be developed that can be use to improve knowledge transfer and sharing in project based groups and organizations?

Brief Literature Review
Although most project management methodologies claim to be interested in knowledge management, none offer any real guidelines or practices for gathering and maintaining knowledge throughout the project lifecycle.

Disterer (2002) argues that traditional project management methods are overly concerned with efficiency and effectiveness of project team members, which in turn makes the act of capturing knowledge a lower priority during a project (Disterer, 2002). This is compounded by the fact that the knowledge needs of future projects doesn’t lie within the context of the current project requirements therefore project managers and leaders do not focus on these efforts (Disterer, 2002).

Leseure & Brookes (2004) take this claim a step further by stating that knowledge transfer is one of the largest issues in projects today when they write “Knowledge is generated within one project and then lost. Failure to transfer this knowledge. leads to wasted activity and impaired project performance” (Leseure & Brookes, 2004, p. 103). Leseure & Brookes’ designed a research project that would attempt to benchmark knowledge management practices within projects to help provide a broader and more qualitative evidence of knowledge management methods in projects. The results of this research pointed to two main areas that could improve knowledge management in projects: collecting knowledge in projects; and managing tacit knowledge (Leseure & Brookes, 2004, p. 106). By focusing on these two areas, organizations can help to improve project knowledge management.

Kasvi, Vartiainen, & Hailikari (2003) performed research on how knowledge is managed in projects and what knowledge management capabilities are required for proper knowledge management in projects (Kasvi, Vartiainen, & Hailikari, 2003). The researchers used interviews to gather data on knowledge management capabilities and practices in various organizations. The results provided interesting feedback on organizational knowledge practices in projects and led the authors to observer that “knowledge management practices were weak and unsystematic” (Kasvi et al., 2003, p. 578) and that paper documents and interactions with colleagues were the most important sources of knowledge.

Research by Karlsen & Gottschalk (2004) addresses the factors that affect knowledge transfer in projects (Karlsen & Gottschalk, 2004). The authors used surveys to gather information from project managers and organizations on knowledge transfer in projects. The survey results showed that organizational culture plays a key role in knowledge transfer within projects and should be the main area that organizations focus when looking at knowledge transfer methodologies capabilities.

Research by Slaughter & Kirsch (2006) extends the concept of the importance of organizational design and culture on knowledge management with the introduction of Knowledge Transfer Portfolios. This research, which was conducted as a field study in the area of Software process improvements, provides some very interesting ideas on organizational design and knowledge transfer and outlines the following three items as being key for knowledge transfer within organizations: Proximity, Frequency of Interactions and Relationships (Slaughter & Kirsch, 2006).

The Framework

Blaize Horner Reich, an Associate Professor at Simon Fraser University and Visiting Associate at Templeton College, Oxford University has developed a framework for knowledge management within IT Projects which seems promising. This framework, published in the Project Management Institutes’s Project Management Journal in an article titled “Managing Knowledge and Learning in IT Projects: A Conceptual Framework and Guidelines for Practice“, proposes a three level model that addresses the following topics:

• Describes what “knowledge management in IT projects” is
• Provides a typology of critical IT project knowledge
• Identifies the top ten knowledge-based risks found in IT projects. In addition, key principles for knowledge management in IT projects are provided for use in helping build strong knowledge management capabilities within IT projects.

Reich’s framework is a good place to start as it provides a model built upon sound principles and research in the IT project space.

The first ‘level’ in Reich’s framework defines IT Project knowledge management as:

Knowledge management in the context of a project is the application of principles and processes designed to make relevant knowledge available to the project team. Effective knowledge management facilitates the creation and integration of knowledge losses and fills knowledge gaps throughout the duration of the project (Reich, 2007, p. 8).

The second ‘level’ in Reich’s framework consists of a typology of IT Project knowledge. This typology contains four distinct types of knowledge: process, domain, institutional and cultural. A brief definition of these types of knowledge follows:

• Process Knowledge: knowledge that project team members have regarding the project (tasks, methodologies, timelines, structure, etc) (Chan & Rosemann, 2001; Meehan & Richardson, 2002; Reich, 2007).
• Domain Knowledge: knowledge that a project team or member has about the industry, technology, processes, current situation, business and products (Chan & Rosemann, 2001; Reich, 2007).
• Institutional Knowledge: knowledge that a project team or member has about the organization (Reich, 2007).
• Cultural Knowledge: knowledge about the organizational culture as well as cultural backgrounds of the project team members (Reich, 2007).

The third ‘level’ of Reich’s framework consists of knowledge-based risks in IT projects. The author has listed ten risks that can affect knowledge in IT projects. These risks are:

• Lessons aren’t learned
• Flawed team selection
• Changes in the project leadership team
• Lack of knowledge of project team roles
• Poor knowledge integration
• Poor knowledge transfer within projects
• Changes in project team
• Determining “who knows what” (knowledge maps)
• Project team changes between phases
• Failure to Learn

Building Upon Reich’s Framework

Using the knowledge contained within Reich’s framework, and knowledge generated during a literature review, the following seven topics must be considered as key pieces of this framework in order for it to address project knowledge management:

• Continuous Learning / Lessons Learned - Ensures that all “lessons learned” are documented and shared throughout the organization and applied in future projects.
• Organizational Design – Develops proper project teams to ensure that the necessary knowledge transfer mechanisms can be implemented per Slaughter & Kirsch’s (2006) research
• Organizational Culture – Works toward building a culture that is pre-disposed to sharing knowledge.
• Human Capital Management practices – Covers the human capital management aspects to ensure proper motivation for project teams.
• Project Selection – Covers proper project selection as well as team member selection.
• Risk Management – Covers the aspects of project risk management as well as knowledge-based risk management as described in Reich (2007).
• Knowledge Typology Management – Covers the four types of knowledge outlined in Reich (2007) including Domain, Process, Institutional and Cultural Knowledge.

There is a considerable amount of research and thought that needs to be done to further develop this framework but an initial model can be found in Figure 1. This model provides a high-level overview of the areas that must be considered when developing project knowledge management practices.

Click for Figure 1: Project Knowledge Management Model

The model is separated into three “sections” plus feedback loops. The three sections are: Project Leadership, Project Teams and Projects. Each section contains the areas of focus for that particular project entity and outlines the areas of responsibility. A description of each section as well as the feedback loops follows.

• Project Leadership – the project leadership section covers the higher level “strategic” aspects of project knowledge management and contains Organizational Design, Culture, Human Capital Management Practices, Project Selection and Management, Risk Management and Knowledge Management.
• Project Teams – the project teams section covers the individualistic aspects of project knowledge management and contains the knowledge types (Domain, Process, Institutional and Cultural) as well as project management methods and processes.
• Projects – the projects section contains the more “tactical” aspects of project knowledge management and includes Knowledge Transfer, Lessons Learned and Continuous Interaction.
• Feedback Loops – In addition to the three sections, the model contains feedback loops that are used to ensure that continuous feedback is provided from each layer of the project knowledge management model. For example, project teams will continuously communicate with each other throughout projects regardless of which projects they are working on. Project Leadership will always be “kept in the loop” on all projects.

This framework provides an easy to recognize area of responsibility for the seven key topics that must be considered to ensure proper knowledge management in projects. As an example, let’s consider Slaughter & Kirsch’s (2006) research on Knowledge Transfer Portfolios. One of the key outputs of that research was to show that organizational design plays a key role in knowledge transfer. Using the model shown in figure 1, it is easy to see that organizational design lies solely on the shoulders of the organization’s leadership to consider.

There is still a considerable amount of research that needs to be completed in order to create supporting data to support this framework. Although not complete, the model does show areas in which organizations can begin to consider making changes to improve project knowledge management.

Conclusion
The extent of knowledge management in most project management methodologies begins and ends with the “lessons learned” document that is created after the completion of a project. This document is a good exercise, but doesn’t do much to manage knowledge during the project or ensure that knowledge is transferred between project members because project members must know to read the document to receive any value from it.

It is widely reported that project failure rates are still very high (Ahn, Joo, Cho, & Park, 2005; Owen, Burstein, & Mitchell, 2004; Pawlowski & Robey, 2004; Reich, 2007; Scarbrough, Bresnen, Edelman, Laurent, & et al., 2004). Industry research shows fifty to sixty percent of all projects are considered failures (IT-Cortex, 2007). While most research blames these failures on poor project management and/or lack of executive sponsorship (Reich, 2007), the fact that there is very little knowledge transfer and sharing between project teams has to play a key role in allowing these failures to occur.

By building a framework that can be used to help improve knowledge transfer within project teams, it is hoped that the failure rate due to knowledge-based issues will drop significantly. This framework, which still is the early development stages, should help organizations understand the underlying requirements for project knowledge management, provide best practices for knowledge management in projects and provide a way to build a corporate culture that is focused on sharing knowledge.

References

• Ahn, H. J., Joo, L. H., Cho, K., & Park, S. J. (2005). Utilizing knowledge context in virtual collaborative work. Decision Support Systems, 39(4), 563.
• Chan, R., & Rosemann, M. (2001). Managing knowledge in enterprise systems. Proceedings of the Americas Conference of Information Systems.
• Disterer, G. (2002). Management of project knowledge and experiences. Journal of Knowledge Management, 6(5), 512.
• IT-Cortex. (2007). Statistics over IT Failure Rate. Retrieved 3 May 2008, from http://www.it-cortex.com/Stat_Failure_Rate.htm
• Karlsen, J. T., & Gottschalk, P. (2004). Factors Affecting Knowledge Transfer in IT Projects. Engineering Management Journal, 16(1), 3.
• Kasvi, J. J. J., Vartiainen, M., & Hailikari, M. (2003). Managing knowledge and knowledge competences in projects and project organisations. International Journal of Project Management, 21(8), 571.
• Leseure, M. J., & Brookes, N. J. (2004). Knowledge management benchmarks for project management. Journal of Knowledge Management, 8(1), 103.
• Lytras, M. D., & Pouloudi, A. (2003). Project management as a knowledge management primer: The learning infrastructure in knowledge-intensive organizations: Projects as knowledge transformations and beyond. The Learning Organization, 10(4/5), 237.
• Meehan, B., & Richardson, I. (2002). Identification of Software Process Knowledge Management. Software Process: Improvement and Practice, 7(2), 47-55.
• Mitchell, V. L. (2006). Knowledge Integration and Information Technology Project Performance. MIS Quarterly, 30(4), 919.
• Owen, J., Burstein, F., & Mitchell, S. (2004). Knowledge Reuse and Transfer in a Project Management Environment. Journal of Information Technology Cases and Applications, 6(4), 21.
• Pawlowski, S. D., & Robey, D. (2004). Bridging User Organizations: Knowledge Brokering and the Work of Information Technology Professionals1. MIS Quarterly, 28(4), 645.
• Reich, B. H. (2007). Managing Knowledge and Learning in It Projects: A Conceptual Framework and Guidelines for Practice. Project Management Journal, 38(2), 5.
• Rice, M. P., Oconnor, G. C., & Pierantozzi, R. (2008). Implementing a Learning Plan to Counter Project Uncertainty. MIT Sloan Management Review, 49(2), 54.
• Santhanam, R., Seligman, L., & Kang, D. (2007). Postimplementation Knowledge Transfers to Users and Information Technology Professionals. Journal of Management Information Systems, 24(1), 171-199.
• Scarbrough, H., Bresnen, M., Edelman, L. F., Laurent, S., & et al. (2004). The Processes of Project-based Learning: An Exploratory Study. Management Learning, 35(4), 491.
• Slaughter, S. A., & Kirsch, L. J. (2006). The Effectiveness of Knowledge Transfer Portfolios in Software Process Improvement: A Field Study. Information Systems Research, 17(3), 301.

The article reviewed is:

• Slaughter, S. A., & Kirsch, L. J. (2006). The Effectiveness of Knowledge Transfer Portfolios in Software Process Improvement: A Field Study. Information Systems Research, 17(3), 301.

It’s an interesting article with some interesting results but I’m going to make you watch/listen to my presentation to hear more about it

This is my first presentation using PowerPoint and recorded narration and I’m anxious to hear some feedback. Due to the assignment, the presentation is about 30 minutes long and is probably very boring if you aren’t interested in Knowledge Transfer. Even if you are interested in KM, it may be boring too!

Please drop me a message or leave me a comment about the presentation and/or ideas for how I could improve it.

Presentation with Narration:
http://ericbrownmedia.com/infs834/articlereview/start.html
*The presentation was converted from PowerPoint into Flash using a product called Pointecast.

PowerPoint Presentation without Narration:
http://ericbrownmedia.com/infs834/ArticleReview-slides.ppt

To read the entire article, download the PDF titled “Information Technology Human Capital as Competitive Advantage“.

This paper provides a brief review of the literature within the space of information technology and business alignment, and more specifically, the areas of creating competitive advantage by managing human capital to create a sustainable advantage in the marketplace.

In today’s ever-changing world, organizations must learn to evolve, adapt and continuously rethink their strategic objectives and operational abilities. As part of this strategic planning process, organizations have historically looked at two aspects; strategy (how they will go to market, what they will sell, etc) and execution (how to implement the strategy, how to do business, etc). The seminal research on strategy and competitive advantage (Andrews, 1986; Porter, 1998a, 1998b) historically overlooked two of the most important aspects of any strategy; technology and people.

In the 1990′s, researchers and practitioners began looking at merging technology into the strategic planning process and how the alignment of business strategy with information technology can help to create a competitive advantage (Henderson & Venkatraman, 1993). These researchers had brought technology into the strategic planning process, and in some respects they considered the human resources of the organization, but they still overlooked the people as being a valuable piece of capital that could be used to create competitive advantage.

This oversight is most visible within the information technology (IT) groups. Even though many organizations and researches stressed the need for IT and business alignment, they still seemed to overlook the human capital aspect while aligning IT and business strategy.

These oversights have led to the current environment of overworked, disengaged and misaligned IT personnel and IT groups. The “turnover culture” that has arisen within the IT industry provides some evidence of the unhappiness and/or discontent that most IT personnel have (Moore & Burke, 2002).

Recent research has provided a path to the solution of the problem of creating sustainable alignment between IT and business strategy. These solutions involve not only aligning IT and strategy but also implementing human capital management practices to ensure that people are considered as much of a resource for creating competitive advantage as any other asset within the organization (Hu & Huang, 2006; Robert, Agarwal, & Ferratt, 2000).

This paper provides a review of existing literature related to the strategic alignment of business and information technology and human capital management practices. The first section, titled “Alignment of IT with Business Strategy” provides a review of existing business and IT alignment research. The second section, titled “Human Capital Management, IT & Business Alignment” provides an overview of existing research into human capital management practices within the IT space.

The third section, titled “Human Capital as Competitive Advantage” outlines the use human capital as a means to gain competitive advantage in the marketplace. Lastly, the fourth and final section titled “Future Research and Conclusions,” outlines areas that may provide avenues of further research and concludes the paper.

To read the entire paper, download the PDF titled “Information Technology Human Capital as Competitive Advantage“.

Further Research and Conclusion

Further research into this area can follow Ferratt et al.’s (2005) study of the effects of human resource management on information technology (IT) employee turnover (Ferratt et al., 2005) and Joseph et al.’s (2007) suggestion that adopting a human capital management approach to managing IS employees may increase employee engagement and reduce turnover and job dissatisfaction (Joseph et al., 2007).

Another area of further research that could be considered is Huang and Hu’s (2007) approach of combining human capital management along with a business-IT alignment model by using a balanced scorecard system to implement and measure alignment. This balanced scorecard approach seems reasonable but very little quantitative data exists to measure the success or failure of this approach (Huang & Hu, 2007). Further research into the use of balanced scorecards to align IT, business and human capital management practices could be accomplished by collecting quantitative data in multiple organizations to provide more insight into the success and/or failure of this approach.

Yet another avenue for further research is within the area of validation of alignment of IT system requirements with business strategy (Bleistein, Cox, & Verner, 2005). Bleisten et al.’s research provides a framework for measuring and ensuring that all IT system requirements are in alignment with business goals. This research is interesting but as yet unproven.

Lastly, research into furthering the application of the resource based view of firms and the creation of resource diversity and resource immobility within organizations seems to be a fairly wide open area. In many organizations today, outsourcing work has become the norm as has hiring contractors instead of full-time employees. Many research questions arise from this. A few examples are:

• How can an organization create resource diversity and/or resource immobility when they are drawing from the same talent pool of outsourcers and independent contractors as their competitors? This is an idea that is very interesting and something worth pursuing.
• How can an organization segregate IT projects so that non-strategic projects (is there such as thing?) are managed with non-strategic assets and resources while strategic IT projects are managed with strategic assets and resources.

There is still considerable research to be done to better understand how to create sustainable advantage using technology and people. The areas of information systems, strategic human resource management and organizational behavior can provide models to help create sustainable advantage and value for organizations.

In order to truly create sustainable competitive advantage, an organization must have the right strategy, technology and people in place. In today’s world, it isn’t enough to have only one or two of these; an organization must obtain and maintain the mix of the right strategy, the right technology and the right people.

As a follow up to my previous post titled Competitive Advantage – The Human Capital Approach, I wanted to take a second to talk a little bit about the Resource Based View of the firm that I mentioned in the previous post.  Before I continue, if you are interested in this topic, definitely take a look at the book titled Managing Knowledge for Sustained Competitive Advantage: Designing Strategies for Effective Human Resource Management (affiliate link).

Most organizations don’t place a high enough focus on human capital management as a component of competitive advantage. In order for an organization to be successful in any market, they must create value for their clients. This value can be created using a new strategy, new technology or some other ‘gimmick’ but in order to sustain this value (and the competitive advantage it brings), organizations must develop and maintain an engaged, knowledgeable and creative workforce (Afiouni, 2007).

To create a workforce that provides sustainable competitive advantage and value creation, an organization must create an environment that allows their human capital to grow, much like money sitting in an interest bearing account does. This growth, expressed within people as increased knowledge, increased motivation, increased engagement, etc can be used to create competitive advantage that would be very difficult for competitors to imitate (Afiouni, 2007; Agarwal & Ferratt, 2001; Luftman & Kempaiah, 2007).

Out of the many theories of organizational behavior, one aligns itself well with the human capital view of people within an organization. This theory, called the Resource Based View (RBV), suggests that the method in which resources are applied within a firm can create a competitive advantage (Barney, 1991; Mata, Fuerst, & Barney, 1995; Peteraf, 1993; Wernerfert, 1984). The resource based view of firms is based on two main assumptions: resource diversity and resource immobility (Barney, 1991; Mata et al., 1995). According to Mata et al. (1995), these assumptions are defined as:

• Resource diversity (also called resource heterogeneity) pertains to whether a firm owns a resource or capability that is also owned by numerous other competing firms, then that resource cannot provide a competitive advantage.
  • As an example of resource diversity, consider the following: a firm is trying to decide whether to implement a new IT product. This new product might provide a competitive advantage to the firm if no other competitors have the same functionality. If competing firms have similar functionality, then this new IT product doesn’t pass the ‘resource diversity’ test and therefore doesn’t provide a competitive advantage.
• Resource immobility refers to a resource that is difficult to obtain by competitors because the cost of developing, acquiring or using that resource is too high.
  • As an example of resource immobility, consider the following: a firm is trying to decide whether they should buy an ‘off-the-shelf’ inventory control system or have one built specifically for their needs. If they buy an off-the-shelf system, they will have no competitive advantage over others in the market because their competition can implement the same system. If they pay for a customized solution that provides specific functionality that only they implement, then they will have a competitive advantage, assuming the same functionality isn’t available in other products.

These two assumptions can be used to determine whether an organization is able to create a sustainable competitive advantage by providing a framework for determining whether a process or technology provides a real advantage over the marketplace.

The resource based view of the firm suggests that an organization’s human capital management practices can contribute significantly to sustaining competitive advantage by creating specific knowledge, skills and culture within the firm that are difficult to imitate (Afiouni, 2007; Mata et al., 1995). In other words, by creating resource diversity (increasing knowledge and skills) and/or resource immobility (a culture that people want to work in), sustainable competitive advantage can be created and maintained.

In order to create human capital resource diversity and immobility, an organization must have adequate human capital management practices, organizational processes, knowledge management practices and systems, educational opportunity (both formal and informal) and social interaction (i.e., community building) practices in place (Afiouni, 2007; Barney, 1991; Mata et al., 1995; Schafer, 2004).

NOTE: I am finishing up a White paper on the topic of Competitive Advantage & Human Capital and hope to have it available within the next week or so…check back soon.

References

• Afiouni, F. (2007). Human Resource Management and Knowledge Management: A Road Map Toward Improving Organizational Performance. Journal of American Academy of Business, Cambridge, 11(2), 124.
• Agarwal, R., & Ferratt, T. W. (2001). Crafting an HR strategy to meet the need for IT workers. Association for Computing Machinery. Communications of the ACM, 44(7), 58.
• Barney, J. B. (1991). Firm resources and sustained competitive advantage. Journal of Management, 17(1), 99-120.
• Luftman, J., & Kempaiah, R. M. (2007). The IS Organization of the Future: The IT Talent Challenge. Information Systems Management, 24(2), 129.
• Mata, F. J., Fuerst, W. L., & Barney, J. B. (1995). Information technology and sustained competitive advantage: A resource-based analysis. MIS Quarterly, 19(4), 487.
• Peteraf, M. (1993). The cornerstones of competitive advantage: A resource-based view. Strategic Management Journal, 14, 179-191.
• Schafer, M. (2004). Why Workforce Management Is Back In Style. Optimize, 67.
• Wernerfert, B. (1984). A resource based view of the firm. Strategic Management Journal, 5, 171-180.

[tags] competitive advantage, technology, resource based view of the firm, human capital, organization [/tags]

I fell into the trap of using Porter’s descriptions and other schemes of describing what it is and how to achieve it and while I was talking I saw eyes glazing over and people losing interest very quickly. I had to find another way to describe competitive advantage and quickly.

The ‘usual’ definition of competitive advantage goes something like this (from QuickMBA):

When a firm sustains profits that exceed the average for its industry, the firm is said to possess a competitive advantage over its rivals. The goal of much of business strategy is to achieve a sustainable competitive advantage.

Michael Porter identified two basic types of competitive advantage:

• cost advantage
• differentiation advantage

A competitive advantage exists when the firm is able to deliver the same benefits as competitors but at a lower cost (cost advantage), or deliver benefits that exceed those of competing products (differentiation advantage). Thus, a competitive advantage enables the firm to create superior value for its customers and superior profits for itself.

That’s an awful lot of big words that really don’t provide a lot of actionable information, especially if you are trying to understand how to use people to create sustainable competitive advantage.

I hit upon the following definition and example and these seemed to stick fairly well…these aren’t mind-blowing but they were effective. My definition:

In order to gain competitive advantage, you must do something different than your competitors in such a way as to make it difficult (hopefully impossible) to imitate.

The above definition was easier for the audience to understand but they still wanted an example to help clarify and solidify what it really means to gain competitive advantage.

After thinking for a few minutes, I came up with the following example….maybe its not the best but it definitely helped the audience get a good grasp of how to use their human capital to create sustainable competitive advantage.

Suppose you’re the owner of an American football team and you’re trying to find a way to ensure that your team wins. What do you do?

Do you…

• Spend millions on the best technology?
• Spend millions on a new stadium?
• Move your team to a new city and hope it works out?

These things might help attract a larger fan base and perhaps bring you more revenue but will they help you win? In football, the superfluous things such as technology,stadiums, etc mean nothing if the team is a losing every game. People won’t pay to see your team play if they lose. So what do you do?

You hire the best coaching staff and players that you can. Your coaching staff spends months (years?) ‘training’ and coaching these players to create a cohesive team that works well together. The coaching staff understands the strengths and weaknesses of the individual players and develops offensive and defensive schemes to take advantage of the strengths and hide the weaknesses.

Now…any other team can imitate the plays that your coaches develop. They can try to imitate the coaching style and the players…but they will fail. Unless they take your players/coaches from you, they will never be able to fully imitate your team.

Your competitors can always try to hire better people and develop better schemes but if you are doing your job as the owner of the football team you should be constantly evaluating your team to ensure that you have the right people with the right training in the right places to ensure success.

The ability to create a unique team is one of the most cost-effective ways to create real sustainable advantage in the marketplace (and in my opinion, the only way).

You can try to use technology, marketing or other approaches but unless you develop those approaches internally they will not provide sustainable advantage because your competitors can use the same approaches to match your every move.

Using the people within your organization to create advantage is one of the most overlooked methods in business today. In most organizations I’ve been a part of, the organization try to mold people to fit the organization rather than create an organizational model that fits the strengths and weaknesses of its people.

I’m planning on expanding on this topic a bit more in later posts by discussing a theory called the Resource Based View of the Firm. This theory states that by creating resource immobility and resource diversity, a firm can create sustainable competitive advantage. Check back for more.

Note: For books on organizational alignement, check out these amazon books: Books on Organizational Alignment.

Organizational alignment is the practice of aligning an organization’s strategy and culture. In other words, organizational alignment helps to ensure that ‘what gets done’ is in line with ‘how things get done’ and vice versa. For a more detailed description of organizational alignment, take a look at the article on Organizational Alignment on Vanguard Consulting’s website.

As mentioned, Organizational Alignment is the act (or art?) of aligning strategy and culture. The field of strategic planning and organizational strategy is a very well researched and fairly well covered in academia (and blogosphere) so I won’t go into the ‘strategy’ aspect but I will cover the ‘culture’ side here.What does organizational alignment have to do with project success? In my opinion, everything.

For a project to be successful, an organization must have its strategic goals aligned with its cultural values…and projects must also be aligned with the organizations’ culture and strategy. Consider the following brief example (paraphrased from Vanguard Consulting’s website):

Assume that the goal of your organization is to create a flexible service delivery model to allow you to be flexible for your clients. You’d want to make sure that the organization is aligned to meet these goals by having flexibility as a core value. You wouldn’t want to implement a ‘command and control’ structure that requires everyone to get approval before acting. The command and control structure would completely counteract the stated goal of flexibility for your clients.

The cultural aspect of organizational alignment covers ‘how things get done’ (while the strategic aspect covers ‘what gets done’). The ‘how’ covers the values, behaviors and processes for getting things done, which are things that can be addressed across the organization using various methods, such as the implementation of a Project Management Office (PMO).

Many organizations have implemented PMO’s to standardize project management methodologies, align projects with corporate strategy and act as a central point of management for all things projects. The majority of these PMO’s usually don’t address the values and behaviors across the organization. In fact, most definitions of a PMO only describe the use of a PMO to standardize project processes and align projects with strategy but values are usually overlooked.

A PMO is a good thing for most organizations but its doesn’t go far enough to ensure alignment. Standardizing project methodologies can be a good thing but standardization doesn’t go far enough to address the issues of values and behaviors. The PMO, by definition, isn’t setup to address values and behaviors but could easily be converted into an office to help align values, behaviors and process and perhaps it could be renamed the ‘Project & Alignment Office’ (PAO).

So….after all of that (and my creating the PAO!), how do we ensure project success by organizational alignment? We don’t…you can never ‘ensure success’…but we can help set projects on the path towards success by working to align the ‘how’ with the ‘what’ and the ‘why’.

Look for more to come on organizational alignment and projects…and maybe even more on the newly created PAO

[tags] Project Management, organization, Strategy, Projects, Project, Strategic Planning, culture [/tags]

Why I’m telling this story

Before I get into the back-story, I want to share the reasons for telling the story. It isn’t to talk about how I’m a great consultant or how well I work with clients. I’m sharing this to provide an insight into how technology implementations can easily be deemed a “failure” and how easy it sometimes is to turn that failure into a success story.

Technology can be used to help an organization succeed…but only if implemented in a seamless manner. The ideal implementation would be to allow all processes to work in the exact same manner after the technology is implemented as before.

Of course, there are very rarely ideal implementations, but you can minimize the effect that new technology has on an organization during planning phases.

When poorly planned, technology implementations can wreak havoc within an organization. If technology is thrown into an organization without any thought to that organization’s processes and operating model, there will be a lot of headaches for the users of that technology.

Implementing technology isn’t an easy, step-by-step process that follows a predetermined task list. There must be a considerable amount of thought put into how the technology will integrate into the organization and how that organization can best use the technology. Without this type of planning, technology implementations will fail.

The “back-story”

The project supposed to be approximately 6 months of assisting a client with implementing a new HR software package. The new package was replacing another package that they had been trying to implement and use for more than a year.

The CIO who contacted me told me that they had gone through 3 different consulting companies while attempting to implement the original product and didn’t feel as though they had been successful.

The HR software package was originally implemented by the services arm of the software vendor. The implementation plan was their “standard” plan that had been used with many organizations with varying levels of success and failure. With this implementation, the software vendor didn’t provide any customizations (perhaps they weren’t asked to) and after the implementation was complete, the end-users didn’t feel that they could use the software to do their jobs.

After the software vendor failed, my client then hired a large consulting firm to come in and “redesign the HR system and processes” to make changes to the organization to fit the HR software package. This firm proceeded to fail miserably due to not understanding their client’s needs & expectations. My client then hired another consulting company and realized quickly that they would have the same problems.

After the fiasco with the previous implementations & consultants, the CIO contacted me and asked if I’d be interested in coming in to discuss their problems and help point them in the right direction. I’m not an expert in HR software at all…but I do understand technology and the need to adapt technology to meet business objectives….and apparently, that is exactly what they needed.

The company was on the verge of buying a completely new HR software package because they were tired of dealing with the old and thought the new system would make everything OK (this is rarely the case but it happens all the time).

The CIO asked me to come in and help select the vendor and help oversee the implementation to ensure that all requirements were met. I visited with the client, took a look at the original implementation plans and started talking with some of the key stakeholders. I quickly realized that the plans for the new software package were no different than the original plans.

The plans called for the organization to change their processes to match the new software rather than the software being implemented in such a way as to accompany the processes in place. This is usually a step in the wrong direction because you are asking your organization to change very rapidly with a new software package AND new processes.

I asked the CIO for 2 weeks to study the current system and see if there was a way to salvage it. He agreed and the HR team and I set about looking for a way to save the company ~$1.5 million in software licensing and implementation fees (on top of the almost $2 million already spent on the previous package and implementations).

I spent a few days with the HR team and realized that the old software, whose implementation had been deemed a failure, would work quite well for them if a few modifications were made to allow them to follow their original processes.

After a few days of discussions and thought, the HR team and I sat down with the CIO and shared our plan with him. I told him that the original implementation was handled fairly well but the original idea for the use of the new software was flawed. Instead of forcing the software and process changes on the organization, as the original plan called for, they should have implemented the new software and customized it to fit the needs of the HR team.

A new plan was then presented that called for the already implemented HR software package to be customized to match the requirements of the HR team. This work could be performed best by the software vendor instead of farming it out to another consulting firm.

Once the customizations were complete, the vendor would then train the HR staff on using the tool and spend a few more weeks working with the team to ensure they were able to use the software in the manner in which they required.

The plan was approved by the CIO and the software vendor. The vendor, who was happy to be back in the client’s good graces, agreed to split the cost of the customizations and to provide training and additional consulting services at a discounted rate.

Conclusion

I didn’t do anything special with this client. I think the biggest value I provided was an independent set of ‘eyes’ to look at the problem and evaluate the issues.

Instead of a spending six months on a project managing a large scale implementation of a new HR system, the project ended in 4 weeks. The client saved a considerable amount of money (~$1.5 million) while regaining the use of an underutilized software package that had been considered a failure. The software vendor was able to repair a relationship with a client, which seems to be something the vendor likes as they’ve called me to help them with a few other projects.

Successful technology implementations require a little common sense, a little thinking and some consideration of how the technology will affect the business. Project planning and management tools are also require, but if the upfront thinking hasn’t been done, there project may start out on the wrong foot.

[tags] Human Resources, Technology, information technology, technology implementation, HR Software [/tags]

Over lunch recently, a good friend and very experienced project manager shared his thoughts on managing software development projects when he said:

“Software developers are so hard to manage. They never do what I tell them, never report status and are always behind schedule and over budget. Most times, they never finish the project!”

I asked him to think about what he just said and to think about whether he is ‘managing’ the project or ‘leading’ the project (a project manager should be a good leader first and foremost). I then jumped into my philosophy on managing projects using a more agile mindset and finished with the following comment:

Perhaps software developers aren’t any harder to manage than any other function…perhaps it’s the system that has been put in place to manage the developers and their activities that causes the problems.

I believe most software developers are bright and hardworking people…but they tend to be put into situations that drain all of the initiative and drive they may have. Traditional software development methods (e.g., Waterfall, etc) can and have been used quite successfully in software development projects but the large up-front requirements gathering, milestones and end-of-project testing usually result in software that is late and buggy. Of course there are successful projects that have used these traditional methods. The majority of successful projects are those that are given the appropriate level of resources, people and time and give the product development team the ability to get their job done without much hassle. Some smaller organizations have a difficult time with these traditional methods because they aren’t able to fully resource the project and aren’t able to be as flexible and responsive with these methods.

I recently encountered one of these smaller organizations who needed some help crafting a product development plan. As you will see, we were able to change the development plan from one that delivered a revenue generating product in 12 months to one that delivered a product with ~85% of the same features in 6 months at less than half the cost. Oh…and we were able to capture $3.5 million in revenue after 6 months.

Case Study – Software Development

I was approached by a small technology company to see if I would be interested in helping them re-design their product development strategy to release a product within 6 to 9 months in order to beat their competition to market and gain an edge over their competition. The product had to be something that clients found useful, valuable and worth paying money for and needed to be able to compete with the ‘big boys’ that were moving into this space. It appeared to be a pretty daunting task: take a product that was planned for release in 9 to 12 months and have it ready for market in 6 months.

The company is a small startup focused on a niche market in the technology field product uses a third-party content management server package to serve up large amounts of data from the enterprise network. They had some very good developers and had hired a consulting company to develop a product development strategy to provide for a product release to their client base in 9 to 12 months. This same consulting company had been planning on actually doing the development work as well.

After reviewing the plan, the senior leadership team and board of directors felt that 12 months was much too long to wait to enter the market. They had heard rumors that some very big names in the industry were starting to make moves that would allow them to enter this niche market within 12 to 18 months and felt that they needed to be first to market in order to gain a competitive advantage in the marketplace.

I agreed to help with the project and joined the company in a consulting role to help them create a new plan that would see a product released within the next 6 months.

The Original Product Development Plan

On my first day with the company, I walked into the office and found myself staring at a very large Gantt chart hanging on a wall. The chart had the words “Product Development Roadmap” written across the top and looked just like every other Gantt chart ever created (e.g., milestones, resources, dates, timelines, critical path outlines, etc etc). My first thought was that least they understood what they were trying to do and had a plan. My second thought was ‘what are they delivering and when are they delivering it?’

I sat down with the team and over the next few days and discussed the product development strategy. I realized that the original development plan created with zero lead time (each task could only start when the previous task finishes). My gut feeling told me that his was done to lengthen the project and create more billable hours for the previous consulting company.

Since the plan was created using zero lead times, it required that a considerable piece of the network architecture design had to be completed before database design could be completed. In addition, a significant portion of the database design had to finish before any work on the CMS Integration could be started. The User Interface design could begin during Database design and was scheduled to begin after network design in conjunction with CMS integration.

As you can see from the high-level overview of the plan shown in Table 1, it would have taken 9 months before a product was available to demo and/or beta release to a client and 12 months for a final release.

Table 1: Original Development Plan

After reviewing the plan and talking with the leadership of the company, I started looking at methods to “bring the plan in” so we could provide a demo and beta release much sooner than 9 to 12 months out.

The original resource schedule for the development provided for 1 network architect, 1 database architect, 1 content management expert, 1 user interface ‘guru’, a documentation specialist and 2 QA specialists.

The New Product Development Plan

To create the new development plan, I visited a few key clients to gather requirements for features that they felt must be in the software in order for it to be valuable to them. After these visits, I sat down with the development team and created a “Top Feature List” to help us focus the development efforts on only those features that were the most valuable to our clients.

Interestingly enough, the items that ended up being the most important items for the clients were the last things to be implemented in the original development plan. It’s amazing what a little bit of client communication will do!

Using agile software development methods, common sense and the “Top Feature List” gathered from my discussions with clients, the team and I created a development plan. The new plan would allow for the most important (i.e., valuable) features that our key clients were looking for to be ready for release as a Beta release within 3 months.

Due to the small team size and the inability to bring in additional developers, some of the tasks still needed to be performed in serial but most of the tasks were performed in parallel with each other. Table 2 shows the new product development plan.

Table 2: New Development Plan

The budget for the new plan turned out to be less than half of the original budget, although we weren’t trying to dramatically cut costs, the shortening of the development cycle by half brought us considerable cost savings.

The outcome of the plan thrilled senior executives, investors and clients. Based on the first Beta release, we were able to book about $1.5 million in revenue that may never have been booked if we had used the original plan. The initial Beta release was nothing like the final release from the original plan, but it did provide the key features that the client(s) wanted to see.

The release after the final iteration contained about 85% of the features from the original plan. Think about that…85% of the product features in half the time at less than half the cost! That’s the power of agile thinking!

After the final iteration, the product was released to quite a bit of fanfare. In addition to the revenue we had already gained with the Beta release, we were able capture another $2 million in revenue from new clients and create a great footing for the company in the marketplace. At the time that version 1.0 was released, the competition was still mired in product planning and development and their release dates seemed to be at least another 12 months out.

Conclusion

After releasing version 1.0 and capturing $3.5 million in revenue, the company was able to attract quite a bit of interest from investors and potential buyers. They ended up being gobbled up by a much larger competitor for quite a bit of money (many times multiple earnings). I’d like to say it was all my doing…but it wasn’t…I just helped them to see a new way of looking at the development process.

Using agile methods allowed us to deliver real value to our clients and to our company by create a product in half the time. We were able to deliver $3.5 million in revenue because we focused on the needs of our clients and delivered those features that they thought were the most valuable.

That is what Agile Project Management is all about. Delivering value to clients.

Note to readers:
When I use the word ‘agile’, I don’t want to imply that I am explicitly talking about iterative or agile software development methods such as eXtreme Programming (XP), Scrum, Feature Driven Development (FDD) or other types of ‘Agile’ methods. Agile methods like XP and Scrum are the framework for my project management methods for managing software development projects but I am not a strict proponent of any one method or process over another. By using the word agile, I am trying to capture the frame of mind that someone should have to be able to accurately focus and respond to clients’ needs in today’s competitive world.

Related articles by Zemanta

• Extreme Programming inventor talks about agile development
• Agile Can Work For Your Whole Company
• The Future of Software Development

Strategic Project Management (SPM) (also called Enterprise Project Management by some) has been defined by Callahan & Brooks (2004) as

“the use of the appropriate project management knowledge, skills, tools and techniques in the context of the companies goals and objectives so that the project deliverables will contribute to company value in a way that can be measured” (Callahan & Brooks, 2004, p. 23).

They further describe SPM as

“a process that takes into account a company’s way of doing business, allowing for the possibility of a significant payoff with fewer risks” (Callahan & Brooks, p. 30).

The above definitions are good, but they do not convey the most important aspect of SPM, which is the fact that senior leadership needs to be involved in selecting, defining and prioritizing which projects are undertaken within the organization. Because of this, the following definition does a much better job of accurately defining SPM:

Strategic Project Management consists of selecting, managing and measuring project outcomes to ensure optimal value for an organization. All projects undertaken by an organization must meet a set of criteria setup by the organizations’ leadership to ensure alignment with the strategic vision of the organization.

Strategic Project Management is really nothing more than picking the right projects for the organization to ensure optimal returns. This sounds very simple and straightforward, but research shows that there are many organizations that have overlooked the important fact of aligning projects with corporate strategy.

References:
Callahan, K., & Brooks, L. (2004). Essentials of strategic project management. Hoboken, NJ: John Wiley & Sons.

[tags] Strategic Project Management, Project Management, Consulting, Project Portfolio Management [/tags]