An efficient project management software - a better information flow, more satisfied clients

While developing support tickets software, we quickly noticed a need to differentiate between the request received from the ticket creator and the job request sent to the programmer performing a given task.

We needed to develop an app that improves control over tickets, so that we could quickly and easily transfer customer generated tickets to the person performing those. By design, one of the main features of the app was the ability to control the time of execution which in return allows us to reliably determine the cost for any given task.

We knew that there are multiple standardized solutions that allow users to track information about clients requests and create tasks for individual project participants. Those usually provide huge functionalities attached to them, are complicated and in reality generate more work rather than improving it. Standardized task management software lacked some functionalities that are a day to day development process obstacles like the ability to assign tasks to multiple users from different departments and highlighting the task needed to be done based on clients request or followup technical information requests. This led us to a simple, yet important solution that requests made by the client must be differentiated from the task that development team receives but have to contain all of the information provided by the client.

We started developing the system that allows multiple tasks creation to one request with additional description, date and status of both.

At this stage we defined what will the user journey look like

1. After signing in the app, user can add a request for an ongoing project - for example, a bug report report or a system upgrade request.
2. The request information is sent to the email address of the project manager. After reviewing the request, the Manager assigns it to the appropriate type - if the request requires additional information, he adds a comment to the request. Based on the request, the manager creates and assigns it to the appropriate employees.
3. Information about the new task is sent to the email address of the employee (developer). When the task is completed, the developer changes the status of the task and completes the information about the time of completing the task. The system sends an email notification to the manager when the task is completed.
4. The manager performs acceptance tests and report any comments. If the task is completed correctly - he changes the status of the request, which immediately informs the Customer that the request is complete.

An important part of this structure is the ability to assign multiple tasks to a single request, while recording the creation date of both the request and the task, status updates and fulfillment of the request and on the task. This architecture ic crucial for software development purposes, where single request execution may require several tasks, specialists and thoroughly tested request execution.

The request is passed through three groups of recipients:

At this stage it is worth pointing out that each of the above groups needs a slightly different amount of information to perform their work properly. From the customer’s perspective, it is irrelevant whether the task will be split into one or more tasks and whether it will be performed by one or more people, nor does it matter to the developer whether the request is defined as additional functionality, a contractual one. The idea is simple - a given group should see only information that they need - in the most readable form and as well described as possible.

This influences every part of the app since even the tasks/requests list needs to look different for every user type. It is important that each group sees slightly different information as they priorities are largely in conjunction with each other.

Customer Account - requests list

After logging in to their account, the customer sees a list of their requests. Each request should contain detailed information about the request:

• ID - the identification number of the request
• Applies to - Project name
• Subject - Request Description
• Implementation status - tells user what stage the request is at - e.g., in progress, pending or completed
• Request Type - the request type is assigned by the manager after reviewing the request details, e.g. if it is an errors in the application or if it is a change in the way an existing feature is displayed/functioning
• The date on which the request was added
• Last updated - for example, if the status changes or new comment appeares

Developer Account - Task List

After logging in to their account, the user sees a list of their tasks. Each time they log in, they will find:

• Priority - request priority - high, medium and low is assigned automatically in relation to the planned date of processing the request. The date is assigned by the Project Manager.
• Name - Who the task is assigned to
• Applies - Project name
• Task- Description of the task
• The request number to which the task is connected
• Implementation status - Informs the manager what stage the task is at - new, pending, or completed The date on which the task was created
• Implementation time - the developer can specify the implementation time for the request here

Manager - Request List

After logging in to their account, the manager sees a list of entries and tasks attached to their projects. Each request should contain detailed information:

• ID- the identification number of the request
• Applies - Project name
• Subject - Request Description
• Implementation status - informs what stage the request is at - e.g., in progress, pending or completed
• Request Type - the request type is assigned by the manager after reviewing the request details, e.g. if it is an errors in the application or if it is a change in the way an existing feature is displayed/functioning
• The date on which the request was added
• Last updated - for example, if the status changes or new comment appears
• Pinned tasks
• • Priority - request priority - high, medium and low is assigned automatically in relation to the planned date of processing the request. The date is assigned by the Project Manager.
  • Name - Who the task is assigned to
  • ask- Description of the task
  • The date on which the task was created
  • Date of the task completion
  • Task status - specified by the developer
  • Implementation duration - specified by the developer

The distinction between tasks and requests, while maintaining a link between those two objects, is simple and effective solution that allow development teams to process requests fast and with minimal number of errors.

A similar principle can be applied to multiple support/services structures - e.g. computer support, car workshops, household appliances related services, etc. as well as digital products - including software, virtual servers, telephone services, printing services, etc. When thinking about any software solution, it is important to carefully analyze the needs of its receiving group, consider their needs and simplify the procedure that a given user has to go through in order to obtain the desired effect. For each form field or information that we add, it is worth considering whether it is relevant for the recipient, whether it can be removed, or whether it is necessary for the implementation of a given request. If the form/list/page is simple and short and contains only relevant information then users will be more likely to use the app - and the information they provide or receive will be more meaningful.