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?
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 projec
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.
Let's say you want to create a project for evaluating a vendor. You may start by listing off all the tasks related to it. For example, "check the web for reviews",
"request references", etc.
If you're the type of company that deals with hiring a lot of vendors, you may do this multiple times a month..
This 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.
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.
Another problem with trying to manage any project or define a process is vaguely defined tasks. Instead of simply adding a broad task like "market research" to your project, think about the specifics involved in said research.
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"?
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.
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.
