Project Management Lifecycle
At the end of the day, your work falls under the project management lifecycle.
- Initiation
- Planning
- Executing
- Monitoring & Control
- Closing
The size or scope of the project doesn't really impact this. A project that's "just" design concepts, follows all of these processes. As does just creating a whitepaper for an earlier released product. Or doing end-to-end software development work.
PMBOK Chapter 1.5 The Project Life Cycle
A Project life cycle is the series of phases that a project passes through from its start to its completion. A project phase is a collection of logically related project activities that culminates in the completion of one or more deliverables. the phases can be sequential, iterative, or overlapping. the names, number, and duration of the project phases are determined by the management and control needs of the organization(s) involved in the project, the nature of the project itself, and its area of application. Phases are time bound, with a start and end or control point (sometimes referred to as a phase review, phase gate, control gate, or other similar term). At the control point, the project charter and business documents are reexamined based on the current environment. At that time, the project's performance is compared to the project management plan to determine if the project should be changed, terminated, or continue as planned.
The project life cycle can be influenced by the unique aspects of the organization, industry, development method, or technology employed. While every project has a start and end, the specific deliverables and work that take place vary widely depending on the project. The life cycle provides the basic framework for managing the project, regardless of the specific work involved.
Though project vary in size and the amount of complexity they contain, a typical project can be mapped to the following project life cycle structure:
- Starting the project
- Organizing and preparing
- Carrying out the work
- Closing the project
OPAs (Organization Process Assets)
What it sounds like from your description is your company has different service offerings (development, test, wire-framing, etc.) and those very likely have their own OPAs
PMBOK Chapter 1.10 Enterprise Environmental Factors and Organizational Process Assets
OPAs are the plans, processes, policies, procedures, and knowledge bases specific to and used by the performing organization. These assets influence the management of the project. Examples include by are not limited to: change control procedures, templates, information from previous projects, and lessons learned repositories. (Refer to section 2.3 in the PMBOK Guide for additional information OPAs).
Your company most likely has a template for a certain type or size of project. Some projects have a wide variety of project assets, attention from multiple teams and which get significant project documentation. While other projects have just one part-time person to execute something as small as a single task, which gets project documentation that could fit on the back of a cocktail napkin.
So, your organization is doing "project management". You can call the different types of projects whatever you like (OPA) and you can market your services any way you like (also, OPA). So calling it "Task-based services/development" is totally valid.
Similarly, it doesn't matter if you're doing "Agile", "Scrum" or "Waterfall" -- because each of those frameworks also follow the same basic lifecycle.
