Thinking the whole when making decision about your ERP development projects

Buildings

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.

Businessmodel

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.

Decisions

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.

Kano_Model

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.)

Conclusion

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?

Why technical debt removing is painful?

Technical debt exists in code architecture and in code base. Debt appears when product requirements changes and new features are built in without taking care needed, small or big, architectural changes. Your code base starts to contain more and more shortcuts which will make it more difficult to develop system. Development speed will slow down. Finally you are so slow that developing the system does not make any sense. That sucks.

Why it’s difficult to remove technical debt? In this post I will introduce some common obstacles. I will show that usually debt comes because short term goals drives over long term goals and that without craftsmanship of the whole company or department product will have more and more technical debt. We need to start fight against debt.

Short term goals are driving

It’s easy to be blind for long term goals because of short term goals. You do what you were asked to do and deliver it fast. Everybody is happy. You have taken some shortcuts but who cares. Feedback is positive and mood is high. Some guys from the team are praised for finding clever shortcuts, like using database fields for totally different things than their name says, or just controlling same functionality with more and more input parameters and if -branches.  Short term speed tastes good.

I think this short term goal achieving is ok. As far as it’s understood that by doing these shortcuts you take debt which you need to pay back. If only short term goals are driving the development and short cuts are taken iteration after iteration and year after year then your product will be screwed up. There has to be balance between short and long term goals. Product owner has a major role in goal setting.

Technical debt is difficult to measure

If you don’t have any measurements for technical debt then it’s difficult to know that it exists. For example: As product owner, do you know how many shortcuts were taken in last sprint? Do you know their effect on upcoming sprints?  It might be that development team is the only one who knows current technical debt amount. When you don’t know about technical debt in your product then you are not ready to eliminate it. Most likely paying debt back  is not in your backlog, or is it? After all, reducing technical debt will only bring indirect value for customer.

What happens if we combine these two first problems? Only developers know about technical debt and you are rewarding them to take more debt.  You might see that velocity will drop and what you will do? You put more pressure to get to the deadlines. And again more short cuts are made. It’s like product has fallen to ground and you are still kicking it. Lucky us, product doesn’t feel pain (yet).

Legacy code

Ok, we know we need to know if technical debt exists and some way to measure it. Then we look those 1000 classes with 20 000 LOC each and without any automated tests. Critical business processes use the existing build binaries every second. What do we do? Maybe some sensitive guy starts to cry? Somebody proposes to refactor it all (product owner opens bottle of Jack). Well yes, this is serious situation. Then we need the leading developer to stand and say: “I have some ideas so let’s not make it any worse than this, let us know where it’s most valuable to start to remove technical debt and when we will start?”

Conclusion

Usually technical debt is compared to financial debt. I have an another example in my mind.  Technical debt is like a unhealthy food. Like candies and cakes. It tastes good but if you eat those candies all the time you will start to get fat, you will end up being in not a good shape. Same way as product architecture starts to be in bad shape. If you don’t continuously measure your weight you might not notice effect from candies. Fat comes slowly.  At the beginning you might not even notice it. At some point you will find out that you are too fat. You will notice that you can’t run anymore. Maybe then you will start to think differently about eating candies and start to do some walking exercises.

Be as serious with technical debt as you are with your own health. As a product owner try

  • Balancing short and long term goals for product development
  • Studying and understanding your product and technical debt in it
  • Small steps to get rid of debt

Otherwise principles of technical debt will kill your product.

Case study: Planning communication for managing stakeholder expectations

How could stakeholder expectation management be done in practice? We already went it through in theory and now I’ll adopt theory to practice with imaginary case study.

Let’s assume we have product which has been built as a back office solution. Marketing and product owner sees opportunities in markets if frontend would be web UI instead of back office UI. Development team has checked that new UI can be implemented with reasonable cost and owners of the company have agreed to invest money for the product development. Marketing department have got two pilot customer signed in for beta testing.

Identifying stakeholders

There has been named one person from the owners to be responsible from the cash flow for this project. He has authority to cancel project. There are two customers who have agreed to be pilot customers. They have named 2 main users (1 from each) to be responsible about feedback. Pilot customers are able to purchase software later on with discounted price. Customer support will support product after it’s published. Marketing department is interest how they are able to sell product and company has one 6 people scrum team which will work with the project

Analyzing and grouping stakeholders

Customer support wants to have product which is easy to support. They want to know that there has been taken care of usability issues and that there is followed company’s standard for web UI development. Support is also interested that team will not build too complicated features for new UI. As customer support knows the team and what they can do it’s enough for them to monitor such things.

Pilot customers are more interested. They have some investments in as they have people inside project. Also they are interested that final product will give as much value for their business as possible. They also have some power as product goal is to fulfill needs of customer segment which selected pilot presents.

Marketing has almost similar interest for the product as owners of the pilot customers. Market’s contains lot of potential new customers but it requires that product features matches market expectations. Marketing provides lot of important information for guiding product development.

Dev team is interested to deliver valuable product (case company is proud to have such team). After all it’s their job to do project. Also they have some power as this team is only team which can make product with reasonable cost.

Main users are interested from the product as well. Product impact will be high for them. They will use product in their daily work after this project. Their power is not high as dev team but it is higher than customer owner (we assume that owners of the customer companies are listening these users).

Owner is providing cash flow. He has high power. He is also interest about product success. There are certain risks with dev team and web UI. Because of that owner is interest to follow how product development starts.

Following picture shows how stakeholders are placed to matrix based on those groups.

When product beta’s will be taken to use it has impact to customer support. Even customer support priority group is  small it should be managed closely in release planning. Based on this short analyze there can be created groups

  • Manage closely: Owner, Dev team, Main users (+ Customer support for release planning)
  • Keep informed: Marketing, customer owners
  • Monitor: Customer support

But these groups are only initial.  For example, after project goes on then stakeholder can be moved from group to another. Why? Because environment changes. After a while owner finds out that he can trust the team. Also he notices that feedback from main users is positive. Things have changed and he doesn’t want to use such much time for this project. He is then moved to group Keep satisfied.

Communication

Grouping is now done and communication can start. First there is created vision with people who needs to be managed closely and kept informed. In this case study vision is written by product owner but it’s based on co-operation with marketing, owners from customer, main users, owner and representatives from dev team.

After vision there is planned schedule with people who needs to be managed closely and who will have impact based on schedule. Owner of the company has told that he only wants to be informed about release plans. Product owner starts to work with developers and with main users to create rough product backlog. This backlog has first estimations from the size of product features. Release plan is created based on rough product backlog and for that also customer support and marketing are asked to contribute. Backlog has now first priorities.

Development starts and reviews takes their place. Demos are important for  the people who are in the group which needs to be managed closely.  Other groups are invited to demos but its optional for them to join. This means that there can be found at least dev team, main users and the owner from the demo session. Sometimes you can find people from marketing, customer owners and customer support as well.

Stakeholders decides to split releases to two sessions. First one introduces release  and second session works as a retrospective for the release. To both sessions there is invited all stakeholders. In the second session there is checked how project is going based on the vision and release plan. If needed then changes to expectations and groups are made. This goes on until project is finished.

Conclusion

In case study there was used 4 steps to manage stakeholder expectations:

  1. Identify stakeholders
  2. Analyze and group stakeholders
  3. Manage expectations with known tools
  4. Iterate

Case was pretty nice and in practice there comes many surprises along the project. Environment changes. It would be nice to hear what are best surprises what people have experienced along the way. If you share some of yours, I can share some of mine. We can together think how to handle stakeholder expectation management in those cases.

Stakeholder expectation management – introduction

Let’s go more deeply to managing stakeholder expectations as it was discussed in earlier post comments. Successful project and product needs successful stakeholder expectation management. When expectation management is kept effective it provides valuable source for the feedback. Even expectation management sounds relative simple to do I have found myself many times figuring how it would be good to done. Other question is that how much it’s needed.

In this post I’ll go through basics of stakeholder expectation management from product owner point of view and in next post I’ll adopt theory to practical example in my agile context.

Stakeholders

From the wiki we can find that project stakeholders

  1. sponsor a project, or
  2. have an interest or a gain upon a successful completion of a project;
  3. may have a positive or negative influence in the project completion

In practice it can be management, customer, main users, dev team and customer support. For finding how much expectations management is needed we could group these entities with these question.

How much communication is needed

First you need to identify the need. Identify and analyze your stakeholder to different groups based on their needs. After you have groups then communicate based on group needs. This way you are avoiding unnecessary overhead. After a while start to get feedback and re-arrange groups if needed.

For grouping there is several ways

  • Users, governance, influencers and providers (source)
  • Priority groups which are based on variables: power (high/low) and interest (high/low) (source)
  • Impact of product (ROI, change in future work load etc.)

Also there is needed to consider that how big trust there is for project/product success. If stakeholder trusts product success then need of the communication is not so high. From my experience there is variances like

  • Competence people vs. not competence people working with product
  • Small project vs. big project
  • Known markets vs. unknown markets

How communication can be done

Keeping expectations in already familiar tools will help you to avoid unnecessary overhead.

Product vision

  • Here you will capture your business value, customer main needs, critical attributes etc. So it is already telling you what are the stakeholder expectations
  • Checking this regularly will give to you and other stakeholders opportunity to know if product is still going to deliver value what was expected
  • This usually is document. For communicating more about critical attributes I propose tool from Mike Cohn’s blog.

Release plan

  • What expectation are going to be filled and when? What are milestones? When people with impact needs to be ready?
  • With this it’s also easy to visualize what happens when stakeholders come up with new ideas and requirements (yes it really happens when stakeholders understands that changes and feedback are welcome) or some key people are lost from project.
  • Visualization can be simple time line or gant chart or release burndown chart.

Product backlog

  • Which are the next things to be build.
  • More detailed than release plan and from my experience big picture can be hided to backlog. Use it for correct purposes for needed stakeholders (like dev teams and users).

Demo sessions

  • Useful session to make sure that expectations for this sprint are filled.
  • Is more detailed and might hide big picture so this is not ideal for all stakeholders.

 Conclusion

Identify and analyze your product stakeholders. Try to find how often and what kind of information they are interest to get. After this is done then include information to existing tools which you are using for your product. During implementation phase get back to these tools and check is product still meeting stakeholder expectations. If not then fix direction (or expectations).

One point which also good to know is mentioned in this post. There are realistic and unrealistic expectations. Don’t let unrealistic expectations be alive.

Checklist to keep myself agile product owner

This post is related to earlier post: Reminder: Why I choose agile.

I experienced that even I found out reasons why to choose agile I don’t follow those in my daily work as much as I should. Because of that problem I decided to create check list for myself. I usually plan my upcoming work week at the last week Friday or at the beginning of the week. Following list will help me to plan my week.

  • Product
    • Will you get  feedback for the product?
    • Will you work with vision and backlog based on feedback?
    • Will you arrange possibility for development team to work with end users?
  • People
    • Will you discuss with team if they are having needed competences?
    • Will you let team to self-organize to make  best process for themselves to build the product?
    • Will you let team to find out best implementation for product?
    • Will you let team know to which direction it needs to grow to build the best product?

Additional note: Most likely you need to work with constraints like budget, time, quality, shared vision etc. If needed then communicate with all stakeholders. Don’t let constraints to be obstacle. Let it be possibility for new discussions.