The Project vs Process Dilemma
How Processes Disguised as Projects Can Hurt Your Business (and What You Need to Do About It Today)
Written by Alex Hughes
Project management is a term that gets thrown around a lot in the enterprise environment. These days, it seems that any organized effort that includes tasks with due dates is deemed to be a project.
But what if it isn't? Misidentifying it could set your project or initiative back at the very outset.
Ask yourself: "What are the main tasks for my next project?" If you answer with responses such as, "begin requisition," "send notification letter," or "log hours," ask yourself another question. "Is what I am describing actually a project?" Are you sure that it is not in fact a process that you are describing that just happens to have steps with due dates associated with them?
Process vs Project Venn Diagram
Traditionally, enterprise projects are one-off major endeavors that have resources dedicated to unique tasks that are specific to that one endeavor. When I think of a project, I think of things like replacing an office phone system or switching corporate health care providers. Basically, traditional projects are endeavors that are not part of the regular operational processes of the business.
The point here is that different people define "projects" and therefore "project management" differently. That said, when starting a project using project management software, it is important to define what your specific needs are and what type of "project" you are taking on. What I have found is that a lot of project management mistakes are made at the very beginning during the planning phases. As you might imagine, having project team managers and team members who all have different ideas as to what a project is could prove to be problematic. Here are three pointers to help keep you on track to a solid foundation when working with project management software.
Is it a project or a process?
As I mentioned before, more often than not when I ask a client to start listing off some main project tasks for me, they will say things like "feed client information into computer", "send kick-off letter", "request references", etc.
When I see this happening, I follow up the description with something like, "Okay, how many times do you do this per month?" The client then informs me that they do this "project" all the time.
What are you noticing about this description? What the client is describing in the aforementioned scenario is in fact a process, not a project. This just happens to be a process that requires due dates and sign offs. When starting your project, it is important to note that just because a particular task requires accountability from a certain person, and has a due date, does not necessarily mean that it a project task.
Let's say the project is "preparing a research report." If you're in the business of producing these types of reports on an ongoing basis, it's likely that you have a process, as shown in this flowchart:
Steps in the process can be broken down into sub-processes, with additional flowcharts, such as this:
Does this mean that you can't use dedicated project management software to help keep track of your operational processes? Not at all! It just means that you have to be prepared to repeat what the software treats as a project as many times as your business process requires you to do. So if there is a process you execute every week, you will need to be prepared to define tasks, associate resources, and build due dates every week. This, obviously, can be a repetitive and time-consuming chore.
Fortunately, SmartDraw can help you with either scenario, or both. Perhaps you have a process, as per the "report" example above, but also need to track each report as a project. Your project chart for a single report might look something like this:
For this project type, you can save repeated tasks and assignments into a task library that you can quickly load in to a new file every time you want to start a new repeated project. From there, all you have to do is add new dates.
Be as specific as possible
Another issue I frequently encounter with clients is vaguely defined tasks. When I ask a client to start listing off some major project tasks and I hear responses like "market research," I immediately ask something like, "So who is in charge of that? How do you report on that?" Often times, the client responds with, "Well, several people; it is actually quite complicated." Sound familiar?
I always respond by insisting that the client be more specific with the task. Ask yourself, if you were a project manager, would you rather see tasks like "Marketing" or tasks like "Complete Initial Social Media Research" and "Assemble List of Potential Product Names"? A quick look at this Gantt chart makes it easy to understand why a more detailed breakdown of tasks is a more effective way to ensure everyone understands all of the things they need to accomplish.
The point here is that the more specific the task, the easier it is to comprehend in the grand scheme of the project, assign to a specific person, and most importantly, report on.
Use the tool consistently
Finally, it is extremely important that whatever software you are using is used consistently by your team. This means that everyone involved in the project needs to be familiar with how the tool works but more importantly, use it in the same way. It is important to set the parameters of how your team will use the tool and account for any special uses and idiosyncrasies at the very beginning of the project. For example, if you want to highlight critical tasks in red, set that parameter at the beginning of the project and ensure that everyone is on the same page about it. After all, you wouldn't want to have your efforts derailed over something as trivial as mis-colored project chart lines.
Have you experienced the dilemma of managing processes that are disguised as projects? Do you have pointers to offer? We welcome your input. Share them in the comments section below!