Sage CRM 2020 R2: Developer Best Practices (Part 3)

5 minute read time.

This is the third in a short series of articles on Sage CRM Developer Best Practices. At the end of the previous article, I promised I would discuss how project management and communication factors can influence overall project success.

What is project management within a Sage CRM Implementation context?

There is nothing intrinsically difficult within a Sage CRM implementation project. The actual installation of the sales, marketing and customer service modules is very straight forward. But if you are going to implement Sage CRM successfully especially in the context of an existing Sage Business Management system (accounting solution) then you need to be prepared to be very disciplined in the way in which you approach every part of the project. That is from the very start. How you initiate the project, how you plan the actions to be carried out and then how you execute those actions, all require you to have a strong control of the project. This control and discipline need to run from the beginning to the end of the work. It is not just your own actions that need to be controlled and managed but the whole team that includes the customer and users and other stakeholders. You need to be clear about project expectations and how you can measure your achievement of the project goals and what may be the customer's own success criteria.

Management of a project involves understanding and managing three key elements -

  1. What do we have to do (Scope),
  2. How much time do we have to do it (Time),
  3. How much money is available to do it (Cost).

A Project Manager quickly realises that all of these factors - scope, time and cost are interrelated project constraints that need to be carefully monitored. A change in one constraint immediately affects the other. All three constraints combine to influence a fourth constraint - quality.

One constraint cannot be changed without affecting the others.

They compete against each other, for example:

  • Increased scope (e.g. adding more features) typically means increased time and cost. The choices that are made about approach workflows, extending Sage CRM to cover new entities or deciding to use the Advanced Email Manager to process inbound communications will by necessity require more time to design, implement and test.
  • A tight time constraint could mean increased costs (e.g. adding more people to get the job done on time) and reduced scope (remove features).
  • A tight budget could mean increased time (not able to hire enough people to get the job done on time) and reduced scope (remove features).

Each of these three constraints can impact the fourth constraint, "quality", and inversely, changing the quality constraint can affect other constraints, for example increasing the required quality level for the project can put demands on cost and time. Quality within the context of a Sage CRM project is not about whether a feature works or not but how the user experiences the system. What is the performance like? Is the screen design right?

It makes sense that quality sits in the middle of the triangle being influenced by and acting as an "influencer" on the project constraints. The user experience is going to be at the heart of the project.

But whatever project methodology you use within your projects, your work is going to be about managing these constraints to achieve a successful project delivery, as defined by the objectives of the project.

You do need to think carefully about the risk involved in each time of implementation. You can approach the implementation of Sage CRM within an integrated system as either a big bang, a series of phased or a set of parallel projects.

A phased project offers the best approach where professional services resources are scarce and you wish to minimise the risk at the same time being able to demonstrate a clear benefit for the system. A phased approach could see the different modules of Sage CRM each being rolled out across a customer's organisation in a sequence. This would allow for the project team to learn from the process. This would mean the team became better at understanding the amount of work that each phase would actually take. Smaller phases allow for better estimation and baselining for each subsequent phase.

Measuring up

At the start of the project, each of the constraints is "baselined". This simply means that estimates are produced against each project constraint to allow the project manager to take "temperature readings" at defined milestones to determine how well the project is progressing. Corrective actions can be taken if the project is veering off track. Monitoring the baseline and taking corrective action is part of the risk analysis and mitigation that all project managers do during a project, and will often necessitate using up contingency that has been built into the project plan.

It doesn't matter what type of methodology you use within a Sage CRM implementation. Waterfall or an iterative approach can be equally successful. The key factor is your confidence and experience of managing the process.

"What we have here is a failure to communicate"

In most projects, there could be many people working on different aspects of the project. A project manager needs to be able to communicate with each individual, whether it is for gathering requirements, understanding the scope, identifying risks and for communicating status. A failure to communicate will lead to poorly defined requirements and constraints (Cost, Scope, Time and Quality). This can lead to serious confusion among team members and ultimately project failure.

 Each step in an implementation requires a large amount of non-technical project management. These are not skills and requirements that are unique to Sage CRM. These will be transferable from anyone who has successfully implemented a Sage accounting solution or another software system.

Links to articles in series

  1. Introduction - Developer Best Practices (Part 1)
  2. Project Pain Points - Developer Best Practices (Part 2)
  3. Project management and communication factors - Developer Best Practices (Part 3)
  4. Practical Tips - Developer Best Practices (Part 4)
  5. Proper preparation - Developer Best Practices (Part 5)