Just as artifacts from ancient times give us information about early man, the documents and presentations you create in IT can give insight into your technology initiatives.
We know relatively little about the humans that were roaming the earth thousands of years ago. But because we have the artifacts they left behind—pots, arrowheads, and so forth—we have a glimpse give us a glimpse into their daily lives and who they were.
Artifacts (documents, Powerpoint presentations, spreadsheets, etc.) also allow a glimpse into the processes that are happening in your IT organization. Learning how to encourage the creation of artifacts is an essential part of managing an IT department.
The power of the artifact
An artifact is anything crafted by human hand that is left behind. This can be a product, a training manual, help documentation, project management documentation, or anything else which is tangible. Most of the time artifacts are documentation or diagrams of some sort but they can also be the finished product or some piece of the finished product.
Artifacts are powerful because they have a focusing effect. It's hard to evaluate a product, for example, until there's at least a one-page summary of the evaluation, or a three-slide presentation given to the rest of the team.
One organization I worked with faced chronic challenges with their research department. They were always looking for new technologies to bring into the organization. These evaluations went on for years but, because they had nothing to show for their research at the end of the process, they were largely ignored. Without a defined artifact such as a technology evaluation, they never completed the evaluation of the technologies they were testing.
Because artifacts are tangible, they bring focus to projects, evaluations, and operations which are not necessarily easy to complete, describe, or improve. Many projects that flounder for months or years can start to recover after a few weeks once weekly status reports are added to the project communications plan. No new technical breakthroughs need occur and no new resources have to be added to the project. The simple requirement of putting together a weekly status report has caused many projects to "get better."
It's about the process
Artifacts are often needed simply to cause the right kind of thinking to happen — and to verify that the thinking has happened. Therefore, the artifact itself isn't the most valuable part, which may explain why they are often buried for so long. The valuable part of developing artifacts is the thinking that it forces to happen. This thinking reduces the undiscovered risks, improves the clarity of the common vision, and generally aligns a group better than those groups who simply walk through the process without the known quantity of the artifact.
In a recent discussion I heard, four software architects were discussing this very topic. One insisted on a design document, another insisted that design documents were a waste of time and were unnecessary. After an hour of debate and a few beers the group finally came to the consensus that the process — the thinking — was the important part, not necessarily the artifact (design document.) However, some conceded, the only way to ensure that the right thinking happened was to have an artifact — a design document that described and clarified that thinking that had been done in the discussions which led to its creation.
Artifacts also expose us the processes that were performed. Much like artifacts from people who lived thousands of years ago can expose information about those people, project artifacts can help us to understand how a project was formed a few months or a few years ago.
Keeping artifacts from overwhelming
There is a school of thought that if you spend all of your time creating documentation then you won't be able to get anything done. Certainly that can be the case. There are those situations where the level of documentation that must be produced unfairly burdens the project or the team. However, here are a few things that you can do to keep the process from becoming overwhelming.
- Focus on function not form — if you feel the need to have fancy formatting in an artifact that you create, do it in a template so that time isn't wasted on doing the formatting over and over again. Don't make the formatting so distracting that it makes it harder to read the artifact. The objective is to force thinking to happen and to document what happened not to create a burden on the efforts of the team.
- Less is more — A few shorter more direct artifacts are more useful than a tome of information that is lifted into place on the ceremonial bookshelf of unread documents. Make a few smaller artifacts that may get read once in a while.
- Don't duplicate — Rather than duplicating content that is located in another document, simply refer to it. A design document doesn't need to repeat a requirements document verbatim, it only needs to reference that the requirements document exists. >li> Use informal documentation — Make allowances for less formal forms of artifacts that don't require much effort. A weekly e-mail may be appropriate for some project status reports — it doesn’t have to be difficult.