For many businesses, now is the time to move to Salesforce Lightning.  But moving to Lightning can feel like a daunting task.  Where should you start?  How to you make sure you don’t disrupt the business?  So in this first post, we will take a look at how to plan your move to Lightning Experience.

In the next post, we look at how to implement your plan and go-live!  But in the meantime, if you have any tips of your own, feel free to add them in the comments section below.  And let’s start planning…

Planning your move

Before we start, let’s just clear the air.

As an #AwesomeAdmin you probably already know there is planning required to make the switch over.  The old adage – ‘failure to plan, is planning for failure’ – is never truer than when changing how a user works within a system.

But driving user adoption and making the transition as smooth as possible, doesn’t need to be overly complicated process though.  And by planning your transition you set yourself up for the best possible result.

So let’s get started.

WIIFM?!… What’s In It For Me?

One of the first steps to planning any change should to be understand the ‘what’s in it for me’.  It is the first question most users want to know about any change…

Sure Lightning Experience looks great.  You can now customise the colours to match your company identity…

But that doesn’t really engage end-users in using the platform.  After all we want them to use the system once we make the change, don’t we?…

Be honest with yourself.  Would a typical sales, customer service or partner really care about that?

Answering this question for each type of stakeholder is one of the best ways to ensure everyone buys-in to making the move.

A great example is dealing with a stakeholder from Sales.  Lightning offers many new features which benefit most sales users.  Here are a few…. Sales Path to guide on what to do in the system to move to the next stage.  Kanban board for managing your pipeline with drag-and-drop ease.  What about Sales Console?  Use of macros practically anywhere in Salesforce?

The point here is to you need to demonstrate you understand your end-users by understanding their problems.  If you understand the problem, you can effectively position a feature or benefit that solves it.  And this helps engage these stakeholders early on…

 Why should we invest in making this change?

The next step is to develop a business case.  It sounds horrible, but it can really help in convincing your senior stakeholders on why they should support the change.  And to drive adoption when launched, you need their support…

This may not be applicable for all business, but I always try to work out a rough cost/benefit to any changes my team make.  Even if it is just an estimate.  And this loops back to understanding the WIIFM within your business.

Every business problem – and in turn the potential solution – have a potential time/cost associated with them.

This is the gold dust in developing your business case to answer the question most senior stakeholders within business would ask,

As an example, a simple cost-to-benefit calculation could be based on decreasing sales admin time.  By improving the time taken to process and close a contract within the system, you can quantify the potential upside to the business.

So if an average salesperson closed an extra 2 deals a day/month/year due to improving the sales workflow in Lightning, how much is that worth to your business?  (average contract value * extra deals per day = potential upside).

Keep in mind, this is only an estimate.  But it can be a useful way to engage the business and to capture metrics relating to the success of the project once completed.

Mind the gap…?

Salesforce has spent the last couple of years attempting to make Lightning match the features of Classic.  But there are still some gaps between Classic and Lightning Experience.

The next item on our list is to check what these gaps actually mean your org.  By doing so you ensure your users can still use all key features they need.

If there is a feature gap or limitation, the next step should be to look at the publicly available roadmap.  This outlines the upcoming features planned for release and may cover the feature that is a priority for you.

Also each published version of the release notes now include a section on what is and what is not included in Lightning Experience.  For the Spring ’18 section, please have a look here.

Side note: The roadmap is scheduled to be updated after the Spring ’18 release, but a handy video to watch about the Force.com platform and upcoming features is the True to the Core video.  Or there is a breakdown of the expected features in the 2018 predictions post here.

Resources

Salesforce is clearly invested in supporting all orgs to move to Lightning Experience.  Releases now introduce most new features as Lightning Experience only.  But to help, there is a wealth of content available for free to sink your teeth into.

For starters there is a great Trailhead module specifically on getting hands-on with a Lightning Experience roll-out.  There is also a quick overview of the steps on the Admin blog.  But personally I highly recommend jumping to the Power of Us site, which has been setup to cover best practice for making the jump to Lightning.

Each and every org now also has the Lightning Readiness Check built-in.  And the check gets an update every release to give you more and more insight into your org’s compatibility into making the change.

If you want more information about how to take a business-first approach to rolling out Lightning, I found this article over on SalesforceBen.

So we are almost ready to go.  In this data migration series, we have already looked at how to migrate data and some tools to help with the migration.  But now for the fun part, I want to share with you some data migration tips to help make your migration into Salesforce as smooth as possible.

Let’s jump right on in, and please share any of your own tips in the comments section below.

Data Migration Tip #1: External IDs & Upserts

Let’s walk through a common scenario in a data migration…

The Data Migration nightmare:

You are about to migrate 12 different objects into Salesforce, everything from Accounts, Contacts and Tasks through to Opportunities, Cases and a number of custom objects you have created in your org.

How do you create these records in Salesforce, and still have all related records end up linked together?

Do you insert the first object (let’s say Accounts).  Because you need to link the Contacts to those Accounts, in the second file do you use Excel to create the link?  Do you take the import file from Dataloader, run a VLOOKUP in the Contacts file and then pull in the related Account IDs?  YUCK!  Now imagine having to repeat that process for all 12 objects…

I have been there myself.  And when it is a very large migration it can become extremely difficult to track and manage all the spreadsheets.  Especially when you are working with live data, that is always changing and is never static.

This scenario can be the nightmare of any data migration but it doesn’t need to be.  #NoMoreVLOOKUPS

Salesforce External IDs:

As you know, each Salesforce record is given a unique 15/18 character ID.  That is great, if you are only dealing with data in a single system or Salesforce org.

But what happens when you are need to store the ID of a record, that is actually sourced from a system outside of your Salesforce?  For example an ID from an invoicing system like SAP or Oracle.

This is where External IDs come into the picture.

By configuring a field to be an External ID you can then use it to store the original reference/ID from the other system.  Additionally, you can also use it to prevent duplication within Salesforce by setting the External ID field to unique.

It is this ‘uniqueness’ that helps us out when migrating bulk data into Salesforce.  As Salesforce will automatically index the External IDs, allowing you to use this as a reference when doing an Upsert within Dataloader.

#NoMoreVLOOKUPS: Upserts with External IDs:

Now let’s take a quick look at Upsert within Dataloader.  Upsert combines the ability to either Insert/Update records while using a single file.  However, using Upsert in Dataloader also gives you access to a few extra features.

After you click Upsert and start going through the Import Wizard, you will get the ability to select either the Salesforce ID or an External ID (if available on the object).

Additionally, for any relationship you have on the object, Dataloader will also prompt you to select the applicable ID fields which is also referenced in our import file.

This is how you avoid using VLOOKUPs!  

By populating an External ID, on each record you load into Salesforce you can then use this to get Salesforce to do the lookup for you.  Even if you don’t actually have an External ID from another system, you can create your own.  Just make sure it is unique for each record.

I know this is a little confronting to start with.  It took me a little while to wrap my head around just how exactly to do this when I ran my first data migration.  However Upsert & External IDs can save you so much time, I strongly recommend you practice and learn how to use this ‘double act’ to your advantage 🙂

There is of course more resources available on this topic.  Salesforce Help has an article which gives you a step by step process you can follow.  I also found a video series on YouTube by Doug Ayers, which really breaks this down over an informative video tutorial.

Data Migration Tip #2: Update System Audit Fields (Salesforce’s ‘hidden’ trick)

In Salesforce, every record has a number of system date fields which typically can’t be edited.  Fields like ‘Created Date’, ‘Created By’, ‘Last Modified Date’ and ‘Last Modified By’ are locked down (and for good reason!)

These are your standard audit fields and are very important when tracking a record’s history.  While planning a data migration, you might come to realise that you need to retain this information from the previous data source.  And that is where the permission ‘Update System Audit Fields’ comes into the story.

Imagine a sales person’s activity report, which is displays only activities created in this quarter.  As such after a data migration is complete, you still want your users to run these reports.  So what can you do?!

In the past, being able to edit these fields was part of what I called the ‘hidden Salesforce toolkit’.  You know the list of things that Salesforce can do, but they don’t really publicise? Like increasing the cheeky workflow limit here or there…  But all part of the Salesforce Support toolkit, but you had to ask for it to be enabled in your org first.  The problem was, you had to know them in the first place you could even ask, so that you could get it requested to be turned on!

Winter ’16 Release & Update System Audit Fields

In Winter ’16 Salesforce made a number of these ‘hidden’ features publicly available.  And with a few clicks you can now enable it easily for your data migration.

There are a few considerations to look at before you enable the ability to update the System Audit Fields, so check them out here.

And then head over to here, for instructions on how to setup and enable this feature in your org!

The biggest point I will highlight about accessing these fields, is that they are only available on record creation via Dataloader.  Meaning you can’t insert a record and then try to update the created date on it separately.  If you did try to edit/update these fields after a record has been created you will get an error.

Data Migration Tip #3: Automation Anchors

Automation with Salesforce is fantastic.  Admins and Developers have access to a wide array of automation tools within most Salesforce orgs, including Process Builder, Triggers, Workflows, Sharing Rules.  But when you are migrating data, they can quickly become an anchor.

What do I mean by that?  Do you know what automation will fire off based on the data work you are doing?  For example, is there a workflow that will send an email alert to another team, or even the customer directly?  Is this what you expect to happen, if so that is OK.  But you do need to make sure you know what any data you load or update into the system will do to the existing automated processes in your org.

In addition, automation in Salesforce can end up adding extra time to any data insert, update or upserts.  Remember even deletion of records can fire off a trigger!  When you are moving or manipulating a bulk volume of records, this time can easily add up.  Complex sharing rules might really slow down an insert/update of records.  And depending on the volume of data you are working with, you of may end up hitting some of Salesforce processing limits.

So before doing any data migration, test and make sure the automation you expect to work does.  Otherwise see if you can deactivate the workflow while you are doing the migration.

Share your tips

This is by no means a definitive list, and there is plenty more to come.  But in the meantime, please share your own experiences or tips in the comments section below!

Happy migrating!

Everyone loves data!  In my last post I shared with you was some thoughts on how to make sure a data migration goes smoothly.  There is a treasure trove of tools out there that can help you with any Salesforce Data Migration (more than I can put in this single post!).

In this post, I am going to share some of the most popular tools to help you out with any Salesforce Data Migration, and best of all they are all free!

Tools to help you create & edit records in bulk

Salesforce has a good data import wizard which can guide you through basic record inserts, like when you need to create a bunch of new accounts/contacts.  But what happens when you need more power?

First thing is first, the tools below will respect any object/admin permissions you have within Salesforce org.  Meaning if you don’t have access to create records on a certain object, you won’t be able to create records via one of these tools.

1) Dataloader

This is a tool developed by Salesforce themselves.  Once installed on your PC, you have a powerful tool to help you to migrate or update data in Salesforce.  The interface itself is a bit basic, but it is relatively straightforward to use and allows you to either Insert, Update, Upsert, Delete and Export records from any object in Salesforce that is available via the API.

Most of the features of Dataloader are available through a simple user interface, but if you want to unleash even more power there is also an advanced option allowing you to use a command line interface.

It is worth mentioning that Apex Dataloader only supports .CSV files.  So if you have Excel/Google Docs, make sure you save the file as a .CSV file before starting your Salesforce data migration!

Final thing to point out, this tool uses SOAP API, which means you need to be on Enterprise, Unlimited or Performance Editions of Salesforce.

To get it, once logged into Salesforce, go to Setup -> Data Management -> Data Loader.   Once there you have options to download the installation file for Windows or Mac.

To read more about Dataloader, click here.

2) Jitterbit Data Loader

This is a tool is similar to Apex Dataloader in most regards.  The basics are relatively similar – you can still Insert, Update, Upsert, Delete records though has a few extra tricks up its sleeve!

First up Jitterbit’s tool supports more versions of Salesforce, with Group Edition the minimum requirement!  Meaning many more people can use this tool versus Apex Dataloader.

Secondly, this tool supports more than just CSV files, it works with any flat file or even a database connection for the more advanced users out there.

You can also perform basic transformations with your data on the fly, and link your configuration settings to the Jitterbit Cloud.

It also has a relatively simple point and click interface with a helpful wizard to guide you through the steps.  Where to get it?  Head on over to Jitterbit’s website to register, download and install.

3) Field Trip

In my last post, I made reference to making sure you understand the data you are migrating.  Question, analyse, question and repeat!

Field Trip is a free tool available on the AppExchange, which helps you understand the data completion rates already in Salesforce.

Why is this helpful? You can view which fields actually contain data, represented as a percentage across the entire data set within an object.  This is very handy if you are looking at removing technical debt within your org, or trying to understand what fields are most used.

Imagine you are reporting on the Account table.  A field that has 100% completion rate means every single record has a value in that field.  This enables you to then analyse the fields that are most used and ignore the fields which aren’t.

Go forth and migrate!

We are only just skimming the surface here, and there are plenty of other tools you can use for a Salesforce data migration.  As an example, Salesforce also have Workbench which is an web-based version of Dataloader, with a few differences.

Everyone has their own favourites, so please feel free to share yours in the comments below!

In my next few posts, we will cover some popular tips to use when migrating data.

There comes a time in every administrator’s life, where you might have to migrate data into Salesforce.  Why is that important?  Data is the core of any CRM platform and has the power to become a blocker for your customers and/or internal users!

A request to migrate data could be as simple as someone asking you to import data into Salesforce from a spreadsheet.  Or it could be due to the retirement of another system.  Even a merger/acquisition!  But when the time comes, you will need to be able to really get under the hood to understand the data and create a data migration plan.  Because without a plan, migrating data can become a massive risk to any project.

Over the next few weeks, I am going to dive into a number of topics relating to all things data migration.  YAY! I hear you screaming! Also please feel free to share any of your experiences in the comments below, as with all things data migration there is always plenty to learn!

So let’s get started and dive into the key things to plan for when you are attempting to migrate data into Salesforce.

Everyone loves data

Data is the lifeblood of any business.  And your data in your CRM is no different.  Good data can empower any business.  While on the flip side, data can also become a blocker for your teams when not managed well.  But the good news is this shows your users have something at stake in making it better.  These are the same people who can become your data champions!

To further the point I am trying to make around identifying your stakeholders.  Your end users play a big part in advising you on what the data actually means (for them).  And it is here you will also need to identify other potential stakeholders.  Does the data have an impact on sales reporting?  How about on your company’s financial reporting?  Or is it used to help serve or fulfil your customers.

I have a question for you ma’am!

As part of any data migration, you will need to get up to speed on understanding the data.  Understand and interrogate the old data.  Analyse it.  Test out any assumptions you might have.  And also think through how you want the data to look once the migration has been completed.

This is a time you are going to need to ask a lot of questions and ensure you (and your stakeholders) fully understand the definitions being used.  If there is something that doesn’t make sense, ask questions!  Questions are your friend!  Really drill down and confirm your understanding.  Leverage the experience of your stakeholders, bring them along the journey too.  And make a note of these questions are you get answers.

One lesson I have learned over many data migrations is no-one has all the answers unfortunately.  Most times you have to really dive into the data and test what you have been told.  This is one area that is a big risk to any project and can end up causing a lot of pain no matter how well planned!

I have been on the tail end of a few really complex data migrations.  Even with the best planning and stakeholders, there has always been an inconsistency somewhere in the data which has you screaming ‘WHY!!!!’   Especially if you are dealing with an older CRM!  (but that is a story for another time!).

The point I am trying to make is it has been down to the project team to really untangle and interrogate the data to make sure it makes sense.

Prepare, verify, test

One you understand the data, you can plan to migrate the data!  There can be a lot to think about at this stage.

In your preparation, you need to map out where you want the data to go.  Are there new fields created to support the migration or are you mapping to existing fields in Salesforce?  Does the data-type match (eg does a number field map to another number field)?  Do you have any validation rules or mandatory fields that might get in the way?  If so what is your plan to mitigate that?  Do you update the data before you move it?

Some of the biggest problems I have encountered in a data migration have all stemmed from a lack of full testing in a sandbox.

If you have access to a sandbox, plan out your testing.   Even if you have Professional Edition, you have access to at least a Developer Sandbox (check here).  Part of your testing needs to include verifying the actual data.  Does to match what you had in the data source?  Do any lookups to other records link up correctly?  Are the number of records the same?  All those questions you wrote down while understanding the data, can be very useful in the testing phase.

I have thrown a lot of questions around there, but hopefully you get an idea of some of the things to think about in this stage.  Testing is another great time to re-engage with your stakeholders.  Heck, even get them to login and run a few test scenarios on the migrated data.

Once you have tested and verified your data, you can start planning the go live and move into production!  Your almost there!

Step back in time

With the actual data migration into a production / live system, you should plan in advance on how you intend to roll back any changes you make.  Even after testing in a sandbox, there could be something which causes you to halt the data migration.  And if that happens, you need to be able to restore the system to how it was before you started.

Take a backup, run reports, hold onto the import files from Dataloader.  Whatever it is, just know how you can go back without causing further issues.

This is doesn’t need to be overly complex, but it will depend on the size of the overall size of the data migration.  Sometime it can just be a simple plan to say ‘if this happens, this is how we move forward’.

Press the button & migrate data!

This is the fun part, and all your planning comes together.  This is where you start the migration and hopefully completed the migration as planned.

Once you have migrated the data into Salesforce, test and verify again.  Repeat the steps you did after you loaded the data into the sandbox.  Test and verify, test and verify!

Are you finished yet?  Good.  But did you disable any workflows/validation rule/mandatory fields?  Did you remember to turn them all back on?

And finally, and most importantly.  Have you communicated the successful data migration out to your stakeholders!? 🙂

Do you have any lessons learned?

As mentioned at the start of the post, I feel there is always soomething new to be learned everytime you migrate data.  One of the projects I am working on at the moment is pushing me to learn something new every day! (More on that in another post though).

Sharing is caring 🙂 Do you have any tips or things you like to plan for?  Share them in the comments section below!

As a Salesforce Admin/Consultant/Developer, you will often be involved in projects or initiatives.  In this post we will take a look at identifying and managing project risks.  Why?  Because in a project, risks can cause major problems and lead to roadblocks that you simply can’t get around. 

In a previous post we talked about why setting a roadmap is important.  It allows you to engage with your users and stakeholders while involving them in defining the Salesforce strategy.  (You have setup a roadmap now, haven’t you?  :-))

But once you have planned what and when things should be delivered, now we need to focus on identifying potential project risks.  How do you judge what is an acceptable project risk?  And how can you manage and then mitigate these risks?

What is a project risk?

Risk is an everyday occurrence in our world and it is subjective from person to person.  In an extreme example, some people would take any perceived risk and jump out of a plane (hopefully with a parachute), while others wouldn’t even dream of it!  The point is risk is all around us and we make decisions everyday, even if subconsciously, to say ‘I am prepared to take that risk’.

Project risks are the same, things that you or the team can see that may potentially cause issues later on.  Now I have used two key terms in that sentence.  Risks and issues… What is the difference?

In its simplest form a project risk is something that may happen during the project.  And if it does it occur, it may have an adverse effect on a project’s delivery.  That can be either what is being delivered, the timelines for delivery, or in extreme cases can block delivering anything.  Risks’s are potential/future focused.  For example, a risk to a project could be that after the project has finished, end users don’t use what was delivered to them.

An issue on the flip side is generally something that is current or happening right now.  An example of an issue would be unexpected sick leave.  This could disrupt timelines and what was planned today can’t happen.

So how do you capture project risks & issues?

Now imagine you were on ship trying to reach your arrival port, you want to arrive on time but there are a number of risks you need to consider.  What route to take?  Are there any storms/icebergs in your way?  Or would you just set sail and hope for the best?

By identifying any risks and issues, you can then come up with a plan to mitigate it.  Allowing you to avoid extra the time and costs hitting an iceberg would cause

It isn’t an exact science but the key is to take time, stop and think about it.  Think about what you are trying to achieve.  Risks are related to what you are trying to deliver.  What could derail the project?  Is it related to resources (access to certain people at a specific time in the project)?  Are you at risk of other systems / integrations causing issues?

You can keep these simply enough in an Excel/Google Sheet that the project team has access to. Everything you brainstormed,  enter down as a new line.  The key is to do it, start it early on in the project life cycle and to continue doing it throughout the project.

Once you know what the risks are, you can then take measures to address them.   This allows you to plot a course around any risks and hopefully avoid them becoming issues.  As an example, need specific involvement from a subject-matter expert at a certain phase?  Plan for it and book them in.

Get creative

When defining risks (either good or bad) you could hold a session with your key stakeholders.  Have a project kick off and discuss the objectives of the project and what does project success look like.

For something a little different, get creative.

One session I have run a few times with stakeholders is to split people into smaller groups of three or four people.  Then get people to draw out a treasure map with labels on it.  Draw the risks as circling sharks, a skull island or a ship upon the rocks.  And the treasure is the project being delivered after circumnavigating all the risks.  But the aim is to think about problems creatively, I have even seen a group draw a space ship making a journey through the galaxy…

I find it helps get people out of their comfort zone and shifts their mindset from their normal day to day work.  You can then also ask the groups what are some ideas to mitigate the risks.

After the sessions add the risks to your spreadsheet (if you haven’t got them already).  If your group came up with possible mitigations, also make note of this as you can build on it as you start your project.

How can planning a roadmap be used to support your Salesforce org?  Especially when it is used by more than just one team in your the business.  How can you ensure you deliver what is truly needed?  How do you prioritise your efforts?

What is a roadmap?

First thing first, let’s have a quick look at what a roadmap is.

So how does that relate to Salesforce?  In a world that is full of change and competing priorities, business is no different.  There will be new bugs and issues to fix.  New business priorities which may change the strategic direction, resulting in changes to the system. As a result, any roadmap will need to continously evolve as the business priorities change.

A system roadmaps is most often used in Agile delivery environment, and will help stakeholders visualise where/when any planned improvements are likely to happen.

But why is it important?

Imagine your working on a jigsaw puzzle.  You know somehow it all fits together, but you are not sure what you should focus on first.  All the pieces just seem a bit random at the start.  Then slowly but surely you start to set a strategy in place.  A plan of attack for solving the puzzle.

Maybe you start by putting all the edge pieces in place first, followed by any pieces that relate to distinct image that is part of the puzzle.   Then over time as you have more and more of the pieces in place, you start to see the image come together.  Now imagine you are working on the jigsaw puzzle with other people.  How will can you make sure you are all aligned and working towards the same goal?

To me this is essentially what a roadmap is and why it is important.  Breaking the puzzle into smaller focus areas allows you to create a strong foundation for tracking your progress as you go along.  And by setting a strategy in place, you should be able to deliver the finished result quicker than if you just tried to solve it in a random / unplanned fashion.

As an example of a roadmap, Monzo (a start-up bank here in the UK) openly publishes a Trello product roadmap for their apps, detailing the features planned running against a timeline (short term, medium term, etc).  If you want to check it out, you can view it here.

How do you create a roadmap?

Where do you start?  Planning your roadmap is an overall, continous process.  But by taking the time to define and maintain it, you continually evolve what the future vision looks like and become more proactive about where Salesforce will grow/develop – which in turn should minimise those ‘why didn’t I know about it’ moments.

There are a number of steps you can go through, and by all means this isn’t a definitive list.  Also keep in mind that project methodolodies (eg Agile) may also play a part in the ‘how’ and ‘what’ you need to define.

Identify stakeholders & research

If you are starting from scratch, identify your key end-users & stakeholders (Sales, Finance, Marketing, IT, etc)?  By knowing who to go to, you can then research what is important to your business.  Ask what are their key priorities for the year ahead.  What improvements would they love to see made to Salesforce?  If you don’t have a relationship with your stakeholders, this will helps to open the door.  And will also come in handy later on.

Innovation & ideas

You might also have your own improvements or changes you want to make to Salesforce.  After the last post, you might have identified potential technical debt within your Salesforce which needs to be addressed.

Also what about new features and innovations you want roll out.  Things like a move to Lightning UI?  All of this will need to be added into the mix too, as remember we need to balance out all of the priorities as we won’t be able to do it all at the same time. 🙂

By combining the earlier research with your own ideas, you now have a list of different and competing business priorities.  But how do you sort through the list?

Setting the business priorities

Firstly some priorities which get raised will simply be so critical to the business that the priority and timeline will almost be set for you.  For everything else, here is where you can get creative.

One idea is to get your key stakeholders together in a room.  In this session encourage people to be open and transparent, while keeping everyone focussed on what is best for the business  and not individual departments/teams.  Going around the table, everyone who raised a priority gives an elevator pitch to the group covering where they see the value of the request.  As each pitch is given, a card or post-it goes up on the wall.

After the pitches are finished, give out three sticky dots to everyone (or you can simply use pens).  Next tell them to place two dots next to the idea they would prioritise first and one dot on their second priority.  The aim is to get some overall coordination on what to focus on first, where the priority is driven by the highest amount of dots – where you sort the cards by descending order.  Close out the meeting by going around the table again and confirm if people agree with the outcome.

By involving your stakeholders in setting your roadmap, you allow them to buy in to the future vision of the platform.

Unfortunately there can be circumstances where stakeholders can’t come to a conclusion.  This is when you would become a little more direct.  The group should at least try and seperate out the list into what is needed versus what’s a nice to have.  If this still doesn’t work, you may need to get an appropriate Sponser (possibly a senior leader within the business) involved.

Visualise the roadmap

Roadmaps come in all shapes, sizes and formats.  It is important to realise that they are generally high-level in nature.  Covering the themes and objectives you plan on delivering. Save the detail of what needs delivery for a project plan and the team involved in delivery.

Personally, I have I tend to only set a roadmap for the next 6-12 months.  And then bundle everything else together under a header of ‘future items’, but you can be as creative as you want.  As mentioned earlier, these plans are subject to change.  Aim is to make it easy enough to adjust moving forward.

When it comes to estimating the time and effort, there will be an element of making an educated guess on some of the work involved.  Ask around the Salesforce community and see what others estimate.  If there is a vendor/partner involved, they can also give you an idea of the effort involved.

Another very simple example of a roadmap would be to group items by a theme down one column, and have your timescale running along the top.  Then your individual deliverables/projects become the cells in between.  Here is another example of what you could do simply in a spreadsheet:

Communication

Now we are near the finishing line of this whole process.

After putting all of this together, play back the outcomes with key stakeholders to get a final sign-off.  Doing this allows any further alterations to be made.  It also ensures that everyone has bought in to the process and vision, meaning you can then focus on delivery.

And remember to revist the roadmap roughly every six months.

Wrap up

I will reiterate that this is just one way to come up with a roadmap.  The process can vary depending on the size of your business, what the priorities are and even lines of accountability within your company.

For an additional resource there is a great Trailhead module (Innovation Solutions), which covers the topics of roadmaps and implementation planning.

I would love to hear from you and your experiences when setting a roadmap.  Please feel free to add in the comments below any steps you take in creating a roadmap.

How many projects teams have you been a part of?

Now let’s count up how many of those were projects were a successes?  Is your tally 100%? (If it is, congrats!)

The more projects you play a part in, the more likely it is that you would have been part of a project that might not have been a success.  It might have missed its planned dates or not delivered on one of its core objectives.  Or even worse, it might not of set objectives to start with!

Regardless of which project methodology (Agile, Waterfall, Prince2, etc) you subscribe to – is the magic formula that drives success?

The ‘magic’ formula

I am going to share the secret formula with you – but you have to promise to use it wisely!

S = cm ( cl + de)

Ok, ok – so I might be joking around a bit there, but let me put it another way.  Success = communication, clarity & definition.

Success = communication, clarity & definition

Communication:

Before you take another step this is where you should make sure the basics are in place and for me that revolves around ‘communication‘.  I will definitely agree that it is important throughout a project’s life-cycle, but the start of a project is when it’s the most critical, yet this is when its most overlooked!

Have you defined who you need to communicate with?  There will be key stakeholders, subject matter experts (SMEs) and end-users.  Depending on the project, they might be the same people.  How are you going to make sure people are involved at the right time?

What frequency will the project team communicate to the various groups of stakeholders, SMEs?  Set expectations early on and adjust accordingly.

The key is to ensure the project team and the business are ultimately aware of what they need to be, and when they need to be to make any relevant decisions.

Clarity & definition:

This is the fun part for a lot of projects! And more often than not it’s because the project team is a group of people who have never worked together before.  Which can add additional challenges and potential set-backs on top of trying to deliver the project.

As a team develops it goes through various stages of development (see here for the theory).  Generally the most painful part is the ‘storming’ stage, as this is where people in the group may start to step on the toes of others within the team.

This is where clarity and definition play such a pivotal part within the project.  By providing as much clarity and definition, the aim here is to fast track the project team through the forming and storming stages of development as soon as possible.

What are some key ways of doing this?  The type of things I would consider going into a project would include:

What are the objectives and goals of the project?  How do you know when the project is finished?  Believe me some projects aren’t so clear cut as to when the finish line has been crossed!

Can you define what success looks like at the end of the project?  It is great getting to the finish line, but how will you and the team know what success looks like?

Does everyone in the project team know what role they will play within the project?  Having clear roles/responsibilities can help reduce future issues and help the team come together faster.

Is everyone talking the same ‘language’?  I don’t just mean English/Spanish/Mandarin… But what about common jargon/terminology used within the business?  This tends to be a big area where a lot of assumptions are made, and then cause major issues when delivering of the project.  You might be all talking about a football, but what kind of football – soccer, rugby union, rugby league…  Don’t make assumptions!

Key deliverables versus wish list items  – defining this early on will help with stakeholder management and to prevent project ‘scope creep’.

Get the team involved…

You might not be able to answer all of these by yourself, so what better way to get the team involved early on?

Share your experiences.

There are a lot of moving pieces when it comes to project management.  But the most successful projects I have been involved in have really focussed on getting the small things right early on and building on that foundation.

So for me, the magic formula is the basics done well…  Success = communication, clarity & definition 🙂

Do you have any project success stories to share?  Or maybe some less successful ones, where you have some lessons you learned from?