Over the course of working on CRM Projects I have seen a variety of Project Management practices, some very good and some less good – and picked up a good number of tips along the way which I thought I’d try to put into words.
CRM Projects can be very difficult to manage, and this often comes from CRM Projects being thought of and managed as IT Projects, and the difficulty of finding good CRM Consultants that know both know how to understand the business, and how to fit the technology to the business. Each of these topics could probably easily fit a post all of their own, but for this article am aiming to think more of the Project Management side of things.
Be Consistent – Being a consistent figure in the project who provides a strong sense of how the project will be delivered can go a long way to give the people working on a project a sense of engagement and common goal.
Consistency in how project meetings are run and issues recorded can prevent the feeling that a project is ‘jumping around’ different issues or different problems from week to week. This lack of consistency can lead to a sense of disconnection for how the project is progressing, and for the people working on the project, to a sense of disengagement from the project itself.
Occasionally with failing projects I have seen the tendency of ‘project bloat’ in a similar fashion to ‘code bloat’ in that the Project Team adopt different methodologies or standards at different points in the project – which can lead to confusion, particularly for outside suppliers or customers of the project who see the project management or meetings running in a different fashion each time they are involved.
This can lead to team members or suppliers becoming disengaged from a project as they do not have confidence that issues or meetings will be managed effectively and so can often favour the approach of simply not raising issues or not speaking up during meetings where they think the project is off-course. The common symptom is for a valid issue to be raised and recorded, and then simply never addressed again, which leads to a ‘why bother in future’ line of thinking.
The key is to remember that the purpose of a project structure is to provide an environment where the team members can deliver the intended outputs of the project, and a consistent environment goes a long way to this.
The coders and designers are the ones who can be the crazy mavericks in a project, the PM gets to be the lucky one who runs regular structured meetings with these regular issues and consistent reporting, it’s not glamorous but it is effective!
Project Management Methodologies such as PRINCE2 can work to give a Project Manager a set of tools and benchmarks to operate within to provide an established framework for how the project should be managed, which can then keep project time focused on the deliverable itself.
Focus on the Outcomes – A common point for CRM Consultants is the need to focus on the business objectives and not the technology, and projects can be very similar. There are many different Project Management tools out there for managing time, issues and tasks which can be a big help to a project; but ultimately it can be worth remembering that a project can be well managed using a simple set of spreadsheets. (Methodology not Technology)
Have seen and used a good number of useful Project Management Tools from MS Project, SharePoint, good old Excel, online offerings such as Zoho, various Time Tracking tools and others – all of which have good points and bad points, but ultimately a good project manager sets out their framework using whichever technology and uses it consistently to meet the outcomes of the project.
Have seen some project managers get side-tracked into looking at all sorts of different technologies to help run the project at different times in the project, and it can quickly become a distraction away from the real outcomes that the executive are looking for the project to deliver.
Be involved, but not that involved – This can be particularly tricky for managers who have progressed from the technical side before moving into management, in that they may have their own opinions of how a design is architected or how development should be implemented.
However a Project Manager has to be careful not to disenfranchise the resources that are working to produce the deliverables for the project by becoming involved in these deliverables.
I have seen cases where a project manager would occasionally jump into the detail of discussing the design of workflow or what fields need to be on a screen – and this can act to throw off the Consultants or Developers working on the project as it becomes unclear who is responsible for what.
For the Project Manager this can then centralise decision making on them that should be being made by the different members of the team, which can lead to the manager being all things to all people and so burning out under the act of getting involved in all areas of the project.
In my opinion the art of a good project manager here is to delegate the project down to the resources involved and trust them to make the decisions that they are responsible for, but still being through in understanding the deliverables that are being produced but not dictating the detail of how these are produced.
In simple terms – if you are the developer, concentrate on developing code to meet the outlined requirements. If you are the solution architect, then concentrate on specifying the best design for the solution and communicating the requirements down to the developers. If you are the project manager, then concentrate on managing the project and delegating the specifics.
This comes down to the age old mixture of being hands-off to a point, without being so hands-off that the project happens by accident; as ultimately the manager always needs to take responsibility for the outcomes.
Audit – At some point somewhere the project executive or stakeholders are going to ask you where money has been spent, and at this point having a well audited project is going to pay dividends, particularly if the project hits a ‘turbulent period’.
No one really likes on-going documentation but a project without this reporting can simply appear as a black hole – in which only the Project Team understand where the costs are going. Unless the standards for how a project will be reported on are established and adhered to, the project can end up simply ‘existing’ without a comparable notation of progress against cost. This can become increasingly important the longer the project goes on, otherwise we can suffer from the project which runs for years but no one quite knows why or what has been achieved so far. Have seen and read of a few Public Sector projects which fit this model, which is not to say they are bad projects but more so that the value cannot be seen – particularly if staff on the project or executive change during in the life of the project.
On the more extreme side I have seen projects fail and the only secure final payment due to a complete set of consistent reporting showing that progress was made and agreed to be made – without this, the project manager could have been liable for explaining why that payment was in dispute!
Beware creating hidden costs – the importance of scope to a Project Manager cannot be underestimated as traditionally a Project Manager will base their estimated costs on the requirements or scope known to date, and these costs communicated back to the executive to inform their decision of whether to proceed with the project. It is therefore crucial to have a full picture of the scope available and that this scope successfully addresses the objective of the project.
I have seen Project Managers paint themselves into a corner by sending information to the executive on the basis of the current scope, whilst knowing that this scope was either incomplete or there were known ‘unknowns’ – which often results in Change Controls being raised that in effect cannot be refused without compromising the project’s ability to meet the original objective, which essentially holds the executive to ransom as the project cannot proceed without the Change Control and hence their original sign-off of costs was in effect not a real picture of the project.
A valid well-defined Project should always be able to continue and meet the original intention of the project without a particular Change Control being authorized –as a valid Change Control should be an addition to the original objective. If a project cannot meet the objective without a Change Control being authorized, then the project manager is effectively holding a gun to the executive to say that the project cannot continue without the change and additional costs – meaning that the executive have to debate either cancelling the project and wasting whatever money has been consumed to date, or are forced to approve further funds as the project cannot deliver without the change. At this point, this is not a valid change control and rather is the result of the scope of the project not being correctly defined which places both the Project Manager and Executive in a unworkable position that will likely place greater stress on the project.
This concept of not having defined scope for a Project can cripple a project via a resulting loss of confidence in the project.
Internal Resources, they don’t work for you – As a Project Manager, people do not work for you – managing a project will involve assigning tasks and using different resources, however you should be assigning well-defined areas of responsibility and not just giving people tasks. This allows for resources to understand their place within a project and the level of freedom their have to manage their deliverable; this can be particularly helpful when an internal resource is involved in a number of different projects with potentially different managers.
If people perceive themselves as working for an individual on a project, they can become more concerned with how best to meet the manager’s expectations as opposed to meeting the requirements for the project – ultimately a good manager wants a resource to best work for the project (or their area of responsibility in the project) and not to keep someone happy.
In some cases a Project Manager can also be a Line Manager for some of the project team – in which case, it can be useful to aim to try to divide yourself between the two roles such that you are either managing the project or managing your employees and not combining the two. (however I imagine any experienced project manager will be used to wearing a number of different hats at points in their career!)
External Resources, managing suppliers – As well as managing internal resources a CRM Project Manager will usually find themselves managing external suppliers who will be bringing their work to the completion of the project. This can often lead to Project Management problems concerning the difference between a fixed project budget and variable costs from suppliers.
The real benefit of using a 3rd party is the ability to pass the responsibility of delivery for an aspect or component of the project – such that the 3rd party can quote for the work, specify the metrics of delivery (i.e. has the product been delivered to an acceptable standard or not) and then an agreement to deliver within a time frame. In this sense the Project Manager can then ‘black-box’ the delivery (and therefore the associated risks) of the component to help them manage the overall complexity of the project.
One common flaw that I have seen with CRM Projects is for a 3rd Party to be engaged purely as outsourced development resources who ultimately have no responsibility for the product they deliver, or have specified their own metrics of success in a way that guarantees success for the 3rd party but not for the Project Manager – which can leave the Project Manager exposed to further costs if the eventual product needs to be taken back to the 3rd party for refinement. Naturally, having a well-defined scope here is vital in specifying the desired component and specifying each party’s responsibilities within the engagement.
This can be common in CRM Projects where the ultimate product of the project is a CRM Solution and a 3rd party is involved to deliver a CRM System, the gap that may exist between the Business’s CRM Solution and the 3rd Party’s delivered product is then the responsibility of the CRM Project Manager which can then give rise to additional costs that the manager has not anticipated. In this incidence it can be better to connect the 3rd party with the business or customer in a fashion that allows them to present a specification that the business has agreement with, such that the metrics between the customer and the 3rd party are well understood as opposed to being owned by the Project Manager and so potentially creating this gap.
Ultimately using an external supplier should involve outsourcing a certain level of risk as well as pure resource – or in another way, outsourcing a component to a 3rd party should include the responsibility for delivering the component within defined metrics, as otherwise the 3rd party can profit from the engagement whilst all the risk remains with the project itself which is less than ideal. In a way this keeps overall responsibility for the project with the project manager but allows components with their associated risks to be delegated to outsourcing providers on a contractual basis as opposed to simply outsourcing for a particular technical skill or resource. This element of risk differentiates an external supplier from an internal resource in how a Project Manager can manage the engagement.
The other model where a 3rd party simply delivers time and materials is more akin to using an internal resource, just one that happens to work for another company, and should be managed as such.
I imagine discussing the different aspects of managing 3rd party providers (and where freelance Contractors fit into this equation) could take up a post all of its own and there is certainly enough management books also discussing the topic – but I think put simply, it is best to aim that both parties benefit from the engagement such that the risk/benefit ratio is split roughly equal so both parties stand a good chance to profit from the engagement.
Engage and Sell – Projects can often run for a long time, and it is easy for the initial impetuous and momentum of the project to drift away. One useful skill for a Project Manager is the ability to sell the project back to the executive and to the customer as way of keeping that initial interest in the project alive.
This can be particularly true in CRM Projects where the level of user engagement can be a crucial factor in correctly understanding the business process and henceforth the scope of the deliverable – this can often be the role of the Consultant in the project, but can also often be down to the Project Manager. Presentations to the user-base or the executive to outline why the project is taking place and the intended benefits can be a crucial step in maintaining this engagement, which can be also be very useful in describing how the project budget has been spent and (in a more sales fashion) be useful for securing future budget.
Have seen projects where this constant engagement has proved key in generating a ‘buzz’ around the project which has massively helped training and user adoption, and in turn helped the project to deliver the intended business outcomes.
Often Project Management can be perceived as a step up or a progression to ‘greater things’, but I think managing a project involves a number of different skills and a different mind-set to development or consultancy, and should be treated as neither better or worse really.
A good developer can be every bit as crucial to a project as a good project manager, and should not naturally be assumed to be ‘lower down the food chain’ – as otherwise it gives the incentive for good developers to aim to be project managers for no other reason than chasing money and you can end up gaining a poor manager and losing a brilliant developer; likewise for consultants.
This being more debatable than many blog postings is very much subject to opinion, but is some of my collected thoughts from managing or consulting on a good number of CRM Projects.
Thankfully I have been involved with mostly good successful projects but am obviously drawing on experiences with more tricky projects as well, so please feel free to drop me a line or comment if you have any thoughts on this list.