Posts Tagged system
The replacement of HR and Payroll systems or services is often commenced without a clear understanding of the resourcing required to ensure a successful project. Organisations undertaking such transitions focus primarily, at least at first, on the procurement aspects of the project. Where implementation resources are considered in detail, these usually comprise the resources to be provided by the supplier rather than those that will need to come from the purchasing organisation. The organisation may well ask the supplier, on the basis of their experience of these types of transition, to estimate the level of customer-side resource needed. However, it is likely that during the sales process the supplier will play down this requirement. It can be discouraging for buyers of systems or services to discover that not only must they finance a wide range of supplier consultancy activities but that significant internal resource costs will also be incurred.
In this article I discuss the customer-side resourcing needed in HR and Payroll system and service transitions. I also briefly touch on the types of resourcing which organisations should purchase from their supplier in terms of application consultancy, training, business intelligence consultancy, data migration consultancy and project management.
People And Skills
Implementations of systems and services inevitably require detailed decision-making, intensive configuration and close supervision of the supplier/client relationship. Even when organisations are outsourcing their HR or Payroll business processes, or transitioning between outsourced arrangements, customer-side involvement cannot and should not be avoided. Whatever the nature of the transition, a range of business-specific requirements will need to be met… and your supplier should not be the final arbiter as to whether or not this has been accurately and comprehensively achieved.
So, for HR and Payroll system or service transitions, what types of people and skills will an organisation need?
Whilst this is clearly subject to organisational size, business complexity and the degree of outsourcing involved, I attempt to broadly answer this question as follows.
Area Experts And Decision Makers
All system and service transitions will require the involvement of individuals who understand the business processes and system needs of the areas affected by the transition. For a transition to be successful it is crucial that these individuals have the seniority to make final decisions on system use or service provision without recourse to committee. It is also crucial that their allocation to the project is clearly defined and not simply slotted around a ‘day job’.
Examples of the type of experts needed by the project might be the payroll manager, an HR manager, the team leader of the Recruitment team, a Training manager and so on. I will touch on what this means in terms of FTE (full time equivalents) for each type of implementation later in this article.
Transitions for in-house system use will require individuals with a working knowledge of the business processes in their area and with the skills to assimilate and apply any changes needed. They must have the aptitude to learn how to operate the new system and to share this knowledge with other users when required. HR and Payroll officers and Recruitment and Training administrators may be suitable for these roles.
It is also worth placing in these roles individuals who are positioned to continue working with the system or service after the transition has been completed, thus ensuring that the organisation benefits in the long term from the knowledge and experience gained during the transition.
Business Intelligence Experts
Business Intelligence is a crucial requirement from any HR and Payroll system or service, and transitions between systems or services must be managed closely to meet this need. Even within a fully outsourced arrangement the purchasing organisation may need to assign to the project staff who understand the organisation’s BI requirements:
– to ensure continuity of reporting;
– to liaise with the service provider;
– to confirm access to reporting; and
– to participate in report validation prior to go-live.
For in-house arrangements organisations will require staff who can administer the new reporting tool and write reports. Relying on the supplier for this can be inefficient and expensive. In smaller in-house scenarios the area expert may pick up these BI responsibilities, though this can significantly impact on implementation timescales.
Subject to the nature of the transition, future users of the system or service may need to be involved in the quality control and testing aspects of the project; and they will certainly need to be inducted into any changed business processes or system use. This requirement should be considered when preparing the business case for the transition and analysed closely during project initiation, in order to determine the likely impact on users and the amount of time they will need to set aside.
Technical Support / IT
The involvement of the organisation’s IT team will be required in any system and service transition, even if it is only to ensure access to an externally hosted database for data interrogation processes. In fully in-house arrangements, significant IT support will be needed during key stages of the transition to administer the set up and configuration of relevant servers (or to liaise with the supplier if these are hosted externally); to set up or liaise on comms; to provide desk top support to the project team; to liaise on installing the software and on subsequent software upgrades etc. Organisation size has a close correlation to the technical FTE required.
With the obvious disclaimer on vested interests, I strongly recommend employing a customer-side project manager when transitioning between HR and Payroll systems or services. At one end of the spectrum this role might involve little more than managing and monitoring the service provider (a responsibility that can perhaps be assumed by one of the area experts); at the other extreme, for larger and more complex projects, it will necessitate a full time Project Managemer with Project Office back up, covering stakeholder management, project control and governance, project team management, supplier management and project communications. In the latter case it is not advisable to use supplier-provided project management since this creates a clear conflict of interest between project manager and project, i.e. the project objective of maximising quality and reducing costs vs. the supplier’s interest in maximising profit whilst minimising their costs (inclusive of project management time).
(Optional) Business Analysts
The suppliers of HR or Payroll systems and services are unlikely to emphasise the amount of business change implicit in the implementation of their product since this may deter potential customers. However, the business change implications for the organisation should be closely analysed, preferably in advance of the procurement, and the resultant workload assessed. In large scale projects the business analysts involved in this may also be deployed later on to facilitate the business change during the transition and to generate procedural documentation and guidelines on system use. In smaller projects the area experts or assistants may inherit this responsibility.
(Optional) Data Migration Specialists
Payroll and HR system and service transitions invariably require the migration of data from the old system to the new. For larger and more complex transitions, where data is sourced from multiple locations and significant mapping is required, it may be useful to deploy in-house data migration expertise if available.
In smaller, in-house projects the Area Experts and Area Operators will undertake most of the testing activities, with participation where appropriate (e.g. during parallel running) from future system users. In larger projects, one or two individuals or even a team may be brought in to work specifically on testing and quality control.
Subject to the size, nature and complexity of the transition, trainers may need to be deployed to train system users.
Ad hoc involvement may be required from Audit, Finance, Communications, Employee Representation, Infrastructure, Property Services and so on. This will be determined by the nature and size of the organisation involved and should be identified during the initiation or planning stages of the project.
Resource Numbers (FTE)
So what are the resourcing levels that organisations will need during system or service transitions?
Clearly this must be definitively established through detailed analysis of the proposed changes and the business environment in which they are taking place. Nevertheless, to offer some initial guidelines, I hazard approximate “full time equivalents” below based on my experiences of these types of project and that of colleagues with whom I have worked closely.
In-House System Transitions For Large Or Complex Organisations (2,000 to 10,000 Employees)
|Area Experts And Decision Makers||1 per area||If the organisation is undertaking an in-house Payroll and core HR implementation, with Recruitment, Training and Self Service to follow, then this would entail an initial ‘Area Expert’ FTE of 2 (these being HR and Payroll representatives at a management level). If Recruitment and Training are to be deployed in parallel, the FTE would rise to 3 or 4, subject to the scope of the later implementations.|
|Area Operators/Assistants||1 – 2 per area||1 FTE per area may be sufficient here, but this may need to be increased for larger and more complex transitions.|
|Business Intelligence Experts||1 – 2||If the organisation has a very large business intelligence requirement then up to two FTE may be required during the transition, to analyse the requirement, develop specific reports and configure report access and delivery. In moderately sized organisations 1 dedicated BI role is normally sufficient.An alternative approach is to train area experts or operators in the use of the Business Intelligence tool. This approach, in my view, is preferable, but it will add significantly to the FTE indicated in the boxes above, particularly in light of the training required.|
|System Users||Analysis required||System users may need to participate in:
– testing at different stages of the transition;
– in discussions on current vs future system use;
– in decision making; and
– in parallel running and in attending training.
The FTE utilised here is closely dependent on the approach taken to the project.
|Technical Support / IT||0.5 – 2||Ad hoc IT support will be needed at various stages in the system transition: to administer the set up and configuration of relevant servers (or to liaise with the supplier if these are hosted externally); to set up or liaise on comms; to provide desk top support to the project team; to liaise on implementing the software or software upgrades; to maintain users and so on. Organisation size has a strong bearing on the technical FTE required.|
|Project Management||1||A dedicated project manager reporting directly to the organisation significantly improves the likelihood of a successful transition. Conversely, asking managers with other, primary responsibilities to assimilate this role inevitably compromises the management of the project.As noted above, it is also inadvisable to rely on supplier project managers as this introduces a clear conflict of interest: the supplier’s interest in maximising profit and minimising costs vs. the organisation’s interest in a successful project on time and in budget.|
|(Optional) Business Analysts||1 – 2||Business process re-engineering, if included in the transition, may well necessitate the involvement of business analysts. Business change can also negatively impact on the post-transition productivity of staff using the new system.|
|(Optional) Data Migration Specialists||1 (occasional)||At specific points in the project life cycle 1 or more data migration experts may be needed to collect, collate, map, upload and test migrated data. This is normally supplemented by supplier consultancy.|
|(Optional) Testers||1+||Subject to the project life cycle and the size of the organisation 1 or more testers may be required for testing and quality control activities. This FTE will not be continuously required.|
|(Optional) Trainers||1+||Subject to the project life cycle and the size of the organisation 1 or more trainers may be required to train users in changed business processes and the use of the new system. This FTE will not be continuously required.|
|Miscellaneous||0.5||Involvement may be required from related teams, e.g. Finance, Audit, Properties and Communications.|
Note: Very large or complex organisations with tens of thousands of employees on very disparate payrolls will need to scale up the above estimates. Senior administrators or managers with experience of each type of payroll may need to join the project team. It is also the case that these types of transition respond well to increased resourcing – showing clear improvements in the quality of the implementation when good project staffing is provided. An example might be providing dedicated resource for project and system documentation, resulting in high quality procedural documentation being made available for current and future users of the system.
In-House System Transitions For Organisations of Moderate Size and Complexity (500 – 2,000 Employees)
|Area Experts And Decision Makers||1 for HR, 1 for Payroll, 0.5 for other areas||Even moderately sized and reasonably straightforward Payroll and HR implementations tend to need one expert decision-maker for each area.Recruitment, Training, Self Service and other modules may well require less resource, or, if these are phased in after the HR/Payroll transition, the HR expert may move on to support the implementation of the smaller modules.|
|Area Operators/Assistants||1 for HR, 1 for Payroll, 0.5 for other areas||Please see note above.|
|Business Intelligence Experts||0.5||It is difficult to predict the need for Business Intelligence skills in this scenario since this is very much subject to business need. The area experts may be able to meet this requirement but this will increase the FTE indicated above, particularly in light of the additional training entailed.|
|System Users||Analysis required||System users may need to participate in testing at different stages of the transition; in discussions on current vs future system use; in parallel running and in attending training. The FTE needed here will decrease with decreasing organisational complexity and size.|
|Technical Support / IT||0.5 – 1|
|(Optional) Business Analysts||1|
|(Optional) Data Migration Specialists||<1||At specific points in the project life cycle data migration tasks will need to be undertaken. This work may be inherited by the area experts.|
|(Optional) Testers||1 – 2||Subject to project size and complexity. It is in fact more likely that the Area Experts, Area Operators and future users will undertake this activity.|
|Miscellaneous||0.5 – 1|
In-House System Transitions For Smaller Organisations (Less Than 500 Employees)
|Area Experts And Decision Makers||1 HR, 1 Payroll||System transitions for smaller organisations can be very demanding, since in-house resource is often difficult to find and often one or two individuals combine many of the roles indicated in this table.|
|Area Operators/Assistants||0 – 1 per area||As a minimum even small organisations will benefit from 1 HR FTE and 1 Payroll FTE to see through a successful transition. In this scenario the Area Expert and the Area Operator is often the same person. A less efficient option is to have multiple part-time contributors.|
|Business Intelligence Experts||< 0.5||In-house Business Intelligence expertise is critical to a successful project – but it may be the case with small organisations that this must be provided by the HR or Payroll area expert or by the supplier.|
|System Users||Analysis required||See comments above.|
|Technical Support / IT||0.5||Technical support cannot be avoided… but the requirement will be ad hoc rather than continuous.|
|Project Management||0||For system transitions in small organisations the project management is likely to be provided by one of the area experts or by a manager on a part-time basis. In either scenario, it is advisable that the individual picking up this responsibility researches the typical life cycle of these kinds of project. (A modest starting point might be my article Getting System Implementations Right.) Ideally an experienced project manager will be brought in, possibly on a part time basis.|
|(Optional) Business Analysts||0||Undertaken by the area experts.|
|(Optional) Data Migration Specialists||0||Undertaken by the area experts.|
|(Optional) Testers||0||Undertaken by the area experts and operators.|
|(Optional) Trainers||0||Undertaken by the area experts.|
|Miscellaneous||Ad hoc||Undertaken by the area experts.|
Note: The relationship between organisation size/complexity and the resource required for system transitions is not directly proportional. A minimum amount of resource will be needed for even fairly small organisations. If insufficient resource is allocated there will be a significant risk of project failure or of overloading the individuals assigned to the project.
System Implementations With Partial Outsourcing
To determine the resources organisations will need where partial outsourcing is planned, please see the estimates in the tables above. For each area being outsourced the Area Expert FTE can be reduced by 50-75% and the Area Assistants to 0%, since much of this work will be picked up by the service provider. The Area Expert FTE cannot be reduced to 0%, however, because in-house expertise will still be required to monitor the setup, testing and outputs of the service being provided.
Transitions To or Between Fully Outsourced Services
|Area Experts And Decision Makers||0.25 – 0.5 per area||As noted above, the Area Expert FTE cannot be reduced to 0% since area expertise will be needed to make decisions on the service configuration and to monitor the performance of the supplier and the service.|
|Business Intelligence Experts||0 – 2||If the outsourced provider maintains a database which the organisation’s staff must access for their reporting and data needs, then business intelligence expertise may well be required during the transition to set up or refresh the reports to be used.|
|Technical Support / IT||0.5 – 1||Ad hoc IT support may be needed for desktop and comms if the organisation’s staff access an externally hosted database for their reporting and data needs.|
|Project Management||0.25 – 0.5||Some element of supplier and resource administration will be required even for fully outsourced transitions.|
|Miscellaneous||0 – 0.25||Contributory work may be required from teams such as Finance, Audit, Communications etc.|
The above table indicates the resourcing needed for transitions in outsourced arrangements for small to fairly large organisations. Larger national and multinational organisations with employee numbers in the tens of thousands will need to scale these up accordingly.
Implementation Services Provided By The Supplier
As part of the procurement of new HR and Payroll systems or services, organisations will need to buy help and support for their implementation or transition. For organisations taking in-house solutions, the suppliers can be expected to provide:
– Supplier-side project management, to oversee the day to day relationship with their customer and the timely delivery of the purchased products or services;
– Application consultancy, to lead the customer’s project team through the setup required to implement and use the new system;
– Business Intelligence consultancy, to advise on reporting tool configuration and potentially produce the more complex reports needed for go-live;
– Data Migration consultancy, to facilitate migration into the new system;
– Tech consultancy as determined by the proposed hardware, comms and database configuration;
– Bespoke software development; and
– Training in all areas of the new system and in the use of the reporting tool.
The numbers of days purchased for each of the above types of consultancy will be subject to analysis, negotiation and the supplier’s recommendations. However, it is important for organisations to emphasise during the procurement and within the resultant contract that these recommendations should be reasonably binding and that a stream of change controls relating to work that the supplier should have been able to foresee will be unwelcome.
Areas which are frequently underplayed in system and service transitions are the amount of training required; the amount of data migration consultancy which should be purchased; and the amount of bespoke development needed. Examples from a recent project I worked on were the omission of a Finance interface from a Payroll implementation contract, which then had to be separately purchased at considerable extra cost; and the failure to recommend data migration consultancy to cover fairly obvious data such as post and hierarchy information.
In summary, HR and Payroll system or service transitions are almost always more resource intensive than organisations expect. This is partly because organisations tend towards optimism when it comes to using existing staff, and partly because system and service providers tend to emphasise the direct rather than indirect costs arising from transitions. To avoid surprises it is therefore useful, when preparing the business case for such transitions, to include a detailed analysis of this potential area of cost. The resourcing guidelines above will, I hope, offer a useful starting position for organisations embarking upon this exercise.
Luke Andreski PMI PMP
Project Management Services
With thanks to Emily Roach of Approach BI Ltd for the addition of ‘Testing’ resource to the above discussion.
© 2013 Luke Andreski. All rights reserved.
Implementing HR and Payroll systems is a precarious business. Whether you are looking at e-recruitment, training systems, core HR and Payroll, document management, workflow, P11D, talent management or self service solutions, the business environment in which your implementation will take place is complex, evolving, effected by organisational ethos and constantly striving for synergy between the employees’ needs and those of the employing organisation. Throw into this heady mix the divergent temperaments of technologically astute system developers and payroll- or people-focussed system users and the implementation of new software can be quite a challenge…
This is a challenge, however, which offers considerable rewards.
Successful ERP, HR and Payroll implementations can offer:
– improved organisational morale;
– increased employee engagement with the processes and objectives of their employer;
– a shift in the focus of talented staff from admin to strategy;
– consolidated management information;
– devolved and more timely input of data;
– improved business processes;
– more effective workflow
But what is the trick to realising these benefits? What are the ingredients needed to get your system implementation right?
A contract that works
A decisive starting point for your implementation is a well formulated contract with the supplier. Useful features of such contracts include:
– SMART delivery targets
– A detailed and binding confirmation by your supplier of the extent to which they can meet each and every requirement in your ITT
– A supplier-incentivising payment profile
– Penalties for non-performance
– Defined implementation consultancy and support
– An agreed change control procedure; and
– Clear lines of escalation…
If your contract is cursory, vague or simply inadequate, as software and services contracts often are, then you must make sure your project begins with the development of a detailed project charter or Project Initiation Document which both you and your supplier sign up to before work begins. Then, whether you have in your possession a good contract or a good Project Initiation Document, you should keep this in your back pocket at all times – and be ready to call on it at a moment’s notice.
It is essential to ‘work your contract’, making sure your agreed objectives are met and the promised deliverables delivered. This means keeping a tight rein on change control, documenting even honeymoon lapses in supplier performance, and ensuring your supplier is always aware that you expect them to meet both the letter and the spirit of your initial agreement.
Manage your supplier
As the saying goes, keep your friends close but your supplier closer. Throughout any software or service implementation it is important to insist on high level supplier representation at Performance Reviews, Steering Group and Project Board meetings. Your supplier’s representatives will far rather get it right, or fix it quick, than explain, face to face, why they got it wrong!
It is important that you own your project’s deliverables; and it is equally important, if your contract permits this, that you maintain some degree of payment leverage. For most suppliers the bottom line is the bottom line. If at all possible, you need to be able to maintain financial leverage up to the last possible moment, otherwise you will find, once the bulk of your payment has arrived in your supplier’s bank account, that their interest in your project rapidly diminishes.
Rigorous project management
Of equal importance to supplier management is the management of your own organisation. No matter how tempting it may be, organisations must avoid improving upon their original objectives. Stick to the initial scope of the project and you are far more likely to end up with demonstrable success.
Your project manager must manage your internal stakeholders, keep them informed, and ensure that all those departments or teams effected by your project also recognise their responsibilities towards it. Similarly, your project sponsor must ensure executive level participation, and publicise the executive level commitment to the project.
Communication at all levels is a key ingredient of successful projects.
A strong project team
Your project team will be central to your implementation… and should include:
– Senior members of the effected departments empowered to make system set-up or business process decisions without recourse to committee
– Hands-on team members to undertake the non-strategic work; and
– Supplier-provided consultancy with in-depth knowledge of the system and its implementation.
At various points in the implementation you may also wish to include in the team:
– Business process analysis and re-engineering expertise
– An expert on documenting the use of the system
– Dedicated resource for project communications; and
– Super-users who participate in pilot and parallel running.
Further recommendations in regard to the project team are:
– That core membership of the project team should be dedicated to the project full time
– That nominated individuals continue to work with the system after project completion, thus benefitting the organisation with the expertise gained during the project; and
– That a discrete project area is provided for the duration of the project.
A project board or committee should also be convened, inclusive of executive-level representation, senior management from the areas affected (including IT), and a nominated project sponsor.
Other key factors of successful projects
Further recommendations towards ensuring project success:
– Purchase sufficient expert consultancy for your project, but emphasise skills transfer from consultants to employed staff during the implementation period;
– Purchase sufficient system training, and also plan for in-house, cascade training where required;
– Work to a plan and change control any deviation from it;
– Develop test scripts and test rigorously;
– Phase your implementation, allowing time to get each phase right;
– Include pilot or parallel running in any project;
– Educate stakeholders to expect a productivity dip after system implementation, as the new processes bed-in and familiarity with the system is acquired;
– Engage with other organisations who use the new system; and
– Encourage the project team and stakeholders to enjoy and take pride in the project… It’s not every day that you get new toys or the chance to learn new things!
A Challenge Successfully Met
I hope these suggestions and tips offer some little guidance toward ensuring that your system implementation is a successful one. If you have other recommendations for increasing the success of ERP, HR or Payroll projects please get in touch via my blog.
In summary, within complex and forward-looking business environments the roll-out of new software or services is a major challenge… but it is a challenge which your organisation can, with a little planning and foresight, successfully and rewardingly meet.
Luke Andreski PMI PMP
A version of this article appeared in the respected Digby Morgan Newsletter, Human Resourcefulness
© 2013 Luke Andreski. All rights reserved.
Before an HR or Payroll system implementation can begin, a number of important activities must already be underway or drawing to a close. This post briefly looks at the following:
- The decommissioning of the existing system
- The procurement of a new system
- The opportunity for a business process review
- Other important ‘up front’ success factors.
Decommissioning The Current System
The decommissioning of the current HR and Payroll system can be considered a project in itself. This project should include:
- A review of the current system’s strengths and weaknesses
- An analysis of how the system’s weaknesses may be addressed by a new system
- Consultation with champions of the current system, if there are any, to ensure buy-in for system change (i.e. the initial stages of change management)
- A cost/benefit justification for moving from the current system; and
- Decisions on which current system data should be deleted, which should be archived and which data should be cleansed for loading onto the new system. It is best practice within system transitions for the new system be populated only with data that has been checked for accuracy, coherence and integrity. It is also crucial for the implementation of the new system that close attention is given to – and time allowed for – the data mapping process.
The analytical outputs from the decommissioning exercise will feed into the procurement process for the new system and into the initiation and planning stages of the implementation project.
The decommissioning of the current system may be dealt with as a subproject of the implementation project, but it should nevertheless be undertaken rigorously, with the activities described above commenced well in advance of acquiring the new system.
The procurement project will have outputs of central importance to the implementation project. These outputs should include:
- The initial business case for the system transition, which may feed from the decommissioning exercise
- A Schedule Of Work or detailed definition of the requirements which the new system and its supplier must meet
- A contract which includes:
- Delivery targets
- Implementation timescales
- The supplier’s detailed confirmation of the extent to which they can meet each individual requirement in the SOW
- A supplier-incentivising payment profile
- Penalties for supplier non-performance
- Insurance against subcontractor non-performance
- Defined implementation consultancy and support
- Defined system and DBA training
- A detailed Support SLA including escalation points
- System performance guarantees
- An agreed change control procedure
- A supplier/client conflict resolution strategy
- The purchased software, hardware, database environments, comms, services and implementation support.
It is essential, in addition to the organisation’s procurement team and representatives from IT, that both senior and junior HR and Payroll users are engaged in the selection process. Representation should also be sought from other important stakeholders, such as Finance, Audit and the employees themselves.
Business Process Review
An opportunity which should not be missed when taking on a new HR and Payroll system is that of reviewing the efficacy and cost-effectiveness of the business processes being supported by the system. The business process review should cover:
- Document and data flows
- Authorisation processes
- The practices, codes and calculations used in areas such as absence recording
- System-related HR processes and procedures in general
- Departmental boundaries and responsibilities – and whether these should be modified in light of the capabilities of the new system
- The data required by the organisation and who should have access to that data
- The standardisation of data formats and codifications throughout the organisation; and
- Whether all the reports currently generated are needed and what new reports might be required.
Other Important Success Factors
Other precursors to a successful HR and Payroll system implementation include:
- Commitment to system change by management at an executive level
- A recognition of the size and complexity of the forthcoming project. HR and Payroll implementations can range in duration from four months for a small company with straightforward pay and employment conditions to nine months for companies with employee numbers in the low thousands… through to twenty-four months for very large organisations taking a phased implementation approach
- Detailed, up front project evaluation and planning
- A financial commitment recognising the many factors of a system change of this sort, inclusive of:
Hardware, software and comms
Time taken from HR, Payroll and Finance staff for initial consultations through to testing and parallel running; and
Temporary productivity reduction whilst familiarity is gained with the new processes and system.
For an extended discussion of the key features of successful HR and Payroll implementations, please see the document ‘Best Practice for HR and Payroll System Implementations’ on this blog.
Implementing a new HR and Payroll system does not begin when system access is first provided to the project team – or even with the signing of the contract for the new system. A rigorous procurement exercise must first take place, and this should be supported by analysis of the reasons for change, the production of a compelling business case, the production of a comprehensive requirements document and some anticipatory change management.
Undertake these activities and your implementation should get off to a running start.
© Luke Andreski 2012. All rights reserved
Comments and feedback welcome!