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

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.