IPA/APA Interactive Framework forProducing Interactive Projects in Advertising Constructed by IPA/APA in January 2014 IPA/APAi Framework for Producing Interactive Projects in Advertising 1. Summary This document sets out a standardised framework for agencies to follow when working with 3rd party production partners delivering interactive projects, typically websites, tablet and mobile experiences that prompt user interaction, being produced to support advertising campaign activation, product launches, and web based destination sites. The framework does not currently give consideration to Online Display, Installation, ECRM, or Product Development projects. The document has been put together as a collaboration between Advertising agencies and Production Partners, with the aim of outlining a process that will be of mutual benefit to both Clients and partner companies. The framework should provide an educational resource and a best practice approach to ensure that projects are managed with consistency across the advertising industry in the UK. It should be considered a living document which will continue to be updated with regular review from the APAi. 2. Process phases: 1. 2. 3. 4. 5. 6. Brief Pitch Project award Discovery (Scoping) PPM Production a. Design b. Development i. Alpha ii. Beta iii. Release Candidate 7. Quality Assurance (QA) 8. User Acceptance Testing (UAT) 9. Launch 10. Usability testing 11. Warranty period 12. Maintenance 3. Brief 3.1. Client and Agency deliverables at briefing stage: Signed Mutual NDA NDAs should be mutual wherever possible, however it’s understood that some larger groups (e.g. WPP) have standard NDAs that cannot be amended at the time of writing. At this stage the Client or Agency should clarify any project-specific points with regard to confidentiality and IP ownership. Written creative concept The Agency should provide a written concept, and give a clear indication to all production partners as to the type of response required (e.g. Ball-park, Treatment, Initial thoughts, etc) Scenarios: ● Creative Scoping: When no creative concept has been provided by the Agency, and the production partner performs the creative role. The Agency should consider only approaching one production partner. ● Feasibility: When the Agency is assessing whether the project is broadly achievable. The Agency should consider approaching up to Three production partners. ● Ballpark costings. The Agency should consider approaching up to Three production partners. ● Technical Scoping: When detailed technical scoping is required, with specialist knowledge being provided by the production partner. The production partner may reasonably ask for a fee. ● Complete concepts based on a defined brief as outlined below. The Agency should consider approaching up to Three production partners. Budget The Agency should define a budget that has been signed off by Client. If no signed off budget is available, a guide is required to understand scale (£50k ,£150k, £500k etc.) It’s acknowledged that the Client may not know how much budget they have for a specific project, but an indication should be given for the entire campaign, in order for the production partner to provide an appropriate like-for-like treatment. Agencies should provide guidance budget, or actual budget. If this can’t be defined the Production Partner will typically: ● Ballpark the idea (requires a defined creative concept on the table) ● Initial thoughts detailing range of how to approach the concept (used more when there is a lot of creative work to be undertaken). It is accepted that at this stage, the requirement for the cost control process will vary depending on the nature of the specific client/agency relationship, its maturity/predictability and the status of the project e.g. signed off, speculative. Ideal practice for accuracy would be to engage cost control once the scope is agreed and details locked down but if/when it is a requirement at an earlier stage the agency should flag to the prod-co in advance (where possible). The current status of the project with the client Is the project signed off, speculative, or if the agency is pitching this must be made clear. Visibility of all project stakeholders (both Agency and Client) Wherever possible agencies will highlight Client and Agency stakeholders. Agency stakeholders should be involved in the briefing wherever possible. Strategic documentation, brand information, KPIs. Any background material on the brand is also important for production partners to get up to speed with the Client and its products. This should be provided by the Agency, wherever possible. Outline of deliverables with priorities (I.e. Mobile, Desktop, documentation, localisation requirements, etc) This should form part of the brief/concept above. Timings Pitch response, Award, Kick off with stakeholders present, Launch, and take-down date should all be provided whenever possible. It’s understood that Clients can dictate award dates so agencies can’t always guarantee, but an indication should be provided. In principle, each production partner should be given the same time to respond. Number of competitors in the pitch It’s reasonable for the Production Partner to be informed how many competitors have been asked to respond to the pitch. 4. Pitch 4.1. Treatment Production partners will provide a response to the brief via a creative ‘treatment’ document and ‘Ballpark cost and time estimate’. All documentation provided is Client friendly. The treatment should provide the creative vision of how they will produce the project and a topline approach. The ballpark cost and time estimate covers the initial costs, timings and scope with a list of clear assumptions and dependencies based on the original brief. This proposal is treated as a prescoped estimate of the production, and there should be some tolerance once the discovery phase has been completed and a final cost proposal has been submitted. The Client and Agency should make a decision to continue the project with a Production Partner based on the creative treatment, top line approach, details within the proposal and credentials of the Production Partner. Uncovering the detailed technical specifics of a solution requires huge investment in time and effort from a Production Partner and should form part of the Discovery phase. In some cases it is reasonable for Production Partners to ask for a pitch fee (see Client and Agency deliverables at briefing stage.) Expected deliverables within the Treatment Overview (understanding of the brief) Executive summary Production Partner creative response: ● Top level user journeys ● Mood / references ● Design mock up (optional, used only where required to evaluate) ● Prototype or proof of concept (optional and at discretion of prodco) ● Technical overview (top level tech, risk of mandatory platforms required, etc) ● Company references and related experience. Ballpark Proposal The ballpark proposal is a pre-scoped estimate of the production. It should include: ● ● ● ● ● Scope/roles and responsibilities Initial timings with key milestones Itemised top-level costs Initial assumptions / dependencies Production methodology explained in simple terms that can be understood by the Client. 4.2. Initial thoughts Appropriate for: ● When there is are loose/no creative concepts. ● Budget is completely unknown ● The project is speculative. Output: ● Top level ideas ● One page per idea ● Example references ● Cost ranges provided per idea. ● Estimated timings for delivery LEGAL If there’s no pre-existing contract (MSA) between the Agency and Production Partner then steps should be taken to put one in place before work commences. At the pitch stage, Production Partner should provide a list of legal requirements, in the absence of agreed terms in a signed MSA. A committee is being formed by the IPA to agree standard legal terms. 5. Project Award On award, the Agency should provide written confirmation to the successful Production Partner. The production company should not accept verbal confirmation alone. As a professional courtesy, it’s expected that all engaged Production Partners be updated with the result of the pitch, successful or not. The Production Partner Statement of Work must be signed by the Agency and/or Client as acceptance of the project, and a Purchase Order (PO) provided for the whole production as outlined below before work commences. Final payment on delivery. 5.1. Payment terms Unless otherwise previously stated in the Agency contract, or raised by the Agency at briefing stage, payment terms should be agreed between the Agency and Production Partner before production begins, as follows: 5.1.1. Option A In productions expected to be completed within 120 days, 50% of the contract price is due and payable upon signing of the contract, but not later than 5 business days after the award of the job. The next installment of 25% of the contract price is due and payable halfway through of the production schedule of the job (the midpoint of the hours budgeted to complete the project). The final installment of 25% of the contract price (including all approved and invoiced change orders) is due and payable upon delivery but not later than 30 days from the date of the final invoice or not later than the use of the work (e.g. the airing of the commercial or launch of the website), whichever is sooner. 5.1.2. Option B When digital productions are expected to extend beyond 120 days, a monthly cash flow schedule should be determined proportionate to the budget spent in each month provided the production company receives a minimum of 50% of the budget upon signing of the contract, but not later than 5 business days after the award of the job, and 75% of the budget prior to delivery. This schedule should be attached to the contract. Invoices should be generated no less than monthly, i.e. on the first day of the month and payment made by the last day of the respective month. 5.1.3. Delayed payment If payment is not received in accordance with the payment schedule the production company shall be entitled to cease work on the project and/or withhold final deliverables until such payment is received. Subsequent delays caused by non payment will result in delay to the end launch date. 6. Discovery A relatively short scoping phase or research and creative development, typically lasting between 2 and 4 weeks, (sometimes longer dependent on scale and complexity of the project). The tasks undertaken and output should consist of: ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● Kick-off session where Agency shares all relevant creative, brand and technical requirements and materials, schedule, and full list of stakeholders within Client and Agency. A ‘Prioritised Feature List’ detailing features that form the experience ○ in priority order according to business value, ○ strategic importance, models for Return on Investment (RoI), risk log, etc. Proof of Concept (PoC) ○ Prototypes ○ Initial animatics ○ Mock-ups Defined core team roles and responsibilities across all phases of the project on Agency and Production Partner teams for UX, design, development, and QA. User Experience flow diagrams and wireframes (if not being produced by the Agency) Outline technical approach including ‘Technical Specification’ and recommendation for hosting infrastructure, hardware requirements and minimum browser support. Details of risks and dependencies uncovered during the discovery phase for the Client/Agency to accept as part of the production. Legal requirements and review (by Agency and Client/Agency teams) Insurance requirements (beyond Duty of Care and standard Contractual Obligations) Review and sign off process - identifying what the Client/Agency will sign off for each deliverable, and the approval chain. Recommendation of necessary QA time and suitable process. Usability and user testing requirements and responsibilities. Recommendation of maintenance/support levels post-live (outside of agreed warranty period). Outline requirements for a Service Level Agreement (SLA). Requirements for documentation and handover of source code. Agreement of the process to follow in the production. Specifically, it should be decided if production will follow the ‘fixed cost’ or ‘time and materials’ (agile) model.Finalised detailed budgets and timings required to deliver the project. Rate card submitted to define rates for work outside the SOW. At the conclusion of this stage of the project, the Production Partner will provide a written Statement of Work (SoW) clearly outlining all of the above. This document should then be approved by all stakeholders before the Production phase begins. Or, it can be agreed by all parties that the SoW is a 'living' document which can be progressively signed off — with sections/ features being locked as they're agreed. Cut off points for sign off should be mutually agreed. In situations where the feature list required exceeds the budget available for producing all the features, or the time required to produce all the required features, the Client/Agency teams must prioritise/descope those features, or provide additional budget/time for those features. Agency and Client stakeholders must be fully involved and available during the Discovery phase. Inability for the production company to obtain the relevant information could lead to omissions and a delay to future phases of the production. This phase should always be funded by the Agency/Client. 7. Pre-Production Meeting (PPM) The purpose of the PPM is to confirm all details of the production to be discussed with all the members of the production. The meeting is designed to ensure all parties are on the same page and understand and agree what will be included (or not included) in the production. All lead stakeholders in the production from Client, Agency and Production Partner must be present at the PPM. The PPM must be signed off and agreed before the project can move into the Production phase. 8. Production Production is generally organised around iterations, short time-frames involving a cross functional team working in all functions: planning, requirements analysis, design, coding, unit testing, and acceptance testing. Production is an iterative process between the Client, Agency and Production Partner. It includes 2 key phases, as follows: ● ● Design Development ● Alpha release ● Beta release ● Release candidate Before development commences, both parties should agree to either follow a ‘fixed costs’ model or a ‘time and materials’ agile model. 8.1. Design The design process and a detailed list of design deliverables should be agreed in the SoW, based on the requirements of the end Client. Some Clients will ask to sign off individual designs for every screen of an experience (a task that grows exponentially for projects employing responsive design across multiple devices); other Clients will be happy to limit approval to key screens or style frames. Both approaches are available to the Production Partner, but it's necessary that these deliverables be agreed in advance (during the Discovery phase) in order to provide a meaningful estimate of time required. During production the Agency and Production Partner must agree the roles and responsibilities within the design phase. There are two approaches and there are pros and cons to each which may change depending on the various circumstances/complexity of the work and skills of both Agency and Production Partner. It is important to define this relationship to avoid any unnecessary overlaps and inefficiencies. 1. Agency designs for the Production Partner to build. 2. Production Partner designs with close working relationship with the Art Director/Design leads within the Agency. Stakeholder design feedback should be limited to Two rounds of consolidated review (from both the Agency and the Client) and amends, (the Production Partner will make clear what constitutes a single review, as soon as designs are of an acceptable standard to be suitable for feedback) with a view to the Production Partner proceeding as quickly as possible with front-end build. However, it's understood that further iterative design changes may be required during the build process, to the benefit of the project. It's therefore reasonable for the Production Partner to secure and charge for design resource for extended periods throughout the project lifecycle. 8.2. Development Key moments in the development cycle consist of: ● ● ● Alpha ○ ○ ○ ○ User Acceptance Test Alpha Load and performance test Security audit Alpha amends phase Beta ○ ○ ○ ○ User Acceptance Test Beta Load and performance test Security audit Beta amends phase Release Candidate The Production Partner will provide release notes to detail what is included in each release, and the features that should be reviewed and approved by the project stakeholders. 8.3. Alpha release In software development the Alpha phase of the release life cycle is the first function deployment of the experience and the first phase to begin software testing. The Alpha release should include a set of functionally complete user journeys as described in the Discovery phase. The Agency should view the Alpha release as an early version of the experience with a view to getting a good feel for how the experience will work; reviewing the flow, timings and interactions. The strong recommendation is that the Client also sees the release at this stage. This phase is required to ensure the production company has the time to take comments and adjust any fundamental flaws that may arise in the user experience. 8.4. Beta release The Beta release is typically feature-complete, i.e. all content has been integrated as defined in the SoW, but with some aesthetic issues (class B bugs) still outstanding. Beta begins when the software is feature complete following the Alpha phase. Software in the Beta phase will generally have many more bugs in it than completed software, as well as speed/performance issues. The focus of Beta testing is reducing impacts to users. This is typically the first time that the software is available outside of the organization that developed it. 8.5. Release Candidate A release candidate (RC) is a Beta version in a state of completeness that could be considered a final product, which is ready to release unless further Class A bugs emerge. In this stage of product stabilization, all product features have been designed, coded and Beta tested. The sign off of the Release Candidate leads to Code Freeze. The code development is stopped and QA begins. 9. Quality Assurance (QA) It's understood that software cannot be guaranteed to be bug free, and it's accepted that bugs may arise post launch. However, the Quality Assurance (QA) process ensures that, as far as possible: ● ● ● ● ● All functional user journeys are complete and behave as documented in the wireframes, initial animatics and mock-ups. Validation of use cases, using data or content that replicates live use of the software Behaviour is as expected across multiple devices (as defined in the requirements) Design integrity across multiple browsers (as defined in the requirements) Validation of non-functional requirements i.e. performance, load times, scalability of content. In the Statement of Work (SoW) the Production Partner and Agency/Client will agree functional and non-functional requirements against which testing will take place. Functional requirements include a matrix of browsers, OSs, software versions, devices, etc. Non-functional requirements include a forecast of expected site traffic, concurrent users, performance, Client IT infrastructure, etc. Where possible, the Production Partner should speak directly with the Media Agency or partner to understand non-functional requirements. The period of time allocated for QA in the SoW must be protected to ensure the production is delivered in the most bug proof state possible. Any reduction in this period of time, due to factors outside of the control of the Production Partner, will impact post-live support and warranty period. The Production Partner will provide access to a bug tracking tool (if an existing tool is not in place between the Client or Agency). The purpose of the bug tracking tool is to provide a central, shared repository of all bugs and defects discovered during the QA phase. For more complex sites with multiple page states and edge case scenarios, it may be recommended by the Production Partner to formalise the testing of user journeys in a written test plan. This test plan will be shared with the Agency/Client. It's expected that all relevant stakeholders will be included in Client and Agency reviews (as defined in the stages above). All bugs and defects must be logged within an agreed testing window, agreed in the schedule between the Client/Agency and Production Partner. Each bug and defect will be raised as a single ticket in the bug tracking tool. These tickets are then prioritised and categorised into releases by the Production Partner. 9.1. Bug classification Bugs are prioritised as follows: ● ● ● ● Class A: Critical functional bugs that affect fundamental user journeys . Class B: Not-Critical or aesthetic issues. Highly undesirable and should be resolved before launch. Normal: Issue may be deprioritised or resolved post launch. Low: None essential. Fixed at the discretion of the Production Partner if time and budget is available The Production Partner will provide release notes to detail what is included in each release, and any bugs and defects should be reviewed and approved by the project stakeholders. Any bugs that remain unresolved will be moved to the next available release, or be de-prioritised for launch. 10. User Acceptance Testing / Soft launch The UAT phase allows stakeholders to validate the completed experience against the original SoW, wireframes and functional spec — either with the Client, or a closed group of individuals. This phase typically includes three stages; Production Partner testing, Agency testing, and Client testing. These stages can be combined, and should be agreed during the Discovery phase. A UAT phase will require further work to prepare a final release candidate and perform an additional QA phase, with the timeline must be adjusted accordingly. 11. Usability testing If required, this phase can be introduced before the project or release candidate is launched. The aim is to allow stakeholders to review the final launch release with a view to suggesting improvements and adjustments that could not have been foreseen during the Discovery or Production phases. Usability testing should be considered as additional work for the Production Partner if it has not been included in the original SoW. 12. Launch The project launch date will be defined in the project brief. The Production Partner will run through a checklist to confirm all necessary steps have been taken in preparation for the experience moving to a live domain. For example, clearing databases and tracking data, provisioning third party applications, etc. If the live domain is a real world location, Pre-Live Documentation will cover the necessary call sheet, risk assessment, hardware and architecture schematics, health and safety and insurance materials. Once live, the Production Partner will perform a short ‘smoke test’ to validate all core functionality is behaving as expected, and that hardware integration has been successful. In cases where the Agency has requested handover of source material (subject to ownership), the assets will be supplied on the same date as the project live date. In all other cases requests for source material and raw assets will be made within 30 days or within the warranty period (whichever is shorter), after which the Production Partner assumes no responsibility for storing such materials. 13. Warranty Period The warranty period will have been agreed up front (typically between 10 and 30 days), unless the Live period is less or an exception is agreed in the SoW. The purpose of the warranty period is to fix any Class A or Class B issues or bugs that arise from the original production which are pre-existing from the launch date. Outstanding Class A or Class B bugs, or material bugs caused by regression, will be addressed during this period. After this period, newly logged issues will be assessed and discussed with the Agency on an individual basis. The Warranty period is not used for any agreed de-prioritised functionality and will be treated as change requests (see below). This de-prioritised functionality should be clearly documented and agreed by all stakeholders. Any changes in any 3rd party platforms, browser, devices, operating systems, or other 3rd party systems outside of the control of the Production Partner, are not covered in the post-live support, even if within the warranty period. The warranty period is valid providing the time allocated for the QA period was honoured as specified in the SoW. Any time utilised for investigating issues deemed to be the responsibility of the Production Partner, but after investigation are proven to have been caused by a fault of a Client nominated provider is not covered under the Production Partner’s warranty agreement and the Agency/Client can be invoiced by the Production Partner at its discretion. 13.1. Post-launch Change Requests The Production Partner reserves the right to charge for any work based on requirements not identified within the pre-defined testing or maintenance period. Changes in project scope, unforeseen delays or developmental issues are a common experience on interactive projects, no matter how well planned in advance. All requested changes should be provided in writing in order to be assessed by the Production Partner, before going back to the Agency or Client for approval prior to carrying out any additional work. APPENDICES Appendix: Terminology Advertiser The Brand or Product associated with the interactive experience. Agency The Advertising Agency that has engaged the Production Partner. Third party service Documented third party web interface that makes an existing application or platform feature available to the experience. In regards to an Installation or OOH this could be a fabricator or an event partner. Ballpark cost and Milestone time estimate During the Discovery phase, Ballpark costs and a Milestone timing estimate are given in order to show initial commitment to the project being feasible within the time and resources available. Budget The confirmed, total amount of money to be made available to the Production Partner for the work completed. Change Request/Change Order A new or undocumented feature which is requested outside of agreed functionality. The Production Partner will assess impact and effort required to implement the new feature and submit a written document or appendix to the Statement of Work (SoW). Client The projects key stakeholder(s), typically a part of a Product or Marketing Team for the Advertiser. Client nominated provider An existing partner of the Client of Agency. For example an enterprise hosting partner, Media Agency, or other. Code Freeze A predefined window for the Production Partner to perform internal testing against a stable build. No new request, functional or creative changes will be released for review during this period. Feasibility An initial assessment made by the Production Partner with regards to whether a project is creatively, technicality, and/or financially viable. Initial thoughts The Production Partner may provide a short written response to the initial brief. This document gives a rough indication of Feasibility, approach, references, and perhaps Ballpark cost and Milestone timings. Launch/go live Experience is moved to a public domain, usually with media driving traffic to the experience. Maintenance A fixed period of support as defined on a project by project basis in the Maintenance Service Level Agreement. Round of amends A single written list of comments made by the Agency/Client on behalf of all stakeholders following a complete review of user journeys as defined in the wireframes. Statement of Work/Scope of Work (SoW) The contract for a specific project detailing specific items to be approved by the Client and Agency. This is ‘the’ document that describes the specifics of the project that will be created. Technical specification Detailed document outlining the technical architecture of the project. Timings A schedule for the project which shows a daily breakdown of tasks to be completed, with milestones for Releases and Agency/Client reviews. Pre-Live Documentation This documentation acts as an overview for the next steps to going live at an event or real world location. It also acts as a call sheet, technical and architectural reference and important health and safety documentation. Treatment A creative and technical response to the project brief. This is a visual document, submitted during the Pitch process, that makes clear the Production Partner's vision for the project, and overarching approach. User Experience (UX) / Information Architecture (IA) / Wireframes Blueprint diagrams for the built experience, showing basic page layouts, user journeys, points of interaction, validation, etc. Warranty A fixed period following launch where outstanding or legitimate newly discovered issues will be addressed inclusive of the original budget. Appendix: Integrated projects Where a filming/shooting aspect to the interactive project is required, the filming aspects should follow the standard APA guidance, contracts and processes. Appendix: Change Control The main factors which causes delays to the production schedule: ● Change in scope ● Delays in review sign off and approvals. ● Late assets ● Hosting platform provision ● Client nominated suppliers ● 3rd party platform changes If there are any issues that will cause delays to the schedule the Production Partner will initiate the change control process detailing the impact (in costs and timings) to the production, or will recommend items to de-prioritise to discuss with Agency/Client in order to keep the project launch date. All change requests should be discussed and approved by stakeholders within Client, Agency and Production Partner. to ensure all production change implications are agreed. Appendix: Sign Off Process One individual from the Agency team will be responsible for collating and prioritising all Client feedback and communicating this back to Production Partner. (the Agency Producer). The same person will also be responsible for getting Client side approval on all deliverables and Change Order (CO). This will greatly support Production Partner in keeping to the agreed Project schedule. If further changes are submitted after an approval on deliverables has been granted, Production Partner may need to create a CO. All project documentation and deliverables will be read, understood and signed-off by Agency and Client. This documentation represents our shared expectations regarding scope, time, cost and delivery for this project and all CO’s will be based on this original agreement. Approval processes that go beyond the dates outlined in the project plan may affect the project timeline and may subsequently impact the project budget. Appendix: Document Templates List of templates to standardise: ● ● ● ● ● ● ● ● ● NDA MSA Budget / Estimate Statement of Work Change request authorisation Maintenance SLA Testing / QA / Doc / reporting system Coversheet / checklist pre-award Checklist for launch - flight check Appendix: Maintenance Retainer On completion of the project, if agreed as a requirement in the Statement of Work, the Production Partner will enter into a service level agreement (SLA) for a given project. This SLA will typically include: