Sign in

Using PRINCE2® for a CRM launch at the University of Manchester Case Study

Case Study

prince2-logo.svg
Using PRINCE2® for a CRM launch at the University of Manchester Case Study

Case Study

prince2-logo.svg
  • Case Study
  • Project progress
  • Project planning
  • Project management
  • PRINCE2

October 1, 2020 |

 11 min read

  • Case Study
  • Project progress
  • Project planning
  • Project management
  • PRINCE2

All of our White Papers and Case Studies are subject to the following Terms of Use.

The Graphene Engineering Innovation Centre at the University of Manchester is using PRINCE2 to introduce a new customer relationship management system. The PRINCE2 method’s trademark stage boundaries, lessons log, and principles have been invaluable to their progress.

You can read all about their project in this new case study.

Introduction

The Graphene Engineering Innovation Centre (GEIC) is an industry-led centre at the University of Manchester specializing in graphene applications in partnership with academics.

The GEIC specializes in the rapid development and scale-up of graphene (graphene is an allotrope of carbon consisting of a single layer of atoms arranged in a two-dimensional honeycomb lattice) and other 2D materials applications. The GEIC will focus on six application areas to rapidly accelerate the development and commercialization of new graphene technologies, including:

  • composites
  • energy
  • membranes
  • inks, formulations, and coatings
  • graphene production
  • measurements and characterization.

This case study will explore a project called CRM procurement. The project was linked to a programme of business change taking place with the GEIC systems and processes.

The GEIC CEO mandated the kick-off of the project and placed the Business Development Director as lead of the project board. As the project manager, I was responsible for managing the entire project, working with key stakeholders to deliver what was required for the GEIC. My first task was to create the project brief.

Background

The GEIC had been open for two years and had tried to implement Dynamics CRM (A Microsoft customer relationship management application), which the IT department had recommended as other departments were using it. The GEIC needed the CRM to manage new inquiries through to winning new projects. The Dynamics CRM was very clunky and not user friendly and after months of trying to make it fit the needs of the GEIC, it was scrapped.

The team at the GEIC had been working without a CRM for several months but, due to the increase in new opportunities, they needed to be able to track potential new customers.

It was agreed that the project would be managed using PRINCE2® to make use of stage gates (or boundaries). These stage gates would not allow the project to deviate from the project brief. Another advantage of the stage gates is that the stakeholders are able to set tolerances and agree the objectives for each stage plan.

The drivers for change were the GEIC senior management team agreeing for a CRM to be obtained and implemented. This case study explores the project which implemented the CRM.

I drafted out an initial plan on a page (the whole project time-lined on one page, so you can see the stages from start to finish) of the outline of the project. This plan on a page was used to seek sign-off on the project.

Aims and objectives

The GEIC senior management team wanted a system that was easy to use for the end user, cost-effective for the business, and accessible from all current user PCs and laptops.

The GEIC CEO requested that there was an improvement to onboarding the customers, from initial conversations through to completing projects. The CRM would allow each staff member to be able to view all notes, meetings, and emails with a customer, ensuring that the onboarding process completed for each new customer followed the company process. A business case was created to support this.

Long-term goals

The long-term goal set by the board was to find a solution that would be able to grow and adapt with the business over time.

Short-term goals

The short-term goal was to carry out business requirements gathering to create the process for the use of a CRM, in order to obtain sign off on the CRM selected from senior stakeholders and the University IT team. The financial objective was to ensure that the cost per user was kept low, with options for upgrades to the package and users.

Approach

Specification of requirements for the six project controls:

  • Benefits: A system that is easy to use for the end user.
  • Cost: Cost-effective for the business, could not cost more than £20 per user per month.
  • Scope: Accessible from all current user PC/Laptops, as a minimum but could include the use on phones as well.
  • Quality: Ability to view all customer details. A minimum was phone numbers, email addresses, and so on, but ideally should be able to view email conversations.
  • Scope: Scale-up, to be able to add additional users. Must allow up to 50 users.
  • Risk/Time: The system should be fully operational within three months for the test users and deployed by the end of month four.

The stage planning 

Once the project had been signed off, I created a detailed plan using Microsoft Project, with key stage gates (gate reviews stop the project from progressing if the current stage has not been complete or the project is no longer viable or desirable). Workshops were held with key stakeholders to review the plan and seek agreement to move forward.

Once the plan was agreed, reporting methods were also agreed, as were the work packages.

The scope of the project (requested by the senior leadership) was to create a process for new customers to join, through to completing projects. Once this was complete and signed off, we procured a CRM. The CRM solution we brought was a basic off-the-shelf product that you are able to build/design to fit your individual needs. As part of this process, we tested, implemented, and established a deployment to the team, refining it once it had been used. I was given three months but, due to lockdown, was given an extra two months to complete the project.

In the end, the timeline was:

  • Stage 1: Weeks 1-4: covered the requirements gathering to build into the process. This was carried out by the group and individual meetings with key stakeholders and users using the MoSCoW prioritization method to ensure we only added in the MUST as part of the solution design.
  • Stage 2: Weeks 3-6: developed a process to be used with a CRM and sought sign-off.
  • Stage 3: Week 6: procured a CRM that fitted with the needs of the business.
  • Stage 4: Weeks 6-8: tested and configured the CRM.
  • Stage 5: Weeks 8-9: carried out further testing with a large sample group and refine process and CRM configuration.
  • Stage 6: Week 10: deployment to all staff with early life support.
  • Stage 7: Week 11: sought feedback from all users and refined for the last time.
  • Stage 8: Week 12: handover CRM responsibility to end user.
  • Stage 9: Week 12: close down report.

Challenges

Overall, the key challenge to the project was that this project started in tandem with two other projects, which meant stakeholders’ time was split over the three projects.

Throughout the duration of the project, we encountered challenges within the following stages:

Stage 2: agreement on the process took a lot longer than planned, due to conflicting opinions from key stakeholders. To overcome this, a deadline was given to stakeholders to provide feedback & approval on the process.

Stage 3: IT raised questions about the cloud-based system and its security, which added delays in obtaining sign-off for the questions raised. To overcome this, we simply had to resolve any queries raised by IT and wait for IT to approve the use of the cloud-based system. This stage issue was managed by exception as dealing with IT did not change the stage plan any questions that users agreed by the project board.

Stage 5: the solution used has a team that will answer questions, but we found that it took a considerable amount of time to get a response from them. We found it difficult to handle the influx of questions raised by the end users due to a delay in responses. To overcome this, we used a lessons log and communicated these weekly to answer any questions that users may have and carried out some additional training to users who needed it.

For future projects, especially while the completed process was being created, we would look to seek agreement from stakeholders on the process overview and define any manage by exception factors clearly within the stage gate plan (agreed by the project manager). This way, when the completed process was presented the approval would have been almost agreed.

Successes

We are currently at stage 8 of the project, so the work is still in progress and we are yet to evaluate all the benefits realized. Using the PRINCE2 method, I was able to create the stages, which ensured the project did not progress until the current stage work was complete and allowed us to appropriately allocate work to team members using a structured approach.

Already, we have added additional users. Users are now able to view other colleague cases through the solution as we selected a solution that would able open cases. The CRM solution can be viewed on all PCs and as a result, we have not had to replace anyone’s equipment.

The entire staff are using the CRM effectively and are finding it easy to use. The GEIC is managing the onboarding of new customers with ease.

Conclusion

This project was created to deliver a CRM solution to ensure that the onboarding of new customers can be carried out quickly and effectively. By using PRINCE2, the project delivered what was originally agreed in the project brief. The GEIC now has an easy-to-use solution, and all cases can be viewed by the whole team which has meant that the absence of one member does not impact the onboarding process. The stages of the project allowed the project board to close the project before any costs had been incurred on the purchase of the CRM, as the first few stages gave them the confidence to progress into the final stages.

As mentioned, the key challenge was that two other projects started at the same time as this one, which meant stakeholders’ time was split over the three projects. Looking back, it would have been useful to have these projects delivered within a programme, so they could have been staggered and managed more effectively. Despite this, we were still able to complete the work required for each stage and effectively progress to stage 8. The CRM selected is easy-to-use and can be accessed on all laptops and PCs. We can now add users and reduce the number of users. The process created means no action is missed during the onboarding of a new customer but is still easy to use for end users.

The key lesson learned is the need for agreement from stakeholders. Challenging senior staff members is a difficult task due to their busy schedules and and the need to obtain a firm agreement upon action for the new work package. Stakeholders can, and do, change their mind on the best course of action. In this case, the stakeholders decided to change the rollout process and I found it useful to email back what was agreed in the meeting straight after so to ensure there was a good record of the agreed actions. I found that providing stakeholders with deadlines via email for the feedback helps support you in achieving your objectives for that stage in the project. For those who were unable to respond to email, I would book in 1-2-1 meetings in order to obtain a response.

In 12 months, we have planned to look at the integration of the CRM across other applications used at the GEIC.

About the author

Nathan Lumb is a PRINCE2 project manager at Graphene Engineering Innovation Centre at the University of Manchester. Having previously worked for Debenhams and Rathbone Brother Plc, Nathan has experience in delivering and managing projects across the financial services, property, science & engineering and retail sectors.

Using PRINCE2® for a CRM launch at the University of Manchester Case Study