Project Artifacts - Risks, Issues, Questions, Requirements and more

August 14, 2009 · · Posted by Jordan Frank

Glen Alleman at Herding Cats offers really nice distinctions in Risks and Issues Are Not The Same. In the course of working with a lot of teams as they deploy TeamPage as a project wiki, I've seen a wide range of terms for project artifacts. The more these concepts are discussed and hashed out, the better.

To risks and issues, you can add questions, requirements and ideas.

In some contexts, the terms are changed but mean the same thing. For example, in a software development shop, Requirements are Features and Issues are Bugs.

Quoting a DOD Risk Management Guide, Alleman describes risks as "a measure of future uncertainties in achieving program performance goals and objectives within defined cost, schedule and performance constraints."

He describes an issue, by contrast, as "impediments to the progress of the project."

As he notes, people often have a hard time distinguishing between risks and issues. For that matter, there is a fuzzy line between issues and questions.

When I helped John Evans at ShoreBank deploy his TeamPage system for IT Project Management, we spent considerable time figuring out which artifacts he would need in his project wiki and blog. I wasn't sure if we should include both Questions and Issues - and though that if he could tell me the difference, then we could use both.

"John, what's the difference between a Question and an Issue?"

"That's easy. Issues are showstoppers. Questions are accelerators."

That was as good a distinction as any, so we included both items. Characterizing Issue as show-stopper in John's terms or impediment in Glen's terms works really well. Over at KUKA Systems, the enterprise applications teams setup an Issues blog for each enterprise system. This opened the door for people to contribute and characterize issues as they came up, and a transparent way for the team to comment back on how they will be resolved.

Here is a list of basic project team artifacts that teams may include a in a blog or a wiki:

  • Milestone: A point in time (that often moves!!) around which a set of requirements and other project artifacts and activities are aligned.
  • Requirement: A description of a actions or processes that must be taken to solve a problem. Alternate terms may (accurately or inaccurately) include feature, specification, or objective.
  • Risk: Defined above as a measure of future uncertainties in achieving program performance goals and objectives within defined cost, schedule and performance constraints.
  • Issue: An impediment or showstopper along the road to building against the requirements associated with a milestone. An issue may be the manifestation of a Risk.
  • Idea: The alter-ego of an issue, an idea is a suggestion for actions or changes that will improve a system that is working or otherwise on track to be built. An idea may turn into a requirement or be referenced by a separate requirement.
  • Question: A knowledge accelerator. Usually, a person can figure out the answer to a question through experimentation or research - but can get a faster, better answer by asking a crowd.
  • Status Report: An update on progress against requirements, issues, and other activity.
  • Bulletin: A resource that is an important touchstone in the project. This may include a basic working policy, documentation of a team process, or other key information.

When it comes to wiki and blog technology as the basis for project team collaboration and communication, there is a good fit because of how all these artifacts are continually updated, reflected upon, and added to a system. In that light it's obvious how the context offered by a wiki and blog approach beats "traditional" project team tools which generally include email, word documents and task lists.

Page Top