Kiwi Project Framework

About

The Kiwi project framework (KPF) is a project management system to organize and classify projects based on their stage. A stage is a point in the project lifecycle, such as "Proposal", "Development", or "Publication". Each stage is divided into sub-stages, which indicate specific milestones or tasks within that stage.

Entities

An entity is a person or a group thereof who is involved in a project. They can be single person, a team, or an entire organization. Multiple entities are involved throughout the project lifecycle; some last for the entire project (project-entity), while others may only be active in specific stages or sub-stages (stage-entity).

Entities usually only exist within the context of a single project, although the members themselves may be part of multiple projects and may be predetermined to always be part of the same entities in all projects.

The key entities in the KPF are:

Name	Lifetime	Description
PROJCOM (Project Committee)	Entire project	The main entity responsible for the project, overseeing its progress and deciding on its direction. At each stage (except stage 60), it votes on whether or not to accept the work done and what the next course of action will be (stage-vote). It also acts as the main secretariat for the project.
PROPCOM (Proposal Committee)	Stage 00 (Proposal)	The entity responsible for establishing and submitting the Project Proposal Draft (PPD).
DEVCOM (Development Committee)	Stage 20 (Development)	The entity responsible for the implementation of the Project Proposal (PP) and develop the Working Draft (WD).
APCOM (Approval Committee)	Stage 40 (Approval)	The entity responsible for evaluating and voting on the Final Draft (FD) with the PROJCOM. It's the only stage-entity that gets a vote in a stage-vote.
PUBCOM (Publication Committee)	Stage 60 (Publication)	The entity responsible for the publication of the Accepted Project (AP).
REVCOM (Review Committee)	Stage 80 (Review)	The entity responsible for creating and submitting the Project Review (PR) at the agreed upon time. It can make recommendations on whether the project should be withdrawn or extended, but it does not have a vote in the decision.
WITCOM (Withdrawal Committee)	Stage 90 (Withdrawal)	The entity responsible for preparing and submitting the Project Withdrawal Plan (PWP) if or when the project is to be withdrawn. If the PWP is accepted, it also gets a vote on whether the project should be archived or removed.

Members of an entity can be part of one or more other entities (cross-entity members). However, a special case is made for cross-entity members who are part of the PROJCOM: if they are also part of an entity that is responsible for the current stage, they should not get a vote in that stage-vote unless one of their entities – except the PROJCOM – usually entitles them to a vote, in which case they may vote in their capacity as a member of that entity (e.g. if a person is a member of the PROJCOM and the APCOM, they are entitled to a vote on the stage-vote in their capacity as a member of the latter).

Users of the KPF are free to define their own requirements and structures for these entities, as well as add, remove, or modify them as needed. Users are also free to define the requirements and procedures for stage-votes.

Deliverables

The delivrables in the KPF are documents or other artifacts that are produced at each stage of the project lifecycle. They are used to track the progress of the project, establish its direction, and evaluate its success.

The key deliverables are:

Name	Creation	Author	Description	Trajectories
PPD (Project Proposal Draft)	00.10	PROPCOM	The initial draft of the Project Proposal (PP), which outlines the project's goals, scope, and requirements.	Becomes PP if accepted in 00.60.
PP (Project Proposal)	00.70	PROPCOM	The final version of the PPD, which was accepted by the PROJCOM. It serves as the basis for the development of the project	Guides development of the Working Draft (WD).
WD (Working Draft)	20.10	DEVCOM	An iterative draft of the project, based on the PP. It is developed and refined throughout the development stage.	Becomes Final Draft (FD) if accepted in 20.60.
FD (Final Draft)	20.70	DEVCOM	The accepted version of the WD.	Becomes the Accepted Project (AP) if accepted in 40.60, gets downgraded back to WD if rejected in 40.60 and if the project is not abandoned in 40.80.
AP (Accepted Project)	40.70	Technically the DEVCOM, though the APCOM may make slight modifications	The final version of the FD, which was accepted by the PROJCOM and APCOM.	Becomes the Published Project (PUP).
PUP (Published Project)	60.50	Again, technically DEVCOM, though the APCOM and PUBCOM may have made minor modifications	The published and available version of the project. In other project management systems, this may be called the "final deliverable".	Becomes the basis of the Project Review (PR) creatd in 80.10 and may be extended if decided so in 80.60.
PR (Project Review)	80.10	REVCOM	A systematic review of the project occuring at a predetermined time after the AP is established. Recommends whether the project should be withdrawn, revised, or extended.	May lead to an extension of the project, a revision, or a withdrawal.
PWP (Project Withdrawal Plan)	90.10	WITCOM	A plan for withdrawing the project. It describes the steps to be taken to withdraw the project and a recommendation on whether it should be archived or removed.	If accepted, leads to the withdrawal of the project. Otherwise, the project is either revised or reviewed.

Users of the KPF are free to define, add, remove, or modify deliverables as needed.

Project lifecycle

In pure KPF (i.e. not modified by users), the project lifecycle is divided into six stages, each with its own sub-stages.

The stages are:

Code	Name	Number of sub-stages	Description
00	Proposal	9	The initial stage where the project is proposed and the Project Proposal (PP) is defined.
20	Development	11	The stage where the project is developed.
40	Approval	11	The stage where the project is approved for publication.
60	Publication	3	The stage where the project is published.
80	Review	8	The stage where the project undergoes a systematic review.
90	Withdrawal	13	The stage where the project is withdrawn.

Some stages are mandatory, while others are optional. Usually, all projects must go through the proposal, development, approval, and publication stages, but some projects may never be withdrawn or may not have a review date set, which effectively makes the project "immortal".

Immortal projects

Immortal projects are those that, deliberately or not, do not have or never go through the review stage. This means that they never "expire" as that stage is usually required to withdraw a project. Immortal projects are not inherently bad and they may exist for a variety of reasons (e.g. they could be used for one-time projects that do not need to evolve). At any point in time past publication, the PROJCOM may decide to force an immortal project into review.

Systematic project review

The systematic project review occurs at a predetermined time after the project is published. That date is usually set during the approval stage by the PROJCOM. Any entity may request an early preview of the project, although only the PROJCOM has the power to accept effectively enforce that request.

Glossary

Term	Definition
Stage	A point in the project lifecycle.
Sub-stage	A specific milestone or task within a stage.
Entity	A person or group involved in the project.
Deliverable	An item or concept produced in the project lifecycle.
Project	A task, plan, or undertaking with a specific goal or outcome that is organized and managed through the KPF.
Stage-vote	A vote held at the end of a stage to decide on the next course of action for the project.
Revision	A change made to a Working Draft (WD) or that transforms a deliverable into a WD.
Publication	The process of making a project available to its intended audience, usually after it has been approved.

Clarifications

Publication

Projects may be made available to their intended audience prior to the publication stage, but the publication stage is the point where the project is formally recognized as published.

Removing vs. archiving

Removing a project means that it is no longer available to its intended audience, or at least not available publicly. This is useful for projects that contain sensitive information that may carry prejudice if kept available.

Archiving a project, on the other hand, means that it is kept available, but no longer actively maintained or updated.

Withdrawal vs. cancellation vs. abandonment

Cancellation means that the project is stopped before it was ever published. This is usually done when the project is no longer needed or when it is determined that it cannot be completed.

Withdrawal is reserved for projects that have been published and are either being archived or removed. Projects that have been published cannot be cancelled, and projects that have not been published cannot be withdrawn.

Abandonment is a union of cancellation and withdrawal. It means that the project was either cancelled before it was published or withdrawn after it was published.

Internal modifications and derivatives

All users of the KFP are free to modify the framework to suit their specific needs. Gaps are intentionally left in the stage numbers to allow for additional stages or sub-stages without breaking the existing structure.

All feedback, suggestions, or questions regarding the KPF are welcome and may be directed to the Kiwi Committee for Standardization Main Secretariat