"Maintaining your customer relations is our success"

 

Project Management Basics

Anyone who has undertaken a project will be aware of the basic stages of a project. Fundamentally something occurs within an organisation which initiates a project. This "trigger" usually requires that the business must change its operation in order to continue trading successfully. This can be caused by growth, legislative changes, competition or other strategic factors. Regardless of the "trigger" the motivation for undertaking the project must be clearly understood.

The "trigger" will often lead to an investigation or feasibility study. As a result of this process, a recommendation will be formulated and the project requirements can be gathered. Once the requirements are completed a range of solutions can be sourced and evaluated. The project can then be planned, undertaken and finished thereby giving the complete project life cycle. The figure below illustrates this process.

Evolutionary Delivery

Evolutionary Delivery (ED) aims to identify project parameters such as scope, benefits etc. by actually delivering a cut down version of the solution. It aims to do so in the shortest possible time and utilising the minimal resource. It works by defining simple project aims and investigating the feasibility of key parts of the project, and in doing so the risks and rewards can be assessed more accurately. ED is particularly appropriate to the software projects as prototypes can be built very quickly without vast cost. i.e. the cost of a mistake is minimal and it identifies the riskiest parts of the solution at the earliest point in the project cycle.

There are effectively two stages to this type of project, and investigation phase and a delivery phase. This investigation phase aims to define the project parameters in enough detail for the project viability to be assessed. Documentation and bureaucracy is kept to a minimum to avoid wasting time, however strict task management is deployed to keep the project focused. If the project stakeholders are satisfied with their understanding of the project (i.e.. scope versus benefits), then the decision to continue the project is made. If it is deemed viable then the project mitigation criteria is agreed and the delivery stage is started. If the viability cannot be assessed then either another iteration of investigation is undertaken or the project is put on hold.

The number of iterations required for the investigation stage is not defined, however before undertaking the investigation, limit of expenditure and time, must be agreed to prevent the project meandering.

The delivery phase differs only in the level of documentation and project management control. The same process as before occurs where the solution is developed and validated against the requirements. As a result of the investigation phase an idea f time, scope and cost of each requirement can be assessed quite accurately. Therefore plans can be put together with a greater deal of confidence than during the investigation stage. This means the iterations are longer in this phase and require more project management control.

Even though the investigation phase uncovers a lot of the unknowns, problems can still arise that are unforeseen. For this reason the delivery phase is iterated so corrective action can be taken if things do not go as planned. This process is known as mitigation and is vital for successful project management. Mitigation basically is an agreement as what should happen if the project starts to slip. In ED the migration is defined in terms of how scope, cost, and time are compromised against each other when problems occur. E.g. do we employ more people on the project, reduce the requirements or extend the timescale. The outcome of this decision will vary depending on the nature of the project, however mitigation must be agreed before the delivery phase is started. This avoids wasting time figuring out what to do should problems occur. It also increases project transparency as all stakeholders are involved in mitigation and validation throughout the project lifecycle.

CRM Projects

In 2002 Gartner research showed over 65% of CRM projects failed to live up to expectation. This was most likely caused by misunderstanding the nature of a CRM project. Unlike most projects undertaken within an organisation, CRM projects vary tremendously from company to company. The term CRM means different things to different organisations, and often revolves around competitive advantage and operational differences between organisations. Of course there are similarities, but the implementation often requires bespoke development in order to achieve the most effective solution.

Poor project management was not the only reason for the high failure rate of CRM projects. The two other factors for the high failure rate were stakeholder buy-in and data quality. If the data is inconsistent, stakeholders do have confidence in the system and are likely to revert back to old methods. Also, if the system does not improve the company's performance to the stakeholders then they will find ways of avoiding it. Stakeholders include everyone touched by the project including company share holders, directors, managers, staff, supplier and most importantly customers. Often the needs of some stakeholders are overlooked by decision makers this can lead to lack of buy-in and ultimately failure.

For these reasons KCS have developed an Evolutionary Delivery model for CRM project as this method is highly appropriate. By building a prototype around the companies data, stakeholder quickly get a grasp of the project and gain insight as to what can be achieved.

BACK

© 2006 KCS, Inc. All rights reserved. Contact Us.