Many moons ago, I worked for a firm where I had been building my power base steadily and after badgering from the sales team leaders, decided it was time to take on a big project, possibly outside my traditional remit. The project was a Customer Relationship Management system which would bring me from my back office IT into scary places like "Business Process Management".
The project went well, and a lot of this can be attributed to the preparation work I'd done. Although I will go into it in greater depth later, in "Building a Power Base" I skimmed over the importance of understanding your organisation. Because I'd taken the time to understand the team, their challenges, their mindsets and most importantly their fears, I was in a good position to handle these in advance.
I wrote a basic proposal, presented it to the board, wrote a full blown project plan and met with the heads of the teams affected individually and discussed it, then implemented. Once the project was in, I publicly held a small early adoption group, took their feedback on board and reimplemented. I then devised a training plan aimed specifically at the needs of the teams and delivered it tailored to their strong points. Following this, a periodic review was held and this helped keep the project on track even once implemented.
There are a number of tools that can help the novice project leader to try and anticipate how the project will pan out and to look and be more effective throughout. A great change management tool that really helps with the whole process is the change cycle (below), which allows you to keep a rough track of what stage the project is at and also what kind of reactions you can expect. This model can be applied to the project as a whole, or individuals and is a good way to prepare other people involved with the project for the likely nature of the adoption before the project starts. It also helps motivate yourself through the difficult phases by reminding you that the project will come out the other side.
Also, the "diffusion of innovation" model (below) applies to most projects and is helpful to look at the overall project to figure out roughly how far through the cycle the whole of the organisation is as a whole. This also helps to tailor a targeting strategy for the remaining people who haven't adopted yet
---------------------------------------------------------------------
Learn from my mistakes
Even though the planning was extensive, the approach was well thought out and the system excellent, the project wasn't a total success. I was working with people far more 'organisationally powerful' (in a higher role) than me, didn't have enough power to pull it off on my own and attempts to engage my boss and other allies couldn't pull the whole company through the process. In a small part, I can lay a little blame at my boss's door for not pulling more weight. However, when it became apparent that the head of sales wasn't going to do their part, I should have acted sooner. If I'd have taken opportunities to bring this up constructively either directly with them, with their manager (the MD) or perhaps more strongly with my boss, I could have saved myself many sleepless nights and made the project run far smoother. Lesson #1: problems usually don't just 'go away'. If you think there is a problem, there probably is and you need to deal with it NOW before it gets out of hand.
However, in retrospect I didn't have true buy-in at any point from the four team leaders or the head of sales and if I'd realised this sooner, I could have made a greater success of the project. Lesson #2: if you go around trusting everybody, you will be frequently disappointed. On the surface, they were all supportive and spoke well about how they were on board both privately and in public. However, it had escaped my attention that they hadn't actually done anything. Deadlines had rolled past without input and I was constantly chasing them. Lesson #3: listen to what they say but watch carefully what they do. This was because they didn't want to be seen as the bad guys by forcing the teams to do these administrative tasks, which took time away from their other activities. Lesson #4: ask for a small task first to see if they’re actually interested in taking part. If they don't complete it, they're wasting your time and theirs.
I should have confronted them. Not with a shouting match, but just by saying I had a feeling they had some issues with what I was doing and I needed to understand what and why. In actuallity, the teams weren't driven to use the system, the blame for the extra admin work came to me and the system took a lot longer to get going. Not productive.
No comments:
Post a Comment