Posts Tagged ‘Cost’

The Two Main Project Enablers; Cost and new Opportunities

1 Comment »

There are two reasons that determine if a project is an IT project or not. Projects aim to raise the return on invested capital; the two main enablers are to save money or raise the perceived customer value. Either you become more efficient or you get new opportunities. There is often a combination of these two where projects aim to both get new opportunities and save money at the same time. If the first priority is to get new opportunities and raising the perceived customer value the marketers will probably be your customers. And if the main enabler is saving money, you customer will probably be a administrative manager.

This knowledge that it either cost or new opportunity focus is important when you analyzing requirements and do privatizations. You might have a lot of different stakeholders and users that you need to interview and it might be hard to understand what they really wish to accomplish with a specific feature or demand. Then it can be helpful to think is this a cost saver or a new opportunity? And if you plan a project and come up with a plan you might surprised that you customer will be negative and worried if you after interviewing different stakeholders and users comes back with only features that enables new opportunities when the customer did expect cost saving features.


If You Adapt to Change! How Do You Handle the Price?

4 Comments »

A couple of days ago I wrote a blog-post “Plan-driven versus Agile = Predictive versus Adaptive”, the first comment I got on the post was a question from Hila Annis about how are these changes are priced. A great question and here is an explanation.

Hila Annis question:

I like your entry but I have a question – how are these changes in what the customer wants priced? I mean, in the end, we’re talking about a business, and if customer signed off on B but wants C, how do you price these changes along the way?

My Answer:

The answer is hopefully nothing! Let me explain a couple of principles and then I will get explain why it shouldn’t cost the customer anything.

Explanation:

First of all agile is not about selling or delivering the (B) + (Something) it’s actually to deliver (B) + (Something) – (Something else). In order to explain how the process works I will explain

  • Statistics about features never used
  • The project Iron-triangle is turned upside-down
  • Time boxing
  • Product backlog

Features Never UsedStandish report on features never used

In a 2002 report from The Standish Group, an investigation was made into failed projects to see how much the built-in features were used. They found that 20% of the features were used either always or often. The interesting part was that 45% of the features were never used. There could be many explanations for why features are never used in a system or product. But if you ask stakeholders to give you all the requirements up front, you end up with a lot of things that will never be used. If you deliver work in small pieces and work first on the first priority and also allow stakeholders to re-prioritize work, this problem can be addressed.

The Project Triangle Turned Upside Down

The traditional plan-driven projects are based on the traditional “iron triangle” of Time, Cost and Quality. All requirements have to be accounted for in the requirement phase and then the project is planned around the expected features to be delivered.  The features are the first ones to be fixed, afterwards an estimation of time and costs in delivering those features is drawn up.

triangleupsidedown

The Agile mindset, on the other hand, is to fix time and cost to manage a variable scope. This leads to the ability to hit deadlines both in the short and long perspective. This way it’s easier to focus on features that build value and to avoid building features that never will be used.

Remember Pareto’s principle – the old 80-20 rule. Vilfredo Pareto, an Italian economist, observed in 1906 that 80% of the land in Italy was owned by 20% of the population; he also observed that 20% of the pea pods in his garden contained 80% of the peas.  This is how he came to formulate this principle. In business, people say that “80% of your sales come from 20% of your clients”.  So wouldn’t it be great if you could avoid building features that will never be used?

Time boxing

Time boxing means that you budget the project based on time and not scope. You plan to have a specific crew in a specific time. You work for example for 4 iterations that last 3 weeks with a 4 person crew, it becomes what it becomes during that time. That way you can plan a budget.

Conclusion so far:

If you do big upfront design and requirement you will not capture all requirements and not understand what’s creates 80% of the value for the customer. Let’s look on some tools that help you handle this and how this might work in Scrum.

The Scrum Process

When planning the project you start with some requirements either as a user story, scenario or as a use case. Then you make a rough estimate of what it will cost to deliver that requirement. Then you order them all in a product backlog. All requirement have a unique priority, two requirement can never be prioritized the same, someone is always more important. Then you look on all requirements and their estimate and summarize the cost and then you got a rough budget of what it will cost to implement all requirements. When you start the first iteration (called sprint in Scrum) you look on how many persons you have for example 4 persons working on this project for 40 hours a week and the iteration will last 3 weeks. This means that you take out the top requirement until you reach  360 (4 x 40 x 3) hours of planed work. This requirements cannot be changed from now, but all other requirements in the backlog can be change and re-prioritized or you can remove or add new requirements. At the end of each sprint everything that has implemented is demonstrated or even better delivered for use. When you demonstrate and users use the software new requirements will evolve, they might say “When I see this you will need to do this also, otherwise this has no value!” Now the backlog grows and the value of all implemented requirements and all new are higher then what you budget the project from start. But at the same time the things that goes down in the backlog is the requirement that wasn’t prioritized.

The Product Backlog

Conclusion

The trick is not to sell a project that have a “fixed” scope but a project that have fixed budget, time and quality. The thing that is variable is the scope. This way the customer will not get all requirements that they thought when the project was planned but because the customer can re-prioritize whenever he like he will be able to adapt to new knowledge and therefore get the things he appreciate most at the end and within a fixed budget. If the customers would like to implement the requirements that fell out of the budget you can directly give him a price of what it will take to implement them. But often they will have change their mind and realized that those requirements will not produce any business value.  This way it also gets easy to argue for further development that is outside the original budget. If we added requirements that where estimated to 40 hours and they where prioritized higher than something estimated 40 from start, it’s not strange that the first requirement is not done within the budget. If you get 40 hours on something you have to remove something else worth 40 hours. The requirements that will not fit inside the budget will not be implemented or you have a good foundation for a new “offer”. This way the business value of (C) gets greater than the value of (B). Changing your mind when you have acquired new knowledge is just a benefit, a late change in requirement are a competitive advantage.

So hope this answers your questions Hila Annis!