Project Setup
Project Setup
An OrderFlow implementation begins with a set of setup actions to kick off the project.
OrderFlow implementation project setup involves the following:
- Identification of key Project Roles
- Setup on the OrderFlow Support Portal Projects
- Agreement from you on the Change Control Process and Rules of Engagement for chargeable work
- Agree timing of Project Kick-off and Weekly Calls
See the sections that follow for more detail on each of these tasks.
Role Identification
At Realtime Despatch, we believe that good communication and clarity of roles and responsibilities is essential for a smooth OrderFlow implementation. Before project setup, it is important to know the names and contact details of the everyone who will be working on the project.
Your Organisation
| Role | Responsibilities |
|---|---|
| Project Owner | A key stakeholder, who can make strategic decisions and approve large pieces of work. |
| Project Manager | Responsible for maintaining the project plan, and coordinating the activities across all parties involved. |
| Requirements Lead | Understands, in detail, your warehouse design and processes, and so can work with us to define requirements. |
| OrderFlow Test Lead | Works with us to test the OrderFlow implementation in detail before Go-Live. Able to provided detailed feedback to support verification and sign-off. |
Note that in some projects, some or all of these roles may be performed by one person.
Realtime Despatch
| Role | Responsibilities |
|---|---|
| Realtime Despatch Project Lead | Your main point of contact at Realtime Despatch, who will coordinate Realtime Despatch's involvement in the project. |
| Requirements Lead | Works with you to produce detailed specifications for each of your implementation requirements. |
| Testing Support Lead | Responsible for the timely resolution of any issues you might experience during the testing phase. |
As with your organisation, some of these roles may be performed by the same person, depending on the project.
Third Party Systems
| Role | Responsibilities |
|---|---|
| Support Contact | Our main point of contact that we can liaise with when dealing with support issues. |
Third party organisations that we tend to deal with include eCommerce and Server Hosting companies.
Redmine Project Setup
All of our customers use our Redmine Support Portal as a wiki and ticketing system to define new OrderFlow requirements and raise any support issues. This single point of contact makes it easier for us and our customers to monitor the progress of specific tickets, and to get an overall picture of how a project is progressing.
During pre-launch phase of project where the emphasis is on rapid and frequent turnaround, we are also happy to use other communication channels to facilitate this.
At the Project Setup stage, we need to know the names of who in your organisation will be raising, updating, approving or simply viewing tickets, so that we can create the relevant user accounts. We will create one user account per person - the same user account should not be used for multiple members of staff.
Typically we will set up one parent project for your organisation, with 3 sub-projects:
- Launch - during the Project Scoping and Build stages this will be used to define, implement and monitor testing of detailed requirements. Applies only for work that is identified with the scope of the launch project.
- Support - this covers any work that is identified as being outside the agreed launch scope. After Go-Live this will be used by you to raise support tickets.
- Development - any custom development work that is commissioned to meet your requirements will be managed through this project.
- Third Party System - in cases where we are required to have a non-standard integration with a third party system, a sub-project is set up so that we can liaise directly with the technical support staff of that organisation.
In the Change Control section in the next chapter, we describe in more detail the need for separating the launch tickets into a separate launch project.
Project Kickoff and Weekly Calls
Once all key project roles have been filled, and a target launch date has been identified, we're ready to kick the project into gear. This involves:
- an initial kick-off call or meeting where the participants in the project get together to agree at a high level on responsibilities and objectives for the project
- a weekly progress call to review progress over the previous week, and agree to agree on actions for the coming week of activity
The weekly progress call is important in ensuring that we are able to maintain momentum throughout the entire period leading up to go live, and that obstacles to launch can be quickly identified and removed.
In both cases, the Realtime Despatch Project Lead will take you through the process.
Change Control and Ticket Management
We appreciate that in real world projects requirements do change, even requirements that were previously considered to be fixed or locked down. We realise the need to maintain flexibility, but also to have a clear mechanism for identifying this work as separate from the work agreed as in scope for launch when the Project Plan is signed off.
As mentioned in Redmine Project Setup, with each new customer implementation we set up two 'projects' on our support portal:
| Project Type | Covers |
|---|---|
| Launch | All work that is explicitly agreed up front as being delivered on the basis of a relatively firm estimate |
| Support | Work based on unknown, unclear or modified requirements |
Where this happens, the work involved will be covered using tickets in the Support ticket, and will be separately chargeable. It will not be offset against any fixed cost allowance made during the Project Scoping phase.
Similarly, work for requirements that cannot be accurately determined during the Project Scoping phase will also be tracked using Support tickets. For example, if courier selection rules are complex, fluid or not well understood, this part of the project will be tracked using Support tickets.
In summary:
- The Project Plan will not be presented until all Launch Project tickets have been been estimated based on a signed off requirement.
- No new tickets will be added to the Launch Project after the Project Plan is signed off.
- All requirements that are added or modified after Project Plan sign off will be tracked using launch tickets.
The project planning we have put in place aims to provide the flexibility the customer needs to make changes where necessary, while ensuring the that risks and costs are associated with these are balanced fairly between Realtime Despatch and the customer.
Agreeing Rules of Engagemeny
As mentioned above, any work that is identifed that is outside of the agreed scope of the launch will need to be separately chargeable. The Rules of Engagement covers details on which situations charges are applied, how we seek approval for work, and how we book time.
Please refer to our Customer Support Guide for details of our default rules of engagement. This document will also tell you more about our technical support and development processes.
As suggested, an important area that this document covers is in the area of Billing and Time Booking.
We request explicit agreement from you that you are comfortable with these rules of engagement before we proceed the implementation of the project. If there is anything in the document that you do not understand, or if you wish certain exceptions to be made for your specific implementation, then please discuss this with our Project Lead.
Customer Sign-off Notes
Getting the mechanics of the project setup, with Support Portal interaction through tickets and weekly calls,
is essential for efficient communication and smooth running of the project. Agreeing the Change Control and Rules of Engagement gives us a commercial basis for handling unplanned or unanticipated work while not limiting your flexibility in making changes.