• A.1 Introduction
• A.1.1 Stakeholders
• A.1.2 Model elements
• A.1.3 Derivation
• A.2 Stakeholders
• A.2.1 Customer
• A.2.2 Team
• A.2.3 Organization
• A.2.4 Funders
• A.2.5 Regulators
• A.3 Model elements
• A.3.1 Artifacts
• A.3.2 Team
• A.3.3 Tools
• A.3.4 Plan
• A.3.5 External responsibilities

A.1 Introduction

In Chapter 16, I presented an approach for determining what features and capabilities should be supported in the project in order to do a good job of building a system, and meeting stakeholder needs. In this appendix, I present the detail of that derivation.

Bear in mind that this derivation results in a set of objectives for a project. It does not say how any particular project should meet these objectives; each project must decide those things in ways that meet the specific needs of that project and that system. The objectives can be seen as a set of considerations that each project should examine as they decide how to run the project.

The derivation only addresses matters that are related to the project’s approach to building a system. There are many other factors outside this scope: matters of project management, or of policy in the organization that hosts the project. Where appropriate I have made notes of these matters external to the system-building scope.

A.1.1 Stakeholders

The set of stakeholders is:

1. The customer for which the system is being built;
2. The team that builds the system;
3. The organization(s) of which the team members are part;
4. Funders who provide the investment to build the system; and
5. Regulators who oversee the system and its building.

I introduced each of these in Section 16.2.

A.1.2 Model elements

I introduced the model for making systems in Section 7.3. This model is organized around the tasks that need to be performed to build the system, and has the following elements:

1. Artifacts that are created by performing tasks, and represent the system and records about it;
2. The team that builds the system by performing tasks and making artifacts;
3. The tools that people on the team use in doing tasks; and
4. The plan that organizes what tasks need to be done, in what order, and using what resources.

In addition to these elements, I have include an element for matters external to the system-building project for matters that stakeholders need but that aren’t about building the system itself.

A.1.3 Derivation

The derivation maps stakeholder needs onto objectives for parts of the model.

The result is a set of objectives or capabilities that people should consider when working how how the project should operate.

I discuss each stakeholder in the sections that follow, along with tables of the needs or objectives of each. The objectives that support these stakeholder objectives are annotated with a right-pointing arrow: →.

A.2 Stakeholders

A.2.1 Customer

The customer (see Section 16.2.1) is a stakeholder who wants the system built because they are going to use the system. They may or may not be funding system development directly—if they are, then they are also a funder below.

A.2.1.1 Filling purpose

A customer has some purpose for the system, meaning something they want to achieve by deploying and using the system. This is the problem that the customer wants solved, which is a higher-level concern that the specific features that the system will provide.

A customer may have additional requirements on the system. They likely have a need for a minimum level of reliability. They likely have needs related to safety and security of the system.

The project needs to build a system that can meet this purpose and the requirements.

The project can meet these needs by:

• Learning and documenting the customer’s purpose and requirements, resulting in documents that the team can refer to while building the system.
• Having processes defined that ensure that the team will follow a deliberate process as they design, build, and verify the system.
• Having processes for checking the design and implementation to ensure that it meets the customer’s purpose, and for finding and fixing errors.
• Having a team that has enough people with the right skills to do the work, and gives them clear assignments for what steps they are responsible for.
• Having tools that help the team analyze and verify the design or implementation.
• Keeping track of the work that needs to be done, including having a general plan to guide the work and tracking the work currently in progress.

A.2.1.2 On time and budget

The customer likely has a deadline by which they would like the system delivered. They likely also have a budget for how much they want to invest in acquiring the system. At minimum, customers generally want the result as soon as possible and for as low a price as possible.

To meet these needs, the project should:

• Know what the budget and deadlines are for the work.
• Have a plan that can be used to estimate resources and time needed to get to deadlines or finish the project. This plan should be visible to everyone on the project, so that they can understand how what they are doing fits into the overall work flow.
• Account for degree of uncertainty in these estimates—which will be inaccurate early in the project, and become more accurate as time goes by.
• Track how much resource has been used and the progress on tasks.
• Regularly update the plan based on progress made and information learned.
• Have processes in place to detect when there may be a budget or deadline problem, and to figure out how to resolve the problem.

A.2.1.3 Certifications

In many industries, some kind of certification or approval is necessary to operate the system. An aircraft, for example, needs a type certification from the local aviation authority as well as approval for a specific instance of the aircraft. Even if there is no overt certification required, there are often regulatory standards to be met.

The project must build the system in compliance with regulations. When certification is needed, the project must follow the process to get that certification.

To achieve this, the project should:

• Know what regulations and certification process applies to their work, and make that information available to everyone on the project.
• Have people who interface with regulators, to learn when regulations change, to ask for clarification or guidance when needed, and to work with the regulators during certification.
• Account for regulatory requirements in the specifications for the system, equal with customer objectives and requirements.
• Maintain design, analysis, and process records that can be checked to verify that the project is working to meet regulations.
• Have a process for regularly checking that the project building a system that meets regulations, including verifying the design or implementation.
• Have a process for working with the regulators to get certification, including having a process for resolving issues that the regulators identify that stand in the way of certification.

A.2.1.4 Release and deployment

The customer needs the system actually to be delivered and put into operation. The project must deliver the system, and provide or support its deployment.

To do this:

• Maintain the tools used to maintain products for release, including a protected repository for software releases and stockrooms for hardware inventory.
• Have a process defined for releasing and deploying a system.
• Have people on the team who are trained and responsible for release and deployment.

A.2.1.5 Evolve system

The the system is successful, the customer often finds that it can be made even better with some changes. Or the customer’s needs may change, and they will want the system to adapt to meet their changed needs. The project should be able to maintain and evolve the system to support the customer’s changing needs.

A system may also need to change when regulations change.

The project can support an evolving system by:

• Having people, tools, and a process for receiving requests for changes.
• Having a process to decide (and prioritize) which requests to act on, and which to defer or reject.
• Tracking which changes are being reviewed, which are being worked on, and which have been completed.
• Maintaining rationales of decisions made during design and implementation, so that people working on a change can accurately understand how the system can be modified without causing errors.
• Having processes and tools to maintain all the design, implementation, and verification artifacts as they are changed—and keeping changed artifacts consistent with each other and separate from versions without a particular change.

A.2.2 Team

The team (see Section 16.2.2) is the collection of stakeholders who build the system. These people need the things that skilled, technical workers generally need: satisfaction, security, confidence, compensation.

Meeting these needs is mostly outside the scope of systems-building itself. These needs are largely met by the project and organization management who create the environment in which the team works. Still, there are aspects of systems-building that can help (or hinder) meeting the team’s needs.

The analysis of a team’s needs presented here is somewhat idealistic. It focuses on skilled workers who are not readily interchangeable, whose value to a project derives in part from the knowledge they carry about the system being built. It assumes workers motivated largely by work satisfaction and have essential material needs met by their compensation. These assumptions lead to a particular balance of power between the team and the organizations that employ them. This would not apply to a team of interchangeable workers or workers whose material needs are not well met by their employment.

A.2.2.1 Satisfaction in the work

Team members are expected to need satisfaction arising from the work they are doing on the project.

The satisfaction comes in part from believing that the work they are doing will have some positive outcome. That outcome might be that they see the system deployed and having a positive effect on the world. It might be that they see their work acknowledged, publicly or privately, even if the system ultimately is not deployed. It could come from social standing among their peers improving because of their association with the work.

Skilled workers also want work that makes use of their skills—which leads to a sense that they, as a specific individual, are making a contribution to the work. Work that challenges them or from which they learn things contributes to that satisfaction.

Doing work that is seen as not relevant or not likely to have value decreases their satisfaction. If asked to do something that is not achievable, they will lose enthusiasm. If they are asked to do work that they perceive as irrelevant, they will feel a lack of their individual value.

To support team satisfaction, the project can:

• Have a clear explanation for why the organization decided to go ahead and run the project to build the system.
• Have a plan that gives team members context for how their work fits into the overall flow of work.
• Use tools that automate as much repetitive or low-skill work as possible.

Other aspects are outside of the project’s scope.

• The organization and project management need to keep the team informed on how the project is proceeding. This helps the team have confidence that the project will successfully finish the system, and it gives the team a way to get involved if there are problems in execution.
• The project management needs to assign work to the people with the right skills to do the work.

A.2.2.2 Appropriate staffing

A team needs to have enough of the right people to do the work—but not too many people. Having enough people on the team who can do the work contributes to a team member’s sense that the project has a good chance of having a positive outcome.

Having too few people, or too many people who lack necessary skills, leads to an overworked and burnt out team.

Having too many people leads to team members who don’t have useful work to do. It can lead to people making up new work just to feel like they are contributing.

The “right” staffing level is dynamic. It changes over time as the project moves forward: a particular skill in designing electronics boards may be important for one period in the project, but once the necessary hardware has been designed and built, the need decreases. It changes over time as people change. As a team members learns new things, they may find that they should move on to a different project. Life events occur that change a person’s motivations and needs. The key is not to always have the perfect cohort working on the project, but to have a pretty good group and work to address changes as they happen. If the team has trust in their management that the management is able to address team composition, people will generally stay satisfied.

Ensuring appropriate staffing involves:

• Having a reasonably accurate idea of the staffing needs, which comes from having an overall system design and a plan for building the system.
• Ability to hire staff, or transfer them in from other projects. This includes having the ability to bring new staff members up to speed on the project.
• Having an accurate record of who is on the team, and what role each person plays, in order to identify where there are gaps in staffing.

Much of this is outside the scope of the project itself. The organization holds the funds used to pay staff. It also provides the ability to hire and fire people.

A.2.2.3 Sufficient supporting resources

As with staffing, the team needs resources to do their work: a place to work and the tools to do the work, for example. They may need consumable resources as well. For example, a team might need a ready supply of liquid nitrogen in order to test a hardware component that is supposed to operate at low temperature.

If the team lacks these resources, they can’t do their work. This affects their satisfaction.

The project needs to have:

• Facilities where the team can work. This includes both office space for desk work and lab space for building and testing.
• Ability to make hardware components, including the machining used, the stock used for components, and ability to store and track the inventory of made parts.
• Software build and test tools.

A.2.2.4 Secure position

Team members need to have a sense of security in their position. This means that they need to believe that they understand their position in the project and organization, believe that they will be treated fairly, and believe that issues they raise will be addressed. The opposite of this is when they have a sense of insecurity—because they do not understand what is expected or how they are evaluated, or because they believe that problems will not be resolved, even if they raise an issue.

The sense of security allows people to put their effort into their work, rather than spending their time and energy on worry. The sense also helps keep people on the team so that their knowledge of the system continues to benefit the project.

This comes from the project:

• Having clear records of what role each person is expected to fill, and the ability for each person to find the people who have some role or responsibility.
• Having clear reporting and decision authority, documented for all the team to know.
• Having a process for raising issues about both technical and team problems, along with a process for tracking the issues as they are resolved.

The organization also needs to:

• Document how the project fits into the organization’s overall structure.
• Document (and follow) a policy for how each person will be evaluated.
• Respond to raised issues promptly and without retribution.

A.2.2.5 Fair compensation

A technical worker needs to believe they are being fairly compensated for their time and effort. They need to be compensated well enough that they are not distracted by want. That compensation may be monetary, but it may take other forms as well.

Setting compensation policy is usually a responsibility of the organization, not the project.

A.2.2.6 Belief in project

Skilled workers often have choices about what project they work on. Many of them are motivated by a belief in the work they do: that it will help its users, or that it will result in some good for the world. If they come to believe that either or both is not true, they will be demotivated.

The project should:

• Document and maintain the reasons why the organization and the team are building the system.
• Maintain documentation of what the customer will use the system for.
• Communicate regularly with all the team about how interactions with the customer are going.

The organization should also maintain an ethics policy that details:

• What the organization considers ethical behavior by team members;
• What the organization commits to as ethical behavior in the world; and
• Procedures for raising and resolving ethical questions—including external reporting when appropriate.

A.2.3 Organization

The people in the team work for the organization, which provides a home for the project (see Section 16.2.3.) The organization is responsible for finding funding for the project and providing a legal entity for doing the work. The organization provides the business operations that make the project possible.

There is no one kind of “organization” that fits all situations. The organization might be anything from a single person, to a company, to a consortium of organizations, depending on the project. The organization might exist to return profit in exchange for the work, or it might be a non-profit or a governmental organization that looks for non-monetary benefits from the project. Some organizations exist only to build and deliver one system; others expect to deliver the system to many customers and to build more systems in the future.

Many of an organization’s needs are not to be met by the system-building project itself; they are met by how well the organization’s management and business operations. Nonetheless, how the system is built can help or hinder business management or operations.

The diversity of kinds of organizations means that the list of needs below has to be tailored for each project and each organization.

A.2.3.1 Ability to deliver

The purpose for the organization pursuing a system-building project is to deliver a system to the customer. If the project does not deliver something, the organization will see little return on its investment and effort.

Of course, an organization might get a contract from a customer and get started, only for the customer to cancel the contract. (Hopefully the organization has taken this into account in its planning.) The organization still needs to have been able to deliver the system, even if the work was stopped.

The ability to deliver has two aspects: communication with the customer and support for the team, in addition to the general ability to build a system for the customer.

When the system being built has a specific customer, the organization needs to be able to talk to them, keep them updated on progress, and hear concerns or issues from the customer. When there is disagreement, the organization needs people who can negotiate and resolve issues.

The project can help this by maintaining the interface with the customer, including having people assigned to work with the customer, documenting what they learn from the customer, and negotiating with the customer as issues arise.

The project team can do little without the organization supporting them. The team needs leadership; it needs workspace and other infrastructure; it needs human resources and payroll and accounting support. The organization needs to:

• Provide the resources (funding, space) that the team needs to do its work.
• Provide supporting capabilities, such as hiring, problem resolution, and marketing.
• Maintain a safe and regulation-compliant workplace.

A.2.3.2 Ability to sell

If the system is expected to be delivered to multiple customers over time, the organization needs to be able to find those customers, make the case to them that the system will benefit them, and work out a deal to deliver the system.

I have written this need in terms of selling, but the needs apply when something is being delivered not for monetary return. An open-source project that is freely available to users does not sell the system for money, but the way that project has value is for users to pick up, deploy, and use the system. The project may want to attract developers to build up an ecosystem of related products or services. Meeting these needs involves making potential users aware of the system and making the case that they will benefit from the system.

To be able to sell the system, the organization needs to:

• Be able to say why the system is worth acquiring and using. The system-building project can help this by keeping records of the intended value proposition for the system.
• Ensure that there is a market for the system. The project can assist by having that documentation of what the system is for, and by working with the organization’s marketing team while designing the system.
• Have a team that can do sales and marketing.

A.2.3.3 Profit

The organization will be expecting to get some kind of return on its effort. That may be a monetary return, but a non-profit or government agency may look for a non-monetary return, such as a community benefit.

The project can support this in two ways. First, the organization can set business objectives for the project, such as expected profit. The project can keep records of these objectives, and take them into account in the system’s design. Second, the project can organize its work as efficiently as possible so that investment goes as far as possible (consistent with deadlines). The project’s management can monitor the time and money being spent and work out how to adjust the project if it looks likely that the project will not meet the organization’s expectations on return or profit.

A.2.3.4 Positioning for future work

Many organizations build multiple systems over their existence—whether this is building multiple bespoke systems for customers, or building multiple products that are delivered to many customers. The ability to continue to deliver profitable systems is a major part of a company’s stock performance: the stock price is determined by the market expectation of future returns to the investors.

An organization’s reputation affects its ability to attract customers and investment, as well as its ability to hire talented staff. The reputation depends in part on its ability to deliver good systems.

An organization can become more productive over time—and thus improve its reputation, its ability to deliver, and its profitability. This comes from learning and improving. If the organization builds up a staff that knows how to run a system-building project well, future projects can be executed more efficiently. Better tools will help the next projects. However, learning and improvement does not often happen by chance; it happens when an organization sets out to learn from its performance.

The project can:

• Add to the organization’s reputation for building a system well, on time, and on budget.
• Maintain a transparent and good working relationship with the customer, so that a happy customer will refer others for future projects.
• Meeting its team’s needs, so that people on the team spread the word that this is a good organization to work for.

The organization should:

• Take steps to build up reusable capability from one project to another.
• Have the the commitment and processes to learn and improve over time.

A.2.4 Funders

The funders provide the investment that funds the team building the system (see Section 16.2.4.) The funder provides these resources in the expectation of some kind of return, be that monetary or not. A venture capital funder is most likely to look for a monetary return from future profits from the organization it is funding. A company providing internal funding more likely is looking the project to add to the company’s capabilities, which will in turn enable the company to increase its future profits. A government agency is likely looking for something that will benefit the public in some way.

As noted earlier, there are many different kinds of funders, from venture capital to company internal funding to customers paying for development.

A.2.4.1 Return on investment

Funders provide capital to run the project on the expectation that they will get some return on that investment.

In some cases, the return will come from profit realized in building the system (Section A.2.3.3) or from an increase in the value of the organization (Section A.2.3.4). In other cases the return will come from the value of the system after it is delivered and deployed (Section A.2.1.1, Section A.2.3.1).

The funders will also expect to be able to track the organization’s and project’s progress, and to raise issues when they find that there may be a problem that could jeopardize the funder’s return. The organization needs to have people whose responsibility includes interfacing with the funders.

The project can support the interface with funders by maintaining a realistic plan for the work, managing its budget, and keeping the organization informed of progress. The project should also have the processes in place to respond when the funders raise an issue that leads to a potential change to the system.

The project may also need to maintain accurate records and artifacts that allow the funder to audit the project—verifying that the information the funder has received is accurate and complete.

A.2.4.2 Ability to attract future investment

The funders get the capital they invest from somewhere. In many cases, the investment capital comes from their customers: individual and institutional investors for venture capital, legislatures and the public for government investors. The funders will keep their investor customers satisfied if they can show that their investments produce the expected returns, leading to a reputation for using capital wisely. At the same time, funders want to avoid bad press from projects that have problems, which can reflect on the funders’ ability to select organizations or projects.

The ways that the project can address this funder need are all included in the previous section, on the funder’s need for return on investment.

A.2.5 Regulators

Regulators (Section 16.2.5) provide an independent check on work to ensure that it meets regulations or standards, thus ensuring that some public good is maintained that the organization or project might not otherwise be incentivized to meet.

The interaction between the project and regulators depends on the countries involved and the nature of the project. Some industries require licensing or certification of some kinds of system: most aircraft, for example, must obtain type certification from the local civil aviation authority before that aircraft is allowed to fly or be sold. Spacecraft require a set of licenses for launch and communication. Other industries, such as consumer electronics or automobiles in the United States, depend on compliance with regulation but compliance is only checked after the fact.

I include voluntary standards as part of regulation. Non-governmental organizations set interoperability standards; the standards for USB (set by the USB Implementer’s Forum) and WiFi (set by the Institute of Electrical and Electronics Engineers 802.11 working group) are examples. Other organizations set safety standards that help to ensure consumer products are checked to be safe.

The regulators perform multiple tasks:

• Setting regulations or standards.
• Communicating those regulations to those who might be affected.
• Performing compliance checks for certification, when appropriate.
• Performing compliance checks when violation is suspected.
• Working with the organizations that are being checked to identify and resolve issues.
• Overseeing remedies, when appropriate.

A.2.5.1 Compliance and certification

The regulator makes regulations (or standards), and makes them available to teams building affected systems.

The project responds to the regulations by designing and building the system so that it meets the regulations, maintaining records needed to show that the regulations have been met, and beginning a process for getting certifications or licenses when appropriate.

The project is responsible for:

• Finding and documenting all the regulations that apply to the system, and communicating those to the team. The project should maintain artifacts documenting these regulations, and needs people assigned to tracking down this information. Frequently the team will need to ask the regulator for explanation or clarification as well.
• Tracking regulations for change. When regulations change, the team needs people who will find the changes and oversee any changes to the system needed to comply with the new regulations.
• Designing and building the system to meet the regulations, including documentation of how compliance has been verified. The team must include regulation as it formulates requirements and designs. The team should have a process that ensures that designs and implementation are checked against the regulatory requirements, and maintains records of the checks.
• Maintaining records of the process that has been followed, so that the regulator can audit the process that has been followed (separate from the content of the system).
• Applying for certification. This involves knowing how to apply, developing a working relationship with the regulator to perform the application, delivering information to the regulator as needed, and responding to issues raised by the regulator.

A.2.5.2 Monitoring

In some cases, the regulator must monitor the project’s work—for example, during aircraft certification, which is generally a joint effort between the aviation authority and the company building the aircraft. A regulator might also need to monitor the project after a violation has been found and the team is working on remedial action.

Accurate and timely information is paramount when this occurs. The project must maintain good records to be able to provide that information to the regulators. The information potentially covers everything about the project: the design and analyses of the system, its implementation, records of design rationales, and logs of the processes followed.

The team must also be prepared to notify the regulator proactively as situations arise. The team should have people who will watch for situations and communicate with the regulator.

A.2.5.3 Problem resolution

I have never observed a licensing or certification process to go with no problems. The processes and regulations are often complex, and unless a team has done the process several times before there will almost certainly be things the team needs to learn to get through the process.

This means that there will be problems to resolve. Sometimes the team will discover the problem and need guidance from the regulator. Other times the regulator will raise the issue.

The team can make smooth the problem resolution process by:

• Documenting the process it is following, including notes on how the team understands the process and what it learns along the way (to help the next time).
• Maintaining good communications with the regulators, in order to be able to ask them questions or receive notices from them. This implies having people on the team who have the ongoing responsibility to maintain the interface with the regulators.
• Maintaining accurate information, as noted above.
• Having and following a process to handle regulatory issues when they are found or reported, including working with the regulator to find a resolution and then implementing and verifying the resolution.

A.3 Model elements

All of the objectives in the previous section map to objectives related to artifacts, team, tools, and plan. Some of them also map to things other than the system-building that goes on in the project.

This section lays out tables of the objectives for each element of the model. Each objective is annotated with its parents; that is, the objectives that are the reason that this objective is included. These are annotated in the tables with an arrow pointing down and right: ↘. If one of the objectives has children, those are annotated with a right-pointing arrow: →.

A.3.1 Artifacts

A.3.2 Team

A.3.3 Tools

A.3.4 Plan

A.3.5 External responsibilities