Whether at work or at home, just because you are busy does not mean that you are productive. You can work a whole day on a task, but at the end of day feel like you did not accomplish anything. You may even dread the thought of going back the next day to do more of the same thing. Or perhaps you came home at the end of the day feeling like you are on top of the world and could accomplish anything. Furthermore, you cannot wait to go back tomorrow and do it all over again. Does that define the difference between busy and productive? If so, what does that mean if you never feel productive, just busy?
There may be some truth to the statement that one person’s busy is another person’s productive day. Some people just seem to like certain tasks and hate others. Does that mean the difference is all in your head? Perhaps to some extent that is true, but that is not the whole picture. Let us look at some examples of tasks that may get classified as either busy work or productive work.
Suppose you are the manager at ACME Software Inc. and you have two forms that you need immediately. You have one team of traditional web programmers who build pages with HTML, CSS and ASP.NET so you give one form to them. You have a second team that has been responsible for building your internal employee intranet and collaboration sites using SharePoint. You heard that they can use a tool called InfoPath to create forms so you give the second form to them. Both groups start on their respective forms on the same day.
The SharePoint team builds their form, tests it, and deploys it to production by the end of the week. The web programmers appear to be working just as hard but they do not deploy their finished and tested form until the middle of the next week.
Both teams were busy as far as you can tell, but you might think that the SharePoint team was more productive. Were they really more productive because their skills were better or that they were better programmers, or were they more productive because the tools they used, InfoPath to design the form, SharePoint Designer to create the workflow, and SharePoint to deploy the finished form to the production intranet site, allowed them to appear to be more productive? Experience is always a factor. An experienced .NET development team could outperform a novice SharePoint team. On the other hand, good productivity tools can go a long way toward improving the productivity of a developer at any level. However, no productivity tool will improve productivity unless people receive training and have the time to learn how to use the tool, but that is another story.
So is productivity about the tools you use to get the job done? Does getting the job done faster define productivity while other people without those teams are merely busy?
Let us look at two teams where each team over the past year has worked on 3 special ‘emergency’ projects for management. In the case of the first team, while they completed all three projects, none of the three projects went into production. In one case, the project kept changing every few days because there was no well define set of requirements when the project begin. Management just assumed that making changes in the middle of the project could be easily managed by the team without affecting the delivery date which kept getting pushed back. Another project did not go into production because even after it was completed, there was no executive sponsor to see that others in the organization actually used the new program instead of the old manual way of processing their data. Finally, the third project died a slow lingering death when no one in management would take responsibility for the design and sign-off on the specifications.
The second team had projects in which all of the specifications for the project were clearly defined at the start of the project, management quickly signed off on the design, and when the project was complete, management required all company users to switch to the new programs to guarantee consistent and timely processing of the data.
Both teams were busy, but it might be argued that only the second team was productive. In fact, at the end of the year, the first team was on the verge of falling apart. Some of the team members had already transferred to other groups. Others had left the company entirely. They had been busy, but they did not feel that they had accomplished anything. On the other hand, the second team is ‘pumped’ by being part of the successful implementation of their projects. Some have even turned down job offers from other departments and other companies because they felt like they were really making a difference. In fact, the second team looked forward to new requests for challenges from management while the first team viewed new requests as merely another task to keep them busy, but nothing to get excited about because probably no one will ever use it anyway.
Are you busy or are you productive? If you do not go home at night feeling that you were productive today, what can you do to feel productive tomorrow? If you are in management, how can you work better with your teams to insure that they feel like their work is a productive addition to the organization? Remember the statement, “We work to live. We do not live to work.” If you do not feel productive at the end of the day or if your team does not feel productive, change something and keep changing things until you do. Being busy is better than not being busy. However, the satisfaction of feeling productive is much better than just feeling busy. In the end, life is too short to be just busy. Go out tomorrow and make a difference for your team and for yourself experiencing the satisfaction of being productive.
C’ya next time.