Section Headings
Terminology
An explanation of some of the uncommon and unusual phrases, acronyms and/or terms used in this document. Typically this segment would be entitled ‘definitions’, but the title has been reserved for use elsewhere in the document.
Purpose
Explains the document’s role in the project lifecycle. Describes in detail the reason for the project’s existence. An outline of the initial high-level challenge and opportunity which would typically solicit a professional business response e.g. proposal(s) in a project brief format (containing pre-plan estimations of timescale, budget and cost). Details the client’s ambition(s) which they now seek to pursue. A direction forward to take, explore and maintain.
A driver of motivation and consistency over time for all stakeholders. Derivation of knowingness and meaning for project participants. Reassurance for investors that coherent steps are being taken so that they can diligently assess the project and their own personal and professional interests for alignment and synergy.
Definitions
The project definition forms the basis of a project. Describes the process of initialisation and thus the definition of the general conditions of a project. Describes the result of this process. Both the aforementioned may vary. Definitions also aid individuals in differentiating between the number of projects, milestones and/or work packages they are actively working on in parallel.
Background
Describes the arrival at the current state with respect to business development. And helps clarify confidence in the overall business strategy and business moving forward. Insight as to why processes and configurations are the way they are. Helps identify other areas of development that may have been overlooked in the past, so as to be included in the current business strategy and affiliated projects.
Objectives
Particular business objectives extracted from the strategy to be fulfilled, in full or in part, by the client. These objectives may have sub-objectives and can even include the objective of having more objectives (and/or sub objectives) based on expertise that may be outside of Clients board’s remit of knowledge e.g. Objective 12 – There needs to be a set of smart contract objectives that counter the functions performed by competitors” smart contracts. This objective is to be explored, defined and fulfilled by the project team, commissioned to execute this project. And elaborated further in the pre-planning project brief/whitepaper and plan which build on this mandate.
Scope
Constraints
Known constraints help clarify the reality of the surrounding environment of the Client, successful tenderer and the project team and their combined resources in order to successfully achieve the goals and objectives, by ensuring no limiting factors are left out of the equation. Constraints to consider can be anything from financial, politicalor, psychopolitical, environmental, technical, legal, commercial etc. In all cases known constraints should surface into this document as later exposure to constraints may have serious implications that can affect the project goals and objectives and subsequent deliverables. Ultimately the more information and more refined the definitions earlier in the project pre-planning, the more chance of success exists in the final solution meeting and even exceeding the clients original expectations, as expressed in this mandate.
Interfaces
Information regarding the Client’s preferences surrounding interfaces (e.g- user login portals, front-end (progressive) webapp design etc) is detailed in this section in as much detail as can be afforded in the time allotted to its publication. This will help the project team ensure that after functionality has been achieved by the project team, the way the Client interacts with the controls will be in compliance with their requirements which will be outlined in this section in as much detail as possible.
Quality Expectation
Conveyance of communications preferences, channels, recurrence & priority in consideration of other active projects and business activities. Detailed, exact expectations and requirements in order the final deliverables of project result is adequate fulfillment of timescales, budgets and quality expectations. Clear definition of what is expected from project contractors. Concise expectations to be met throughout the entire duration of the project. Clients Quality expectation is detailed in this section and has been explained as clearly as possible so that the project team includes these expectations in the quality control phase of the project. This segment is designed to ensure that all work meets the quality expectation as well as the objectives before it can be expected to be approved and/or delivered to the Client. This is by far the most important section of this entire document and tenders should insist on its revision, as with any part of this mandate, if Client’s Expectation of the final deliverable is unclear or vague, because leniency, patience and understanding at the deadline delivery date may not be afforded by the Client, to those whom are contracted to undertake this project. Throughout the course of the project, whereby the Client is the project board and authority, it becomes the obligation of the successful tenderer(s) to insist the Client and/or the project board and authority, update this mandate to include missing quality expectation information in a sufficient time frame before the deadline delivery date, since the Client cannot be expected, at this juncture, to know everything to expect from the solutions presented after this documents publication.
Outline Business Case
Describes the business outcomes and service/works requirements in a way that is unambiguous. This segment also ensures that the total project scope is described from the standpoint of storytelling with examples and/or conceptualized use cases. Requirements are specified in terms of outcome, based on “what” rather than “how”.
Associated Documentation
All the Clients material in relation to this mandate are enclosed and referenced within this document. The reason is to help clarify the descriptions given in this document as well as aiding the project team in visualizing the current status of the company and withstanding and inviting challenges in terms of credibility of the sources of information upon which this mandate has been constructed. Should the sources of this mandate become invalid or lose credibility and dependability throughout the course of the delivery of the proposed project, it will be up to the successful tenderer(s) and/or project manager to raise the concern with the mandates author(s)/ project board/ authority, so that the mandate and all documents which depend upon it, are able to be updated and/or corrected.
Proposed Project Board
In this segment the Client puts forward their proposed executives that will be included in the construction of this proposed projects board and project management team. These individuals will have decision making responsibilities that form an axis on which the success of the project will be determined. It is also recommended that any second in command (2IC) personnel are included to ensure contingency plans are not abruptly reverted to, should the primary decision maker be unresponsive throughout the project.
Customer and User
In this segment we outline any and all known users/ customers and any other interested parties, as well as their specific relationship to this project and the overall strategy e.g. existing ecommerce customers and booking/pledge/pre-registration details that may need to be migrated to the new system. The data itself will not necessarily be sourced here, but information of where the data can be obtained from, in a meaningful yet secure way, will be disclosed in order the successful tenderer(s) needn’t bother the Client and/or the project executives for these and other related resources throughout the course of the project.
Other Information
These may include annexures such as schematics, laws, source code/ changelogs, whitepapers, images or even entire books related to this proposed project.
Role Description
List of people who are participating in the project development from the very beginning until project closure, along with their roles and responsibilities. The pivotal role plays the identification of responsibilities, which implies roles of project manager, team leader, sponsor, supplier, user representative, stakeholders and members of steering committee.
References
Approvals
All approving parties named in the approvals section at the end of this document, must sign to collectively authorize this document. This segment also ensures the document serves as a legally binding agreement and point of reference for “What the client (EVL) wanted, expected and ultimately understood they were financing/ paying for”.