User Manual

• Purpose
  • Introduction
  • Definition
• Concept
  • Introduction
  • Model
  • Layers
    • Conceptual
    • Organizational
    • Operational
  • Access
    • Organizational
    • Operational
    • Identity and Context
  • Ownership
  • Responsibility
  • Elements
    • Types
    • Users
    • Teams
    • Status
    • Classes
    • Classes' Status
    • Objects
    • Objects' Status
  • Associations
    • Users on Teams
    • Teams on Classes
    • Status on Classes
    • Classes' Status
  • Statistics
• Usage
  • Levels of Usage
  • Administration
    • Organizational Hierarchy
    • Operational Context
    • New Elements
    • Adding Associations
    • Editing Elements and Associations
    • Changing Objects' Status
    • Copy Elements
    • Moving Teams
    • Deleting Elements
    • Removing Associations
  • Normal
    • New Elements
    • Editing Elements
    • Changing Objects' Status
    • Deleting Elements
• FAQ

Purpose

Introduction

In an Organization, there are too many redundant communications, mainly the kind one relative to the reporting of the state of affairs. It's to reduce that kind of communication that this software is intended to.

Definition

The purpose of the StatusQuo may be defined as "an Instrument of Communication between the Operation and the Organization".

The communication is made trough horizontally change of status associated to objects at the operational layer, and vertically viewed at the organizational layer, where horizontally means non hierarchical, and vertically means hierarchical.

Concept

Introduction

The present software uses some concepts that are important to have in mind. In this chapter all those concepts will be explained.

Model

The model in use, is defined as COOperational model, where COO stands for:

• C - Conceptual
• O - Organizational
• O - Operational

This model allows the control of the Organizational Success degree, accordingly to its objectives, and the control of the Operational Compliance needed for that Success.

Layers

There are three layers, the Conceptual, the Organizational, and the Operational. You can access to those layers by clicking in each one on the vertical menu in the left (can't miss it).

Conceptual

This layer involves the form of working of the software, in practical terms it's this manual. Albeit its lack of protagonism in the usage of this software, this layers is fundamental, because it dictates the rules that are in the other two layers. In this way, the Conceptual layer incorporates the fundamentals associated with the software.

Organizational

This layer is where elements are associated in a hierarchical (vertical) form, this means that information in this layer is accessed accordingly to a pre-established hierarchy that is representative of the organization. The referred access kind for this layer is a read only (ro) one with exception for the ROOT Team.

Operational

This layer is where elements are only associated in a contextual (horizontal) form, this means that information in this layer is accessed accordingly to a contextual association that is representative of an operation. The referred access kind in this layer is a read and write (rw) one.

Access

There are two kinds of access, the Organizational and the Operational, where the first one is hierarchical, and the second one, contextual.

Organizational

This kind of access is defined through the element Teams and Classes, where one given team has also access to all the elements associated to the subordinated Teams and the respective associated Classes. This form of access allows the creation or changing of any element exclusively for the Team ROOT.

Operational

This kind of access is contextual, where the context is defined only by the element Classes. In this way, one Team in a given Class, has access only to the elements associated to that Class. This form of access only allows the creation or changing of Objects and its respective Objects' Status.

Identity and Context

To Access to any information in the system it's necessary that the logged user belongs to at least one Team, and that Team is associated to a Class, because accessing the system is exclusive to Teams trough Classes. Independently of being an Organizational or Operational access, there are two forms of restricting your access. One is trough Identity and other trough Context. The identity restriction is made selecting the team that you want to be identified with.

The identity restriction works slightly differently depending if the access is Organizational or Operational. For the two different layers of access we have:

• Organizational - Option to be identified as a team where the user is associated to, and to be identified as a team that is a descendant (subordinated) to any team the user is associated
• Operational - Option to be identified only as a team where the user is associated to

When a Team is selected it's called an Identified Team.

The Contextual restriction also works slightly different depending if the access is Organizational or Operational. The contextual restriction is made selecting the class that defines the context. For the two different layers of access we have:

• Organizational - Context selected as class that is associated to the Identified Team or any other Team descendant (subordinate) of the Identified Team
• Operational - Contextual option selected as Class that is associated to the Identified Team

When a Class is selected it's called a Restricted Context.

The main difference between the two levels is that in the second one (Operational), the hierarchical relationships are ignored, only the access to the Class is considered (see Operational).

IMPORTANT NOTE: The access to the system is faster with an Identified Team and a Restricted Context.

Ownership

Ownership is a concept exclusive to the element Teams. The meaning of owning an element, relatively to a Team, means a slightly different thing depending on the element considered Owned. The meaning of MY OWN for each element is the following for each level:

• Organizational - Elements associated to the identified Team and all subordinated ones
• Operational - Elements only associated to the identified Team

When a User select a list of elements as MY OWN, in fact he is selecting elements that are Owned by the Team or Teams in which he belongs to or it's identified by. To Users it's also applied the term MY SELF, that lists the logged in User. In the case of Teams, the respective Stats represents all the accessible elements for the listed Teams. For each Element it's always possible to select ALL Elements, listing all Elements that the Team or Teams have access to (see Access).

Responsibility

The notion of Responsibility is essential for the correct use and administration of the software. The responsibility it's applicable to all those elements listed trough the MY OWN tab. Like some other concepts, this one has a different meaning depending on the type of Access, meaning that we have Organizational and Operational Responsibility. So, for any Team Identified its responsibility is defined in the next manner:

• Organizational Responsibility - An Identified Team, is responsible for its and all subordinated Elements (Take care of all)
• Operational Responsibility - An Identified Team, is responsible only for its directly associated Elements (Each one by it self)

For any element listed, it's always possible to select MY OWN or ALL Elements, where the last option includes the elements out of responsibility. Elements that are out of responsibility appear in Italic!

Elements

The software defines seven types of elements, with the elements Teams and Classes central in their interaction. The first five are structural to the organization, the last two, its operational result. Elements have the following common fields with the exception of Classes' Status and Objects' Status that only have in common the ID:

• ID - Number exclusive to the element
• Name - Name given to the element
• Description - Description associated to the element

Types

The software has two types of elements, Structural and Conjectural:

• Structural - Elements that represent the structure of the Organization, where those elements are: Users, Teams, Status, Classes and Classes' Status
• Conjectural - Elements that are the result of the Operational actions, where those elements are: Objects and Objects' Status

All Associations are Structural. For the field Name/Username, all Structural Elements are limited to 15 characters, while the Conjectural ones, are limited to 20.

Users

This type of element, represents Users of the software, having the next data:

• Username - Equivalent to Name with the particularly of being used to log in
• Password - Data necessary to the log in process
• Full Name - Full name of the User
• Email - Email given by the Organization
• Phone - Phone number
• Mobile - Mobile number

Users are actors in the system trough Teams, so their Statistics are the result of the summed stats of the Teams they are in, meaning that outside a Team, a User has no stats or actions associated.

Teams

Teams are elements that besides its name and description, hare linked to one another Team defined as Upper Team, that represents the closest team over in the hierarchy. The extra data is the following:

• OBS - OBS (Organization Breakdown Structure) code that represents the hierarchical place of the Team where the number separated by dots (.) represents the respective ID of each Team

Teams also have Users associated, where Tasks are given, in this way, a Team can be seen as a deposit of Users. Teams define the Organizational Access.

Status

The element Status, represents the meaning of a given status. Because the Status has two states, given or ungiven, it's necessary the existence of a description to the Status reflecting its meaning. Status have the next two extra fields:

• Pending - When the status given, means that actions are expected to return the status to the expected ungiven state
• Single - Even when multiple Team are able to Give, at the same time only one Status may be given, make it ideal for representing situations of usage or reservation

Classes

The element Classes defines the structure of the Objects made. It defines the associated Teams and if may or may not create new objects, defines the Status that may be used and in which way, and finally, the scope of each status relatively to the associated Teams.

Classes may been seen as a prototypes for made Objects containing Teams and Status. Classes define the Operational Access.

Classes' Status

The element Classes' Status, incorporated in the Classes, defines the scope of each status relatively to the associated Teams. A Classes' Status establishes the connection between a Status and the Team for which the meaning of the Status stands for. As the name stands for, Classes' Status are contained in the respective Class. For the data of this element see Status on Classes.

Objects

The element Objects represent an instantiation of the respective Class, having associated the same elements that the respective Class has. The Classes' Status give place to the Objects' Status where the last element is explained next. Objects may be OPEN or CLOSE, in the last case no changes are allowed. The extra data associated is:

• Report to Owner - Means that any change in the Objects' Status will be reported to the Users of the Owner Team
• State - Indicates if the Object is OPEN or CLOSE for changes in the Objects' Status
• Owner - Indicates the Team that owns the object (See Ownership)
• Made on - Time stamp that indicates when the object was made

Objects' Status

The element Objects' Status, associated to an Object, is the result of the instantiation of the respective Class and its Classes' Status. Objects' Status are the place where Users, trough Teams, change Status communicating them to the Organization. As the name stands for, Objects' Status are contained in the respective Object. The extra data associated is:

• Giv - Shot for Given indicating if the status was or wasn't given
• Pen - Short for Pending indicating if the status when Given is also Pending
• Given on - Time stamp that indicates when the status was changed
• Given by - The Team and respective User that changed the Status
• Change on - If a future time stamp was set on change of Status, this field indicates that commitment for change, and when the respective time comes, it passes to Given on changing the respective Status
• Change by - The Team and respective User that committed the change at a future time that become Given when that time becomes past

Associations

Associations may be seen as a connection between two elements. This way the software predicts 4 kinds of associations.

Users on Teams

This type of association, represents the Users that are on a given Teams and its respective Tasks. This associations may be seen while viewing a Team or a User.

Teams on Classes

This type of association, represents the Teams that are on a given Class with the following attributes:

• Ownership - Means the possibility of Objects Ownership (allowed to made Objects)
• Consultant - Means that the team has no authority over the respective Class, this implies that if all non Consultant Teams became deleted from a Class, that Class is also deleted, and, the copy of Teams also copy all the Classes which all non Consultant Teams are also being copied

This associations may be seen while viewing a Class or a Team. In an Object, to turn this more evident, this association is called Classes' Teams.

Status on Classes

This type of association, represents the Status that are on a given Class with the following attributes:

• Default - Means that when an Object is made this Status is Given or Ungiven by default
• Omitted - Means that the respective Objects' Status are omitted from the Organization and other Teams but the one it is associated to (scope)
• Owned - Means that the respective Objects' Status it may only be changed by the Team that Owns the respective Object
• Restricted - Means that the respective Objects' Status it may only be changed by the Team that Owns the respective Object and the Team associated to that Objects' Status (scope)

This association may be seen while viewing a Class. The Omitted associated Status are printed in italic.

Classes' Status

Classes' Status is an element and at the same time an association. As an association defines the scope of the Status to make clear to the Organization which team has the responsibility of the Status in scope. The Objects' Status isn't an association by itself, because it's connected to Classes' Status, and a change in the last implies a change in the first.

Statistics

The Statistics for each element have always the same header, only varying the result for those headers. The common header is:

• Use - Users associated
• Tea - Teams associated
• Sta - Status associated
• Cla - Classes associated
• CSt - Classes' Status associated
• Obj - Objects associated
• Pen - Pending Object's Status associated
• Giv - Given Objects' Status associated
• Ung - Ungiven Objects' Status associated
• Tot - Total Objects' Status associated

It's needed to say that in the case of Teams, Statistics also represent the Owned elements of the respective Team. So, the number of Objects associated to a Team means the number of Objects Owned by that Team.

Usage

Levels of Usage

The software expects in the organization 4 levels of usage, they are:

• Administration - As a ROOT Team, this level of usage requires a full knowledge of the software, namely, installation, backupping, managing the Software elements, and, helping other users to understand it (read and write type)
• Normal - In this level the User knows how to use the software in the optic of a normal Team (non ROOT), namely, creating objects, management of its Objects' Status, and guarantee that the information relative to its Own Objects and Objects' Status is accurately and rapidly reflected on them (read and write type)
• Simple - In this pseudo-level the User knows to log in into the system, and can interpret the information relatively to its Team or Teams and act in the Organization accordingly to the information viewed in the system, this User reports to the Owner of the Object instead of being itself making the changes (read only type)
• None - In this pseudo-level the User knows nothing about the software, reporting its changes of Status to the Teams he knows he has to report, and those Teams, with users with Normal level of usage, update the Objects' Status accordingly (none type)

The Organization should make sure that have the minimum number of Teams with the Normal level of usage to make possible the utility of the software.

Administration

For information in installation of the software the website should be consulted. Here we will see the administration trough the usage of the Software. Only the Team ROOT has the task of administration.

Organizational Hierarchy

The Teams must reflect the Organizational Hierarchy, so it's fundamental to give the right superior Team when adding a new one. The Organizational Hierarchy should have to account the share of Responsibility, meaning that Contexts (Classes) that are supposed to be the Organizational Responsibility of a given Team, should have the Operational Responsibility's Team owner of the respective Objects under the former on, becoming its subordinated (descendent). By other words, the Objects made by the last Team also become the Responsibility of the former one.

The well and correct distribution of Responsibilities, mainly the Organizational one, may require a multiplication of Teams with similar competences albeit the same Users, this is perfectly acceptable because some times this is what really appends.

Operational Context

The Operational Context is defined trough Classes and respective associations, and this context is crucial for the performance of the software and the simplicity of the resultant Class and its interpretation. As a general rule, you should balance the number of Classes' Status with the number of expected Objects for that Class, where the product of the two gives the expected number of Objects' Status. In this way it's possible to define a Class as Open or Close type of Class, where you can see it as:

• Open Class - A Class with broad number of Teams associated to, which results in a considerable number of Classes' Status (ideal for few Objects)
• Close Class - A Class with a restricted number of Teams associated to, which results in a spare number of Classes' Status (ideal for many Objects)

A Class can be anything that is likely to have a Status, it can be, resources like vehicles, places like meeting rooms, tasks like reports, or any other thing you can imagine. So if you have a Class that is expected to have too many Objects, for example, a Class for purchase orders, the Teams associated to the process of approval should be the absolute necessary. On the other hand, if it's expected to have few Objects, for example, a Class for reports, the Teams associated may be all the participants and no more Classes are needed. For instance, a Class with 10 Classes' Status (not Omitted), if it gets 200 Objects it will result in 2.000 Objects' Status (10 times 200).

Because the purpose of the Software is the communication of the sate of affairs (see Purpose), it should not be seen has a simple archive of information, that is intended for the respective archive used by the Organization, so, if too many Objects start to pile in, consider the elimination of the closed ones, where this may be accomplished with the simple expedient of Coping the respective Class selecting the OPEN Objects to be copied and its consequent deletion, after that, you only need to give the same name to the new resultant Class.

New Elements

The Team ROOT can create any new Element with Name, and add any Association. In general, these elements are created trough the tab NEW....

Adding Associations

Adding associations is exclusive to the Team ROOT. The way you can add associations for each one is like this:

• Users on Teams - In Teams View pressing the respective Add/Remove button
• Teams on Classes - In Classes View pressing the respective Add/Remove button
• Status on Classes - In Classes View pressing the respective Add/Remove button
• Classes' Status - In Classes View pressing the respective Add/Remove button in the Teams on Classes table

Editing Elements and Associations

At the Organizational layer the ROOT Team can edit the data of all elements and associations trough the button Edit. The exception are the elements Classes' Status and Objects' Status that haven't data to be edited.

Changing Objects' Status

At the Organizational layer the ROOT Team can change any Objects' Status pressing to the button Change in the respective Object.

Copy Elements

Only the Team ROOT in the Organizational layer can copy elements, and this action is exclusive to three elements:

• Teams
• Classes
• Status

Copying a Team, means also copying all subordinated Teams. To do so, you have to give a prefix that will be attached, or replace an existing prefix, to all copied Teams. Other thing to have in mind, is that all the Classes that only have non Consultant Teams that belong to those being copied (see Teams on Classes), will also be copied with the same prefix. The copy process will ensure that are no conflicts in names for both, Teams and Classes, and if there are any conflict, the operation is aborted. Relatively to the Teams copied, the respective structural associations, Teams on Classes, Status on Classes and Classes' Status will be replicated. This copy is ideal for the cases where a new organizational branch is needed and have similarities with an existent one. No User will be copied, and so, all resultant Teams will not have any user associated ("Empty Teams"). The Prefix works the same way to any of the copied Elements.

Copying a Class also requires a prefix and will only be successfully copied if the resultant name doesn't already exists. The structural associations Teams on Classes, Status on Classes and Classes' Status will be replicated. Wile copying a Class, it's possible to choose to copy the respective objects (ALL, OPEN or CLOSE).

Copying a Status also requires a prefix and will only be successfully copied if the resultant name doesn't already exists. The structural associations Status on Classes and Classes' Status will be replicated.

A copy of any element can be totally reversed with the deletion of that copy.

Moving Teams

Only the Team ROOT in the Organizational layer can move Teams. Because Teams are Hierarchy organized, it is possible to move a given Team from a place to other in the hierarchy. One thing to have in mind, is that moving a Team implies that all the subordinated Teams will move with it, so, what you are moving is not just the Team, but also, all the descendent Teams. Being so, it's obvious that you can't move a Team under another Team that is already his descendant (under it), and because of that you will not get the option to select those subordinated Teams.

Deleting Elements

At the Organizational layer, the Team ROOT can Delete any named element. For the deletion of an element it will be asked the insertion of the respective ID for confirmation to avoid not intended deletions. It should be kept in mind that the deletion of an element implies the deletion of others. For example, the deletion of a Team, implies the deletion of the subordinated Teams, full contented Classes (with all non Consultant Teams being subordinated), and all the associations and other Elements linked to that Team and its subordinates. This means that a deletion of an element should be totally understand. Nevertheless, the Elements least invasive in their deletion are Users and Objects, where the most invasive are Teams and Classes.

Removing Associations

At the Organizational layer, the Team ROOT can Remove any association, however, like the deletion of Elements, a Removal of an Association may imply the removal of other associations or even Elements. Again, the removal of a Team from a Class, implies the deletion of all the Objects in that Class Owned by removed Team. The same way as in the deletion of Elements, it's required the insertion of the association ID to guarantee intention with the exception of the association Users on Teams, this because the removal of a User from a Team is the only case that has no other consequences than that same removal.

The removal of Associations is made trough the same buttons as adding, in the list of elements to be selected it's possible to toggle between the possibility of Add... and Remove....

Normal

The Normal level of usage it's applied for the non ROOT Teams, and is designed to be devoid of any unnecessary complexity.

New Elements

The only Element that a non ROOT Team is able to make is the Object element. If a Team has the Ownership permission in a Class, that Team is able to make new Objects of that Class trough the tab NEW... at the Operational layer. You need to select a team (identified team) and a class (restricted context) to be able to create an object (see Identity and Context).

Editing Elements

The only element that a non ROOT Team can edit is an Object. That can be done, at the Operational layer, with the button Edit in the Object Owned by the Team in question. You need to select a team (identified team) to be able to edit an object.

Changing Objects' Status

At the Operational layer a non ROOT Team can change an Objects' Status if it is the Owner of the respective Object, or, the Status on Classes attributes allow to do so. The appearance or not of the button Change is an indicator of the possibility to changing the Objects' Status. You need to select a team (identified team) to be able to change an Objects' Status.

Deleting Elements

The only element that a non ROOT Team is able to delete is the Object element. If a Team has the Ownership of a given Object, at the Operational layer that Object may be deleted with the Delete button. The ID of the Object will be asked to avoid unintentional deletion. You need to select a team (identified team) to be able to delete an object.

FAQ

Q: How do I change Identity or Context?
A: While viewing a Team or a Class, you get the tab USE THIS IDENTITY and USE THIS CONTEXT respectively. To select ALL again, use the push down tabs above the Elements tabs.

Q: Why I can't see the tab NEW... for Objects?
A: The tab NEW... for Objects requires that you select a Team (identified team) and a class (restricted context) in the Operational layer. Also, you must have Ownership permission in the selected Class.

Q: Why I can't see the Change buttons in the Objects' Status?
A: To make any changes in Objects you need to select a Team (identified team) in the Operational layer. Don't forget to check the permissions associated to the respective Classes' Status.

Q: Why I can't see the Tab ALL for the element Objects or Objects' Status?
A: For performance reasons, you are only able to select ALL for Objects and Objects' Status if you select a Class (restricted context).

Q: I'm a user associated to the Team ROOT, why I can't see the Administration menus?
A: You need to select the Team ROOT (identified team) in the Organizational layer to be able to access those menus.

Q: Why I can't see my own Omitted Objects' Status?
A: Omitted Classes' Status and Omitted Objects' Status are only visible in the Operational layer, except, for the Team ROOT.

Q: If I have all needed permissions to change an Objects' Status, why the option isn't given to me?
A: Check if the respective Status is not a Single type one. Remember that only one Yes can be given at the same time for this type of Status.

Q: I want to change my Password, how can I do it?
A: In the Organizational layer select Users and then MY SELF, select the user and the button Change for Password will appear.

---

Check my YouTube Chanel for Video Tutorials!