I am travelling at the moment, currently at Tel Aviv airport. A couple of days ago I went to Jerusalem and my time there reminded me of a day I had last year, both providing me with very clear examples of good and poor use of time.
Last year I visited the National Gallery in Prague. I had heard it was pretty good and held a lot of art that I was interested in seeing. So I went through the logistical exercise of getting there after a late start and entered with a vague idea of what I wanted to see and how long I had until it closed. What I did not bother with was any sort of priority list to work through. So I started at the bottom in the modern art area. After a few hours of trying to figure out what the exhibits were about I finally made it to the areas that held the art I was actually there to see. By this time I was getting tired of looking and being constantly on my feet. I was also getting hungry and the café was a relic from the Soviet era and smelled of boiled cabbage. I ended up rushing through the exhibits I was there to see and even missed a few.
By comparison, when I went to Jerusalem I left very early in the day. I did not get distracted by the souvenir shops and headed to the areas I was there to see. I also had time to wander a bit and grab a Turkish coffee in the Arab Quarter. I got back to where I was staying just after lunch and avoided the hot time of the day. All said, it was a day that took a few minutes to plan and a bit of follow-through with the execution (avoiding shops and getting an early start). In half a day I achieved more in Jerusalem than a full day in Prague.
So how do these travel stories translate to Dynamics CRM projects?
Getting an early start. Often the logistics around a Dynamics CRM project are left to the last minute. Having the environment ready for the development team to get started on day one is the early start – without it your project will be on the back foot before you have even reached the starting line. In iterative projects this is ‘Iteration Zero.’ The good news is that we know the people who can check that this is completed already: the people who will be doing the work.
Which sights to see? Identifying and prioritising business needs. This is not an easy job, especially as the business needs are not always clear. As an analyst you have to dig deep to uncover the true business needs and translate these across to the development team. Too often you are presented with a solution from the business as opposed to a business need. It can be an uphill battle, but a necessary one to deliver the elusive Highest Business Value for the cost of the project. The blame does not lie just with the business. The project team can mistakenly ‘see’ a business need and throw it into the mix, only to find out that the business not only does not require it but that it also causes issues. The moral of the story? Be aware of the distractions (souvenir shops) and focus on the business need.
Roadblocks, hottest part of the day or tiredness – these will invariably come up. People will get sick, servers will crash and bugs will be discovered. Deal with them, work around them, ask for more resources, just do not play the ’blame game’ or fail to act. Escalate issues early, especially if it is your mistake.
My battery is running low, and my plane is about to board. I think I have just enough shekels left for an ‘I Love Jerusalem’ T-shirt.