Project Management Institute

Knowledge-enhanced project management at an Italian CT services company

Francesco Bellifemine, Exprivia SpA

Abstract

This paper aims to present the innovative project management approach at a large Italian ICT services organization. Such an approach heavily leverages on knowledge in order to implement an experience factory, mainly devoted to gathering, improving, and disseminating project management knowledge, not just lessons learned, at all levels of the organization. All project management aspects, such as processes, best practices, risks, project profiles, metrics, issues, politics, work breakdown structures (WBS), software products, lessons learned, quality criteria, decision criteria, and the sort, are properly organized in a knowledge base, in order to allow effective online support and maximum reuse of knowledge and artifacts. The experience factory infrastructure integrates the knowledge base with a project management environment supporting all project roles. Role-specific workbenches are available to support and guide the users in the execution of the activities related to their roles. This is accomplished by means of workflows and other specific knowledge derived by the knowledge base. The approach is under the control of the project support office that, among other things, looks after its basic infrastructure and the proper knowledge organization and exploitation. As experience is gathered and new knowledge is available, a specific role in the project office, e.g., the knowledge engineer, improves the knowledge base as appropriate.

Introduction

Project Management Challenges

In an economy where the only certainty is uncertainty, one sure source of lasting competitive advantage is knowledge. For all companies, current and upcoming business realities are causing managing knowledge to rise as a critical business priority, including:

  • A huge knowledge gap created by an aging workforce ready to retire;
  • The importance of collaboration, social networking, and new modes of communication;
  • The complexities of operating in a global marketplace with worldwide customers, vendors, and employees; and
  • Increased competition and the need to leverage knowledge as a key differentiator.

Innovation and ICT are also becoming central in order to address fast and expensive new market requirements. Therefore, as reported in the last June 2009 issue of PMI Today (Project Management Institute, 2009), huge investments are being planned in the next decade in order to cope with all the required innovation changes and their support by ICT technology and products. A very impressive number of projects have already started or will start in the upcoming years and an important part of them will be ICT projects, which, as shown in Exhibit 1, are still very critical. The table shows the survey data since 1994 of the Chaos Report by the Standish Group (Dominguez, 2009). Despite the improvement in performance in the last 15 years, the 2009 survey shows that there are only 32% of successful ICT projects, still.

Standish Group Chaos Reports for ICT Project Performance in the Last 15 Years

Exhibit 1. Standish Group Chaos Reports for ICT Project Performance in the Last 15 Years

Quality Improvement Paradigm

In order to improve software project quality, in late 1980s professor Victor Basili (1989) proposed a new software development paradigm named Quality Improvement Paradigm (QIP) and in the following years, he guided some important experiments and implementations of software Experience Factories in large organizations such as NASA, the University of Maryland, and Computer Sciences Corporation (CSC). Exhibit 2 shows the paradigm. A continuous improvement can be achieved by means of a corporate learning cycle, which gathers knowledge and experience from inner project learning cycles. Therefore, after a first corporate cycle aimed to set basic goals, processes, methods, techniques, and tools, each new project supplied new knowledge for packaging and storing experience to be both reused and improve processes, methods, techniques, and tools.

Quality Improvement Paradigm

Exhibit 2. Quality Improvement Paradigm

This paradigm is very consistent with both the Software Engineering Institute’s Capability Maturity Model (CMM) and Kerzner’s Project Management Maturity Model. However, it is more specific in the way knowledge and experience is to be handled inside and outside projects. As for A Guide to the Project Management Body of Knowledge (PMBOK® Guide) (Fourth Edition) (Project Management Institute [PMI], 2008), this paradigm is based on the Shewart-Deming Plan/Do/Check/Act quality approach (Deming, 1986). Furthermore, the QIP stresses the concept of lessons learned to the level of experience packages. In consideration of this, we believe it actually enhances the quality approach to become Plan/Do/Check/Learn/Act, as shown in Exhibit 3.

Knowledge-Enhanced Shewart-Deming Quality Cycle

Exhibit 3. Knowledge-Enhanced Shewart-Deming Quality Cycle

Despite the fact that Basili (1989) introduced the QIP for software projects, the paradigm is valid for all kind of projects.

Knowledge, Experience and the Experience Factory

Knowledge can be defined as “familiarity, awareness, or understanding gained through experience, study, or analysis” (Kontio, 2005, p. 5). To be performed, every human activity requires gathering and using knowledge. Civilization has spread because of the continuous acquisition, communication, and consolidation of knowledge from one generation to the next. Experience is knowledge coming from either active participation to events and activities; or previous experience. The experience factory (Basili, Caldera, & Tombach, 1994, p. 9) is a logical and/or physical organization that supports project developments by analyzing and synthesizing all kinds of experience, acting as a repository for such experience, and supplying that experience to various projects on demand. It packages experience by building informal, formal, or schematized, and productized models and measures of various software processes, products, and other forms of knowledge via people, documents, and automated support. It is characterized by the following principle:

  • Separation of responsibilities between product development and improvement;
  • Systematic capture and accumulation of knowledge;
  • Continuous learning from experience through measurement, data collection, analysis and synthesis; and
  • Systematic reuse of knowledge through packaging and dissemination.

Exhibit 4 shows how an experience factory is organized. The project organization, while developing the project products, interacts continuously with the experience factory. First, planning a project uses past experience and can be more accurate and effective by means of available and tailorable knowledge. Experience factory project support activities and tools are used to facilitate the discovery of such knowledge. Then, during project execution, the knowledge base (KB) supplies reusable knowledge and artifacts for the project implementation. At the end of a project, an accurate analysis of the project is accomplished in order to improve the experience base (EB) as needed. A learning phase produces new or updated experience packages by means of generalization and tailoring of new knowledge and artifacts. Finally, a change phase produces formalization and dissemination of new and updated knowledge.

Experience Factory and Related Functions

Exhibit 4. Experience Factory and Related Functions

This model has been applied to several large implementations in the past. Besides the ones reported by Basili et al.(1994, pp. 14–16), we know of important implementation in ABB, Boeing, Daimler Chrysler, HP, Nokia, and Philips. Indeed, adding productive value by means of knowledge transfer has been under investigation for a while both in industrial and academic contexts, and there has often been convergence between these efforts. Some companies, such as HP and Philips, have even established internal organizations to cope with knowledge acquisition and transfer. Some academic efforts have also been devoted to investigating knowledge acquisition and transfer by means of internet (Ardimento, 2008). From published information, we know that the existing KBs may have either a semantically limited scope or, in some cases, too much general knowledge to be usable. However, private companies tend not to publish specific information, and we have been able to learn some minimal details only for Daimler-Benz’s KB (Schneider & Schwinn, 2001), but it has not been sufficient in order to fully understand their approach.

The Case of a Large Italian ICT Services Organization

Experience-Based Project Management at Exprivia

Exprivia is a large Italian ICT services organization that is basing a fair deal of their revenues on project management contracts and project management services. In order to cope this business, since 2005, Exprivia has established a project support office (Casanova, 2006) with a goal of both improving internal project management culture and set-up methods and tools to execute and control projects. This effort was accompanied by a large, multi-annual R&D investment, the CNOS project, to set-up a knowledge factory that could create the conditions for an effective capture and reuse of production knowledge, not just software artifacts. All together, the aim was to:

  • introduce, formalize, and continually improve project management processes at all levels of the organization;
  • support project initiatives by means of a collaborative and integrated infrastructure aligned to modern technology and standards such as Service Oriented Architecture (SOA), Web 2.0 and open source products; and
  • organize, manage, integrate and make available a production KB in order to enhance the implementation of projects by means of a proper EF.

The CNOS Experience Factory

Adoption

Introducing the CNOS infrastructure has been primarily a big cultural shift that is still under development. Much attention was devoted to the following:

  • the strategy for introducing the new infrastructure, its KB, and the related knowledge-based project management and software development processes;
  • the organizational requirements, including needed professional skills and roles; and
  • the supporting environment, made of both technology/tools and people.

However, this is a slow process that has been addressed incrementally and requires some more time to settle.

First, the organizational and procedural aspects were evolved towards the new procedural requirements, thus fostering the role of the project support office (PSO) and extending Exprivia’s project management processes, which are based on the PMBOK® Guide—Fourth Edition, to accommodate this new approach. Therefore, an enhanced project life cycle was introduced and supported by new roles/tasks and new technology/tools. For the sake of gradually introducing the CNOS platform, initially only some non-critical projects have gone through this new life cycle. More projects have been added later, as needed and available. Nowadays the consolidation process is not finished yet and more evolution is planned for the near future.

Architecture

The CNOS architecture has been designed with a goal of making the following available:

  • a collaboration space among both the working groups and the members of a working group, through the sharing of knowledge at all levels of granularity;
  • a knowledge repository to (a) abstract, improve and store experience derived from previous projects; and (b) disseminate it to the working groups; and
  • a process-driven workplace where project team members can exchange and share knowledge, documents, and other project artifacts.

The whole EF infrastructure is made of a project organization (PO), where the projects are organized, executed, and monitored; and a knowledge organization (KO), where the knowledge is extracted, characterized, packaged, and disseminated. These organizations are integrated by means of a knowledge portal, i.e., a role-based collaboration portal that also provides the most popular Web 2.0 collaboration features (Happ, Henkel, Röhrborn, & Wünsche, 2006): chat, wikis, forums, and personal blogs. The portal can also provide feedback for each downloaded new knowledge package in such a way that the whole community can be informed on the utility of such package.

The whole infrastructure is based on open source products that have been configured/adapted in order to implement the portal, the documentation management system, the project management system, and the workflow engine.

Role-Based Collaboration Portal

The portal is the environment where Exprivia’s personnel can log in to collaborate on projects as part of either the PO or the KO. The collaboration paradigms used are:

  • chat devoted only to project groups and general chat rooms to meet all the other colleagues;
  • availability of wiki for each new project to collaboratively create the documentation;
  • project dedicated forum and general purpose forum;
  • personal blogs where you can write articles and news on any subject without restriction on content;
  • document management and file sharing area;
  • a feedback area dedicated to information and feedback associated to the knowledge packages used by community; and
  • tag cloud available for each of previous areas: chats, wikis, forums, etc. It is used to locate quickly hot topics of discussion.

For each role in both PO and KO organizations, e.g., project officer, project manager, team member, knowledge engineer, a sub-portal is available, which is specifically defined for such a role, thereby creating more specialized communities where tacit knowledge is more exploitable. The system is very flexible in that both roles and related sub-portals can be defined on the base of the current operational needs. Roles are also supported by specific workbenches that present the operator with all the operational or supportive tools needed to carryout the role. In case of project team members, the workbench includes the list of assigned activities and once accepted an activity; it is often supported by related activity workflows, as defined by the basic project methodology. Each workbench allows also for knowledge browsing and searching in the KB.

Project Organization

The project organization (PO) is based on people, HW/SW infrastructures, and processes integrated and organized in order to plan, execute, monitor/control and close project portfolios and related projects. This environment promotes a faster and more reliable project execution through the reuse of process definitions (workflows), product artifacts, and other packaged knowledge available in the KB, which are specifically disseminated within the areas of work in the form of tools, deliverables, documents, processes/performed procedures, statistics, and so on. Package identification takes place through the initial characterization and identification of the project and it is then compared among the most suitable projects executed in the past and similar to the current one. The PO engaged the services of three main modules: project characterization (CHR), which is used to initialize a new project and determine its characteristics; workstation, which is the software environment where project assignments are carried-out; and, finally, the workflow management system (WFMS) which, if requested, provides step-by-step support for the execution of assigned activities.

Knowledge Organization

The knowledge organization (KO) is the set of people, HW/SW infrastructures, and processes integrated and organized in order to package and disseminate the experience deriving from the PO. The KO uses knowledge packages that are the minimum reusable information within a project. Examples of knowledge packages handled by CNOS are:

  • process packages capturing the business process knowledge through specific workflow definitions;

  • document packages providing information on a given document via metadata fields. Documents can also be handled by KM, as explained in the following;

  • statistics packages containing statistical information associated with other packages: for example, estimates of activity duration; and

  • tools packages containing information on available software tools;

The KO relies on three main modules: (1) the analysis module, which is used to analyze the files in the delivered project archive, categorize and package all reusable products, or modify existing knowledge packages on the base of new experience; and review/extend the knowledge map in the KB; (2) the knowledge management module (KM), which is the “smart” subsystem that allows the user to classify and categorize knowledge by means of latent semantic analysis (LSA); and (3) the KB, which provides a structured database where all knowledge packages are stored in a hierarchical form.

Knowledge-Enhanced Project Life Cycle

As shown in the next exhibit, the project life cycle in Exprivia starts as soon as an internal order is issued with a basic mandate by the project sponsor, i.e., the sales department (business line managers or accounts), to the service line (SL), which will be responsible for the order execution. An SL will also have responsibility for other possible internal SLs coordination on the project.

Knowledge-Enhanced Project Life Cycle in Exprivia

Exhibit 5. Knowledge-Enhanced Project Life Cycle in Exprivia

Having identified the project manager, the mandated SL issues a project management service order with project requirements, constraints, and other useful project information and documentation. On the service order receipt, the project manager can start the project through the classical project management phases: project initiation, project planning, project execution, monitoring and control, and project closure.

In order to enhance the life cycle for the EF context, a few organizational and procedural modifications were needed. First, the PSO is now acknowledged by the project management service order delivery and proceeds to:

  • classify the project by complexity;
  • prepare and activate the project infrastructure and the applicable project management workflows according to one of the three project categories;
  • warn the project manager of project infrastructure availability;
  • fill the project catalogue with the new project information; and
  • monitor project execution and metrics

Each project category influences the way the project is managed, allowing for procedural simplification when the project category requires it, such as in the case of both micro and small projects.

When logging for the first time onto the project infrastructure prepared by the PSO, the project manager is guided by the relevant project management workflow, according to the project category. The level of guidance can be as punctual as required by the project manager. In case the project manager knows the workflow and the related tasks well, he or she can ask not to be supported. In addition, sequential workflow steps can be activated even when the previous steps have not been completed. It is only required that all steps be completed before phase review and validation.

The life cycle is supported by project management knowledge and workflows, which are indeed a different kind of process knowledge. Specific workflows are associated with each type of product, based on the actual context/methodology used for product development. As explained in the following, workflows are revised and adapted during the project-planning phase, with possible support by the PSO. In some cases, new workflows are to be created since no available process package is suitable. At the end of the project, any new or project adapted workflow definitions will be revised and formalized into the EF for future reuse.

Project Initiation

As soon as the project manager enters the project environment for the first time, the initiation phase is started, asking the project manager to confirm or add basic information about the project, such as type of project, business domain, project methodology, applicable quality management system, expected duration and effort, expected budgeted cost, and so forth. Many of these parameters are a sort of “fingerprint” used to characterize the project; others, such as duration and effort, are used for scheduling and monitoring purpose. The fingerprint is compared with those of other projects in the KB with a goal of selecting a number of projects with higher affinity to propose as reusability assets during the planning phase. After this, the project manager is guided through the kick-off preparation. By answering specific questions about the kick-off, CNOS is able to organize the kick-off by automatically sending invitation emails with the details of the kick-off and the relevant input documentation for such meeting. After the kick-off has been executed, CNOS is able to support the project manager in the minute’s preparation and distribution. All the documents and the knowledge gathered during this phase are automatically stored for recording and future analysis and knowledge preparation.

Project Planning

Project planning is central in the whole EF-based project management process. After asking basic information on the project, which will be used for automatic project plan document assembly, planning can be carried-out with either the support of affinity project knowledge, provided some has been identified during the project initiation phase; or any other knowledge package identified by searching the KB. First, the project work breakdown structure (WBS) needs to be produced. For a more effective reuse strategy, CNOS uses product breakdown structures (PBS), as proposed by the Office of Government Commerce’s (OGC) PRINCE2 project management methodology. Indeed, we believe that a product approach is more object oriented and therefore is more suited for reuse. For example, each product type in the KB can be associated with various workflows, depending on the methodology used and each phase in such workflows can be associated with specific roles, typical risks and percent of effort per role.

A basic PBS is proposed to the project manager depending on the project type, the process business domain, and the product methodology selected. The workflow associated to each product type in the PBS can be revised and changed according to the project requirements. The PBS or parts of it can be filled by copying the PBS of any affinity project or parts of it. Naturally, this requires adaptation. Each product in the affinity PBS is characterized with specific information, such as specifications, skills used, risks, lessons learned. By evaluating the impact on such PBS product, accurate planning is possible. Once the PBS is ready, the system is able to produce automatically a Gantt chart by adding the start date provided by the project manager for any PBS node. Each Gantt activity is derived from the product workflows and resource assignment is accomplished by associating real resources to activity roles defined in the workflow. Finally, all the information gathered during this phase, the PBS detailed definition, and the Gantt chart are automatically assembled by the system into the final project plan document. Future possible changes to any element of the project plan can be easily tracked and recorded and will be accurately considered during the learning phase of the EF (Exhibit 4).

Execution Monitoring and Control

Execution is accomplished by means of an open source project management system. The Gantt defined during the planning phase is automatically loaded onto the system, and all activities are assigned and monitored by the system. Each project resource, once logged onto the system, receives assigned activities, and after accepting an activity, it is supported by a role-specific workbench and is guided in the execution of the activity by a specific activity workflow. This also allows automatic collection of specific process metrics and an effective way to monitor and control the project. During activity execution, it is possible to search for knowledge and reuse packages in the KB. It is also possible to add annotation to any item developed, so that the analysis phase in the KO can be facilitated.

Project Closure

On project closure, a final lesson learned and project report is added in the project repository, before it is archived. The archived project repository is passed onto the PO for knowledge acquisition.

Knowledge Gathering and Reuse

All features described previously make use of the services of knowledge organization, where a specialized knowledge engineer takes care of storing experiences, characterizations, and abstracts and then distributes them to the project organization.

Lessons Learned and Conclusions

Despite a gradual approach, introducing CNOS has been a very slow process because of the difficulty of having real project to experiment. Projects—contract projects in particular—are always critical issues and therefore it is very difficult to find volunteers. Moreover, there is a completely new approach and mentality to inject. Another serious matter is that, for various reasons, in the beginning, there is hardly any experience that can be packaged in a serious way and then used. Then, the case of innovative projects poses serious limitations to this approach and any approach based on knowledge/experience reuse. Finally, there is a heavy burden, particularly at the beginning, organizing, and running the KO. However, from the data gathered so far, we can notice that productivity has practically doubled and the same improvement has been noticed for software defects and adherence to Exprivia’s quality standards. We hope to have data that are more precise by the end of the year.

References

Ardimento, P., Caivano, D., Cimitile, M., & Visaggio, G. (2008). Empirical investigation of the efficacy and efficiency of tools for transferring software engineering knowledge. Journal of Information & Knowledge Management, 7(3), 197–207.

Basili, V. R. (1989, September). Software development: A paradigm for the future. Proceedings of the 13th Annual International Computer Software & Applications Conference (COMPSAC), Orlando, FL, USA.

Basili, V. R., Caldera G., Tombach, H. D. (1994). The experience factory, encyclopedia of software engineering (pp. 469–476). New York: John Wiley & Sons, Inc.

Casanova, P. (2006, May). Is a project office suited for small/medium businesses: the case of Exprivia/[email protected] Paper presented at the PMI EMEA Global Congress, Madrid, Spain.

Deming, E. (1986). Out of the crisis. Cambridge, MA: MIT Press.

Dominguez, J. (2009). The curious case of the CHAOS report 2009. Retrieved on January 20, 2010, from www.projectsmart.co.uk/the-curious-case-of-the-chaos-report-2009.html

Happ, S., Henkel, F., Röhrborn, D., & Wünsche, A. (2006, May). Blogs, wikis, webcasts: Utilization of state-of-the-art communication instruments for project management. Paper presented at the PMI EMEA Global Congress, Madrid, Spain.

Kerzner, H. (2001) Strategic Planning for Project Management Using a Project Management Maturity Model Hoboken, NJ: John Wiley & Sons, Inc.

Kontio, J. (2005, May). Experience factory and organizational learning. Software Business Lab, Helsinki University of Technology. Retrieved on December 14, 2006. from www.sbl.tkk.fi/jkontio/papers/EF_&_OrgLearning.pdf

Project Management Institute. (2008). A guide to the project management body of knowledge (PMBOK®Guide) (4th ed.). Newtown Square, PA: Project Management Institute.

Project Management Institute. (2009, June) The growing talent gap between project manager supply and demand. PMI Today (Suppl).

Schneider, K., & Schwinn, T. (2001). Maturing experience base concepts at DaimlerChrysler. Software Process Improvement and Practice, 6(2), 85–96.

This material has been reproduced with the permission of the copyright owner. Unauthorized reproduction of this material is strictly prohibited. For permission to reproduce this material, please contact PMI or any listed author.

© 2010, Pietro Casanova & Francesco Bellifemine
Originally published as a part of 2010 PMI Global Congress Proceedings – Milan Italy

Advertisement

Advertisement

Related Content

Advertisement