Skip to content
Create an account for full access.

Alpha of the system-of-interest operations/service/utilization/usage

During the development of the target system, it is quite difficult to keep the focus on the time of its operation, when the system is already ready and behaving in the operational environment (run-time/operations). Here is an example of the alpha states of the work/exploitation/use of the target system and the control questions of these states. Remember that you should adapt all of this to the situation of your project, and it may not only be about the work of the entire system as a whole, but also about the work of a specific version of the system or even an increment/feature:

  • Initiated: the required results of the system's work are clear; constraints are clear; the project role paying for the system's work is known; the initiator of the work is identified; project roles accepting the work are known; the source of work products and funding is clear; work priorities are clear.
  • Prepared: commitments to carry out the work by the system owner (or the system itself of a sufficient level of agency/autonomy) are accepted; the cost of work and resource consumption are estimated; availability of materials for work, work space, and energy is understood; rules and control procedures are clear; acceptance criteria are defined and agreed upon; work is broken down into parts to a sufficient extent to start; tasks are defined, priorities for them are set; there is a plausible plan (if not ad-hoc planning, planning can also be external); funding for the work of the target system is available; where to take initial work products and where to place the final results of work, and who and how to report on the completed work is defined.
  • Started: work on the system has begun; work progress is being tracked, historical data is being recorded; resources have started to be consumed.
  • Under Control: the number of work results is increasing; unplanned work and resource consumption are under control; risks are under control; performance estimates are reviewed to reflect the actual performance and resource consumption of the system's work; progress is measured; the need for rework is under control; promises of work completion are being fulfilled.
  • Concluded: only coordination acts remain (notifications of work completion); work results have been achieved; external project roles have accepted the work results.
  • Closed: metrics have been made available for other projects; everything has been documented (digital twins); the budget has been reconciled and closed; the system has been released; there are no unfinished tasks.

If you want to describe the state of work during use/operation, try to answer the questions about the state of this alpha. You cannot just get away with a list of operations that your system needs to perform (a work plan) or that it potentially can do (functionality description).

You must know (that is, identify and document) the states of work/operation/service/operations/use of the target system that will be present after its manufacture and deployment. And, of course, you must monitor this alpha during operation. The states of this alpha are identified by positive answers to questions important for many external project roles: how much does it cost to operate the system is just one of them. Remember that the system description includes a mandatory aspect of the system's overall cost (development + operation), so you cannot avoid answering these questions; they are essential for obtaining a system description with answers to important questions, not just any description with answers to some questions.

Another example, a set of states of the alpha "work of the project organization". The work of the project organization (creator) may have the following states (and do not forget that all of this needs to be adapted to the situation of your project and the specific situation of the creator somewhere in the creation chain!):

  • Initiated: the required results of the work are clear; constraints are clear; the project role paying for the work is known; the initiator is identified; project roles accepting the work are known; the source of funds is clear; priorities are clear.
  • Prepared: commitments are accepted; cost and required efforts are estimated; resource availability is understood; control rules and procedures are clear; acceptance criteria are defined and agreed upon; work is broken down to a sufficient extent to start; tasks are defined, priorities are set; a plausible plan is available; funding for the work is available; at least one person from the team is ready to start work; integration moments are defined.
  • Started: development work has started; work progress is being tracked; work is divided into actionable units with clear definitions of what needs to be done; team members accept and perform tasks.
  • Under Control: the number of completed tasks is increasing; unplanned work is under control; risks are under control; performance reviews reflect the actual team performance; progress is measured; rework is under control; work commitments are being fulfilled.
  • Concluded: only administrative tasks remain; work results have been achieved; external project roles have accepted the system (or its increment/feature).
  • Closed: metrics have been made available for other projects; everything has been archived; the budget has been reconciled and closed; the team has been released; there are no unfinished tasks.

If you want to describe the state of work, pay attention: just listing work activities (especially if you write about a generalized life cycle in its first version: "work includes conception, design, production, testing, and then it's not our business") will not answer questions about the state of the "work" alpha. How will this list of work activities answer questions about the availability of funding? About the presence of a plausible plan? The list of stages -- this is not a plan, it's a list of stages from a textbook! But a plausible plan (the state of the alpha is characterized not by just any plan, but a plausible plan) of the current step, what needs to be done right now -- is there one? Is there a current list of cases/issues in the tracker? Are priorities assigned in it to know what to do now and what to leave for later? This is what needs to be of interest, general words like "we will conceive, design, manufacture the system, and then test it" -- won't work here. You must know (identify and document) the state in which your project work is located. Watch out for the types: the word "work" in the previous sentence is the alpha "work organization"! And what needs to be documented is the managerial (creation systems) description, not the engineering (target system) description (resources, budgets, work speed, and expectations on timelines).