When you drop work that is complex, lengthy, or that has lots of parts into a ticket, you quickly lose track of details and create risks you won’t be able to see until disaster hits. While it’s tempting to disguise complex projects as service tickets, it isn’t an effective way to manage projects.
Louis Bagdonas, Senior Program Manager, MSPs, and Bucky Jobe, VP of Operations at Moovila, break it down.
Can I manage a project with one ticket?
When you cram a project into one service ticket, you create a mess that hides details from the project manager and leaves the engineer overloaded.
Like this illustration of a strained truck, you cannot find key details when you develop a project into a single service ticket.
“All these details are piled into one object. There's no way to sift through that information before your project is off the rails, over budget, over deadline, and customers are frustrated,” explains Bagdonas.
With no triggers to flag when a task is late, how delays affect other tasks, and when that bucket of work is at risk, you must be hyper vigilant, get on the phone, call meetings, then dig into notes to find out what is happening.
Why do projickets happen?
We’ve heard dozens of nicknames for the practice of putting projects into tickets. Our favorite is “Projicket.” It’s a portmanteau word, blending project and ticket. It’s a fun word. But it’s a dangerous practice. People often think projickets are easier than taking time to build a project plan.
“One of the biggest reasons people do this,” says Jobe, “is that they don't have the toolset or training to build out well-structured projects. They haven’t built a process or established a methodology for handling work that falls into this category.”
Recognizing work that exceeds the capacity of a ticket is a skill. It’s a judgement call and is specific to the work your MSP does. This might seem faster to get started without stopping to plan.
“It actually creates a lot of risk,” says Bagdonas. “It also creates complexity when managing and tracking that project, especially as things change. People say, ‘It's easier.” Our engineers don’t want to put time into building projects. They want a bucket to throw hours into.’ But if you build a good plan that tells people when each piece of work needs to happen, it’s easier to look at their day and see what’s needed now.”
Signs that a ticket is really a project
Making the judgment call on which of your jobs is a service ticket and which should be spun into a project depends on the work, your team, the client, plus other factors.
A service ticket includes manageable chunks of work. Look at the job you are dropping into the ticket. Can it be broken into smaller tasks? Are some tasks dependent on others? Will the job require several days? These questions decide if a ticket should be a project.
“I suggest you get your stakeholders – the resources and engineers that are doing the work – involved,” says Jobe. “Let them weigh in on how to break the work apart. How do we define each task? What type of resource needs to be assigned to it? How long is it going to take?”
Methodology: turning tickets into projects
What is the art of determining when a projicket should be a project and breaking that project into manageable chunks?
There are two best practices that help:
- Duration should generally not be less than a day.
- Duration is typically not more than 30 days. At an MSP, max is around two weeks.
Be careful of micromanaging, though. It is tempting to get deep into chunking projects into bits. This will create a new set of problems. If you are creating tasks that can be done in minutes, unless they are big milestones, you are overdoing it. Typically, a task should take an hour.
Remember, you don’t have to perfect this immediately. Start, then allow your system to improve over time.
“Starting out, I recommend you work on budgeted hours, durations, and dependencies,” says Bagdonas. “If you start with those three things, your life becomes easier.”
As you work on projects, your system will improve. If you nurture your system, build a feedback loop to check your plan, document what happened, and use what you learned, that project plan will improve your processes.
“A benefit of having this work broken into manageable chunks and stored in a work bucket that can handle it, is that you’re exposing what was once hidden,” says Jobe. “Seeing what went well, what estimates were accurate, and which were off – and correct that in your work plan – continuously improves your work.”
Once you master budgeted hours, durations, and dependencies, the next things to add to your plan are the resource type assigned to a task, the skills necessary for the work, and the cost of the person who can do that work.
With this project detail, you will approach automated skills-based resource selection, tighter budgets, more accurate scoping, and high-level automated financial analysis.
Projickets cause project pain
Most project pain is caused by a single decision to put complex projects into a ticket. Projickets make you rely on intuition to recognize project risks.
Finding work delays means calling meetings and grilling your team. Are you in danger of missing a billable milestone? Do you have the resources to do the work you are committed to? When it comes to communicating when there is an emergency, it falls to the project manager to notice, panic, and get everyone to pay attention.
“We have a running joke that project managers are firefighters,” says Jobe. “But they should be fire inspectors. They shouldn’t be putting out fires. They should be checking to make sure things are happening according to plan.”
Watch the full webinar and listen to Louis and Bucky explain in depth here.
