Shaking up companies interpretation of ERP systems

I have been chosen to be this week IT-profile on Danish IT-news website Version2. You can read the article here.

It’s in Danish, but the gist of the article is that I think most ERP systems implementations is driven to much by what the system can do, instead of what the company needs, and what will create value for the company in which ERP system is being implemented.

I argue that to realize the full benefit of ERP systems, you have to start with looking at the company’s strategy and goals, and then structure an ERP solution that helps the company reach those goals. Too often I have seen the opposite happen, and ERP being implemented based on the capabilities of a specific ERP system instead of what the company need. And that do not lead to customer satisfaction.

Secondly I argue that ERP system is often looked on as technical implementation of a new IT-system, instead of what it really is – a project that changes the way the employees work. To get the full benefit of the implementation, you have to have change management initiatives running parallel, to ensure that employees and partners understand their benefit of using the system.

I intend to write more about this subject in the coming months, so be sure to check back in regularly.

Gaming for leadership

As you might have read earlier in this blog, I think that we can learn a lot from games and gaming about how to be productive in our work life. So I have been reading a lot about games, gaming (and gamification lately, and it has truck me that what characterizes a good game is also what characterizes good leadership.

It was while reading Jane McGonical's book “Reality is Broken” that it started to fall into place for me. She defines a game as sharing 4 common traits - a goal, rules, a feedback system and voluntary participation. Playing a game is fun, because as we try to reach the goal, certain constraints apply (the rules) offering resistance to reaching the goal, we gain feedback along the way on whether or not we have reached the goal, and since it is a game, nobody is forcing you to do this.

Ideally that is how good leadership should be as well – the goal is set either by the leader or the team as a whole and in come cases by outside forces. Certain constraints apply such as time, materials, and resources available. And while we work to reach the goal feedback should be coming back to us in a multitude of forms from our leadership, from customers and vendors, and other parties involved in the business. It is also a voluntary commitment, because we can in most cases quit the job, if we do not like it.

The problem is off course that things are seldom ideal and hence work is often not as fun as it could be. What is strange is off course that there is really nothing stopping us from trying to reach an ideal state. We have control of almost all the parameters and the ones we do not have control over, we can get feedback on and adjust to. Let look at the 4 traits one at a time.

A game has a clearly defined goal. In in reality projects often have vague goals or conflicting goals from stakeholder to stakeholder. But it does not have to be that way. Practically all books I have read about leadership and management states that having a clear and measurable goal is paramount if you want to succeed. So if we want to make work more fun by making them more like games we need to focus on making good goals – which is something we can do something about.

A game has clearly defined rules - reality do not. However the constraints of a project act somewhat like rules. Things like we cant go over budget, we cant get more members on the team, and we need to finish by a certain deadline can all be considered the rule of the project – the constraints we have to act within. These are usually the things that are hardest to change and hence we feel blocked by them. But if we accept them just as we accept rule sin a game, we can enable faster and easier decision making. Its all about focusing on the goal and how to reach it within the constraints instead of focusing on the constraints and how to get around them.

Feedback is easier if we have clearly defined goals. But we have already established that if we do not feel that the goals are clear we should start by clarifying them. However even when we have good goals to measure against good feedback does not automatically follow. Good feedback requires rules and methods and diligence to achieve it. Most agile methods have lots of feedback procedures in the form of burn down charts, sprint demo's, code reviews and sprint reviews. For some reason I have often experienced, that the first things that are sacrificed when time are about to run out are the feedback routines because the do not seem to add value in themselves. But they are essential as they are what allows us to measure the value of the work we do against the goals.

Voluntary participation might seem something that only really applies to games and not work. Because realistically how many of us wants to quit our job because of one bad project. But this is where the leadership part really should shine. I think this quote from Dwight D. Eisenhower put that very well in perspective: “ Leadership is the art of getting someone else to do something you want done because he wants to do it.". And I think that if you focus on getting the first 3 thngs right (goals, rules, feedback) then you are much more likely to get people to want to work for you and having more fun doing so.

Planning for quality

As the fourth value in the agile manifesto (link) is: ”Responding to change over following a plan”, I have often experienced that it is difficult to convey to a team, why we should plan when we know it is going to be changed later anyway. Why not just start coding and act.

Many agile methods such as XP and Scrum actually has a lot of planning activities in them, and actually follow a quite strict schedule, although that schedule is very different from waterfall methods. But I find that few can explain the paradox of why planning is necessary when we don’t plan on following it anyway.

And then I read this little insight in a book not at all related to agile or programming, but to leadership and it struck me that it was the reason why even agile methods emphasize planning activities, although they value responding to change over following a plan.

The insight is this little quote from a book called Lateral Leadership:

”The goal of planning, however, is not high quality plans but high quality work.”

So when the team ask why they must plan the answer is to heighten the quality of the work they are doing. Work must have a direction, something to work towards, a vision of how the world will be, when our product is finished. And that is what planning does – it gives us a goal, and with a goal it is much easier to see what the next step towards that goal is.

If we look at planning this way, how good a plan is can then be measured by looking at the output of the work that comes from following the plan. This can then be used as input for retrospectives, where we can suddenly ask ourselves, if improved planing can help improve our quality.

It can also help us set the time span of an iteration, as when following the plan no longer provide high quality work or value for the customer, then we should look at stopping to follow the plan or change the plan – i.e. start a new iteration.

The last thing I really like with this definition of what a constitutes good planning is that it gives us an external measure of whether a plan is good. A plan is no longer measured on if it meet certain criteria or conforms to a certain standard. It can be valued on the output – did we get the value we wanted when we did the planning.

What do you tell your team, when they ask you why they should do all that planning?

Gaming for a discount

If you have been reading some of my other blog post, you have probably realised that I am becoming more and more interested in gamification - i.e. how games and gaming can be used to make work both more fun and productive.

So this morning while browsing my emails I noticed an Email form Sitepoint that offered a discount if I completed a simple little game. Normally email with offers goes almost straight into the trash can, but because of the little game, I was intrigued.

The game was a simple game of searching their websites for 3 clues. I completed the game and even though I did not take the offer, they got me to browse their website. I think this is a fantastic way of showing how adding even a little gaming contect can spur the curiosity of a reader and get him to look at your website. This is gamification in it simplest form – I wish there where more like this.

PS – I am not in any way affiliated with SitePoint – I just bought some stuff from them and now receive their newsletter.

Action stations!

When I started this blog, I swore to my self that this was not going to be one of those blogs, that only have 3-4 post and then just stop. And here I am and it has been more than 4 months since I updated it.

Luckily I happened to watch this little fun video earlier today. Since it's core message is to take action, I decided to take some action and make a blog post. The part about taking action is one I have mentioned earlier in this blog post.

So this is the first post of the revival of this blog - please do come back and check regularly - I promise there will be more posts soon!

Cat herding – best done by cats?

Managing creative people are often compared to herding cats (link 1, link 2, link 3). And that can be a daunting task as cats are known to do mainly do what they want to do.

However this is not a blog post about the usual answers to leading creating people. As usual  I have connected som related things and got this crazy idea that I just have to share (and I hope that ranks me as one of the creative peole).

Well, leading creative people may be like herding like herding cats, which sounds stressful, and often taking part in a software development project is almost the definition of a stressfull environment.

This is a bit funny as actually research shows that owning cats have many benefits. One of the benifits are that having cats around reduces stress. Having worked from home the last couple of month I can attest to that having a cat sleeping on your desk next to your keyboard while you work has a very soothing effect that lets you concentrate on the job. And if you need a quick laugh just take 2 minutes watching a cat play with a string (not my cat, allthough one of my cats are called Arthur).

A couple of month ago, I stumbled over a refence to cat cafés. At that time I thought it funny, and was wondering if a cat café would work here in Copenhagen where I live. But recently I have thought further – what about cat offices? Would it be an improvement to an office if there was a cat or two present?

On the top of your head you will probably call the idea ridiculous but try to give it some more thought. Cats are very clean animals and they sleep 60-70% of the day, and are generally not hard to keep. It is a very little expense and that could easy be recovered if they help create a less stressfull enviroment with a less negative mood that increases the productivity.

I am not saying this is an idea that will work for everybody – perhaps it will only work for a few – but on the othe I hand I do believe it should not be completely written off either.

Do any of you know offices where they keep cats? Then please leave a message in the comments.

The user is never right

The user/customer is never right – at least when it comes to designing good IT systems. This might seem like a odd statement to come from someone like me that thinks agile is great. Because agile places a lot of weight on commucation and customer collaboration, and most agile methods uses user stories or use cases as their basis for development. And if we base our design on user stories they must be correct, right?

Well, sorta but not quite. In the recent massive amounts of articles about Steve Jobs that have appeared after his death I came upon this qoute: ”You can't just ask customers what they want and then try to give that to them. By the time you get it built, they'll want something new.". I know from personal experience that this is often the way customers act when you present somenthing to them. There is always changes or imperfections, or their problems and processes have changes. I am sure many other developers out there know the feeling.

So if we do not trust the user/customer to supply us with what to do, should we then just do what is awesome? Well, that often do not work either. I found this qoute in a blogfrom CCP about the problems they face when developing (they use Scrum): ”..when we start off with an awesome idea rather than an actual problem we want to fix or a feature that has a clear, functional and necessary goal, it generally requires painful fixes further down the road”.

Does that leave us with a catch-22 problem? We can't rely on customers and we can't rely on what we find awesome.

No – we actually have all the tools needed in agile thinking. As I see it much of the agile way if thinking is based on that the user never really know what they want. We – the developers – need to help them. So lets look at it that way.

First – as agile developers we are always ready to respond to change over following a plan. We know we can not trust the user/customer to know exactly what he wants, so we make short iterations and continiously deliver stuff to the user, so he can see if he can use what we have made – if the system solves his problems.

Secondly we collaborates with the user/customer. This is usually done by frequent interactions with the user/customer to build trust between them and us – we need them to trust that we understand their problems and that we will deliver something that helps them.

Which leads me back to user stories and the qoute from the CCP blog. User stories is a great tool if used correctly. They are however not requirements. They are a tool that facilitates communication with the user/customer, and grounds our – the developers - understanding of their problem. It is not the solution to the problem – the solution is experessed in deployable code that solves the problem.

When we look at the standard template for a user story (*) it has often struck me, both as a developer and business analyst, how often the last part is omitted – the benefit. But that is crucial for understanding the problem that we want to solve. It is the benefit that creates value not the action. So I find that the trick to creating a good solution is to focus on the benefit and how to achieve that and not so much on the action. If we can find a better/faster/smarter action that achieves the same goal surely we will deliver value. But if we assume that the user/customer is right, we often focuses on the action – which is usually also easier, but also leads us much more in the direction to focus on contract negotiation instead of customer collaboration – afterall the system can do all the required actions, right?

In my experience it is the projects that take user/customer inputs as absolute requirements that fail – at least in delivering value. The ones that succeed is the ones where the developer solve the user/customers problem often using novel technology or solutions that the user/customer did not think of. So the user is never right – but neither is you – but that does not matter if you have a little faith and trust in each other and look at the problem and what creates value.

(*) "As a <role>, I want <goal/desire> so that <benefit>"