Tuesday 28 April 2009

Encourage collaboration and delegation by creating a plan

I don't know about any one else but I often find that the best way to get a consensus in a group of people is often to start with a plan, no matter how basic and essentially disagreeable to everyone its content are and begin redrafting it from there on.

Seriously. Along the lines of 'fail to plan plan to fail' I always like to start with something recorded that everyone involved can access, understand and contribute to. It doesn't necessarily matter who creates the plan, the point is that you have something as a starting point. 

I do this before I've started any work and often it comes out of an initial brain storming session. Get as many people involved in the project together as possible, brainstorm all aspects from early requirements gathering and development to testing and release phases. 

The most important thing to do is to get used to reviewing the plan regularly and encouraging others to do so. Much like a car journey. Your route may be right until a traffic jam occurs, then your route may have to change. You have to check the traffic reports and your map to see if changes are needed. Sometimes they are sometimes they aren't. But regular checks are important. Otherwise you could spend weeks undoing and redoing what you could have done right in the first place. 

This also means as many people that are involved should be in a position to contribute. Maybe they can't change the file but they should be able to see it and understand it. They should also know who to go to to discuss changes and the route to go through to present changes and get them approved. This also implies that everyone should know which is the current plan, which are archived versions and which are those in development that aren't yet approved. 

Sounds like a lot of work already. You quickly get used to it and find that in truth it isn't. Much better to maintain a plan well and know where your efforts are headed than be lazy and find out that you were doing work that nobody wanted. It doesn't matter how good that work is. It's stilla  failure. 

The advantage of having a plan is that you now have something everyone can discuss and it's the discussion that it generates that's really useful. My first plans always need changing. That's normal. As I get more used to the process I get better at creating plans everyone is happy with from the outset but never forget how important a plan is to a project. The more people involved the more delegeation is required. Everyone person putting in effort needs to know who they're affecting and who to work with to ensure it's all coordinated. With out a decent plan this cannot happen well. 

What if your customer changes backend application that manages its sales. This system produces reports in formats you weren't planning for. You were planning for the old version. The new system is going live in three months. Surely some one should have made you aware so that you can begin planning how to connect to this new system and deal with its reports etc. 

With a plan that's open to stakeholders delegation becomes much easier. In this case, if you havd a plan you would have recorded the sales application you were integrating to. Everyone can then see this, with this information in place it becomes more obvious and so the problem is more likely to be spotted and reported. It's also clearer who to report to. The person maintaining the plan at a minimum. It's also obvious how to inform everyone of the changes. Update the plan, distribute it to everyone involved highlighting the changes. 

Every project I've been involved in has gone through phases of major change and very little. At each point it was really important to know what the plan was at the time. To constantly step back and check everything is well coordinated and nothing is getting left behind. 

Very quickly I found that while I worked hard throughout a project I had no more work on at the start than at the end. I generally found that those without a plan felt they had plenty of time at the start and worked like crazy to meet the deadline at the end. The main difference being, every time I veered off course I pulled myself back on course very quickly so when I delivered it always worked as the customer now expected it to work. No matter what was initially expected we'd come to a solution that match the timscales, resources and requirements. 

Those without a plan invariably had some or all of their work that was quite different from what the customer wanted or needed. Sometimes it just was no use to them. Thus a lot of rework had to be done. 

So in the end the process of planning. Of writing and maintaining a plan has always saved me far more time and my employer far more money than the cost or time involved with fixing the mistakes a plan can prevent. 

No comments: