skip to the main content area of this page
Delivering Solutions
How We Work

Outcome Based

Whatever the nature of the work we are engaged on we prefer to be driven by required outcomes. The objective is not simply to provide reporting or build a data warehouse. The activity is intended to make a difference to the business and it is that difference that should be the driving force, objective and value of any engagement.

Projects

Where there is simply a problem that needs to be resolved we can engage on a project basis. We usually operate against a fixed budget and a defined scope of work. Ideally, the scope of work would be defined in terms of the business outcomes required. This allows our clients to control their budgets while our experience allows us to manage project risks on their behalf.

Retainer Agreements

Where clients are seeking continuous support in the technical management or commercial exploitation of their data assets we operate against a monthly retainer. Again, in retainer contracts, we aim to gauge success by what it does for your business: not simply by what we do.

Documentation

In any development project or service provision clear documentation is critical. From our clients point of view this documentation comes in several flavours.

  1. The Statement of Work or Proposal which will describe what we are intending to do along with the associated dependencies, costs and timescales. It will descibe the required outcomes in some detail and will reference the tools and methods to be used.
  2. The project plan that will detail the work packages that will be undertaken and the time, reaources, staff and dependencies associated with them. This will usually be presented as a Gantt chart with detail of each tasks work.
  3. The Functional Requirement which is a detailed adjunct to the project plan and determines what the solution is intended to do from a user's perspective. This is often described as a set of "use cases" which simply means that we examine a users activities and processes (or potential ones) and document what the system will be doing to support these. From this detailed description a technical design team can configure, design and develop the solution.
  4. The Technical Specification takes the Functional Requirement and represents the final system design. We have mentioned elsewhere that we develop primarily on the Microsoft platform (SQL Server, .net etc..) and the intent of this document is that any suitably qualified Microsoft developer coiuld understand and replicate or modify the system. This is particularly important for customers that are intending to take over the operation and maintenance of a system at some point in the future.
  5. Finally, operating documentation. Again, wherever the client has to interact with the system to use it or perform a maintenance task this will be supported by documentation - so you are never left staring at a screen and wondering what you need to do next.

Support

Within any project or retainer agreement we would expect to provide both telephone and on-site support. This can take several forms ranging from simple maintenance of a system through to analytic services and business consulting. Most importantly our intention is to help and we provide our mobile phone numbers to clients for just those occassions when help is needed: we regard the support contracts as representing our minimum obligation.

Methods

On larger projects we adhere to Prince2 methods for project management. While formal project management disciplines can sometimes feel burdensome they are essential where there are multiple parties involved in successful implementation. In many cases there is a need to report progress to senior management and the disciplines and documentation of formal project management both give confidence to project sponsors and allow everyone on the team to understand the implications of delays or changes in another part of the project.

Account Management

Who do you talk to?

There are always many dimensions to a problem - especially ones that require contributions from both technical and business staff.

The art of finding a good solution lies in translating between the languages of business and of technology.

Our engagement begins by simply talking: discovering exactly what the business is trying to achieve; understanding what systems, skills and tools are already available; defining the most cost-effective and sustainable path to a solution.

Our account management, consulting and technical staff all contribute to these investigations. And they will be the same people who will design and deliver the solution.