Some Implications of the Overlap Between Project and Process Roles
Hanzah Khan’s article The Difference Between Project and Processes states, based on a reading of start-up expert Derek Lidow, that confusing the two can be dangerous for the growing enterprise. Anyone who has ever managed projects as part of a growing (or shrinking) organization will understand the differences between the two and will also appreciate why it’s often hard to distinguish between them in the real world.
The basic distinction, according to Lidow, comes down to this:
- Projects: have never done this before.
- Processes: do the same thing repetitively.
Figure 1 illustrates why it can be hard to distinguish between the two in small or growing organizations where people typically have to wear several different hats:
Figure 1. Overlap of Process and Project Roles
Not only is it common for people to work on multiple projects and project processes, they can also perform different roles (for example, management or staff) across different projects and or processes. At any given time the same individual can be managing multiple projects, managing multiple processes inside and outside those projects, and can be serving as a staff member on multiple projects and processes as well.
Another consideration is that, even when people are involved with projects where they have “… never done this before,” they often try to make repeatable how some tasks within the project are performed. How this is done requires a balancing of many factors as in the work I’m doing with Michael Kaplan’s SoftPMO project management services.
Even regularized or repeatable processes need to be introduced and taught to people for whom the processes might appear to be new or innovative, even when the processes have been in place for years; what’s new to one person can be “old hat” to another.
So, while it’s true that projects and processes can be distinguished at a theoretical or functional level, when looked at from an individual’s perspective in a smaller or start up organization, the distinction can break down. While I haven’t yet read Lidow’s work, I can see how, even in such normally confusing circumstances, it might be bad to fail to recognize the different management and systems implications of the two.
As a project manager in the number of organizations where regularization of processes in both projects and non-project situations has been sought, the most important thing to understand is why the work is being done and to communicate this to the individual worker. This is true for both projects and processes especially as we continue to move away from repetitive manufacturing or clerical work towards more knowledge- and information-intensive work where individual creativity and initiative are valued.
Copyright © 2014 by Dennis D. McDonald