Customer Types

]project-open[ is capable of serving diverse customers in many different business sectors.  In order to provide this capability, ]project-open[ includes a number of mechanisms to "configure" (adapt without changing the source code) the application for the specific customer.  This page lists some of the most pronounced variation of ]project-open[ that have been the most frequent in our customer base. 

Overview

  Project Management Office (PMO)

Formal PM in larger Organizations
Embedded

"Isolated PM" on Department Level
in large Organizations
Projectized Organization /
Agency Type 
PM in IT Service Organizations
Industrial / Workshop
Other
 INDUSTRIES
  • Service Industries
    (Insurance Companies, Banks)
  •  Service Industries
    (Insurance Companies, Banks)
  • Consulting
  • Marketing
  • WebDevelopment / SW Development
  • Translation
  •  IT Services
  • Mechanical engineering
  • Construction
  • Governmental Institutions
  • NGO’s
  TYPES/CATEGORIZATION
  • Supportive PMO
  • Controlling PMO
  • Directive PMO
 
  •  Traditional / Progressive
  •  Established / Start-Up
  •   Department / Separate Company
  • Manufacturing Industrie
  • Industry Services

 
 CHARACTERISTICS
  • Highly controlled Environment
  • Formalized / Standardized Processes
  • Conflicts due to Matrix Organization

  • Moderate Project Risk
  • Dynamic Structures
  • High Volume
  • High Risk
  • Integration of External Providers
  • Few hierarchy levels
  • Informal communication
  • Users are technically focused
  • High percentage of Subject Matter Experts


  • Project Planning
  • Ressource Utilization
  • Timesheet Management
  • Financial Controlling
 
 FOCUS
  • Transparency
  • Resource Optimization  
  • Timesheet Management
  • Reporting
  • Strategic Alignment
  • Risk Management
  • PM Methodologies
  • Transparency
  • Timesheet Management
  • Timesheet Management
  • Profit & Loss
  • Communication & Collaboration
  • Expense Management
  • Invoicing
  • Process Support
  • Professional Service Automatization

  • Timesheet Management
  • Integrated Helpdesk/Ticketmanagement
  • Interfaces to ITSM
  • Process Support
  • Knowledge Management
  • Invoicing
   
  

  • [Small vs. Big]
  • [Horizontal Project Management vs. ITSM vs. Translation]
  • [Employee Trust and Security Authorization]
  • [Coherence vs. Incoherence]
  • [Department vs. Company vs. Group]
  • [Country Specific Differences]

 

Small vs. Big

]project-open[ can serve organizations from 3 to 3.000 "Employees".  Employees is a broad term, since we have to include all freelancers, contributing customers, and infrequent or one time users.  Clearly, larger organizations need to formalize processes a lot more then their smaller counterparts - functionality that is essential for large customers tends to be perceived as unnecessary overhead by smaller ones.  Individual customer needs should determine the final look of ]project-open[, there is no set out-of-the-box pre-made installation for any industry sector or company size.

 

Horizontal Project Management vs. ITSM vs. Translation

]project-open[ can serve customers in different business sectors:

 

  • Horizontal PM and Professional Service Automation (PSA):
    Consulting companies, advertising agencies, marketing departments, R&D departments, engineering companies, law companies and many other business sectors basically require generic "horizontal" project management to run their companies.  In addition, these companies need relatively generic financial and human resources management.  This is the "base" configuration of ]project-open[.

  • IT Services Management:
    Organizations running IT systems require special add-on packages to automate the interaction with hardware and software.

  • Translation Organizations:
    Translation agencies and internal translation departments (ITDs) require a number of add-on packages to deal with many small provider companies and to integrate with available CAT tools (computer aided translation).

 

To deal with these different business sectors, ]project-open[ includes a number of add-on packages to the "base" that can deal with the specifics of each business sector.

These specific add-on packages can extend the ]project-open[ "core" using "Plugin Portlet Components", DynFields, DynViews and Menus.  This way, they don't add additional complexity to the "core".

 

Employee Trust and Security Authorization  

Should a normal Employee be able to see the full customer list of a company?  In some companies (in particular ones with high fluctuation and a low barrier of entry) employees should only be able to see their projects and their customer contacts, while by default companies should be as permissive as possible to reduce overhead costs for authorization services and to improve knowledge flow within the company.  Basically there is no correct answer, there is only what is best for the customer, and security and trust decisions should be made on a case by case basis, after fully understanding the company and their intended use of ]project-open[. 

 

Coherence vs. Incoherence 

A member of the [ERP-SELECT] mailing list once put it like this: "An ERP system is merely a place where some people can store data and other people trust that this data are correct".  However, companies vary a great deal with respect to employees trusting each other to enter "clean" information into an ERP system.

Roll-outs in "coherent" companies are usually very difficult, because every employee wants to make sure during the evaluation period that the system will be able to capture his information well.  While the first couple weeks and the roll-out experience in general might plant early doubts and frustrations, this is only temporary and operations usually go very smooth afterward.  This is because the Users had specific expectations on what they would be using ]project-open[ to do, it just took a transitional period in order to learn how using a new system.  The contrary is the case in less coherent companies, when customers realize that either their requirements were not complete, or that they only now fully understand their automation processes, but only after a quick and painless roll-out of a product that has done little to add value to their company.  Not to say that an easy or hard roll-out experience will be indicative of future success with ]project-open[, but be aware of these concerns and recognize them when they happen.

]project-open[ is designed to deal with these differences by means of its default "flexibility" i.e., ]project-open[ in its default configuration provides users with relatively little restrictions on how to enter data and how to structure data.  This default configuration is useful for smaller companies and for a quick roll-out at larger organizations. However, large "coherent" companies will typically ask for additional rules (data checks, workflows) after the initial roll-out and "incoherent" companies will need special reports in order to deal with partially inconsistent data.

Department vs. Company vs. Group

This describes the larger context in which ]project-open[ customer organizations work:

 

  • Department:
    The organization is part of a larger company.  For example, the IT department of the R&D department of a large company might choose ]project-open[ to deal with project and service management, while the rest of the company uses a SAP R/3 systems for managing production, supply chain etc.
    In such a context, all CRM, HR, provider management and finance actions are located at the central (SAP) systems and ]project-open[ would then have to import this data and follow the rules defined in the central systems.

  • Independent Company:
    A (more or less) independent service company will use ]project-open[ to manage most operational processes, except for accounting which is usually handled by a separate accounting package. In this configuration, ]project-open[ will probably serve as the "master" of all operational data, including project billing and finance in general.  This data is then exported to the accounting package, so that the accountants can elaborate on the company's balance and income statements every quarter.

  • Group:
    As a member of a group, the ]project-open[ customer will run more or less like an independent company (see above).  However, special access rules may apply for members of neighboring group companies, particularly of neighbor companies that also run ]proje ct-open[.

In order to deal with this type of variability, the most important tool is the capability to disable portlets and menus in ]project-open[, plus there are several add-on packages (auditibility extension, cost-center permissions, SAP-import, ...) in order to reamain conscincious of a business's "autonomy".

 

Country Specific Differences

Most obviously, language is one the most important difference between countries.  Please see the localization section for details.  Other differences include:

 

  • Different requirements and habits of financial management
  • Varying levels of trust vs. distrust and coherence vs. incoherence specific to each country
  • Different ways to present invoices, quotes and purchase orders to business partners.
  • Legal requirements governing corporate disclosures, finance, and accounting


]proejct-open[ deals with languages using its localization subsystem and is developed using American English as the base language.  Trust and coherence are handled as detailed above, and the presentation of invoices and quotes can be configured using "templates" in the financial system.

 

  Contact Us
  Project Open Business Solutions S.L.

Calle Aprestadora 19, 12o-2a

08902 Hospitalet de Llobregat (Barcelona)

Spain

 Tel Europe: +34 609 953 751
 Tel US: +1 415 200 2465
 Mail: info@project-open.com