It may seem obvious, but I’m often asked when embarking on a new project ‘Can’t you do it Lean?’.
This is normally not what is meant at all – the real question is ‘Can you do it more cheaply?’. Lean is a huge and sophisticated concept and it is well beyond my knowledge to understand all of the things that are in the Lean Toolbox but I do understand that Lean is especially about eliminating waste from a process; not including anything that the customer would not want, unless is must be there. It is also about consolidating processes so that things that must be there that are probably waste are moved downstream until after the customer has received the output of the process.
When it comes to any kind of organisational change, especially that underpinned with technology changes, you have to be very careful in taking a view of what is “wasteful” in a project task list. In my experience it is, perversely, the very things that are considered optional or nice to have that separate very successful projects that deliver real organisational value from those that are just okay but never really achieve the objectives they set out to.
I’d love to have the time to write a book on this (although I’m not sure how many copies I’d sell) but here are the top four items that come up again and again, along with some views and arguments.
1. Project Communication
This can be as simple as posters on the walls, a few project newsletters or formal periodic employee presentations and updates – but why is this needed? Everyone will find out once it goes live, right?
Well, that’s true, but they won’t be prepared, they won’t think it is an organisational priority and they won’t have the opportunity to say ‘have you remembered that we do this special thing over here?’. My point is that there’s a myriad of reasons to do this, both from the people receiving the communications as well as those giving them. Communicating holds the project team to account, it makes sure the whole business is aware of progress, objectives and timelines and, to a lesser extent, scope. This makes sure the team and the Steering Committee or Stakeholders are held in a spotlight where they remain focused on success from start to finish. But, more than anything else, it answers two vital questions (or at least should) for all those involved:
- Why are we doing this and what does the business expect to achieve?
- What’s in it for me and why should I do this?
Once you’ve answered these questions, getting on board with the change seems less optional.
Should we have training specialists, train the trainer, do on the job training or no training at all?
For me, this is one thing will have the biggest impact on overall project success because, whilst it probably won’t make much difference to going live on time and to budget, it’ll have the single biggest impact on whether or not you actually get value and benefit from the change you have made. I’m not just talking about classroom training here either; I’m taking about proper training needs based analysis, training material preparation, delivery and testing of competency. With projects like ERP especially, the ability of the users to not only understand how to perform their role but also how it has changed and how it fits in with others in the business will make the difference between a cost effective project that delivers real improvement and one that never really seems to make the difference everyone expected. A special note about train the trainer – this does of course depend on the trainer. Would you rather have a great teacher who knows how to teach and impart knowledge or someone who knows how to bake a cake but has no idea how to explain it? Be careful of using this to save cost; in some cases it makes sense, in many it is just a cost reduction exercise which ensures the users are poorly trained and prepared.
Should we pay the team members extra to work on the project?
Projects are transient, difficult, frustrating and often thankless (sometimes you might even find there’s no role left for you once you’re done) but they can also be incredibly rewarding, strangely exhilarating and highly educational. The trouble is that, from a team member point of view, you can see all the downsides up front but none of the upsides – why accept the poisoned chalice? Having a financial incentive to make the leap into a project not only means that you’re more likely to get people who are rising stars, highly motivated and willing to learn; it’s also very helpful if you need to ask them to work long hours or over the weekend to achieve a milestone or deal with a problem. It also brings a great sense of teamwork to a project and demonstrates that the business is willing to invest in them (providing they’re successful – both a carrot and a stick).
4. Team Building
Curries and going to the races.
It’s hard work on a project – no-one has ever done the change before, it’s usually in some new technology, you’ve left your previous role or are doing this on top of your day job, you’re being pulled in more than one direction and so far no one has said thankyou. The team is your support group – they’re going through the same thing and you rely on them not only for the practical day to day stuff of making progress and delivering results; they’re also taking the same journey and you all have a shared destination. Team building is not just about having a shared experience or event, it’s about building close bonds and starting to learn about each other’s likes, dislikes strengths and weaknesses. I’ve worked on projects that have had births, marriages and, sadly, deaths and the strength of team made a big difference.
So when you think about whether you have waste in your project tasks or where to look to reduce the budget, try to reflect on why these things are there; even if you don’t believe it. We’ve all worked on enough projects to know that a “cookbook” approach is built on years of good and bad experience so it’s probably likely that if you remove some of the key ingredients, your cake won’t turn out as you’d hoped.