As the industry leader in delivering IT Methodology related webinars, it is sometimes interesting to take a step back and do a little analysis on the delivery of our sessions. For the majority of our IT Methodology webinar sessions we make a point of sending out a survey to those who have attended. In reviewing the comments and feedback of the webinar attendees, it is interesting to see how many participants are seeking to obtain more clarity on the difference between a deliverable and an activity - the following narrative attempts to address this question.

To properly discuss the concept of deliverables/artifacts/work products it is important to establish a context and a basic definition. First, we must understand and accept that these terms (deliverable/ artifact/work product) are fundamentally synonymous in nature – each and all of these terms can be referenced as a specific unit of work, each and all of these terms can be referenced as having a specific purpose, each and all of these terms can be referenced according to a pre-defined quantifiable criteria.  These terms and their usage are loosely applied across and throughout the IT industry – a deliverable at one organization can have the same meaning and purpose as an artifact at another organization or a work product at another organization.

In establishing that premise (deliverable, artifact, work product are fundamentally synonymous) we are able to identify the following characteristics common to deliverables/artifacts/work products.

• each is tangible (can be see and touched)
• each has a specific purpose (i.e. Project Charter, Business Case, Testing Strategy, etc.)
• each has a unique and predefined set of criteria (informational requirements to be completed)
• each is a specific unit of work
• each can be assigned to a specific project team resource
• each can be reviewed & approved independently
• each can be reflected on a project schedule (WBS)
• each can be placed under configuration management throughout the life of a project
• each can be assessed (peer review and quality assurance)
• each can be referenced to enable future application maintenance/modification

Using these characteristics we are able to distinguish between deliverables/artifacts/work products and activities. Let us assume we are going to build a house

Deliverables/Artifacts/Work Products                                     Activities

- Blue Prints                                                                          - meeting with the Architect to review the blue prints
- Basement Floor Poured                                                     - mixing the concrete for the basement floor
- Windows Installed                                                              - purchasing the wood to build the windows

Citing this “building of a house” allows us to draw comparisons in how various IT projects are defined, planned, executed, controlled and implemented.

Organizations and project teams that apply the concept of “deliverable/artifact/work product” are more likely to develop and maintain applications using a structured, predictable, repeatable approach - resources become familiar with their roles, the user community participates in the development and testing of the application, and the project team delivers to expectations. Conversely, organizations and project teams that rely on developing applications through performing “activities” do not have the same luxury of applying a structured, predictable, repeatable approach – “activities” change between projects resulting in changing roles and responsibilities, varying participation from the user community and unpredictability in how the applications are going to be delivered.

Though the IT industry has not yet established the best or ultimate methodology/lifecycle for delivering applications and projects, it has evolved to understand that a project team that recognizes and applies the concept of deliverables/artifacts/work products has a higher likelihood of delivering a quality application/project on time and within budget. Conversely, a project team that does not apply the concept of deliverables/artifacts/work products is more prone to spending time and resources on performing “activities” that may not result in delivering the application/project on time and within budget.


Cameron Watson

Cameron Watson is the President of QAIassist. QAIassist is the industry recognized benchmark in information technology (IT) methodologies for small and mid-sized business ( SMB’s ) – including the certification and support of practitioners delivering QAIassist IT Methodology solutions. Article authored by Cameron Watson – President of QAIassist. Visit QAIassist's website—