COTS Methodology

October 20th, 2008   •   no comments   

Generally speaking, vendors develop packages for situations where they believe they can appeal to a large number of customers who all share broadly similar requirements. Typical examples are where legislation governs these requirements or where the requirements will remain fairly static e.g. Payroll Calculations, Council Tax payments etc. This means that public sector organisations such as Local Government and the NHS are typical package users.

Another area where packages have been deployed in both the public and private sector are the so called Enterprise Resource Planning (ERP) systems aimed to provide enterprise level support in areas such as Accounts/Financials, Electronic Procurement, Human Resources etc. These work on the basis that all organisations share common business processes. In all cases, the customer is expecting that the package can deliver the solution quicker, better and cheaper than the alternative bespoke design and build.

Where packages are not appropriate is if an organisation wishes to exploit IT to gain some kind of market advantage or where the system is a key differentiate in their line of business. For example, banks and other financial service organisations are always looking to provide new products that differentiate themselves from their competitors. In this case, packages would not be appropriate and a bespoke development would be more appropriate.

Organisations looking to implement packages must also be prepared for some level of compromise. Inevitably, the package will force an organisation to work in a particular way. This may require changes to the business processes within the organisation and these could be significant and far-reaching. For some, this will be an ideal opportunity to re-engineer those processes to gain efficiencies and other improvements. For others, this may not be desirable or even possible. If this is the case, an alternative approach is necessary.

Often, it is not possible to form an accurate judgement on package availability or the level of process changes required, until some way into the project. Therefore, it is essential that pre-judgements are avoided at too early a stage and time is allocated to revisit the business case and vision before committing to the project. This can only be achieved following a detailed product and supplier assessment, details of which are covered in our methodology.

Our methodology covers the entire lifecycle of the specification, procurement/selection and implementation of the COTS package. It also has the added benefit that it is compliant with the PRINCE2 methodology used by many organisations although can be used in isolation if necessary. 

read more

Why COTS Projects Fail

October 20th, 2008   •   no comments   

Package based implementations fail just as often as other projects e.g. projects that overrun, are over budget or fail to deliver what the users expected or wanted. Analysis carried out by Templar Consulting has shown that there are common reasons for project failure. These include:

 

  • Requirements and expectations not adequately defined or communicated amongst the relevant parties
  • Unwillingness to compromise on the part of the business – especially in methods of working or businesses processes
  • Business case incomplete – activities and costs overlooked
  • Flawed selection and procurement processes – failure to reach understanding on key areas such as:
    • What the product will and will not provide
    • How gaps will be addressed, by whom and at what cost
    • How customisation will be achieved and by whom?
    • Impact to working practices and what steps are required to implement changes
  • What services the supplier will provide and what expectations they have on the client that might affect their ability to deliver
  • Poor contract and supplier management
  • Lack of relevant client-side project management experience
  • Lack of project and cost controls
  • Failure to implement Business Process Changes
  • Problems with data quality and data conversion
  • Lack of involvement by the key sponsors and users

 

The above problem areas span the whole project lifecycle. Indeed, it is vital that the project is properly set up from the very start and controls put in place to deal with these issues. 

read more

COTS Implementation

October 17th, 2008   •   no comments   

On the face of it, especially to the uninitiated, package based projects appear easier than the in house development approach and they can be. However, package based projects present their own difficulties (see reasons for failure) and challenges. Unless steps are taken from the outset to understand these and to put plans in place, problems will inevitably arise that could have been easily avoided if dealt with early on. Some of these problems can be exspensive in terms of cost, time and performance.

Our methodology is designed to prepare the organisation for the difficulties and challenges faced during the implementation process. The methodology addresses the following areas as well as providing document templates which can be used on their own or with PRINCE2.

 

  • Getting the Project Authorised and Managing Boundaries
  • Assembling the Team and Defining Roles and Responsibilities
  • Managing the Suppliers and the Contracts
  • Agreeing the Vision, Goals and Objectives
  • Reporting and Control Processes
  • Developing a Communications Strategy
  • Understanding the Product/ Package
  • Analysing and Redesigning Business Processes
  • Platform and Network Sizing
  • Systems Integration Requirements
  • Data Mapping, Cleansing and Migration
  • Security, Business Continuity and Administrator Considerations
  • Reporting Requirements
  • Testing and Acceptance Specifications
  • Selecting a Suitable Cut-Over Approach
  • Testing – System, Application, Integration, Acceptance

 

read more

COTS Selection and Procurement

October 17th, 2008   •   no comments   

It is recommended that the selection, procurement and implementation processes are addressed as separate projects. They are different in nature, require different skills and follow a specific order. The implementation project cannot be defined anyway until the outcome from the selection and procurement processes are completed.

Selecting a COTS package requires a lot of time and effort and there is no real way of getting around this. In fact, within the public sector, certain processes must be followed and this in itself can be onerous. However, unless due process is followed, the results can be catastrophic. Therefore, it is important that a strategy is adopted for dealing with selection and it is usual in these circumstances to use the services of an outside consultant with experience in managing these projects.

The procurement process is often seen as part of the selection process. However, we would offer a word of caution over this approach since this can lead to a blurring of the processes which in turn can result in compromise, especially during negotiation and the definition of supplier commitments.

Part of the procurement process is to agree details of costs, payment schedules, service descriptions and other supplier commitments. This information will be used in order to revise the estimates for the whole project and revisit the business case. These must be completed prior to signing contracts and authorising the implementation project.

The management of the boundaries between the selection and implementation projects is therefore of key importance. It will ensure that the implementation project will not commence until the following are agreed:

 

  • contracts and legal issues
  • costs – hardware, software, internal, external services
  • product and service descriptions
  • customisation required and other developments e.g. integration, data cleansing and migration
  • roles and responsibilities
  • timescales
  • payment schedules, trigger points, penalties and bonuses 

 

 

read more

PMO Programme Management Office

October 17th, 2008   •   no comments   

The Programe Management Office (PMO) for many organisations is the home of project and programe management. Whilst the project support office (PSO) is often seen as an administrative function for a particular project, the PMO is the font of all wisdom about projectand programme management processes used within the organisation.

The PMO is often responsible for:

  • Methodology – Selection, deployment, training & mentoring
  • Project Management Tools and Templates
  • Process Creation and Improvement
  • Metrics and Reporting
  • Integration with Portfolio & Change Management
  • Project Resource Fulfilment (staff, equipment, location)
  • Financial monitoring and reporting
  • Maintaining Central Risk & Issue Registers
  • Project Quality Assurance & Project Audits
  • Project Planning and Updating Service

By having a single enterprise wide project office, repeatable processes can be applied which in turn deliver consistent quality. We will help you develop the project office role within your organisation, which will bring the following benefits:

  • provide effective links with the “portfolio management and assessment” process
  • improved standardisation leading to clarity of work practices
  • improved project monitoring, control and reporting allowing decisions to be made at the right time
  • improved financial reporting and control
  • development of templates for activities such as estimating, risk management and planning which will save time and effort by eliminating repetition

read more

Portfolio Management

October 17th, 2008   •   no comments   

Portfolio Management refers to way organisations take a corporate view in selecting new projects. They follow a selection process based on the project’s contribution towards the strategic aims of the organisation compared with other potential projects vying for approval. The process is by its nature enterprise wide. It cuts across the organisation horizontally rather than departmentally (vertical).

Portfolio management offers the following benefits:

Enables a corporate perspective to be taken thus preventing local initiatives that may lead to duplication, obsolescence or conflict

  • Provides business driven project selection
  • Informs better investment decision making and resource deployment
  • Enforces best practice and consistency
  • Enables measurement and continuous improvement leading to excellence
  • Keeps staff gainfully employed by identifying peaks and troughs
  • Provides a means by which all departments can have a fair voice and be assessed consistently
  • Ensures that all projects are scoped and initiated according to the standards in place
  • Provides a means to ensure that live projects are monitored and regularly reviewed to determine their progress, relevance and priority 

The following diagram shows how a generic Portfolio Management model may look

<<INSERT DIAGRAM >>>> 

The benefits of portfolio management are brought about by:

  • identifying new requirements as part of the strategic review process
  • quantifying those requirements in terms of likely cost, benefit, impact and alliance with the strategic goalsprioritising the requirements against the portfolio of projects and potential projectsapproving, rejecting or otherwise prioritising the projects
  • formally handing over the requirements to the programme director or equivalent for project initiation thus ensuring top level recognition and approval
  • monitoring the progress of live projects with the authority to cancel and put on hold if circumstances dictate

As will be realised from the above list, the process necessitates involvement by senior management and decision makers. Although many organisations will employ less formal arrangements for carrying out the above, many find that the process leads to conflict and the danger of departmental projects being instigated which may impact other initiates and developments.

Clearly, implementing successful portfolio management is a project in itself and has to be designed to fit within the enterprise project management culture – whichever stage this may be at. Our associates have experience of several different approaches to Portfolio Management and can help to design an approach that best suites your situation.

read more

Project Governance

October 17th, 2008   •   no comments   

Project Governance …. read more

Project Recovery

October 17th, 2008   •   no comments   

When projects start to get out of control it is normal practice to involve outside assistance to discover why the situation exists and to recommend ways of putting this right. Being detached from the problem, the consultant is positioned to ask probing and sometimes obvious questions without appearing to be apportioning blame.

Templar Consulting have devised a structured approach to project problem solving, which is an extension our Project Assessment Methodology. (PrAM). This approach takes the form of a series of meetings and interviews together with the collection and analysis of the various project documentation.

From this assessment, it is then possible to draw conclusions and present the findings in whatever format is required e.g. report, presentation etc. This will also recommend ways in which the project can be brought back under control.

 

read more

Project Audit

October 17th, 2008   •   no comments   

Just as Quality Management Systems (QMS) are periodically audited, so must project management processes. Where organisations are using a methodology such as PRINCE2, we will check on how this is being applied and whether it is proportionate. One common failing is that the project methodology can consume a large proportion of the project resources for a disproportionate level of return. Alternatively, where there is a lack of adherence to project methodology, this leads to problems in control and communications. We can help get this right.

To achieve this we will carry out a structured audit similar to a Quality Audit that many will be familiar with. At the end of the audit, a report will be produced detailing the findings together with recommendations for improvements. This inexpensive service will ensure that the investment in the methodology and therefore the anticipated benefits of this are being realised.

Where organisations have their own methodology, we can provide a bespoke auditing service designed specifically for that organisation. We would firstly create the necessary auditing forms and templates which can then either be applied by Templar Consulting or by the internal auditors within 

 

 

read more

Project Assurance

October 17th, 2008   •   no comments   

Project Assurance services are designed to measure the extent to which a specific project or programme is performing against an agreed set of criteria. They focuses not simply on whether the project is on track in terms of time, quality and budget but also identify areas for improvement. Often, the role is undertaken on behalf of the project sponsor.

We have developed the Project Assurance Methodology (PrAM©) that provides the framework for our analysis and enables us to easily identify quick wins as well as other areas that require longer-term improvements. The best time to introduce this is at the start of the project but it can be introduced at some later point. Where a project is already underway, we recommend starting with a project assessment, which then acts as a baseline for future measurements.

The outputs from the service detail how the specific project or programme is performing against agreed criteria. They also contain recommendations on how to bring about controlled improvements. These will be presented in a positive way since it is designed to be helpful rather than critical. The scope of the assessment would be agreed with the client but would typically include:

  • an assessment of whether the project’s objectives and scope are clearly understood and communicated and whether they are still relevant
  • reviewing of the business case to determine whether it is still valid and relevant
  • an assessment of the resource requirements against resource plan and identify any discrepancies
  • reporting on the dynamics within the project team and identification of any resource issues
  • reviewing of the project plans to determine whether they are at the right level of detail, are up to date and are relevant to the project’s objectives
  • reviewing and reporting on financial controls and highlight issues
  • examining and reporting on project controls to determine whether they are being carried out effectively e.g. regular reporting
  • examining the project logs to ensure they are being kept up to date
  • report on whether the project methodology is being adhered to and make recommendations
  • highlighting areas of strength an weakness
  • proposing actions aimed at bringing about measurable improvements
  • carrying out a follow-up exercise at a later date to measure the improvement

read more