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.

Advertisements

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. (http://en.wikipedia.org/wiki/Storytelling)

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…

Context

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.

Understanding

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.

Conclusion

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.