5 Universal lessons from a small implementation project.

As an independent consultant , I have noticed a strong preference by recruiters to ask about my experience in large projects. I have happily highlighted those large clients and complex situations. Usually there are multiple countries involved, large user populations, big implementation teams and even bigger budgets. The stakes and pressure are high. Therefore, quite understandably, prospective employers want to know how you handled yourself.

But, no one has ever asked about the smaller niche projects where you do most of the work solo.
I think this is a mistake. Sometimes the smaller projects give people a far better chance to see how a person really works. If you are selecting a contractor, this is ultimately what you want to know. What is their work style, their approach? More importantly, how will they work with us and what impact will have.

The most recent project go-live I lead went live recently. Here is what I learned from it.

#1 Sometimes the project brings very little direct immediate tangible benefit.

We always want to show the benefit of the change we are bringing to people. For example, this will help you to management recruitment easier. Or this will mean you have to do less HR admin. But in my recent case, it involved rolling out improved security features for a user population who saw very little direct benefit of it. In fact, they viewed the change as adding some extra complexity to their daily lives. So, it did not really add any efficiency improvement or make their lives easier. In fact, a bit of the opposite. But since they are using a cloud vendor, and the vendor needs to ensure they meet EU Data security requirements, all their customers had to adopt the feature. The benefit was for the organization, but the end user did not see it as a tangible win. This can be a challenge, but what worked in this case is that we were upfront about it. We explained it’s a necessary requirement, while they won’t see the benefits day to day, they did exist. We were able to explain the reason and defend the decision, even if there was push back. We were also able to strongly show the consequence of not changing. This helped us to get the users onboard, despite the initial scepticism.

#2 Being onsite to help users with the change brings quicker results. 

Long Long ago, onsite implementation teams were seen as the norm. I still have memories of Germany in the late 90s and can remember the chain-smoking implementers, alternating between huddling around terminals in the EDV room or the training rooms.
Most implementation is done remotely now, and with much smaller teams. But there is still a benefit to being on site. In this project I was onsite between 2 and 3 days a week. This was a big benefit because it allowed me to meet the front-line teams first hand. I could explain what we were doing, walk them through what the change would bring, but most importantly understand the valid concerns immediately. I learned much quicker why the same concerns were being raised, and how we could improve the messaging to increase user adoption before the go live. As in any project its impossible to think of all scenarios no matter how good your workshops are. Being there on site allowed me to catch things that would have been missed otherwise.

#3 Strong Leadership sometimes leads to more complexity.

At a key point in the project a decision was needed on whether to significantly change one the organisations core policies. This had been brought in by the current senior leadership for very good reasons. But this reasoning was put under pressure from the technical demands of the project. A choice needed to be made by leadership on whether they would change their business policy, so they could make something technically easier, or whether they maintain their business policy at the risk of a more complicated technical process. As the main IT lead, I saw my role to provide solid advice on the pros and cons of both options, advise leadership on the impact of both. But ultimately, it was their decision to make. The leadership decided to stick firm to their policy and settle for a slightly more complicated technical approach. While I did have my doubts, in the end it was the right decision for them. While it required additional testing and adopting the standard process, it was at least a supported option and could be justified. In the end, it showed me a leadership that knows their business well will need to be given the trust to do what is right for them and not be pressured into always taking the easy approach of what the industry standard is. This was a particularly interesting lesson for me to learn after years of parroting slogans on standardization.

#4 Go lives are not the ultimate measure of success.

 In my past role the project teams fixated on go live dates as a major measure of success. I can still remember a very senior executive asking why a significant number of customers could not just move their go lives to an earlier quarter so that we could meet our internal KPIs. This is unfortunately how KPI and success metrics are viewed in large multi-nationals. Even though this was a very small project, with a small defined scope we still managed to miss our go live by a month. In my old job this would have been seen as a failure of the project team and project manager. But , it was needed to ensure the actual success of the project. Management often get hung up on dates that no one will remember.

#5 Everything is better with Music

Since it was a small project, I was essentially a team of one. This can be lonely work. While I’ve always liked music at work it was not always appropriate with so many daily calls. But during this project I was able to put on the headphones and work better listening to the tunes of my favourite DJ - Issac Varzim. Check him out here.