A quick disclaimer before I begin. This article, as with all in this series, are based upon personal experiences and from experiences of others I have spoken to. What I write here is my opinion and my personal recommendations, none of it is reflective of the views of my employer.
I should also make clear that any people I write about here are not real but are fictitious composites made up of conversations that we’ve all had.
Can I scream for a moment please folks?
Only the other day we finally got the go-ahead to get on with our migration from CRM 2011 to Dynamics 365, now I sit here just wondering what kind of beast I’ve unleashed.
All I wanted to do was replace the fossilised dinosaur and deliver some nice new shiny stuff along the way, but somebody just had to go and ask the worst possible question you can ask a user – “What do you want?”
Seriously, that is up there with saying things like “What’s the worst than can happen”, “Watch This!” or even uttering the words “it’s been quiet all week” before going home for the weekend when you are handling the off duty emergency user help line (you know, for when the users absolutely HAVE to have a particular font installing on the PC next to the one they are using because they are worried about the one they are using crashing on them and then they wouldn’t be able to complete the poster advertising Jimmy’s birthday party)
The last time someone asked “What do you want?” we ended up requiring adjudicators, referees, and emotional counselling for half of the people involved because NOBODY could agree on what they actually wanted. Poor old Ernie from the Money (mis)Management team still gets nightmares over the kind of numbers that were thrown around during that “exercise”
In the latest scheme from The Powers That Be (TPTB) we have to have a Project Specification Talk, which is only called that because somebody decided that this phase should be called ProSpecT and they just threw some words around until they made it fit. I once tried to keep a note of the terminology I should be using but it got to the point that the document revision history was longer than the document itself and our management speak had come back full circle to the language required in version 1 of the document.
Anyway, I digress somewhat…
The ProSpecT session involved sitting around with all the “High Level Prime Drivers” and “constructively communicating by verbally expressing” the “Optimal Requirements In Final Integrated Computing Environment” – OK, that last buzzphrase might just be one I came up with in my head but there was so much management speak that I think I may have lost my grip on reality after the first ten minutes.
Del-Boy Daley (The PM) and Philomena Parker-Packer, the Head of Potential Procurement and Product Placement, seemed to take a great deal of almost perverse pleasure in debating the miniscule minutiae whilst ignoring some of the big issues facing the project – small details such as “can it do it”, “should it do it”, and “will they do it when they get it” that sort of thing. I swear that at one point someone actually wanted to know if the cloud that we were going to be using would be Cirrus or Cumulonimbus and if it would be affected by the wind. I actually wanted to get up and spend time explaining a mobile phone to Auntie Ethel as that would have been an easier task (last time I saw her I had to explain that Android phones didn’t have little robots in them and Apple products were not organic)
By the end of the 4-hour marathon, which was preceded by the 2-hour pre-meeting preparation and was followed by the 3-hour post-meeting post-mortem, it was quite apparent that this simple upgrade project (which you may recall from my first diary entry is anything but simple) is to become a complete redevelopment and re-engineering project… and all within the same budget and time window.
The most frightening thing about this is that the document produced from the ProSpecT meeting that will land on my desk in about 3 weeks’ time (by which point I will have started work of course) will either be a 1-page paragraph or it will be a tome to rival War and Peace, both styles tending to have no more substance to them than a Unicorns expression of wind and both having the potential to completely move the goalposts.
Of course neither of them will bear any resemblance to the discussions that I had been paying full attention to. Honestly, I was paying REALLY close attention. I did not make it to level 635 of Sweetie Store Smash whilst pretending to furiously write copious notes on my phone. Maybe I can say that my copy of the ProSpecT document got eaten by Lord Snufflewump IV… hmmm.
But before all of that I need to face the next step of the project… the dynamic duo of Belinda and Andy, the Blue-Sky Conceptual Capability Co-ordinators.
Before I get into the meat of the post here, I need to ask for your forbearance if you are looking for a series of technical information. As anyone involved in projects will know, before the fun begins (if you are a techie/dev like me) you need to go through the initial project phases. I’m not a Project Manager, or a Business Analyst, so these elements of the diary are written through the lens of a developer. Hopefully you’ll be able to relate to this still, and maybe, just maybe, it may shed a different light on the process.
The scoping phase of any migration project is always an interesting exercise. When you are making such a big jump as that from CRM 2011 to Dynamics 365 it becomes even more challenging as the feature-set that is available to you is far more than the legacy platform.
I suspect that there will be some readers pointing out that the Scoping phase should be done BEFORE a budget is requested and, hopefully, approved. You’d be right of course. However, in this case the key thing was that this was a simple upgrade/migration from 2011 to Dynamics 365 – which removed the need for any major specification work. Feel free to alternate chapters 1 and 2 to your hearts content because the chances are that we’ve all done projects in both ways, and in any number of different variations!
Anyway, back to the Scoping phase.
It’s at this point you need to try and define WHAT the project is:
- A simple “technical upgrade”– just a re-platform and nothing more?
- A like-for-like refresh – when the existing functionality is replicated using the new capabilities, but no more than that?
- A full-on re-engineer and rebuild – taking a deep look at the requirements, what the system can deliver, and agreeing on new functionality along with the any current capabilities?
As previously stated, you will probably have very different project cycles and methodologies, I have yet to come across two companies that operate the same way, but being able to define the WHAT is a vital cornerstone – no matter what your role is.
Quite often the overall Project Scope document is a generalised outline, but as a Dynamics 365 consultant/professional/developer it sets the direction of travel for the project and it’s definitely a process that I recommend being involved in, even if it is just to sit in the back corner of the room and chipping in with the odd comment here and there.
Ensuring that the key requirements of the project are clearly understood by all parties will save time, stress, money, and your own personal well being – and trust me, if you are working on this you will definitely need to look after your own well being!
When doing an uplift from CRM 2011 to Dynamics 365 I found that some of the key areas to consider within the scoping document include:
- What Data is being migrated? – Everything, just some entities, just some fields from entities?
- Have Business Processes changed, and will this impact on the migration?
- Are there external systems and integrations?
- What are the success criteria for the project? This is a biggie – genuinely, if you want to get a proper sign off at the end of things then the closing criteria must be set early on.
- What are the expectations in terms of timescales? (and yes, you’ll hear “as soon as possible” or even “tomorrow?”)
Now it’s not the time to detail every last thing, but an understanding of these things is essential so that the overall size of the work can be estimated with a good degree of confidence.
Next up – the Business Analysis and Architecture phases…