Part 2: How to think when developing software or implementing an Off-The-Shelf system

This is the second post in a series, aimed to give some Do-It-Yourself tips and guidance to traditional companies, when they want to go in a more agile direction. Since agile is not a rule book, but more of a mindset and framework, the order of the posts may seem a bit irrational, but there is logic to it.

In the last post we discussed why Waterfall projects (the signum of traditional companies, in a sense) gives false security. In this post we will discuss how you should think when you carry out digital projects. And this way of thinking can actually also be applied to waterfall modeled projects, so here we go…

Waterfall projects, as we could see in the previous post in this series, are depending on detailed requirements upfront, in order to be planned, time boxed and budgeted.
This means we are handling a lot of information and requirements, from a lot of different stakeholders, in the aboslute beginning of the proejcts. This sounds sound, but in fact it means that some very important aspects of the user requirements often are overlooked during the definition/requirements phase. The reason is simple;

If you are going to implement an ERP system (for example), where are lot of stakeholders are involved, it becomes overwhelming to take more than the hard fact requirements into account. Therefore they tend to focus on the WHAT. Hence; what functionality needs to be in place for the business to run. This means that we often forget about the HOW.

To bring purpose to a project, explain it to the organization, and have clear goals for it, we can use a methodology that sometimes is called “The four W:s” and sometimes “The five W:s”. Some also mix in an “H” in the mix.

Yes, this sounds a bit strange, but it is quite easily explained, and it all starts with WHY?

Here is my own take of the methodology: 

1. Why
   1. Why do we need to do anything at all? We usually know this, but we should get it down on paper. For example:
      1. The company is growing rapidly and has poor system support and very limited automation. This hampers growth and will add additional costs and errors in our processes. 
2. What
   1. What do we need to achieve in order to fix the problem statements we get in the why-discussion? Example:
      1. We need to achieve a higher level of automation.
         
         We should also prioritize the things here, and we will need to investigate where we have the most waste in the processes etc. so that we can prioritize this using a data-driven approach.
         
         Please note that priority here does not equal “When”
3. Who
   1. Who are affected by the targets we set up in the what-discussion.
      1. These are our stakeholders and will help us identify where to put who in the Stakeholder Matrix. This in turn will help us determine who needs to be informed, who needs to have an impact on future solutions etc.
         
         It is good to know this before we go into the HOW
4. How
   1. How will we achieve the targets set in the “what discussion”?
      1. Now we need to look at what information and/or functionality is needed to achieve the WHAT. This can initially be a high-level roadmap without technical details. The details should be taken care of in each one of the projects/product streams:
         
         The “WHOs” we have identified will be part of this process as stakeholders but not, and this is important, as project resources. Unless absolutely necessary, of course. The latter is important in order to gain speed and decrease the workload for colleagues who need to focus on their daily tasks to keep the business running.
5. When
   1. This is the prioritization in terms of what will be delivered when in each product stream.
      1. It is important to have a helicopter view and steer the work here so that we know that the development in all interdependent streams move synchronized towards the goal. There is no meaning to develop one functionality in a system that cannot be used  by the other systems involved.
         
         The When is a combination of task complexity, expected outcome (how much time can we save) and company priorities (we MUST enter a new market next month, hence that has higher priority than something else)

Using the questions above when planning out a project or investment in software will help the organization focus on what is important. This is, in my opinion, one of the first steps for an organization to begin transitioning into a more agile way of working.

Part 3 will discuss why the stakeholders should not run their digital projects, and what is needed in terms of organization.