Four categories of project information

There is a reason why I chose to focus on control mechanisms in my two previous posts (1, 2). Control information is one of the main types of artifact that a project creates and uses during the process of product or service development. The other types of artifacts are managed, project, and influencer, which I will define in a minute.

But first I want to emphasize that this is project information we’re talking about here: It’s not information being published on a website; nor is it transactional information in an application database. It’s the kind of information that most (every?) information-intensive organization needs to deal with because new initiatives (almost) invariably come in a project format. OK, on to the types.

• Managed – Artifacts that encapsulate the work products such as source code, build scripts, ancillary data, test suites, test data, test scripts, test results, requirements, use cases, scenarios, feature specifications, design documents, technical specifications, internal documentation and external documentation. They also include all the information related to how the data are structured in the repository such as folders, document containers and section headers. These are the crown jewels of your organization. You can’t (or shouldn’t) create or modify them without a good reason.
• Project – Artifacts related to project management including the project folder, Gantt charts, resource plans and test plans.
• Influencer – Artifacts that are used to support the project goals such as defects, requests for change, research notes, related emails, sales information and projections, return on investment calculations and support incidents. The information contained in the influencer artifacts suffuses the entire project. These artifacts are used to guide the requirements elicitation process, the list of features to be implemented and their prioritization, the design documents, the test cases, and the documentation process.
• Control – Artifacts used to manage the managed artifacts, as described in the previous posts. These artifacts link the project artifacts to the managed artifacts. They should also be used to record design implementation details that may be helpful for documentation or testing.

Each type of information is used by a different set of users. Managed artifacts are used by business analysts, developers, designers, architects, testers and documenters. Project artifacts are used by project managers and team leads. Influencer artifacts are used by stakeholders, which could be anyone and everyone. Control artifacts are used by everyone directly involved in the project.

This is a picture of how they work. It may not be a very good one, but that’s what the Comment box is for.

The four main categories of project information

The managed artifacts are in the middle. The source code artifacts are regular circles, while other document-based artifacts like requirements and test cases are the stars. The red arrows are the control artifacts and the brown pentagons are the project information. The control artifacts are used by the project artifacts to mediate work done on the managed artifacts. Finally, the cloud of information is the influencer artifacts, which affect all the artifacts in the project.

Obviously there is a lot missing from the picture, especially all the relationships between the objects and the structural relationships that group and categorize the artifacts. Also note that I have made a distinction between source code and document-base artifacts amongst the managed artifacts. They are different, without question, but from the project perspective they can be lumped into one category.