Project Management Process

This process has a number of components:

Tasks to complete during the project.
A system for maintaining a shared actions and issues log with the customer.
A set of internal tools for tracking issues and sharing information.

Project Tasks

All projects should include the following activities.

A Project Plan

During the Sales Process a high level timescale may have been discussed. At the beginning of the project, a detailed project plan (based on the timeline that was discussed) should be produced and shared with the customer.

The sooner this happens the better. If there are issues with meeting the customer’s expectations (e.g. Maybe a deadline was discussed in a sales meeting but the project was not approved for several weeks) it’s better to find out sooner rather than later.

The project plan should detail what project deliverables (either documents, or ‘user stories’) will be delivered and when. On a project delivering more than a handful of ‘user stories’ the stories will typically be broken down into multiple ‘sprints’. Sprints should last between 1 and 4 weeks and should end with a release of the software to the customer.

Kick Off Meeting

At the beginning of the project, a meeting should be organised to discuss the following items:

Present and agree the project plan.
Agree a schedule for regular project meetings/calls.
Agree key individuals and who should be involved in decision making.
Agree the approach for logging tasks and issues. (Ideally trello, see below).

Regular Meetings/Calls

It is important to have regular scheduled contact with the customer. This is an opportunity to:

Update the customer on our progress.
Review the tasks/issues that we’ve flagged as being blocked or requiring more information, and get these issues unblocked.
Agree changes to the project plan

Design Documents

Design documentation should be produced and sent to the customer for approval. Depending on the context, this may include:

UX Wireframes
Technical Specification
UI design

See the Business Analysis and User Experience design process for more information.

Test Plan

A test plan should be created. See the testing process for more information.

Shared Action and Issue Log

It is important to have an action and issues log that both the customer and D4 can see. Our preferred tool for this is Trello. Each project should have a Trello board. Every issue/question/bug/feature etc will become a card on that Trello board.

At the beginning of the project, a Trello card should be created for each of the user stories agreed as ‘in scope’ during the sales process.

Trello cards should also be created for each of the design documents that will be produced.

The customer will be invited to the Trello board and all relevant discussions about the requirements or specification of the system should be either conducted via Trello messages or the outcome of those discussions should be copied onto the Trello card. This is so that every agreement is recorded, making it much easier for us to refer back to something.

For each card in Trello there should only be one topic. If a client has diverged from the original topic or has asked other questions or raised other bugs, a new card should be created for each individual topic.

If the customer is not happy with using Trello, a shared online spreadsheet is the next best option.

All actions or issues on the log should move through a series of statuses, these are:

Blocked / Info Required
Ready to Begin
In Progress
In Review
Done

In Trello these are represented by columns.

The meaning of these statuses, what should happen at each stage, and where the work item can go next, is defined below:

Status	Meaning	Next Step
Blocked / Info Required	This is where new items should be created initially. Once created, each item should be labelled as one of the following: Question Project Deliverable Minor Change Change Request Bug Info / Doucmentation The issue may need to be replicated and/or clarified which may involve messaging the client and/or uploading files to this Trello card.	The issue may need to be replicated and/or clarified which may involve messaging the client and/or uploading files to this Trello card.
Ready to Begin	Items will remain here until the development team is ready to begin the sprint in which this item lives.	The D4 project manager will move this item into In Progress once they begin to work on this item’s sprint.
In Progress	When an item has this status, the development team is actively working on this item’s sprint.	Once this item has been developed and tested by someone other than the developer, and the feature is now available for the customer to test, the item can be moved to In Review.
In Review	Items are moved here once they have been completed, tested by D4, and released to the customer. This is where the customer tests that everything is working the way they expected, and/or provide us with their feedback.	If the subject of the card passes the customer’s testing, the customer should move this item to Done. This process should be explained to the customer during the kick off meeting. However, customers sometimes do not embrace these duties. Instead, if the customer indicates that they are happy with the software release, we may move it to Done for them. If it is not approved, the item can be moved back into Ready to Begin with a comment explaining the issue.
Done	Items in this status have been completed, tested and released. The customer has carried out their testing and indicated they are happy with what's been delivered. The item is now resolved.

Internal Tools

Jira

Jira is used within our own team. Every card in Trello should have a corresponding Jira ticket (the ID of which should be recorded on the Trello card to keep things clear).

If there are any bugs or tasks we come across in our own testing, then these should be raised as tickets in Jira.

Jira tasks will then be grouped into sprints. Each sprint will be worked on in turn.

Within a sprint, Jira tasks will move through a series of statuses, these are:

To Do
In Progress
In Test
Done

The meanings of these statuses, what should happen at each stage, and where the work item can go to next, is defined below:

Status	Meaning	Next Step
To Do	Work on this item has not started yet.	The project manager must: Set the priority of this work item. Assign this work item to a developer. Add more design detail to this work item so the developer and tester know what to build/test.
In Progress	The developer is actively working on it. The project manager will not re-assign the work item to a different developer.	Once the developer has completed development of the work item and tested the change themselves, the work item will be set to “In Test” but will remain assigned to the developer until the item is available for testing in the test environment. Before testing is carried out, there will be ‘test handovers’ between the developer and tester for each ‘significant’ work item. This ensures discussions are had about the changes/fixes that have been carried out and that there aren’t any mix ups about what is required. This also makes it easier for the tester to know exactly what changes have been made.
In Test	The work item has been developed and tested by a developer and is ready to be tested by a tester. Or, the tester is actively testing the work item. All members of the team will have testing responsibilities.	Depending on the outcome of the testing, the work item will either be set to “Done” or to sent back to “To Do”, or left at “In Test” and sub-tasks created to document each of the bugs. If the item is sent back, or any bugs are raised, the tester will add details of: What they did (steps to reproduce) What they expected to happen What actually happened If only minor bugs are found, the tester may move this work item to “Done” but also create new work items in “To Do”. See the Testing Process for more information.
Done	The work item has been developed, tested and released to the customer.

Slack

Slack allows for private one to one instant messaging with each member of the team. There is also the team chat which can be used to convey messages to all members of the team.

Slack is great for:

Chatting and “being present” with the team
Asking a quick question where a meeting would be overkill
Optional stuff e.g. “Hey, checkout this interesting article I read”

But Slack doesn’t have a “flag for follow up” feature like email does, it’s easy to miss important things in amoungst the team chatter, and search is limited on the free tier. So:

If you need someone to see a thing, email it to them.
If you need someone to do something, email them
If you think the person might want to find this information again later on, email it to them

Project Folder (Google Drive)

Each project will have a project folder created in Google Drive. This will be used to store documents about the project such as the Design Documents. It is also a good place to store files that the team need to share.