13 October 2019 - How not to screw up your next Salesforce project
As part of one of my talks at Inspire East I was asked to host a panel in the afternoon, titled: How not to screw up your next Salesforce project. I was joined by 4 other people; a great representation from the ecosystem to participate on the panel and together I think we had around 40 years of Salesforce experience between us. Seriously, we should write a book...
When I was asked to host the panel I first put together questions that we could work through, then ran them past my panelists for their input. I'm going to share with you the questions we came up with and some of the keys outputs from the conversation they generated.
1. What is considered a project?
Funnily enough, I hadn't thought of this for a starter question. Having worked in a project environment for many years my mindset is already switched onto this way of working. But, for our audience, this could be new to them. So, let's start here.
A project is a defined package of work that has been identified to be completed within set parameters and a timeline. This is leaning towards a 'Prince2' definition but it is essentially correct. The reality of any company undertaking a project is that the main ingredients, that are scope, timeline and budget will generally wobble from the initial plan. A project could be as small as an internal user creating a new dashboard, all the way up to full business digital transformation. The size could be the only differentiator while the approach could be very similar.
2. Why do projects fail?
The overriding answer to this question came communication. It was raised under several different veils but ultimately projects fail due to a form of communication failure along the way.
Let's consider why projects are started in the first place. All projects are to bring about change in some way but if you don't have a clear goal of what the outputs of the project are going to deliver then you start with risk. Communicate clearly the project goal with those you can share with to get their buy in. You can't always communicate with all parties as the outputs could affect a workforce's current work pattern.
There are times when projects are kicked off by well-meaning senior people to affect change but can quickly turn into a vanity project, still being pumped of cash and resources despite the evidence showing its the wrong solution, but their pride will not stop the project. This can often be due to being wooed into a seemingly cost-saving and speedy solution as opposed to a longer term, scalable one.
Projects fail when the wrong people are involved from the beginning. Its often assumed that a project must have the most senior people making the key decisions. While gravitas for the project is important, its key to have people who will be using the end output (the Salesforce system) involved and helping to guide through actual business processes when capturing requirements and not perceived ways of working as dictated by those removed from the day to day.
There is always the thought of, do projects fail? An undertaking of a project will generally create some outputs. While they may not be the ones you were hoping for, they could offer the team valuable insights into: ways of working, business needs, requirements, knowledge and experience gaps. The insights gained can then be used for future, more efficient projects.
3. How can you set a project up for success?
For me, you have to start at the pre-sales stage by ensuring that your customer is engaged throughout and understands exactly what they have asked for, what the outputs are going to be and what inputs required from both parties. Get to know the customer, ask lots of questions and speak with all levels of contact so that you can fully capture all requirements.
Be realistic on what needs to be done to deliver the outputs needed. Too many times I have been hit with a new project to deliver that while has been thoroughly scoped out, has been shaved to make the deal more attractive for the customer to sign. Both parties need to be realistic on their version of MVP (minimal viable product) and its associated costs and time. Be too narrow and the system will suffer with poor adoption, or fail to go live.
Get the right people to complete the project. This is an element that can also be impacted by perceived cost but in reality it will cost more in the longer term if you don't have the right skills in place from the beginning. Too often businesses will shave on Project Management, Business Analysis, Testing and Training skills, hoping that these will be somehow covered by the Admins and Devs in situ. While best endeavours suggest they can, its always to a detriment somewhere along the path.
4. Are there any top tips to give an individual about to embark on a project?
Let's start with this, keep calm, it's only a project and not life threatening surgery. Even the most 'fixed' of projects will have their tolerances and will allow a wobble. At the beginning of the project you will never know everything that you need to complete it. There will always be something that will be uncovered that even the client hasn't realised that will be super important for success, so go with the flow.
Communication is key. Find out the best way to do this and keep the comms frequent. The last thing you want to create are secrets and lies by those who are fearful of the change, especially if they are being kept out the loop.
Try not to put yourself in a position where you are being played off against departments within the client. Sometimes there are 'sick' projects where you are asked to play referee to internal politics and spend an unhealthy amount of time doing this than delivering outputs. If this starts to happen then bring the waring departments together to talk openly and find a solution. Don't get stuck in the middle, but if it does become painful then remove yourself from the project. Life is too short.
Deliver something that can be built on. Discover what the MVP is and get that in first, with the idea to continuously add to it. The client may ask for the moon on a stick, start with the stick and suggest the moon will come in 'phase future'.
Remember that projects will go through the change cycle where at some point along the journey there will be the dip of despair. You must try to keep higher up than your customers and colleagues so that you can pull them out of the dip. Stay motivated, focus on the positives and the project goal to keep the project on track.
With thanks to my panelists: Chris Emmett, Richard Clark, Kerry Townsend and Barry Roberts for their insights at Inspire East.
When I was asked to host the panel I first put together questions that we could work through, then ran them past my panelists for their input. I'm going to share with you the questions we came up with and some of the keys outputs from the conversation they generated.
1. What is considered a project?
Funnily enough, I hadn't thought of this for a starter question. Having worked in a project environment for many years my mindset is already switched onto this way of working. But, for our audience, this could be new to them. So, let's start here.
A project is a defined package of work that has been identified to be completed within set parameters and a timeline. This is leaning towards a 'Prince2' definition but it is essentially correct. The reality of any company undertaking a project is that the main ingredients, that are scope, timeline and budget will generally wobble from the initial plan. A project could be as small as an internal user creating a new dashboard, all the way up to full business digital transformation. The size could be the only differentiator while the approach could be very similar.
2. Why do projects fail?
The overriding answer to this question came communication. It was raised under several different veils but ultimately projects fail due to a form of communication failure along the way.
Let's consider why projects are started in the first place. All projects are to bring about change in some way but if you don't have a clear goal of what the outputs of the project are going to deliver then you start with risk. Communicate clearly the project goal with those you can share with to get their buy in. You can't always communicate with all parties as the outputs could affect a workforce's current work pattern.
There are times when projects are kicked off by well-meaning senior people to affect change but can quickly turn into a vanity project, still being pumped of cash and resources despite the evidence showing its the wrong solution, but their pride will not stop the project. This can often be due to being wooed into a seemingly cost-saving and speedy solution as opposed to a longer term, scalable one.
Projects fail when the wrong people are involved from the beginning. Its often assumed that a project must have the most senior people making the key decisions. While gravitas for the project is important, its key to have people who will be using the end output (the Salesforce system) involved and helping to guide through actual business processes when capturing requirements and not perceived ways of working as dictated by those removed from the day to day.
There is always the thought of, do projects fail? An undertaking of a project will generally create some outputs. While they may not be the ones you were hoping for, they could offer the team valuable insights into: ways of working, business needs, requirements, knowledge and experience gaps. The insights gained can then be used for future, more efficient projects.
3. How can you set a project up for success?
For me, you have to start at the pre-sales stage by ensuring that your customer is engaged throughout and understands exactly what they have asked for, what the outputs are going to be and what inputs required from both parties. Get to know the customer, ask lots of questions and speak with all levels of contact so that you can fully capture all requirements.
Be realistic on what needs to be done to deliver the outputs needed. Too many times I have been hit with a new project to deliver that while has been thoroughly scoped out, has been shaved to make the deal more attractive for the customer to sign. Both parties need to be realistic on their version of MVP (minimal viable product) and its associated costs and time. Be too narrow and the system will suffer with poor adoption, or fail to go live.
Get the right people to complete the project. This is an element that can also be impacted by perceived cost but in reality it will cost more in the longer term if you don't have the right skills in place from the beginning. Too often businesses will shave on Project Management, Business Analysis, Testing and Training skills, hoping that these will be somehow covered by the Admins and Devs in situ. While best endeavours suggest they can, its always to a detriment somewhere along the path.
Let's start with this, keep calm, it's only a project and not life threatening surgery. Even the most 'fixed' of projects will have their tolerances and will allow a wobble. At the beginning of the project you will never know everything that you need to complete it. There will always be something that will be uncovered that even the client hasn't realised that will be super important for success, so go with the flow.
Communication is key. Find out the best way to do this and keep the comms frequent. The last thing you want to create are secrets and lies by those who are fearful of the change, especially if they are being kept out the loop.
Try not to put yourself in a position where you are being played off against departments within the client. Sometimes there are 'sick' projects where you are asked to play referee to internal politics and spend an unhealthy amount of time doing this than delivering outputs. If this starts to happen then bring the waring departments together to talk openly and find a solution. Don't get stuck in the middle, but if it does become painful then remove yourself from the project. Life is too short.
Deliver something that can be built on. Discover what the MVP is and get that in first, with the idea to continuously add to it. The client may ask for the moon on a stick, start with the stick and suggest the moon will come in 'phase future'.
Remember that projects will go through the change cycle where at some point along the journey there will be the dip of despair. You must try to keep higher up than your customers and colleagues so that you can pull them out of the dip. Stay motivated, focus on the positives and the project goal to keep the project on track.
With thanks to my panelists: Chris Emmett, Richard Clark, Kerry Townsend and Barry Roberts for their insights at Inspire East.
Comments
Post a Comment