Thinking the whole when making decision about your ERP development projects


As a product manager you quite often find yourself thinking development priorities. Marketing and sales want’s something, business management wants something, technical people wants totally different and list goes on. Addition to the needs you need think about your capabilities.

I already wrote in my previous post how to use the Kano model for prioritizing. Because the Kano model mostly focus on features I wanted to expand my view. The key is to think needs and capabilities as a whole. In this post I give a quick overview to how I have grouped and analyzed needs and capabilities. Based on that I’m able to create better development priorities for my team and communicate those to all stakeholders.

So what point of views to consider when deciding priorities for  development projects? I divide question to three sub questions.

  • What kind of business you are running,
  • what’s your position in existing markets and
  • what kind of resources you have?

How your business model affects to your product development priorities?

Roughly there can be two business models for software development. Revenue comes either from product licenses or from software projects. If first is important then it’s necessary to put focus on product features. If the latter is more important then it’s better to develop tools or methods which help you to deliver quality projects. Usually you belong somewhere in between those two models.


What about markets?

As I wrote in my previous post you need to have basic features and something to keep your product competitive. To make good decisions you need to analyse your position in markets and understand what’s important for your product.

Last question was related to resources

There is two main resources needed. First you need to have the money to do the product development. With the new ERP product it’s usually an external investment which makes it possible to do needed development. When the sales are ongoing activity then part of the revenue can be pointed for the development.

Addition to the money you need skilled people. Without experts it’s difficult to arrange a quality development. There is also interesting connection for the business model: If you own your product then you usually have a deeper knowledge (domain-, product- and technical knowledge) to develop the product.

The point: Think the whole and make decisions

I have mentioned three things which I have needed to consider when thinking priorities for the ERP product development. If  I wouldn’t do this I could end up to situation where I promise features which my team can’t deliver or for which I don’t have money. Or I could promise something which really don’t give value for my business model.


When thinking your context, you might find more.

Developing your ERP product features

ERP is a business management software – usually suite of integrated applications – that company can use to store and manage data from every stage of business, including: product planning and development, manufacturing, marketing and sales, inventory management, shipping and payment. (wikipedia)

With the ERP software a company can steer its processes, collect data and optimize needed functions. The ERP usually is platform where other IT systems are integrated.

As well as other products ERP applications needs a continuous improving during its lifetime. The need for the improvement is different than for example consumer product. Need for new features comes usually from:

Why new features

The same needs applies to many other industry software as well.

Where to get ideas for development

I have found it rather easy to gather ideas for development. You can get ideas from

  • Customers
  • Your team
  • Competitors
  • Platform vendors
  • Sub-contractors

Working with all of these groups gives to you a long list of things to do. After you have the list then it’s still good idea to mix things and getting even better ideas. This means getting customer needs to the same table where your team ideas are and so on.

When collecting ideas remember ruthlessly seek customer needs and match those with solutions. And, of course, check that you are able to do profitable business with ideas. You can use a Vision Board as a template to capture ideas.

How to know what to develop?

As the ERP software is quite large by its nature you will need to do difficult business decision about improvement priorities. Which ideas to select for development? I have found useful to use a Kano model to group needs and try to predict what would be the most valuable thing to build next. It also gives for you a nice context to analyze current market trends.


This is a file from the Wikimedia Commons

Basic needs: You need to have these. With ERP applications this can mean for example mature core without bugs or possibility to integrate 3rd party systems. In time things which use to be delighters starts to be basic features. Without basic needs implemented you will be out of the business.

Delighters: With this group you can differentiate your product in markets. It can be based on some technological innovation or creating tools which gives to your customer in their business competitive advantage. In time competitors will reach you with your deligthers so you need to have continuous innovation. Currently there is going though competition to delight users with smart phone and tablet applications. After some time this kind of mobility will be basic need for ERP applications. Without delighters your sales will have difficult times.

My advice is to look closely to two things: how do you differentiate your product in markets and which features become standard needs for customers.

(Check also my newer blog post Thinking the whole when making decision about your ERP development projects to find out wider angle to prioritizing.)


ERP development has its own specialties. It’s clear that there is need to develop software during it’s lifetime and needs are not the same as for example consumer products.

It’s rather easy to get ideas but more difficult to know to what to build. You can use Kano –model to analyze to which direction you should develop application. Remember to be consistent with the direction.

Optimizing the whole with the strategy and the vision

In the past year I have played and studied chess more or less active. It has been interesting to see how strategy game chess actually is. As well chess is fun to play I have also found interesting relation to software product development.

In both “games” I have found one of the best approaches first doing strategy, then planning and  executing it in small pieces. Let’s take a closer look why I think strategy is important.

Software development and vision

A vision is strategic document in software development. Document usually contains description from the problem and vision from the solution. It also declares in which boundaries solution needs to be implemented.

In other words in the vision you set up strategy how customer problem will be solved.

Based on vision you can start to create more detailed plan like product backlog or functional requirement lists, adjust priorities and then execute it.

Advantages of strategic thinking in chess

chessboardIn chess strategic thinking means you are building a plan which you can follow and finally win a game. That plan is not step by step moves to the victory. It’s rather vision about which weaknesses and strengths to guide you through the game. The game can be in situation when it’s better to attach, switch pieces or even to sacrifice a piece to get better position as opponent has.

Without a long term plan in chess your chances to win are not good. It’s not possible to count all variations which opponent might play. It’s too complex. And if you just move based on opponent’s last move then he or she controls your game. You need to have long term vision how to win a game.

Software development complexity board

In software development complexity might not be so easy to see, but it’s there. I’ll try to explain complexity with software development board.

Let’s start from the chess:

  1. Your opponent has his or her pieces which have different properties. Your opponent has own mind which you can’t read. So he or she moves pieces more or less unpredictably. This causes most of the complexity.

  2. You have your own pieces which have different properties. You can control your own pieces.

Transforming it to the software development:

  1. LIke in chess I added items which cause complexity to the top of the table. Those are again more or less unpredictable and not fully controlled by you and your team. There is two kind of things. There is items which are related to customer and there is items which are related to environment where you are working.

  2. To the bottom I added items which are solution. These items you can control. There is features delivered and then solutions how features were done.

You win if you can handle complexity and unpredictability and build the solution which satisfies stakeholders.

From theory to the game

As I told in chess it’s impossible to count all moves and win the game. Same applies to software development. It’s not possible to create detailed functional and technical documentation upfront.

Why? Because there is too many factors and you learn those when development goes on. That’s why, as in chess as well, you create first a vision and only then plan next and only next moves.

Now let’s take an example about playing with the vision.

Let’s assume that playing couple moves in the chess game. You find out (or learned) that you opponent is attacking from the left side with his bishop. You need to stop that and you have two options. Which one to choose? The one which aligns with your strategy. This way you improve your whole game and you are just controlled by your opponent.

Same in software development. Let’s assume you created a proto and showed it for the users. You learned that the way they do their things are different that you expected. You need to do something. Way to do things was unknown for you and now it’s attacking you.

With this case you have now possibility add more details to feature which will be implemented in near feature. Like in chess game  you had two options to react to opponents move now in software solution you have several ways to fill the need which you learned. You choose one which is aligned with your vision. You are optimizing the whole solution, not just single need. You are going toward your goal, your vision. And the vision declares your strategy. Brilliant.

Vision or strategy is there to help you when you learn more from the vision. Vision is like a compass that guides you to the north pole.

So what I learned?

In chess it is easy to understand game complexity. It’s there front of your eyes. In software development it might not be so obvious. Complexity makes it almost impossible to count all moves upfront. Same applies to software development planning.

When you learn more from the game or from the system then it’s the vision that guides which helps you to do new decisions. With the vision you optimize the whole system, go to the correct direction and not just react to single needs which will pop up.

It’s interesting to think that long term product road maps are strategical documents as well. What could be in the top row when thinking about product road mapping complexity board?

Storytellers in software development

Storytelling is the conveying of events in words, images, and sounds, often by improvisation or embellishment. Stories or narratives have been shared in every culture as a means of entertainment, education, cultural preservation, and to instill moral values. Crucial elements of stories and storytelling include plot, characters, and narrative point of view. (

To reach valuable solutions in software development you shouldn’t be the best requirement writer. Instead you should be a good storyteller. Why? Follow me…


One of the good point in storytelling is that it puts everything in context. I was listening Coplien in Tampere Talo during 2012 spring. His point was that user stories are not good enough as stand alone “requirements”. User stories are missing context.

Storytelling goes from beginning to end. From describing the initial “system” through changes to the happy end (or sometimes not happy end). All of this will set context for user stories. It will tell how small requirements will change the whole system.

Context sets the final value which system will got from the change. Beginning end in mind makes sure that every steps takes the team toward the right goal.

Decision makers

So we understand that context is important. But for who it’s important?

Poppendieck wrote about decision making. I specially remember a Marine team. In the team decision making is given to the front people. Why? Because complex problems can be dealt only on the front line. Poppendieck wrote about a study which result was that when front people are solving complex problems they will do less mistakes than  distant officers.

Poppendieck continued that in the Marines planning process focuses on understanding. This way the team can understand boundaries, simplifying assumptions, alternate approaches and strengths and weaknesses. They can do fast decisions when a mission is going on and act based on that.

Same way as you dig in to the source code and find out what really is going on in the function level. You find out what are real reasonable ways to solve customer problems. You can do best decisions if you have understood the problem and the context.

If you don’t understand the problem and find that some of the manager assumptions were wrong then you have two options: Call in manager for new decision making or do some guessing. Call in will take time and stops whatever you are doing and puts the task on hold. You need to get back to it later instead solving it right away. About guessing… well it’s guessing.


But how to emphasize understanding? As when setting context for requirements you can continue storytelling to help people to understand.

Tell about the users and the customer. Tell what kind of problem customer has and why it happens. Tell about the environment. Tell also about how customer now survives and which kind of consequences she is having. Tell about boundaries. Then move to the time after problem is solved.

Again highlight the value which customer or user gets after problems is solved. Also go through possible solutions which are discussed with the customer. List down pros and cons from different alternatives. That’s way to emphasize understanding.

Isn’t that just creating a good vision for a project?

Storytelling pokes imaginationNot exactly. The storytelling is something more. It pokes the imagination. And the imagination is the key for our emotions and learning.

With good storytelling you can visualize the context, the problem and the solution to other people’s minds. You can make them feel sad and happy.

The storytelling is what you need to do if you want people to stand in customer shoes. To feel the problems. Somebody once said that if you can’t visualize it, you can’t understand it.

So if you already write the vision for your project or product development, check that it’s not boring. Make it interesting.


The storytelling has many advantages. With the storytelling you can

  • Add context to the requirements
  • Create a clear vision about what happens when the problem is solved
  • Help front people to make better decisions
  • Have possibility to feel and stand in the customer shoes

How to find time for the storytelling? In previous post we had unhappy developer Cole. His project started with punch of the detailed requirements. At the beginning of the project Consultant should have been considered to replace most of the requirement details with storytelling. That would have helped Cole to do better decision.

My conclusion is that the requirement writers needs to learn to be good storytellers. The storytellers will put some drama, make people sad and happy. More better story you tell more better it’s remembered.

Working software over comprehensive documentation

Cole is a software engineer who is frustrated to software functional specifications. Sometimes there is details which are changing and sometimes needed details are missing. This happens project after project. With heroic last days work Cole can fix the last things and deploy to customers. But soon Cole has had enough.

In this post I’ll take a closer look to a Cole’s problem and why it happens. I’ll explain it based on principles related to software development and get back to the Agile Manifesto.

Principle based problems

I like three golden rules which have been introduced in the book called Agile Samurai.

  1. It’s impossible to gather all the requirements at the beginning of a project
  2. Whatever requirements you do gather are guaranteed to change
  3. There is allways be more to do than time and money will allow

Why I like those rules? Because those are concrete results from the fact that software project is about solving complex or mediocre problems. Think about present days ERP systems. Those are not simple, are those?  (You can find more about this from Management 3.0)

About principles, it’s again like a nature. If you eat too much fat, you will get fat. Damn fat.

If environment and processes are not set based on the principles then there is too often needed hero’s and flexibility. And only after heroes and flexibility there is change that project is success.

Cole’s challenging project

Cole started with the new project. The project had requirements specification done which were gathered by consultant with customer. All the requirements nicely ordered and all the details were considered and written down. “Very nice. Finally something which I can code from start to end without need to interrupt others.”, thought Cole.

Problem 1 – Missing details and missing feedback. After two weeks Cole faced the first problem. Even though document had a lot details, some details were missing. Cole asked about the missing details and it turned out that the answers were not simple to give. Consult were already busy with the new requirements doc (tying to put down every single detail to not fail again) and Cole were able to feel frustration every time they had a conversation.

Cole got the answers but feelings were not high. Cole decided to start to do his own assumptions instead of asking. Cole was engineer and his decisions were more from the technical point of view.

Finally coding was done and system testing started. Consult participated to testing to check that everything was ok. Testing phase showed that some Cole’s assumptions were not correct.

Biggest surprise was that when consult asked to run old interface for data which new functionality produced Cole answered that it wasn’t possible. Cole explained that he used new database architecture for data sets and old interface just didn’t worked on top of that.

Because there was things to be changed Cole and consult decided to move deadline 2 weeks to make things right.

Cole started to be in trouble as the needed changes were not in align with his architectural solution. To make the changes in 2 weeks Cole needed to do shortcuts in the code and in usability. Shortcuts were not enough and he needed to do long days to make it in 2 weeks. Time started to run out and not all testing were able to do all over again.

“Oh why he hadn’t tested my software earlier. She could have seen how I understood what he wrote in specs and I could have adjusted my work and architectural decisions based on early feedback. Now I have a lot of things build on top of things which I need to change” Thought Cole at one long evening at the office.

Problem 2 – Understanding based on concrete results. It was time to show 2 month (and 2 weeks) results to customer. Customer noticed that for getting the value out from the solution they needed to have almost perfect product name parameters in the system. Customer were very sceptic that they could have such complete data in the system in real life.

But they got an idea when they were using the software. If they could just have one new user selection state for their controller for the data which was produced, they could forget the whole product name parameter problem and go on with just 2 extra week coding with Cole. Together with Cole they found out that this last change to the requirements made unnecessary ¼ of code which Cole already produced in project.

“Why we didn’t thought this earlier?” Said customer. “Yes, why not. I could have been home with my wife and kids if you would have saved some of my time and some of your money.” Cole thought.

Cole was angry. Why everybody checked his work results when it was too late for it!

Understand the principles

Cole’s problems in the project are caused by process which is not the for complex problems. Roughly Cole’s project was done like this:


If you really believe that you can find the best solution before a single line is coded you are wrong. A problem solution process in complex or mediocre environment isn’t straightforward. Even though final solution might be simple and easy, path to find solution isn’t.

This means that work with requirements will not stop when development starts. Consults, customers, coders and testers needs to work together. They need to create a teams where customer and development point of views works together for the best implementation.

In practise there needs to be first created guidelines and only then nearest details are thought. Details which are not needed next are waste. When you build small part of the solution for a review, then team understands problem better and might end up with the better final solution. It means that rest of the requirements might and should change based on the new understanding.

Below you can see picture of a process where team works together with observation from the built solution. “What needs to be done” steers “solution building” and “build solution” steers “the need to be done next”.


Working software over comprehensive documentation

So iterative software development with observation makes sense. But it might be difficult to understand before you are able to admit that the software development is about solving complex or mediocre problems. When you understand it, then you are ready to use tools which are developed to handle such problems.

Use working software over comprehensive documentation. If you will not do it, somebody else will. If it’s your competitor, you might lose your Coles and customers.

Why to not automate testing?

Robot, don't do it

Robot, don’t do it

In previous post we found out that there is reasons to invest money to automated tests. It helps people to develop their skills and automated test increases product quality. We also found out that automated testing suite gives ROI not in short term, but in long term.

But is it always giving ROI? Now we will take a look what are the reasons to not automate tests.

No competence to automate tests

If you want to have automated test suite for your product, make sure team has competence to do it. If there is no person who can take care of architecture of test suite, take care of test tools or to help others, you will end up to trouble.

It’s like working with team without competence to build user stories. Nobody really knows how they should code the thing, but they do it. At the end you find out that implementation cost a lot and readability and maintainability is low. Same with the automated test suite. It’s all the time broken and nearly impossible to develop further.

How you could avoid this trap? Make sure there is competence. Simply ask. Good signal is that, when you propose automated test suite for team, they will throw bunch of questions back. There could be asked questions like:

  • Do you mean, unit tests, component tests or end-to-end tests?
  • What kind of coverage product would need?
  • Do you want stress and security tests as well?
  • What is the value of tests? We are not delivering so many issues inside our stories?
  • Would you like us to help you to find tests which gives most value for product?

Other thing which was pointed out for me, by colleague of mine, Darius Muncys, was worry about misunderstanding the usage of automated tests. He was thinking that people might use automated test suite against the idea of “Quality needs to be baked in”. We were talking about having some end-to-end tests to our product.

His point was that, even people would know how to do automated test suite, people might think that automated test suite is the safety net which would catch all bugs after coding. Good point. That is not the purpose. That is not efficient usage of automated test suite.

Team needs to have competence to know how test suite is used most efficiently. For example team should automate manual regression tests, which they find out repeating. Then they can do, for example better exploratory testing in new areas. If team doesn’t know how to use automated test suite efficiently, then it’s not worth to create such.

One way to think is that, automated testing suite is not separate testing department. Automated tests are like a team member, part of the team. Tests works with the team to build better product.

Dusty automated test suite

Even team has competence to create and use automated test suite, it’s easy to do with the way, that it doesn’t produce needed value. As a product owner I like to think it as a new feature. If you user needs new story only once, was it worth of doing it? Probably no.

If your automated test suite was meant to catch side-effects and you have only once changes to area where tests would be valuable, were test worth of doing? Probably not. There is just not enough ROI. Don’t do things without good ROI.

If you need to run tests only once, it’s better to consider to doing those manually.

What about the new product, which you don’t know if it will be success or not? I liked Google  point of view. They start with the small team which knows how automated tests can be added later. Google is not adding test from the beginning, because if product is not success there wouldn’t be any ROI from automated test cases.

But they choose architecture so that it’s easy to add tests later. And later, if product is success, they will create automated test cases. For this they need hiring guys with high competence.

How to know if you will have ROI from automated test suite? Take your road map and issue backlog. Find out where you are going to need changes and then find out which test cases would have highest ROI in future.

For example team can know codebase side-effects which would be valuable to cover with test cases. And you might know what business domain relation changes will have. If you don’t use road map and analysis to decide needed automated test cases, you end up to guessing what is valuable and what’s not.


Team and product will gain benefit from automated tests but good will is not enough. For having value from automated tests you need to have

  • Skills to do and use automated tests
  • Integrating test automation strategy for your product strategy

If you don’t have those in place, don’t bother to create automated tests.

Why to automate testing

During last spring I have had lot of discussions and studies about automated testing. Question has been that should we start to automate regression tests to more than 10 year old code base and related functionality. Discussions were done with stakeholders including customers, shareholders, management, scrum masters, dev teams and testers. Studies were done by using web and also books from Lisa Crispin and from Google and I participated to testing days to listen how Spotify and F-Secure handle things. Should we start to automate in our context? Answer is both yes and no. In this article I will keep focus on the added value for our product.

How it helps people?

Let’s first check from the people point of view. Good team is more likely going to build product which will deliver needed value.

For the team which wants to improve, it’s important to have fast feedback. With having automated tests integrated to builds we have possibility to have feedback. It’s usually faster than having feedback from manual tests. And definitely faster, and cheaper, than having feedback from not working functionality from customer.

Other point is that team is changing. Some people goes out, some comes in. When product lives longer than the team, you need to manage knowledge how to build the product. One of the ways to store product correct behaviour is to store it to automated tests. This way new people can know, how things needs to work. It works as a document for developers.

For example: you end up coding of new rounding functionality for invoice payments. You tested your new code and it works nicely. It’s time to go home. At the morning you find out that nightly build throwed error. It shows that you broke invoice closing when it is targeted to credit note. It’s not exactly invoice payment, but it works with same code base. Your focus was too much in your story testing, not in side-effects testing.

But you got fast feedback, still remembered your yesterday coding, understood the problem, learned about it and had a clue where issue is. Also you saved money because issue didn’t reached end customers. Who added the case to test suite? It was added together with customer, because team didn’t understood business domain completely.

If issue would have been reported by end customer, it could be month or two later when you would know about it. Would it be easy to fix then? How many similar issues you have done during those months? If you would have known about issue would it have steered you to other direction with architecture?

One of the cons for humans is that we can’t rely discipline of them. I assume that everybody has heard sentences: “This small change won’t break anything. We don’t need to test it.” Computers don’t say that. They test and test if we have told them to do so. If test suite is good then computers will test even small change side effects.

Back to example case. Let’s say we would have found our payment issue in manual regression testing near the sprint end and we wouldn’t have automated tests. After small fixes would someone be running all regression tests manually again?

What about product?

People are changing and so does the environment. Either we understand reality differently or customer business is changing. When we do changes then we might have need for refactoring. When we have good testing suite for product we are able to do changes more easily and with good quality. We are more capable to change product to model real world and to serve customer needs.

When we automate tests we are also saving time from manual regression testing. This is important for big systems. Saved time can be used for testing more tricky case and scenarios which are more difficult to automate. For those cases there might not have been time before. By focusing to corner cases we are able to increase product quality.

In our example case we could assume that we have automated tests in place. Now we have new change request from customer. It doesn’t fit to our current architecture. We know that we will have more similar requests later so team decides to change class structure. That way it will model new understanding of the environment. Team wouldn’t do this change with reasonable cost without automated regression tests. After changes code base is easier to maintain, it’s easier to understand and it’s faster to do upcoming changes.


My point is that either you check automation from people or product point of view it has many good things. Its investment for product success in long run. Good test suite can:

  • give fast feedback and therefore increase learning possibility
  • work as a document
  • always watch your back even for small changes
  • give possibility to create better architectures with less technical debt
  • give possibility to catch more bugs before deployment

Some of the items are more important to other stakeholders than something else for other stakeholder. So, there is good reasons to automate, but there is good reasons to not automate. I will write about those in my next post.