Kavi Help CenterKavi® Status Tracker Help
| Chapter 5. Managing Project States | ||
|---|---|---|
 |
Part I. Kavi Status Tracker Concepts and How-To Documents | 
|
Table of Contents
Project State allows everyone who views a project to immediately gauge which phase of development a project is in. Project State can also be used as gating criteria in built-to-order views, such as a public view of all projects that are currently open for public comment (e.g., a selection of projects that are in the 'Public Comment' state) or a published projects view (e.g., a selection of projects that are in the 'Published' state).
Project State is a label applied to a project when it reaches a certain stage in its life cycle, such as when a project enters a new phase of development or passes a milestone in the approval process. Every Project Type has a set of Project States associated with it, and these are available in all projects based on this Project Type. When a project is added, these Project States are displayed so the Status Tracker Admin can assign the initial Project State, such as 'Proposal'.
Project States are listed in approximately sequential order, so the list of associated Project States provides a sort of road map of the project development process. When a project enters the next phase of its life cycle, an administrator or Project Recorder assigns the next appropriate Project State to the project. Over time, the project is assigned a series of Project States to mark its progress from proposal to active development to approval and publication.
Here is an example that uses the default Project States to illustrate how the life cycles of projects based on a simple 'Standard' Project Type might be modeled. In this simple model, a project is assigned the 'Proposal' Project State when it is created by a Status Tracker Admin. Once the proposal is accepted, it is assigned the 'In Draft' Project State. When the draft is ready for internal review, the Project state is set to 'Trial Draft'. At the close of the trial period, the state is set to 'At Ballot'. Here the life cycle can vary, depending on whether the draft passes the ballot or not. If not, the Project State is set to 'Under Revision', and the draft repeats the 'Trial Draft' and 'At Ballot' states cycle until it passes the ballot.
If the draft passes the ballot, the 'Public Review' Project State is assigned. At this point, the draft standard may be automatically displayed in the Public Area of your organization's website. After the public review phase the project may be 'Approved'. In real life, there would probably be another balloting phase where the standard is voted upon by the top-level voting group within the organization, so that passing this ballot means the standard has organization approval. Sometimes a standard meets with an appeal after approval, in which case the Project State would be set to 'Under Appeal' while the project goes through a formal appeals process. If there is no appeal, or if the appeal is unsuccessful, the Project moves to the 'Published' Project State.
At the end of the project lifecycle, an old standard (e.g., standards for vacuum tubes or 8-track tapes) is retired and the Project State set to 'Withdrawn'. This state can also be assigned to a project that fails to clear some hurdle such as an appeal.
Figure 5.1. Project States and Project Life Cycle
The arrows show the approximate order in which Project States might be assigned, beginning with 'Proposal' and ending with 'Published' or 'Withdrawn'. The diamonds represent decision points, indicating places where the assignment of Project States might diverge. A project that doesn't pass the initial ballot enters a revision cycle. A project that is appealed is published if the appeal is unsuccessful and withdrawn if the appeal is successful.
This is an overly simplified version of the real standards development process, but is probably more complex than the development processes of bylaws and white papers.
Identifying your organization's Project States is one of the first steps in Kavi Status Tracker Setup. Once you know which Project States are needed, the process of adding Project States is simple.
The set of Project States that you need to add is global, that is, it contains all the Project States that will be available in your organization's installation of Kavi Status Tracker. When a Project Type is added, this global list of Project States is displayed and the Super Admin selects which states will be associated with the new Project Type. Later, when an administrator adds a project based on this Project Type, only the selected set of Project States are displayed.
To compile this global list, it's easiest to create lists for each Project Type that your organization requires, then merge these into a single, ordered list. You'll find that there are certain Project States that are common to all your Project Types, and others that belong exclusively to a certain type of project, as illustrated in the following diagram.
Figure 5.2. Project States Lists by Project Type
The Project States lists of three different Project Types are shown in this table: Standard, Bylaws and White Paper. Colored overlays show that some Project States are used by all three Project Types, while other Project States may only be used by one or two Project Types. In this example, the Standard Project Type is the most complex, and includes all the Project States — whereas the White Paper Project Type is the simplest and includes the least number of Project States.
Steps
It's easiest to begin with the most complex Project Type first, which is usually the full-fledged standards development project. Put the Project States in the order that a project might typically pass through during its life cycle. You'll probably find it easiest to prepare this information in a spreadsheet, but some prefer to work it out on a whiteboard or scratch paper first.
Repeat this process for each Project Type.
Since Kavi Status Tracker uses a global list of Project States, these lists of Project States need to be merged into a single ordered list. If there is a conflict in the order, the order required by the most complex Project Type should be given precedence. Project States that aren't shared should be merged into the main list in relative order to the states that should precede and follow them. As long as an intermediate state is placed somewhere between the states it should follow and proceed, the order will be correct, even if it is not immediately adjacent to either of these two states. Remember that when the Project States are viewed in the context of a Project Type, only the applicable states will be displayed.
Tips
Remember to include states that a project passes through before and after active development, as well as those that occur during the main phase of project development.
Include states to cover the most common exceptions, such as a project being challenged, put on hold or withdrawn. New Project States can be added as needed, so it isn't imperative to compile an exhaustive list before setup—but if a Project State is added after Project Types are set up, it has to be added to each Project Type separately.
Your lists of Project States can help you determine which Activity Types you need. Project States can be used to group activities and help you remember to add activities for states that aren't part of the main workflow, such as activities performed in response to challenges or other special circumstances, maintenance activities, etc.
Click the Project States link in the Super Admin menu. From there you can use Add a Project State to add to the global list of Project States, or click the Manage link for each of the default states so you can edit or delete those that don't fit your organization's needs.
Project States can be associated with a Project Type during site setup, when new Project Types are added or existing Project Types are edited. If a new Project State is added after site setup, each Project Type that should have this state will need to be edited through the Edit Project Details tool.
A Project Type is a preconfigured template on which projects will be based, so it contains all the Project States, project data fields and Activity Types that will be available in the projects that are based upon it — so Project Types tend to be rather complex. You may find it simplest to add the most complex Project Type first, then clone it to create similar Project Types. If you take this approach, you'll edit the Project Type details, including associated Project States, for each new Project Type that you create by cloning.
When you add a new Project Type through the Project Types tool, the global list of Project States is displayed. Select those that will be available in projects based on this Project Type.
Project Types can be created by cloning an existing Project Type, in which case the new Project Type will have the same Project States as the original on which it is based. These are edited as needed after cloning.
You can also edit the set of Project States associated with a specific Project Type any time, but this will affect every project based on this Project Type. Use the Edit Project Details tool to select or deselect associated Project States.
Because the list of Project States is global, you shouldn't use the Project States tool to change the order of the states to fit a specific Project Type unless you want to change the order in which this Project State appears in all the Project Types that use it.
If you have access to a project, you can set the Project State by opening the Projects page and clicking the Manage link for that project. The Project Details page is displayed. Click the Edit Project Details button. The pull-down list displays Project States in the approximate order in which they should be assigned. Assign the appropriate Project State and click the Save button.
Back to top|
|
 |
|
| Chapter 4. Access Control |  |
Chapter 6. Configuring and Using Activity Types |