Activities vs. phases

Clarity in writing is essential for successful scientific communication. A pet peeve of mine is the confusion between activity and phase, when discussing about any process, but specifically research processes based on design science.

An activity is something that you do. You applied a method. You searched the web. You went for a walk. A phase is a period of time; often you perform activities within such a period of time. If there is one phase, there probably are other phases, those that came before and/or those that came after. Having phases implies a sequencing of these phases and activities bound to them.

Design science defines six major activities: Problem identification, objective definition, solution design, demonstration, evaluation, publication. If you chain them up in sequence, then you can also call each activity a phase, implying that within the given time period, you performed the specific activity. Design science suggests that you try these activities in sequence, leading to six phases. However, about any method author is also adamant that design science is an iterative process where you don’t have to strictly follow this order of 1 to 6. It is common and alright to return from later design science activities to earlier design science activities, e.g. to stop solution design and return to problem identification.

If you take an activity and use its start time and end time to mark the start and end of a phase, then in a research design based on design science, you will have only six different activities, but you can have any number of phases. As a consequence, you shouldn’t be talking about the problem identification phase, only that you performed problem identification and that when you reached theoretical saturation, you moved on to objective definition.

It is the same in software development processes. In Scrum, for example, a simple sequence of activities is planning, execution, review, release, and retrospective (the core elements of a sprint). A sprint is phase, each activity within a sprint may mark a phase, but the number of different activities (at this level of abstraction) is small while you get any number of phases as time progresses.

Which is to say, you should mostly be talking about activities, and only if there is a particular reason to talk about how they are sequenced in time, you should be talking about phases in which you perform these activities.

Posted on

Comments

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Share the Joy

Share on LinkedIn

Share by email

Share on Twitter / X

Share on WhatsApp

Research Projects

Making free and open data easy, safe, and reliable to use
Bringing business intelligence to engineering management
Making open source in products easy, safe, and fun to use