Project Scoping
Project Scoping
The main aim of the Project Scoping phase is to gain a much better understanding of the likely effort required and anticipated cost of the project. The Project Scoping phase provides is a key sign off point in the project, and is where the overall scope of the launch is largely determined.
In the proposal you received as part of the sale, the Realtime Despatch sales professional would have given you a pretty good idea of what is involved with the project, and the likely implementation cost. With the Project Plan, the aim as to firm this up.
This involves an initial round of Requirements Gathering, done through the initial visit to the customer site. This will be followed by an estimation of the Tasks involved in delivering the project, both of which will feed into a Project Plan and a more accurate estimate of the project implementation costs.
| Deliverables |
|---|
| "A Requirements Document, with an itemised summary of your requirements" |
| "An itemised Task Estimation, with man day estimates covering each area of activity" |
| "A Project Plan with dates and dependencies of the key deliverables required to meet your target Go-Live date" |
| "Sign-off from you on all of these deliverables" |
Requirements Gathering
We encourage new customers to lean towards the simplest, most standard implementation for launch. This allows for the fastest, lowest cost implementation. Refinements can be introduced once the system is operational and the benefits are better understood and more easily quantifiable. This allows for a faster, lower risk implementation.
A simple generic implementation would typically involve the following features:
| Areas to Consider | Example Basic Configuration |
|---|---|
| Locations | Basic warehouse location configuration, involving, incoming, storage, and outgoing locations, mobile locations |
| Products | Simple products only, all individually barcoded |
| eCommerce Integration | Integration to a single eCommerce platform |
| Courier Integration | What are the despatch destination countries? Which couriers and services are needed for each |
| Goods-in | Standard goods in to incoming location, followed by putaway to storage |
| Picking | Handheld picking to single mobile location |
| Batching | Simple batching logic, involving single and multilines, batched by priority and domestic vs international |
| Packing | Standard scan to pack process |
| Returns | Simple returns process using desktop GUI, with no third party system integration |
| Handhelds | Out of the box handheld usage, no custom styling |
| Paperwork | Use of standard out of the box paperwork, with text and logo customisation only |
| Printing | Use of industry standard thermal printers. Workstations running on Microsoft Windows |
| Reporting | Use of standard reports only |
| User Roles | Mapping of users to predefined roles only |
Inevitably, however, there will be some bespoke requirements that will be considered essential for launch. Part of the task of the Project Scoping phase will be to identify these requirements, and to ensure that they are recorded as in scope for launch.
The task of identifying as early as possible and as fully as possible bespoke requirements is very important in allowing us to accurately to estimate the overall effort. This helps to establish a sound commercial basis for the project, and to ensure that there are no unanticipated cost overruns.
The table below shows the key areas where requirements or input will need to be captured:
| Areas to Consider | Example |
|---|---|
| Locations | How are locations labelled and named? How is the warehouse organised. A list locations will need to be provided. |
| Labelling | What label stock will be used for product and location labels? What label reports need to be supported? |
| Products | Do all products have barcodes? Any complex/composite products |
| eCommerce Integration | Which platform/integration to use |
| Courier Integration | What are the despatch destination countries? Which couriers and services are needed for each |
| Paperwork | What are the depsatch documentation requirements? Do we have any examples? |
| Handhelds | Which handheld terminal does the application need to run on? |
| Printing | Which thermal printer needs to be used? |
The output of requirements gathering step will be a Requirements Document, with the following:
- a summary of the customer requirement in each area of activity
- a link to associated detailed tickets, where appropriate
- an indication for each associated ticket on whether the detailed requirement has been signed off
The Requirements Document will be prepared in a standard format. It will be reviewed internally before being presented to the customer for sign off.
Task Estimation
Once we have completed the first round of requirements gathering, the next step is to estimate the tasks involved. For this the man day effort required for each area of activity for which project delivery is required.
In an ideal world, it would be possible to arrive at a firm set of detailed project requirements before continuing to the build stage of the project.
In practice, it is not always possible to obtain project requirements that are sufficiently detailed to allow this to happen. Typically, decisions still need to be taken, and these decisions can affect the scope of work involved.
Where scope of work can be clearly defined, we would give you the option of having this work done on a fixed price prices basis. Where this is not possible, at the Project Scoping stage we would aim to give you a provisional cost estimate for each activity.
The differences between these estimate types are described below:
| Estimate Type | Covers Situations | Action |
|---|---|---|
| Fixed Price | Requirements are well defined at the Project Scoping stage | Realtime Despatch provides a fixed price estimate and absorbs the cost of overruns in this area |
| Provisionaly Allowance | Requirements are still to be defined | Realtime Despatch makes a provisional allowance for the activity |
The output of the task estimation process will be a Task Estimation Document, prepared in a standard format, with the following information:
- an itemised estimate for preparing the system to meet the requirements
- an itemised estimate for delivering each of the remaining phases of the project
For each estimated item, we will indicate whether the estimate is on a fixed cost basis or whether it is provisional.
The Task Estimation will be reviewed internally before being presented to the customer for sign off.
Project Plan
The requirements and estimated tasks will feed into an overall Project Plan which will summarise timings and cost estimates for the project:
- the target go live date for the project
- the proposed timing of the remaining phases of the project
- a proposal for the timing and number of days for which we will be on site to deliver the project
The target go live date will take into account customer business imperatives, but also resource availability on the part of both Realtime Despatch and OrderFlow.
Note that actual go live date will need to be confirmed later in the project once the build and testing phases have been signed off. Requirements that are identified or changes that are made after the sign off of the Project Plan will typically have an impact on the go live date that is actually possible.
Customer Sign-off Notes
Customer sign-off on the Requirement Document, Task Estimation and Project Plan is essential before continuing to the build phases of the project. It is this process that identifies the scope of the project as a whole. The more clearly and accurately requirements can be captured and 'locked down' at this stage, the more certainty we will be able to provide as to the total cost of implementing the project.