DEVELOPMENT OF A SCENARIO-BASED PROJECT MANAGEMENT SYSTEM CONSTRUCTION IN ENTERPRISES WITH THE FUNCTIONAL ORGANIZATIONAL STRUCTURE

Commonly accepted point is that functional organization structure is a poor environment for project management. The scenario repository approach is designed especially to support project management in environment with great amount of operational activity taking into account, that in such cases, project tasks have their reflection in the tasks of business-processes. Creation of a special project and operation task management tools set allows to create a new approach in change management in enterprises with functional organization structure, optimize the processes, involved in project management activities, compile the knowledge base of project and operational task management using the project task operational task mapping to reveal the bottle necks of both.


Introduction
Enterprises with functional organization structure [1], whose basic operational activities are defined by their department functions, are one of the most common types of the enterprises of the process type. The main activity of such enterprises can be described by the set of business-processes, while projects are the tools of making qualitative and quantitative changes in execution of these processes. The project management in such enterprises is not the mainstream activity, but is widely used to perform concurrent changes in the enterprise.
In the enterprises and organizations with functional organization structure, which is characterized by the strict hierarchical subordination and strictly documented employee and department functions, enterprise portfolio management is one of the most prospective tool of strategic goals achievement [4].

Preface
In this work we assume that the enterprise project management system (EPMS) is implemented in enterprises with functional organization structure. The enterprise project management system in such organizations is a set of tightly bound elements including the project management methodology, solving methods for initiation tasks, planning, analysis and monitoring of the project execution, software and instrumental tools, requirements, regulations and procedure descriptions [2,5]. EPMS includes all the organization structure elements taking part in the project management and execution as well as personal, taking part in projects.
EPMS main components:  project management system methodology and methods,  personnelthe human department, provided with a proper training in project management, which acts according to unified rules and performs problem solving according to EPMS directives (regulations, standards, orders etc.),  instrumental toolsautomatic information system, which creates common information space for all participants of the project participants and enables realization of the project management corporation methodology,  resources, human along with material and financial, which are consolidated and common through all the EPMS,  the instrumental tools represent the foundation of the EPMS structure, which defines possibilities and enterprise maturity level in project management area according to enterprise specifics. This is even more essential for functional structure enterprises. Project approach application in the functional organizations has several core specifics, which define the project management specifics in these enterprises: 1) in functional organizations there is big portion of repeating tasks, which are comparable by structure, workflow, and execution procedures in the scope of definite organizational branch (IT, marketing, sales, production etc.), but differ in different branches. This makes it possible to build templates and frameworks for such repeatable tasks and save them for future usage; 2) for structural organizational departments there is a set of standard tasks, defined in functional regulations for such departments, which are executed during their operational activity. Thus nearly any task planned in the project for such department can be mapped to the functional task of this department. The department should not execute any other tasks except those, which are defined for them by their functional regulations or by functions of employees, working in this department. This gives possibility to postulate, that any project task appointed for execution in a given departmental corresponds to the functional task, executed during the operational activity. Such approach makes it possible to calculate average task duration and store information on execution time for such tasks for future use in project planning process (creation of Gantt graph); 3) in functional organizations the separate project as well as aggregated group of projects (portfolio, program, folders etc.) concurrent state analysis is an imperative element of the project management. Task aggregation levels are defined by enterprise organization structure, financial budgets, location and other specifics of enterprise of a set of projects. This must be taken in consideration while building software tools for project management and task execution analysis.
The basic element interaction structure is shown on the Fig 1. It contains such basic elements as:  Project Scenario Repositorybasic standard scenarios workflow storage,  Standard Task Repositorybasic standard project tasks repository corresponding to operational functional tasks executed in separate departments,  Monitoring and Controlling -Project Management system, used for running and controlling projects according to their respective Gantt graphs,  Project Registryregistry of the active projects, their aggregations and archives.

Planning
Executing Closing

Standard Tasks Repository
Monitoring and Controlling -Project Management

Project Scenario Repository
Project management processes, which periodical repeating in enterprises with functional organization structure, can be stored for future use by means of Project Scenario Repository software (e.g. using tools of MS Share Point, Nintex or other), in the form of workflow warehouse. Stored workflows are specific for each enterprise.
Existing project management supporting systems, such as MS Project, Spider Project, Primavera Project Planner and others, are designed to support separate project execution. Stages like project initialization, project execution expedience assessment, work breakdown [3] into stages and tasks, task specification etc. are not included in these systems.
Implementation of project approach in the functional organizations is to be more general and holistic. According to such approach project activities are to be considered along with the operational activities. To completely describe all the project management stages one needs a set of additional tools. Partially, in the field of information technologies, these problems are solved in MOF (Microsoft Operations Framework), where project is included in the product life cycle, but in this case only the IT projects specifics, directed to IT services and products creation, are considered. In MOF the procedure of project planning and execution is not described.
According to MOF one can build structure of project activity scenarios for the functional organizations: 1) Initiation:  correspondeance to the business requirements and coordination with them,  solution reliability,  financing sources and conditions,  project management team formation and project passport composition. 2) Planning:  preliminary planning (top level view and plans for separate project parts),  whole project plannig ( problems, risks, contractors),  project plan and human resources approval.

3) Execution:
 product/service production,  solution stabilisation(according to testing and experimental run results),  product/service implementation (implementation and user instructions).

4) Closing:
 graphs and documents archiving and storing,  repositories data updating. 5) Monitoring and Controlling -Project Management for stages 2-4:  project management and risk analysis according to business demands,  task duration and structure changes (actual and planned changes and their results),  project team management (responsibilities and credentials according to project roles and tasks). Functional parts of these scenarios can greatly differ for different project types, but for projects of definite type they will contain rather uniform structure of the like components.

Standard Task Repository
Standard Task Repository is formed as a list of standard project tasks, built according to restrained list of functional department tasks [6]. It stores information for the project tasks execution parameters using the software of Standard Task Repository.
Standard task repository is meant as:  storage for functional task execution time parameters assessment made by the results of their execution in projects (average execution time, execution time deviations from average for different projects, dispersion assessments etc.),  software processing tools,  documents, specific for definite project tasks and their generation procedures. While it is postulated, that the main goal of any single project is creation of unique product or achievement of unique result [1]; in practice most of companies implement projects of the similar type, according to their direction of activity. Such projects include great number of standard tasks. One can point out the specific features of standard tasks [4]:  standard task list and their precedence is known and well defined for all projects of the same type,  tasks are repeatedly used in many projects,  tasks are executed according to responsibilities of specific departments and are connected to responsibilities of specific employees in these departments. For example, telecommunication company connects new business-subscribers using projects of same type with minor modifications. Such projects contain major amount of repeated tasks, which are standard for such a company. Thus during execution typical for a company project most of the project tasks will be standard.
Standard Task Repository has dual purpose: storing repeated tasks for future usage in building project plan and using data about task execution time from each project, where it is used to make statistical assessment of average task execution time through all projects and dispersion of time data assuming, that the time distribution is random and near to normal distribution. If the standard task is repeated frequently and without significant changes of the task environment (which is usual case for the projects in functional organizations), than the average task execution time derived from previous projects can be used to define the task duration in new project plan. The dispersion, got from statistical assessment, can be used for defining the largest possible execution time deviation (3-sigma rule). This measure can be used for defining the risk of late task finishing. More than that, using the duration less than average execution time for the task will give the raise in the late task finishing probability. The relatively big dispersion value can be the indicator IAPGOŚ 4/2013 ISSN 2083-0157 of instability in the task execution. So such tasks are to be placed out of critical path of the project not to affect the total project execution time, or, at least, means are to be taken to reduce its impact on the whole project.
The Standard Task Repository is a combination of dynamic data structure in database, holding all standard tasks with their time parameters and extra data, and software acting on these data, which implements such services as addition of the new task to the repository, selection of tasks with their parameters to be used in project planning, statistics machine updating definite task parameters on their completion in current project etc.
Many projects can be grouped in project groups according to similar subsets of standard tasks used in them and to the workflows, used to manage project lifecycles. This project classification can be used to create project framework for each class, where planning of new project will be reduced to editing start dates of the standard tasks and insertion of unique tasks if needed.
Even more, each standard task can be combined with document templates set, which is used to generate definite set of documents during task execution, thus reducing the project planning time. Such optional document template sets are saved in the standard task repository along with the corresponding standard tasks.
Due to such approach any tasks, which are included in the project plan, are mutually linked to functional tasks of specific structural departments. Thus, formally, task execution in the busines-process scope characteristic to such department, does not contradict to the project task execution, assignet to the same department. Even more, this makes it possible to reduce great amount of the project tasks to the strictly limited set of standard functional tasks of the department. In this way the standard task repository is built.
Limited number of the standard tasks in repository makes it possible to store quantatative and qualitative information on the specifics of standard task execution for definite department, giving the methodics of building probabilistic assessment of project execution duration on the preliminary stage of project planning.
The life cycle of the Standard Task Repository is shown in the Fig. 2. Given, that some current state of Standard Task Repository already exists, the cycle starts with the Planning stage. In this stage, while planning new project, manager takes standard tasks and their time parameters directly from repository and places them in project plan (Gantt), defining their start dates and links to other tasks according to the project realities.

Standard Task Repository
Planning Executing

Fig. 2. Standard Task Repository Life Cycle
If during project planning new task appears, which cannot be found in repository, than project management defines whether this task must be stored as a standard task to the repository, or marked as unique unrepeated task, which will not be used in future (such task is not stored in repository and no calculations on it are done). In any case for the new task execution time is defined by manager manually and dispersion is set to 0.
While executing the project plan manager makes adjustments to starting dates and durations of the tasks if needed. After the task is 100% finished, new data on execution time appear.
Based on the previous time data for the standard task and new actual time data from the current project the new values of average execution time and time dispersion are calculated under assumptions, that for a single task execution times are normally distributed and task environment stays unchanged. Such assumptions can be made for the enterprises with well-defined and regulated execution processes, which is true for those with hierarchical functional structure. This is done in the Recalculating stage by the Standard Task Repository software.
After gaining new values, they are stored in Standard Task Repository to be used for future project planning and analysis. This loops the whole Standard Task Repository life cycle.

Monitoring and Controlling -Project Management system
Today in most cases of project management in state and commercial enterprises and organizations project management software system used is MS Project 2007 and MS Project 2010 (Microsoft). This choice is made because of relatively small price as well as functionality broad enough for most tasks. Future development of these products in the cloud direction will make them even more attractive for implementation. Major advantages of MS Project 2007 and MS Project 2010 you can point out are:  rather simple implementation and mastering,  wide availability of learning and training courses,  gross amount of literature and tutorials for implementation and usage,  sufficient amount of qualified specialists.
Problems, which arise in MS Project implementation, are derivatives from the initial structure of this software, which was constructed to support the separate project planning and execution.
The main drawbacks of this software according to portfolio and other aggregated project groups analysis are:  impossibility to build project groups aggregated by volatile attributes,  impossibility to deliver restricted access to aggregated project groups and separate projects for definite roles,  absence of reporting mechanism for aggregated project groups,  difficulty in fulfillment analysis of the project budget (project portfolio budget),  impossibility to control critical execution dates for aggregated project groups (project portfolio or folder),  difficulties in effective execution state monitoring for aggregated project groups (project portfolio or folder). To eliminate these drawbacks the specialized software tool of Project Registry can be used.

Project Registry
Project and portfolio management in the enterprises with major amount of operational activity and functional organization structure has great importance for the enterprise strategic goals achievement. It provides a tool of fast response to the rapid environmental changes, and optimization tool for the enterprise business-processes defining the operational activity.
However, the project portfolio concept, which was brought to the project management from the investments management, is not fully defined and in different works has somewhat different meaning. In many sources it is postulated the existence of a single enterprise wide portfolio, which contains all projects directed to the best meet of enterprise goals. On the other hand in the PMBOKs 4-th edition [1] the main portfolio can contain not only projects, but partial portfolios and programs as well. Programs define the connections between several projects, directed to achieve the common goal.
In most of the practical cases portfolios can be viewed as a project aggregation tool at different levels [7]. This approach is especially useful in project management in the governmental organizations with a hierarchical functional organizational structure. Thus projects can be viewed as a main mechanism for change, innovation and development management in the organizations, where main income is got during the operational activities. Such organizations usually have functional organization structure with strict vertical command structure .
Project portfolios in this case are tightly connected with the functional organization structure. Usually projects in such organizations are executed in a single department or branch. Only the projects, executed by different branches, departments etc., can be put into the enterprise scope portfolio.
If so, then it will be logical to define the responsibility zone for each department, and to designate the project manager role to the head of corresponding department.
Usually the different project group state analysis using different properties is integral part of the enterprise strategic management. The aggregated project group state analysis only can give objective and precise enough vision of the current project execution state and results of the investment programs.
Aggregation can be made according to the structurehierarchical properties, as well as due to the financial, time, technical, technological features, work paths or action membership etc.
Project properties can be either mandatory, which are defined at MS Project Server, or such, as defined by demand of project group aggregation or comparison analysis that is analysis of summarizing, averaged or comparison of project data. The aggregation can be made using multiple properties combination (e.g. representation of the project results for the definite department projects during the first annual quarter). This task can be rather complicated because of large amount of information to be processed. Project Registry, being the Project Server's add-on operating through PSI (Project Server Interface), is used to accomplish this task. Fig. 3 shows the Main Interface Structure, where main Project registry interfaces are defined for Project Portfolio primary data and for second level of Project registry Analysis.
From the data stored in Project Server through Project Server Interface (PSI) information on the projects, project managers, execution state and updates, supplier and contractor details along with other additional data is extracted.
To link projects to enterprise organization structure Operational Structure Interface is used, thus making possible to order all projects, published at Project Server according to Operational structure. Operational Structure Interface is based either on Active Directory information, or on Human Resource System, used at the enterprise.
Project Server Interface and Operational Structure Interface are Software Interfaces, specially designed to support data exchange between systems.
The data set, acquired at the Project Portfolio primary data level, is used to build or update Project Registry database, which becomes the main data source for the Project Registry Analysis level. Project Registry Interface gives possibility to control the analysis process for a single project, as well as for project portfolios and other aggregated project groups. Project Registry Interface lets, depending on access rights, to gain access to projects an aggregated project groups. Also it makes possible to create and store new aggregated project groups for their future analysis.
To process and visualize the acquired analysis results the Project Registry Reporting Interface is used. It is specified to enable interaction with user at the stage of project results and aggregated project group status report generation. Project Registry Reporting Interface makes it possible to generate different reports in text form as well as graphic about current project state and aggregated project groups state, which are monitored and controlled in the enterprise project management system.

Fig. 3. Main Interface Structure
Main functions of the Project Registry are:  automatic project registry creationthe project registry is formed using the whole body of projects, published on the Project Server.  human resources organization structure -Project RBS field, structured according to enterprise organization structure, and implied to Project Server.  project state visualization component can represent project states without access to MS Project.  project filtrationmakes it possible to select a project group according to some project feature, which is stored in additional mandatory information field in projects, published at the Project Server.  project state analysisrepresents execution state, risks assessment and data actuality for each project.  reports by the aggregated project groupsare to be generated using appropriate templates and due to the selected aggregated groups.  project and portfolio archivingmakes it possible to restore project information and compare with the state data for the previous periods.

Summary
Enterprise project management system structure, shown above, makes it possible to create software tools set, supporting comprehensive and consistent project management activity in the enterprises with the functional organization structure. It gives possibility to create reports for all levels of the enterprise management to make optimal decisions on the project activities as well as on operational ones. Currently, the design, implementation and testing phases are going on for separate system elements as well as for their interaction in the system as a whole.