We do this by applying our own developed methods and processes that combine the best of IT rigour with media technology pragmatism, and our past experience in media technology delivery. We have done this with organisations such as the BBC, Sky and MediaCityUK. We can help companies do better at any stage of the procurement or implementation phase.

We base our services around the three key stages of technology implementation, from the "what do we need to do?" through to "how do we need to do it?".

Mediasmiths has expertise and experience in each of these areas, and a key feature of our services is the development and constant refinement of our own methods and processes for reducing risk and lower implementation costs.

It is often said that a poor strategy well implemented is better than a good strategy poorly implemented. Mediasmiths believes that the key to creating good strategies and implementing them well, is understanding how to manage innovation and creativity, underpinned with pragmatic process and methodology.

Mediasmiths has evolved our own delivery methodology, based on our perception of the the failure of traditional package implementation methods in video system deployment, drawn from our collective prior experience at large IT system integrators.  This is particularly true of video based content management deployments, which tend to involve large numbers of users and typically a substantial degree of customisation, integration and configuration.  Typically these have been deployed using waterfall approaches, often supported by Prince 2 practitioners.  Our experience to date on content management projects has strongly suggested that a traditional waterfall-based project approach to these significant and important programmes suffers from a number of drawbacks, and in particular:

• Too much concentration on analysing and documenting as-is processes. Accumulating voluminous detailed documentation in this area does not, in our experience, serve much practical purpose to most organisations.
• Moreover where operational workflows will change, a traditional requirements gathering exercise often fails as users cannot articulate how they could work in the future by listing system features.
• The long development and rollout cycles associated with traditional significant systems implementations means that users often are not exposed to the progress being made within the project and consequently become disengaged, in addition to the usual problems of requirements changing during the development and implementation cycle.

In response to these issues, Mediasmiths has worked with our clients to develop ways of working in file-based workflow projects that combines a structured approach to project management with an agile approach to workflow definition, requirements capture and system development and test. 

Our approach involves working with users to focus on outputs and benefits in development and configuration cycles, and maps these into technical requirements.

The “agile-style” implementation part of the method emphasises a pragmatic style and a very interactive approach to gathering requirements from users, developing and documenting future workflows, designing and implementing system configurations and customisations, and testing and deployment.  A key element of this approach is the use of “user stories”.  End users of the system are involved from the beginning of the process by being asked to create user stories which will drive the requirements for a future system.

At the very start of the implementation, an initial planning session estimating the amount of effort likely to go into each user story, will take place. Based upon this, the user stories will be assigned to a “package”, which is a period of deployment – there may be 2-4 packages deployed during the Phase 1 implementation.   During the packages, the user stories are prioritised and broken down into separate tasks. Tasks will be broken down into developer tasks, which will either be configuration or development tasks, functional test tasks and user test tasks. The team will estimate how much time it will take to implement a specific task. Based upon this, the team will allocate a suitable number of ideal days dictating how much effort will be involved in completing a user story.  Within the packages, there will be reoccurring weekly “slice” reviews providing project status updates. These sessions may include a “show & tell” by developers/users.  This approach transforms the deployment of systems, be they package implementations or new development, as users are actively engaged early and carry out testing as they system is being deployed, rather than at the end of it.  This approach has a number of key advantages over traditional methods:

• User expectations are managed upfront
• Users feel more bought into the system, and are more evangelical
• Developers and technical architects will often miss actual user needs in preference to their perception of user needs, which can lead to user unhappiness, particularly when projects are running late, and technical staff start making cuts.  This does not happy with the agile approach as users are involved throughout and are part of the prioritisation process

Typically this involves employing an iterative approach to deployment – designing, developing and testing the solution in small incremental parts. Within the approach, we emphasise the need for appropriate detail and good quality documentation at each design stage, but generally believe in a selective approach – for example in many cases producing future state workflows and an impact analysis is more valuable than spending significant time in as-is workflow documentation.  

We also believe in involving the main video vendor technology firms throughout the process, but this of course requires that they be selected before the work starts.  We therefore recommend an initial approach of defining the core high level workflows that will be implemented, and developing RFPs that ask vendors how they support the workflows.  Vendors are assessed against the quality of response and insights presented, rather than scored against a compliance matrix of requirements that may take a long time to assemble and may not reflect actual needs.

We place very heavy emphasis on testing system functionality and new workflows against formally documented test cases developed in conjunction with current and prospective new system users in order to ensure that requirements are properly met both from the formal contractual and from the user perspectives.

We support our project delivery approach with automated tooling in order to streamline the process and ensure that project metrics can be derived without significant manual intervention – we use Version One as an agile project delivery tool; TestLink for test management tool, and Eventum, a defect management tool, to support the design and implementation process. In addition to this, we have a wide variety of document templates (e.g. workflow design) that we can adapt to the needs of individual clients and projects when required so to do.

Our approach to incremental delivery typically involves the following steps:

• Split the project into a number of phases, and the phases into a number of preparation cycles and delivery cycles.
• For the project and top level phases, define and agree a scope, objectives and deliverables with the client (these are typically documented contractually in the Statement of Work that we have with the client).
• Preparation cycles usually consist of work which occurs prior to system implementation – e.g. specific product selection such as a storage solution
• For each of the cycles, define the outcome deliverable of the cycle by capturing the output state as a set of “user stories”.  We would typically split up the cycles into “packages”, conceptually similar to “iterations”, a phrase commonly used in agile methodology
• For preparation cycles, the user stories are used to construct documents such as assessment criteria, objectives and test scripts, and so on
• For delivery cycles, the user stories are used to develop designs and future workflows, against which systems are configured and new processes/code are developed, depending upon the nature of the project
• Within cycles, teams will work on a series of “burn downs”, where specific functionality is developed and tested alongside users, leading to a very interactive process, where the users are able to participate in the evolution of a system to meet their requirements.

We believe that this type of approach is the best means of managing costs and expectations, while focused on constant delivery of system features.  In a more traditional approach, if the budget was used up 80% of the way into the project, there was nothing delivered.  In our more agile approach, the budget may be burned up, but 80% of system functional would be delivered.  This offers customers the choice of making the case for more money for additional features, or living with the existing feature set.  In either case the customer is in full control of the decision.