Project layer

This layer solves processes of Change and Release management and also Test management - ITIL version 3 (viz official ITIL website, ITIL on Wikipedia).

The fundamental entity of this layer is Project. Project assignment determines its impact on Configuration items basis - which items will be added, which modified and which removed. This is important also for future assessment of project scope fullfilment and making sure that all intended activities were finished. (It is e.g. important that project that is replacing an old application by a new one was closed only after the old application had been removed, in order that on the contrary complexity of the application portfolio and cost of its maintenance do not rise, because part of the organization processes still use the original application.)

Task is a lower, more detailed level entity. Each task belongs to a certain project and has a certain Status. Task relates to certain Configuration items. Task can depend on another task, project may depend on another project. Based on task Service request for a service partner may be created.

Particular changes in the configuration items basis are stored in the entity Change. The change may refer to a task, problem or incident and also configuration items, that are affected b the change.

Release management is supported by entities Change request, Release and Configuration items in change request. The Change request is realized within a certain project and is released within a certain Release. Configuration items in the change request set which configuration items will be deployed and by whom.

Entity Work schedule is used for planning particular actions. Each planned action is determined by the start and end time, sets which configuration items will be aftected and within which project it is performed. It may refer also to a certain Release.

Another area is Test management.

Each project is split in Project phases, in which UAT (User Acceptance Tests) are defined and which shall meet certain Requests. There are Test scenarios defined for particular requests. Each test scenario contains apart from test description also which applications are involved and what is the expected test result. Each scenario may be worked out into detailed Test scenario steps. Particular test are then realized with particular values entered within the course of the test. These are recorded in the class Test case. Who will perform which test case within which UAT is defined in the class Test case for UAT. Defects can occur within each performed test. Each reported defect relates to a particular test. There is organization structure defined over the class Defect, which enables management of access rights on the level of particular records. This enables sharing register of all the errors with various partners developing applications, when partners can see only errors reported to them. (Information about error solving both by internal organization sources and by external partners can be centralized and partners can keep records about work progress directly in the customer database. Ordinary practice when particular projects solve error registering separately with particular partners and that even within a single project, if more partners are involved, falls back. By this Project managers and Test managers get  a complete overview of the course of testing, that often represents a complex activity (in terms of organization) which has a big potential impact on project timing.)

Configuration database (CMDB) and process Configuration management are introduced also in the ObjectGears website.