Getting your techs to enter time

I’ve worked in IT for 20+ years. I’ve worked at large enterprise systems integrators, small IT support companies, and run my own consulting group. I’ve run teams of 5 and teams of 50. No matter the place, no matter who I talk to in the industry, one of the most common issues people struggle with is time management and timesheet entry.

What strategies have people found successful in getting people to enter their time be accountable to this responsibility? Also, how do you manage your workload so that you don’t feel overwhelmed?

Here are a few I've found successful.

1. Explain why it’s necessary

It’s amazing how much a little bit of education can change someone’s feeling about having to do something. When onboarding someone, explain to them, “We need you to enter your time. Without your time entry, we can’t create invoices for the clients, which means we don’t get paid. So it’s pretty important. This is why I’ll be persistent about you getting your time entered.” Even if you don’t need the time entry for invoices, just substitute the WHY on the time entry, explain how it fits in the company process. If people realize it’s not time entry for time entries sake they may put up less of a fight.

2. Make it easy

The more cumbersome the time entry is, the less likely people will be compliant with the process. This kind of true of anything, but if time entry is important to your business, you need to spend the time to remove the fat/overhead from the process.

3. Prioritization

One of the major reasons people get overwhelmed is a lack of focus. There is only one thing you can do at a time. (check the research multitasking doesn’t work) Focusing on what is important. Making small gains feeds momentum. Anytime someone showed up to my office overwhelmed I loved working with them to write out on the whiteboard all the things they felt they needed to do. We would discuss urgency and importance of each. Stack rank the top three things and send them on their way. “Focus on these three first. If you need more help come back and see me after.” Usually, they just needed perspective to break out of the overwhelmed state. They rarely came back soon for help with the next three things.

4. Train them

What makes humans amazing is our ability to contemplate and influence the future. We are terrible at influencing the past, but we sure do spend a lot of time on the past. Switch your thinking and focus on the future. Train yourself and your staff on how you want things to be done in the future, then give them feedback to ensure they follow their training. Forget about what people have or have not done. Focus on what you want them to do. Train them, support them, and coach them.

I’m passionate about helping MSP techs gets more done with less stress and a sense of greater control, so I built the MSP Productivity Accelerator Course. It teaches you techniques of the GTD (Getting Things Done) methodology and how to manage your workload in the Connectwise. I did this type of training in person a lot and people always found it helpful. If you want yourself and your team to be better at managing your time and staying on top of the work in your PSA check it out.


MSP Documentation Systems

Love it or hate it, documentation is critical for effective IT support. Techs having access to documentation about the infrastructure they support will dramatically reduce the time it takes them to resolve issues. Documentation will also increase the quality of support by creating repeatable procedures.

Like many things in business and technology, there is a spectrum of maturity in how organizations approach documentation. On the low maturity end groups may just create a bunch of folders and documents on a file share or maybe they are sharing a Onenote page with loose notes. Here is a list of documentation systems that can help get your documentation from a messy garage full of unorganized junk to an F1 garage where you could eat off the floor and everything is in its place.

IT Glue

My favorite tool is IT Glue. If you run a managed service provider (MSP), IT Glue should be the frontrunner for your documentation platform. It is purpose built for MSPs with powerful features like built-in sync to your PSA and RMM tools, like Connectwise, Autotask, Labtech, and Kaseya.

IT Glue interface

IT Glue interface

Some of my other favorite features of IT Glue is that everything in the system can be linked together. When you open an asset like a Virtual Server, it will show you what Host the server sits on, what network switch that server is attached to, standard operating procedures (SOPs) related to those systems and passwords you may require when working on those systems. All of this information is at your fingertips, hyperlinked together. There are other subtle, but powerful features, like the completeness page. This page shows each client and the percentage of their documentation that is completed. This is useful when onboarding a new client and you can see how much of the documentation you have captured. Another key advantage of IT Glue is that you can share the documentation with the client online. You can also produce physical runbooks to print out, but only if you have the enterprise package.

There are dozens of other powerful features in IT Glue, if you’re not familiar check out their webinars for more details.

One of the key negatives about IT Glue that people note is its price. Also, IT Glue used to have a 5 seat minimum, but they recently changed this policy.

  • Price - $19/user/mth (Basic) to $39/user/mth (Enterprise)

  • Pros

    • Mature platform

    • API & Integration with PSA/RMM/etc.

    • Domain Tracking

    • Linked asset and documents

  • Cons

    • Limited customization

Recognizing that IT Glue may not be for everyone, here are some alternative platforms to review.


If you have more time than money, Confluence might be a useful alternative for you. The major plus of Confluence is that it’s dirt cheap for small teams. $10/mth for up to 10 users.

Confluence is a great wiki and it’s highly customizable, but it will take a serious investment of time to build the basic structure of your documentation platform.

Confluence Interface

Confluence Interface

Confluence has a large community so you can find templates and plugins that may help you replicate some of the more advanced features in other platforms, but it will take an investment of time and the additional plugins cost can quickly add up. One other warning, the SaaS version of confluence can be a bit slow, so I would suggest you get the self-hosted version after you’ve tested it out.

  • Price - Cheap!

    • Cloud

      • 10/mth for <10 users

      • $5/mth/user >10 users

    • Self-hosted

      • $10 one time <10 users

      • $60/user one time with scaling discount

  • Pros

    • Cost-effective

    • Highly customizable

  • Cons

    • No RMM/PSA Integration

    • Requires a lot of time to setup and customize

    • Cost goes up as you have to buy additional add-ons for features

IT Boost

IT Boost is a newer entrant to the market and shows promise as a mature solution. IT Boost seems to have a lot of feature parity to IT Glue and their dev cycles are very fast. It’s worth tracking their development and position in the market.

  • Price - $50/user/mth

  • Pros

    • Documentation + business dashboards + customer satisfaction surveys

    • PSA/RMM Integration

    • VOIP integration

  • Cons

    • Pricey

    • Fast dev. cycle comes with bugs.

IT Boost Ticket Portal?

IT Boost Ticket Portal?

Passportal docs

Passportal is a well established solution for managing passwords for MSPs. Recently they have been working on a documentation solution. It’s still early days of the development of the documentation platform, but it will be worth watching them to see what the solution develops into.

  • Pricing - $15 - 20

  • Pros

    • Combine Passportal Ocular functions with documentation

  • Cons

    • Younger in its dev cycle. Not as feature rich as others

SI Portal

The last noteable solution in the field SI Portal. Honestly, this one needs some work. The basic structure of the platform is similar to IT Glue, but consistent industry feedback says that it’s “unpolished.”  This is reinforced by the fact that when I browsed around on the demo portal it throws all kinds of errors and appears broken. It doesn’t exactly engender trust.

  • Pricing - $15/mth/user

  • Pros

    • Integration to PSA/RMM

    • Cheaper

  • Cons

    • Mixed market feedback

SI Portal Interface

SI Portal Interface

Honorable Mention

  • Stella - Syncs with Connectwise, like a pre-structured confluence.

  • Bizdox - Connectwise solution, which apparently has come back on the CW roadmap. Keep an eye out for future announcements.

  • Docuwiki - DIY, Open Source, Free.

Regardless of the direction, you go. Investing in a documentation platform is worth your time and money. Using a standard system will drive standardization and improve your team's results.

Just remember that documentation is a cultural process, you must be ready to drive the cultural change necessary to sustain a documentation culture. You will fail if you just buy the platform and expect people to use it. Training time, project work, and targets are required to get the team using the system in a way that will drive the results you hope to see.

Improve your project Management Practices - Conducting a Project Kickoff and Close

Not planning for success, is the same as planning to fail. 

In an earlier blog post I explored 5 measures of your project management maturity. You can refer to my blog post here.  

In this post we'll dive deep on the importance of a project kick-off and close.

If you're not conducting kick-off meetings you're missing an opportunity to set your projects up for success. If you're not conducting a project close meeting, you are missing a valuable opportunity to learn to apply lessons from every project that will make subsequent projects more mature. 

Pre-Meeting prep required? 

In keeping with the 80/20 rule. 80% of your project meetings should involve a kick-off and close. The kick-off meeting should involve the project manager(PM), the delivery team, and the stakeholder(s). In some cases, you can even run a prep meeting with just your internal team before involving the stakeholder. This can be a simple 15-minute review of the project to ensure the internal team is clear on the project approach so you appear better prepared once the stakeholder is attending. Alternatively, you could provide the required reading for the internal team before they join the kick-off call. Whether this shortcut works for you will depend largely on your level of preparation and your team's adherence to reading the materials. If your process maturity is low, you should probably stick to the pre-meeting method first, then graduate to the required reading approach later. 

Conducting a Kick-off Meeting 

Once the project scope of work (SOW) has been signed off, schedule the kick-off call with the client. Getting the kick-off scheduled quickly is the first indication to the stakeholder that you are organized and responsive. If it makes sense to conduct the meeting in-person than you can, but doing it over the web is generally just fine.  

As with any mature meeting, you will want to outline the agenda in the invite. Here are the primary topics you will want to cover in the kick-off. 

  1. Introductions 
  2. Review Scope 
  3. Review RACI 
  4. Reporting

1. Introductions 

It's important to give the team context to the project. As Simon Sinek famously says, "start with why." Why are we working on this project? Why has the client asked to engage in this project? Are there any specifics to the project that will be important to be aware of? Is the client doing the project to meet some regulatory requirement like HIPPA? Is this project the first step in preparing the company to implement a new ERP? These details matter because they give the team context to what the purpose of the project is. 

It's also important to introduce the team to the stakeholders of the project. There is some psychological safety in knowing the people involved in doing the work. After all, people do business with other people. Capitalize on this opportunity to drive home trust of the delivery team. Speak to their experience and success in delivering these sorts of projects in the past.  

2. Review Scope 

Reviewing the scope with the client is critical. Formalizing what work the project will include will give you a stronger position to defend the scope against creep. This is your opportunity to clearly state what the expectations of the project are. What is in scope, what is out of scope, when the project will start, when the project will end, and what the end state will look like. Low maturity project groups either don't have SOWs or they skip over reviewing the SOW in detail with the client. This creates a risk of having the client's opinion become the governing truth of a project.  If you find there is a lack of alignment on the scope, consider if the project can proceed or if the scope needs to be re-visited. In some cases, your team may have missed something that needs to be in scope. 

3. Review RACI 

RACI for those unfamiliar stands for: 





Detail to the client and the team who is responsible for what deliverables. Also, outline who are the contact points between the teams. If there are multiple people or teams involved in the project it's important to clarify who is involved at what point in the project. For example, a technical staff member is responsible for provisioning servers and configuring the network switches. The project manager is accountable for the delivery of the project and the communication to all team members. The client’s internal IT team needs to be consulted to coordinate any change windows or outages to the network. The client stakeholder(s) need to be informed about the progress of the project or any roadblocks that are encountered through the course of the delivery. The RACI matrix will grow in complexity with the number of deliverables and number of participants of the project. Be as detailed as possible by assigning individual tasks to responsible team members. 

4. Reporting 

Reporting is a key component to any successful project. How often you report on the project, how you report to the team, and stakeholders will vary depending on the complexity and timeline of the project. As a general standard, I suggest starting with weekly reporting via a scheduled phone-call/web meeting. The trick to making this not a burden is getting everyone to agree that this will be a very fast meeting. It should take no longer than 10 minutes. Come prepared, if you're asking your team for an update with the client on the line you're wasting everyone's time. The implementation person should be reporting their work to the PM in a PM tool, or simply via email. The PM will report the status of the project simply as green, yellow, or red. If the project is not green, there needs to be a plan to get the project back on track. 

if you’re asking your team for an update with the client on the line you’re wasting everyone’s time.

As a part of the kick-off you can ask the client if they would prefer to just have a weekly email update instead of a status call, but as much as possible, stick with an actual meeting. Especially in the early phase of the project. The beginning of a project is always the riskiest. Scheduling conflicts, missing equipment, and other issues will more likely pop-up early. You want to make sure the team is well connected until the project is in full-motion.  

Conducting a Project Close 

Once the project has been completed and all the deliverables have been met, it is important to formally close the project. The kick-off clearly sets out a vision for what success looks like. The project wrap-up meeting measures the performance of your project against that vision. One of my favorite quotes is from Peter Drucker, "What gets measured gets managed." If you're not doing a project wrap-up you're missing a huge opportunity to improve your delivery by simply analyzing, "What went well?", "What needs improvement?" Here are the key components of a mature project wrap-up meeting. 

  1. Review completed deliverables 
  2. Have client formally agree to close the project 
  3. Request feedback on the project 
  4. Review budget performance 

1. Review Completed Deliverables 

In the kick-off, you detailed the project deliverables. To wrap the project, it is important to state that these are completed. You can also provide a tiny bit of color to each deliverable. Maybe noting a roadblock that was overcome. Also, if there were any scope changes that were made, especially additions to the scope, these should be highlighted. 

2. Has the Client Formally Agree to Close the Project? 

In kicking off the project we noted it was important to have the client agree to the scope and deliverables. At the end of the project, it is important to have the client agree that those deliverables have been accomplished. This could require the client to sign a document, acknowledge an email, or simply state that they agree the project is complete. One of the key reasons for this is to ensure your project team is protected from issues regarding scope and testing. Far too often I have seen situations where the client holds the project hostage by continuing to add small changes to the project. In some cases, the client will come back weeks or months later suggesting that something was missed and they need the project team to come back and add/fix something. Most often this is the result of poor testing on their part. If you have some formal documentation of the project being closed, you can at least have a stronger footing to add additional revenue for the work required.  

3. Request Feedback on The Project 

Asking someone for feedback can be tough. The majority of the time they will likely just tell you, "It was great." or "No problems." The truth is they may have some small grievances, but they also don't want to insult you. It helps to be much more specific in what you ask for. Instead of asking, "How did it go?" you could ask more targeted questions like,  

  • Did you feel like you were kept up to date on the progress of the project? 
  • Did you hear any concerns raised from your team? 
  • If we did this project again, what was one thing that would have made it a better experience for you? 

These types of specific questions will help to frame more constructive feedback. Be cognizant that the client may be uneasy about sharing negative feedback with you, especially if the delivery team is involved in the project close meeting. If you get an indication from the client that they have some concerns that they are not sharing, follow-up with them in a more private conversation. Cues that they are not being entirely honest will be things like, pausing or stammering when providing feedback. If in person there will be body-language cues like crossing arms or adjusting their position in the seat. 

4. Review Budget and Performance 

Unless there is a reason to share the fiscal performance of the project with the client, this step is likely an internal review. 

If nothing else, you should measure the performance of the project by the accuracy of the budgeted hours. If you expected the project to take 64 hours and you completed the work in 62 hours, awesome! If it took you 68 hours, you did okay. If your work effort is beyond a 10% variance, it's important that you understand why. When I build a project scope, I usually factor in a 10% variance to account for overrun on administrative time, and small issues. This is fair in fixed-fee projects especially. If you manage your scope well, you shouldn't overrun the budget with work that wasn't accounted for. If your variance consistently runs at 10-25%, you're leaving money on the table or running an unprofitable department. Top line revenue is great, but your business won't survive if you have no margin.  

As you mature your project management practices you can start to measure more specific goals, like variance hours on specific deliverables or tasks. Where you find variances, dig deeper. Understand why those variances occurred and develop processes to eliminate or at least mitigate those issues from recurring in future projects. The Project closure review should be a cold hard look at the performance of the project, don't convince yourself that problems were unavoidable or simply hope you'll do better next time. 

Set goals, measure performance, make plans for improvement, repeat. 

5 Simple Ways to Measure Your Project Management Maturity

5 steps for effective project delivery

It doesn't matter what tools you use to manage your projects. It doesn't matter if you use Agile, follow the PMBOK, or are training for Six Sigma.

What matters in projects is "Who, does What, by When."

Don't feel bad. Most tech companies are counterintuitively terrible at project management. Gartner data suggests that over 80% of technology projects fail to deliver on time and on the budget.  Granted, this includes software projects which are much more subject to scope creep than traditional systems infrastructure. The simple fact is most technology organizations are just getting by with their PM practices. In most cases, people look for a tool to solve all of their communications, accountability, and collaboration needs. Often they are thinking, "If we just had the tool to solve x, we would be okay." In most cases, people need to fall back to basics. 
Who, does what, by when, keep people accountable, and you end up with productivity magic.

Here are simple measures of how well you are managing your projects.

1. Is there a project charter or statement of work (SOW)?

The sales guy has a hot new deal with a client that is rushing to get this server migration finished before they end a support contract.... Is your skin crawling yet? Yes, this is all too common. In our genuine efforts to satisfy the client, we rush the project through without proper scoping. These projects are rarely successful and risk the trust of the client. Don't stand in the way of revenue, but also balance the need for sufficient planning. Have the sales and technical groups establish that a 24-48hr return time on requested SOWs is the standard. If the sales team can trust that deliverable will get back to them within a reasonable time, they will extend more trust to the team. Ensure both parties agree that having a SOW will produce better results for the business and the client. Have a SOW for every project of a reasonable size. 

2. Does the project have a reasonable end date?

Parkinson's Law states that "Work expands so as to fill the time available for its completion." If your project has a statement of work you should know how much effort is involved. Therefore you should be able to schedule that work and determine what is a reasonable end date. For example, you have a project that will take two people at a total of 40 hours. Often people will schedule the work for a week. Which is unlikely to be successful. Instead, schedule the completion for two weeks out. Unless there is an urgency to the work, you're better to set a more reasonable deadline. Keep it tight, by having a deadline, but not so tight that you have no slack for issues. You also want to ensure you have enough time for activities like a kick-off, close, and status meetings. 

3. What is the communication rhythm?

Communication is the most critical tool in keeping projects on target. Unfortunately, communication is also one of the first things to slip when issues crop up. In order to defend against communication degrading your communication rhythm needs to be established and scheduled ahead of time. The type of communication is variable, but as much as possible try to over communicate. If nothing else, keep a high cadence of communication. If the project is active with lots of complexity a daily stand-up might be best. If the project is longer with clear milestones than weekly probably works. A higher cadence of shorter touch points defends the team from sitting in unnecessarily long status meetings without allowing large gaps that could derail the project.

4. What did we achieve last week?

Every status update people need to report on what has been achieved. NOT what hasn't been done. Are deliverables being achieved on the dates set? If not what is required to correct this? This is probably one of the hardest things a project manager has to do in managing the team. People so often want to tell you stories about why something hasn't been done. This fundamentally isn't important, especially in a status meeting. If necessary you can have a breakout meeting to review these types of issues, but it often isn't valuable input, especially for the entire team. If you find your team members rambling on about why something wasn't achieved simply stop them politely and ask them to think about what their plan is to get things back on track. Offer support in working up a plan if need be and that can be the focus of a breakout meeting. This approach will help you keep focused on moving forward rather than litigating the past failures. 

5. Did we have a kick-off and close?

Finally,  did the project start with a kick-off and end with a project close? In an eagerness to get started teams often skip the kick-off which is critically important for a number of reasons. The kick-off is a key component to establishing the parameters of the project including, reviewing the scope, setting the communication rhythm, setting expectations with the client/stakeholder, and reviewing scheduling. The project close also often gets skipped as the team gets busy and wants to move on to other things. A briefing after the project is complete is a valuable way to capture what went well, what did not, and how can we use that information to make future projects better.


Developing a higher level of maturity in how you deliver your projects is not something that will happen overnight. Projects by their nature are messy and complicated. Working on a single task by yourself in a day is straightforward, it has a low level of complexity. Working with even three people on a deliverable that have 15 steps and involves numerous people and/or systems is an order of magnitude more complex. Complex work requires planning and communication in order to be accomplished.

If you're just getting started focus simply on who, does what, by when. Then layer in the above 5 components and your process will already be more mature than the typical organization. If you'd like some support in getting the basics implemented or if you're ready to move your maturity to the next level be sure to reach out to Evolved for a more detailed review of your processes (or lack thereof). 

20 Business Applications to Evolve Your Business

Cloud is the new delivery model for business applications. I've created a reference guide for 20 applications that can give your business a productivity boost. Financial management, file sharing, project management, voice/video collaboration and more. 

Grab your copy of this free guide, now.