Showing posts with label management. Show all posts
Showing posts with label management. Show all posts

Saturday, 19 February 2011

Intellectual Capital – Use it or lose it


What makes an organisation valuable? In the world of consultancy it's the people it employs. Very little distinguishes one organisation from another. They all have access to the same systems, processes and resources. What enables one organisation to outbid the other is the people behind a bid. What makes one project succeed where another fails is the people.

Ok, that's pretty obvious. But what makes the big companies so powerful is the way they harness that. At IBM I have access to a huge back-catalogue of experience on Complex Systems Integration projects. That gives me a massive starting advantage when I come to work on a project.

Younger and smaller companies aren't always so good at this. The charity I'm working with at the moment has absolutely no processes to harness this at all. They have more pressing issues to resolve first, but further down the line it's something they can look to address.

What surprises me more is the lack of some system for storing the knowledge of all the volunteers in the country. There are hundreds of thousands of man-hours that is going missing here.

Let me put this into context. I'm here as an IT consultant. That's my primary role, but I'm already getting into general project management consultancy, that's fine as my role in IBM had progressed down that route. I'm pretty comfortable with the work I'm being asked to do there.

But I'm also being asked to think about putting a HR manual together. And help with writing funding requests. Now I'm out of my comfort zone. I have zero experience here. Now, I'm not completely incompetent, so I reckon I could come up with something that's not completely terrible here. It might even be better than something Srijan would have come up with on their own, but there's no guarantee.

However, I know for a fact that at the moment in India there are people with a huge range of experience in these matters. HR Consultants, people with a background in NGOs and raising funding. BUT I CAN'T FIND THEM. There is no official system for me to make contact with my fellow volunteers and get their advice. There's nowhere for me to upload my new IT strategy document, get people's thoughts on it, or download a sample HR document myself.

Every single volunteer out here is re-inventing the wheel on every single project. And that's a sad state of affairs. Luckily, the volunteers recognise this themselves. There was a Google Group set-up, which unfortunately Google is now phasing out, so I've created a Google Sites repository. It will have a document store, discussion board, contact list and useful links list. The sad thing is that this isn't provided for us. It's also country specific – I have no idea if the volunteers in the other countries have something they can use.

What does your company do about storing and, more importantly, making accessible it's intellectual capital? Can you easily get to the thoughts and deliverables of your companies top people? If not, you're probably letting a huge asset slip through your fingers and you aren't even aware of it....

-------------------------------------------------------

I've just had probably the most depressing experience of my time in India. It's really upset me and I just need to get my thoughts out there. I'm cross-posting this as it applies to both my VSO work and my professional life.

The social development sector is growing. There is a definite move to a “more professional” way of working, with knowledge and skills from the private sector coming over the fence all the time. I'm a pretty obvious example of that. I'm trying to instil better project management and MIS processes into a tiny Indian NGO!

I think most of the time this can be seen as a good thing. Better rigour and transparency in these organisations should lead to benefits further down the line. Unfortunately not everything from the corporate sector is necessarily worth bringing across, and sometimes it is absolutely the wrong thing to do.

I met a man today, he works for another NGO. They appear to be very professional and passionate about the work they do (I won't be naming them, obviously). He wanted to talk to me about my background, then suddenly he asks me about Intellectual Capital. Now, first of all, my views on this are not mainstream. I recognise this. But one of the things he said I just flat out had to disagree with....he said “we have to protect our IC (intellectual capital).”

Sit back and think about this for a moment. This is a organisation who's vision statement (according to his business card) stands for “hope, tolerance and social justice” and over-coming poverty. He's talking about using intellectual property to prevent other organisations from using his ideas. Other organisations, i.e. competitors = other Not-For-Profit organisations. Other aid agencies. Other NGOs.

Now maybe I'm being a bit idealistic here, but I want my NGO to work with others. If they have a good idea, I want them to share it with as many people as possible. Not to do an Apple or a Sony and try to build a closed eco-system where no-one else has access to the market. First of all, I hate the idea of using IC to protect a business model in the first place. MySpace vs. Facebook shows you all you need to know about idea vs. implementation. But surely that principle goes completely out of the window in the development sector?

If I (as an NGO) come up with a great way of improving people's lives in India, surely I want as many organisations to know and to copy it all over India as possible? I don't want to patent the idea and force everyone to pay me for the idea or not use it at all! Surely that defeats the entire point of a development agency – we're working for the people we're trying to save, not the profits of shareholders!

I'm going to have to go to lunch with this man in 10 minutes. I just hope that I can get through the meal without offending him – he's from the funding agency of one of our projects! Hopefully he doesn't say anything ridiculous again – otherwise I'm in trouble!

Monday, 8 March 2010

Planning to make a plan

One of the things I see continuously in this job is plans. Microsoft Project plans. Some are good. The majority of them are very bad. The ones that are good have a good structure, milestones, dependencies and have obviously had a lot of thought put into them. That makes them particularly uninteresting for the purpose of this blog!


My aim for this post is to talk about the poor plans, and specifically one aspect on them - lack of conceptual plans.


Let us take a step back for a moment. Imagine a world for a project manager that is essentially perfect. You have complete control of the resources working for you. You can accurately quantify all of the work that is to be performed, you can build in an adequate contingency level and don't have to worry about costs. Sounds perfect right? Wrong. You've missed something - your dependencies. Every project has them, regardless of how self contained it may seem. It might be talking to the business, it may be getting sign-off from the customer that what you have delivered fits the requirements, but eventually you will have to go outside your project team, and that's when things go screwy.


You see, the biggest mistake most project managers make (and I do mean biggest) is to jump straight into dumping a plan into MS Project. Wrong! You can't do it like that. Or if you do, you need to be very lucky!


The first, and absolutely most important aspect of writing a project plan is to create a conceptual plan first. This needs to show the following:

  • The major deliverable artefacts of the project
  • The workstream responsible for the delivery of that artefact
  • Dependencies for that artefact
The simplest way to do this is with a simple flow diagram. One box per artefact, lines to show dependencies, colours to signify workstreams. Once you've produced this, give it to your workstreams to review, you'll be amazed at how much discussion comes out of something so simple; how many dependencies you hadn't considered; how many artefacts you missed originally.

Now imagine you hadn't performed this task. Each workstream has gone off and produced a project plan to no agreed overall plan. Plan A has included a dependency on Plan B that Plan B isn't even aware of. Project Manager C thinks Project Manager D is responsible for Artefact Z and things are falling through the gaps all over the place.

So when you next kick off a project, or are asked to create a project plan, ask yourself "where's the conceptual plan" - it might just save you a whole load of trouble!