We are a software company being outsourced by another company. Procedures for meetings, new projects, and to-do lists are emails, emails and more emails; no calling, no skyping, just emails.

By this I mean, when there is a need to change content, we get an email. If the client wants to upload a gallery, we get another email. If there's a bug somewhere, we get more emails. After you can't catch up, you just get a lot of unread emails with different subject lines, not knowing what they refer to or when they're due.

This, and the back-and-forth emails caused by mis-understandings, are having a massive impact on our time and productivity by having to link all the different emails on the different pages to their respective project, or tracking down a lost email about some changes that needed to be made to one of the hundred projects.

My question is: Is there a more easy and efficient procedure we can follow (our company and the one which is outsourcing us) to reduce the time wasted, and the confusion, increase delivery time, and making it easier to find specific tasks?


4 Answers 4



You are missing processes, not tools. Specifically, you are missing a formal change-management process that handles your bugs, content updates, and other important tasks in a controlled fashion.

Change Management

At a basic level, change management can be thought of as a process for identifying, controlling, and tracking changes within a system. Currently, your change management process is ill-defined because:

  1. It consists of a pool of emails, which isn't easy to search, manage, or prioritize.
  2. It's hard to enforce administrative controls like formal sign-offs via email.
  3. It's unclear from your post who (if anyone) is responsible for email intake, prioritization, resource allocation, assignment, or sign-off. These things may not even be formally defined within your organization at all.
  4. Your current process makes no distinction between bugs and new work.

Change management, and to a lesser extent bug-tracking and feature planning, should be formal processes that are well-documented and consistently applied. Even an email-based queue could theoretically work just fine if the process itself was properly defined, documented, and followed within your organization.

Recommendations for Improving Your Process

First, apply CodeGnome's Law:

"Define your process, then automate it."

That means documenting your as-is processes and procedures for managing bugs, new content, or client change requests. It's generally best to document what people are really doing, rather than what they ought to be doing, but either will give you a baseline. This can be time-consuming, but it an essential starting point.

Next, determine where your as-is process is not being followed (often a sign of processes that hinder rather than help), or where following the process actually provides poor results. This will help you evaluate the design- and operational-effectiveness of your current processes, and identify areas that could be improved through process engineering.

Then, define your to-be processes and procedures. For example, define the new intake process for content change requests, including the roles required by the process and the procedures that task-performers will need to follow to process the change requests properly. These new processes will form the backbone of your new-and-improved workflow, and should be simple, clear, and repeatable. Ideally, they should be things you can do with paper and pencil; automation comes later.

Finally, once you have a process that is designed to address your organization's specific needs and a set of procedures to implement those processes in a traceable and repeatable fashion, then and only then should you automate those processes. Doing it the other way around will pretty much ensure that your organization will contort itself to fit within the constraints of a generic tool, rather than automating its unique processes.


You should definitely use some project tracker (or issue tracker). For small and middle sized teams and project Asana or Basecamp are good. Both are in the cloud. If you looking for something really customizable or for bigger teams, then JIRA from Atlassian is the best for you.

Team todo lists are IMO not so efficient for project management. But if you are really looking just for simple solution then you can try Trello.


As @stan pointed out, Jira tracking issues would be great. Trello or Wunderlist for ToDO.

I would suggest some readings to sync better like https://zapier.com/blog/how-manage-remote-team/ https://zapier.com/blog/how-build-culture-remote-team/ There are more. I am sure you might have researched.

Personally I find Jira & trello to be excellent, besides syncing up with remote counter parts over video conferences.

Hope this helps.


I think the real problem might not be the e-mail thing, but the fact that work / change requests come in an unordered manner. Indeed, as far as I understand your question, it seems that the team handles the e-mailed requests as if they were all of the same (very high) priority, which produces this messy situation.

I would recommend to consider the situation in a more service-oriented way : try and identify different kinds of work items, and agree with the company which is outsourcing you on classes of service based on their priority / urgency.

You would also need to explicitly limit the work in progress for each class of service. By doing so you would be able to better schedule the work without feeling like you have a thousand requests in progress at the same. Delivery times variance would also narrow down.

Maybe you could have a look at the Kanban Method, and read http://positiveincline.com/index.php/2011/02/kanban-prioritisation-and-scheduling-with-classes-of-service/

Not the answer you're looking for? Browse other questions tagged or ask your own question.