I’m not going into the “is agile compatible with PMBOK” debate now (it mostly is). My interest is in creating maximum value with the software projects I’m involved in, regardless of methodology, framework or whatever you want to call it.

And frankly, “real project management” as defined by PMBOK (Project Management Body of Knowledge) is not impressive with regards to value creation. Let’s take a look.

PMBOK Knowledge Areas

Here’s a list of the PMBOK Knowledge areas, that is, areas in which a project manager should have competence:

Integration Management
Scope Management
Time Management
Cost Management
Quality Management
Human Resource Management
Communications Management
Risk Management
Procurement Management

Put on your Value glasses, and see if there’s anything missing. You’re right!

Value Management

There’s no knowledge area for ensuring that the customer or users gets maximum value, not even that they get something of value – only that they get “something”!

If you have access to an electronic copy of PMBOK, do a search for “value”. The results are pretty depressing.

Frankly, I cannot think of anything more fundamental to a project than that it should deliver value to its stakeholders. It is the very reason for the project’s existence. It should be something the project manager helps happen every day on the project. It should be a knowledge area in itself.

What’s Value Management Anyway?

A Value Management knowledge area should contain everything that is necessary to ensure that the project delivers real value (as opposed to “something”) to its stakeholders. It would probably include something like identify stakeholders, identify their needs (fulfilling those needs represent value), find ways to measure stakeholders needs (i.e. quantify value), identify potential product goals, evaluate product goals vs stakeholder needs, find ways to measure product goals, identify product solutions (or design ideas), evaluate solutions vs product goals, prioritize most valuable solutions, implement, estimate actual value delivered, repeat from “identify product solutions” (or earlier, if necessary).

Basically, I think you could plug in most of Evo, and get a pretty good Value Management knowledge area.

To be fair, you will find many value-related activities and concepts in PMBOK. “Identify stakeholders”, for example, is a process within the Project Communications Management knowledge area. And the Project Statement of Work (input to the “Develop Project Charter” process) references business needs and contains a rough description of the “characteristics of the product” – could be quantified, Evo-style.

So if you really look for it, you will find some value concepts here and there in PMBOK, and some more places where you could plug them in.

However, I don’t think the central issue of “value” should be found “here and there”. It should be blatantly in your face and in the forefront of your mind! It’s more important than Cost Management! It’s more important than Time Management! It’s more important than Scope Management! If we don’t create value, it doesn’t matter if the project is on time and budget – it’s waste nonetheless.

So the PMBOK knowledge areas should be reorganized, with Value Management at a center position.

What about Agile and Value?

I’m an agile enthusiast and practitioner. Is that because agile projects deliver more value? Well, Agile methodologies are generally better at expressing that the purpose of the project is to create value – at least, that’s what we agile enthusiasts are always saying. In practice, agile projects have a tendency to focus on functionality rather than value, means rather than ends, and we are often not even aware that we suffer from a lack of tools to identify and express value.

In short, “Value Management” as a discipline is not – yet – central to agile methodologies either. But I think this issue is growing in the agile community, and I think it will be the next big thing in agile. At least, that’s what I’m working on.

Writing this article, I found this blog post via twitter – also pointing at value driven project management as the next step in the evolution of agile project management. Good one.

I’d really love to hear any thoughts you might have on this issue!

So, just before I started my summer holiday (which I’m in the middle of now), I worked with the other project manager in my department to set up a series of workshops on Team Foundations, each workshop with its own theme. This is what we came up with.

Goals

The first workshop is about Goals. What, as a team, do we want to accomplish? We’re not going to say anything about how, leaving that for other workshops, but we’ll discuss and choose goals – where do we want to go? An example of a goal could be

Satisfied Customers – Our customers shall be satisfied, and they shall be increasingly more satisified. We’ll measure this by asking our customers regularly, and our aim is to always get a higher score than at the previous poll.

We shouldn’t have too many goals, but a few – probably some goals regarding our relationship with the world around us, and some goals about how life should be inside the team.

Values

The second workshop is about Values. Values say nothing about how we should reach the specific goals we have set, but rather what common set of beliefs we share that will guide our work and our actions, regardless of goals. An example of a Value:

Respect – We respect each other. We’re all competent professionals and invaluable people.

As with Goals, there shouldn’t be too many Values, because that may cause each Value to become less significant. I think three to five Values would work well.

Teamwork and Roles

This workshop is a bit different from the others. The focus will be more on team dynamics, and possible formal and informal roles on a team. This particular session will include some social event afterwards. The other project manager will be in charge of this session, so I don’t know too much about it yet.

Principles

Principles are guidelines for how we interact with each others and our customers, on a somewhat more specific level than the Goals. They should support our Goals and our Values. Example of a principle:

We keep our promises – When we’ve made a commitment, we meet that commitment. Always. This will build trust with our customers and trust in ourselves. If it’s something we don’t feel obligated to do, it’s not a promise – it’s a hope or a wish, and we should communicate this clearly to avoid misunderstanding.

Working Procedures

The last workshop may be on Working Procedures, or not – we’ll see how those other workshops go first. But if it’s about Working Procedures, it’s time to get specific on how we, in practice, do some of the stuff we do a lot. An example of a Working Procedure could be

Estimation - We estimate using Planning Poker. We ask the customer to be present. We estimate as soon as a new work item or task appears – we don’t wait until the next Sprint Planning Meeting (or similar).

Note that all of the above examples are for illustrative purposes, as we haven’t done any of these workshops yet. We’ll start them when all of the team members are back from vacation. Even though I definitely have my own ideas about what Goals, Values and Principles we might have, I will do my very best to make sure that the results, whatever they are, are the Team’s results. It simply won’t work any other way.

Looking Forward

I’m looking forward to this, and I’ll keep you posted as the workshops progress. If you have any ideas, comments or criticism, feel free to share them – this is new ground for me, and I could use all the help you can give me.

Now, it’s time for some specific, although simplified, examples. Imagine a clothes shop that also sells through their web site.

Stakeholder Goals

Stakeholder Goals aim at identifying who it is that needs something to be improved, and what that improvement is for them. For example:

Sales Manager Double the revenue from sales through web site within a year after release
Operations Manager Reduce the Operations and Maintenance costs related to this web site by 50 % within a month after final release
Web site editor Reduce effort spent publishing new clothing items by 50 % within a year after release

The point is – identify the major stakeholders and find out what’s valuable for them.

Product Goals

The Stakeholder Goals then need to be transformed into Product Goals – qualities that the product should have in order to fulfill the Stakeholder Goals. Examples:

Product Goal Name: FindItem.Fast
Gist: The user should spend as little time as possible finding the clothing item she wants.
Scale: The time it takes a user to find the clothing item she wants. Average, in seconds.

The important thing is to construct a scale, a way to measure the important qualities, so that the effect of design ideas and implementations can be either estimated or actually measured. Once the scale is in place, we can set a baseline and goal, as well as noting an “acceptable” level, in case we don’t get all we want on all the various Product Goals.

In this example, also note how the focus shifts from simple functionality to a more usability-ish approach, including a usability-like test. Some more examples:

Product Goal Name: Maintenance.ReduceEffort
Gist: Operations and Maintenance costs should be as low as possible
Scale: The time it takes an operator to find and fix a simple error, including stopping and starting the system. Average, in minutes.

Product Goal Name: PublishItem.ReduceEffort
Gist: Editors should spend as little time and effort as possible publishing new clothing items.
Scale: The time it takes an editor to publish a new clothing item, including verifying and possibly fixing appearance on web site. Average, in seconds.

With 10-12 goals like this, we have a really good foundation for steering the project towards creating real value for the customer. Also, keep in mind that the primary use of the goals is to set direction and help prioritize what to do next – it is not to measure success.

Benefits

Now, if we can do this, use the improved Value Process centered on quantified goals, I see at least three huge benefits compared to the standard Product Backlog-centered approach.

1. Everybody knows what is valuable – “value” is made explicit. We no longer have to look behind the Product Backlog, or ask “why” multiple times, in order to figure out what the customer finds valuable. It’s right there, in our face, giving the customer and the developers a very potent tool for evaluating ideas and implementations, prioritizing and basically steering the project in the best possible way.
2. It’s easier to manage the Product Backlog. The Product Backlog is no longer an exhaustive list of functionality to implement that has to be constantly prioritized. Instead it’s a (usually) much shorter list of ideas, all of which are not going to be implemented.
3. We utilize a much larger group of brains to find the good solutions. The customer is no longer alone in her task to find good ways to create value through the project. The developers are no longer limited to just finding good ways to implement a set of user stories. Instead, the customer invites the developers to use their impressive creativity and problem-solving skills to find good ideas for how to reach the goals. The developers go from functionality-implementers to goal-seekers, from implementing means to finding means. Besides resulting in better ways to reach the goals, there are so many positive secondary effects, especially with regards to motivation and collaboration, that one really should not underestimate this benefit.

Summary

In part 1, I looked at three problems with the Product Backlog as a tool for creating value. In part 2, I rose one level and looked at the flawed Value Process centered on the Product Backlog, and proposed an improved Value Process centered on quantified Goals. In this final part, part 3, I gave simple examples of Stakeholder Goals and Product Goals, as well as the benefits to gain from working this way.

References

I did not make up all of this myself (now, there’s a surprise!). The improved Value Process is basically Evo, created by Tom Gilb as early as the 1960′s, and first published in his book “Software Metrics” in 1976. Tom has developed Evo further, working with his son Kai for the past 20 years or so. You should check their web site, www.gilb.com – a treasury of papers, presentations and book chapters and, of course, the authorative source on Evo. The Gilbs are very open with all of their material.

Also, Ryan Shriver has a nice web site called The Agile Engineer, with several good papers and presentations on how this value focus can work with Scrum.

The value process in agile software development projects is flawed, and the Product Backlog is at the center of it. It normally goes something like this:

Flawed Value Process

The customer has some challenges, and starts a project to address them. The project’s goals are formulated – and goals are value statements, explicitly saying what the valuable results of the project should be.

Based on the goals, the customer starts working on the Product Backlog, with its user stories. The user stories, as we saw in part one, are means to reach the projects goals, or ends. In this process, the customer assumes that the user stories she writes are necessary to reach the goals. But there’s no real checking if that assumption is true, if the successful implementation of those user stories does indeed bring the customer closer to the goals.

So this step is basically a one-way process. The goals do not change as a result of creating the Product Backlog, and alternative means (e.g. a different set of user stories) are not considered in any serious way.

Now, with the first Product Backlog established and prioritized, implementation starts with early and continuous delivery of software, checking off from the top of the backlog.

We usually are very thorough in verifying that what we implemented is actually what was asked for in the user story. So this is a two-way process, with evaluation and feedback from implementation to user story.

However, there’s no real evaluation and feedback towards the goals, the value statements! And that is the most interesting part – did we actually get closer to the goals? Ok, so we have the demo where the customer can see what’s been implemented and do some matching in her head and adjust the Product Backlog accordingly. At least, that’s what we hope, but we can’t know. So this is a very weak evaluation and feedback mechanism.

We need something better.

Improved Value Process

This is how I’d like it to be.

The customer has some challenges, and starts a project to address them. Analyzing the challenges, the customer creates goals at two levels. First, she finds out who is it that needs something to be improved, and what improved means for them. These are stakeholder goals.

The customer then translates these into product goals; qualities that the product should have in order to fulfill the stakeholder goals. Both stakeholder goals and product goals are quantified.

Next, the customer and the developers brainstorm various ideas for how to reach these goals, and evaluate those ideas up against the product goals. When we have found what looks to be the best idea at this point, that is, the idea that brings us the farthest towards the goals at the least cost, we start implementing.

Once we’re done implementing, we evaluate the implementation against the goals. What we thought at the previous step is no longer important – the important thing is, did we actually get closer to the goals, and how much? Since the goals are quantified, we can get a pretty accurate picture of where we are at the moment. Also, the implementation may show that some goals should be adjusted, so there’s definitely a learning process involved.

Now, this is all theory so far. In Part 3 I’ll show some examples of what stakeholder and product goals could look like.

Ok, we all want to create value with your software projects. Using agile methodologies is a great way of accomplishing that. But as I’ve gained experience with agile methodologies, I’ve surprisingly found that the Product Backlog is actually hindering us from developing the most valuable software. It’s hugely superior to the standard requirements documents of the Dark Ages, but still – when it comes to creating maximum customer value, the Product Backlog is a hindrance.

I think there are three problems with it.

Huge pile of means

Problem # 1 is that the Product Backlog is a long list of means. It doesn’t state customer goals or customer value, but means. That is, it doesn’t say where the customer wants to be, only how the customer intends to get there. In very small steps, called user stories.

Let’s take a look at a typical user story:

As a repeat user
I can personalise my start page
So that I can get quick access to stuff I care about

That last line hints at a need for a type of user. However, it says nothing at all about why the customer would want to spend money, time and energy on developing, testing and deploying this functionality. Fortunately, good agilists habitually use this important question:

Why?

So, when discussing a user story with the team and the customer, we ask “why” – often multiple times – to work our way backward from the user story itself to the reason for it – the customers’s goal with it, why the customer values it. In this case it might be that the customer has a problem with users not returning, and it would be valuable to the customer to get the users to come back (and possibly spend more money there) - and this user story is one of several means to accomplish that.

Now, when the goal is found, we then ask “Now, is there a better way to reach this goal?”, possibly resulting in a different set of user stories.

But this is quite a backwards way of discovering the customer’s goals. If we want to create maximum value, there must be a better, more direct way.

Huge pile of means

Problem #2 with the Product Backlog is that not only is it a pile of means; it’s a huge pile of means. Imagine a Product Backlog with 500, 200 or even just 100 user stories. It’s quite difficult to look at a Product Backlog that size and figure out where the value is. Also, it gets increasingly difficult to apply the “why” question as the Product Backlog increases in size.

Focuses on functionality

The third problem with the Product Backlog is that it focuses on functionality. A Product Backlog consists of user stories, and the user stories describe what somebody can do with the system, the system’s functionality. But

It’s not about the functionality!

Let me repeat that, just to make sure it’s not misunderstood:

It’s not about the functionality!

Think Twitter, or Google Docs. They didn’t succeed because of loads of functionality. Or let’s use a replacement project as an example. The reason for the replacement project is not that the customer wants more or better functionality. (Even though we sometimes add that as a goal, probably to make it more likely the project will fail.) The reason is usually something like

“This system is running on crap software and crap hardware. We need something better, or else…”

And if we analyze that, we find that the reason for the project is that

Something needs to be improved for somebody.

I believe that’s true not only for replacement projects, but for all projects, including those we software people are often involved in – product development or product improvement. And then we better start by figuring out who these somebodies are, and what this something is, and what improved means.

We’ll explore the value process further in Part 2.

The first factor is that there are plenty of very good managers and leaders in Steria.

In fact, the prospect of working with Remi Hansen, department manager of the then newly formed Project Management Department, was what made me consider joining Steria in the first place. Remi certainly didn’t let me down. Throughout these years, Remi has consistently displayed integrity and courage mixed with a thorough understanding of the field of Project Management. He’s always treating people with respect, even at moments when someone is basically a pain in the butt – which I know I’ve been sometimes. Remi is now heading Knowledge Management for the Scandinavian group in Steria, and I’m certain he’ll rock there, too.

Inga K. Nordberg is taking leadership in the Project Management Department after Remi. She certainly has a different personal style from Remi, but her leadership is rock solid, instilling confidence and trust, and she’s doing a great job.

Remi and Inga have been my closest managers in Steria. When these are the ones I mention, it doesn’t mean I think less of the other leaders and managers in Steria. In fact, every single one of them that I have interacted with at one time or another, come across as very nice people and really good managers and leaders.

The second factor that has contributed to my enjoying the Steria time, is the Steria culture. In the Steria culture, you’re actually allowed to voice unpopular opinions, and to make mistakes. The basic premise, so ingrained in the walls here, is that we are competent people with good intent and integrity doing our best to satisfy the customer and do what’s right! In Steria, your opinions are evaluated based on the soundness of what you’re saying, not where you are in the “hierarchy” or who you know.

Steria is also contributing to the society. Though I’ve not been involved in it, I think Steria should be especially proud of the computer courses for immigrant women held in Steria’s offices by Steria employees in their spare time. These courses help the women getting familiar with computers and the internet, breaking down many barriers to meaningful participation in the Norwegian society.

Last, but not least – the great colleagues I’ve had here. It would be unfair to mention anyone above others, so I won’t. I’ve learnt so much from my colleagues, and many of them continue to impress me to this day. In general, my colleagues have a good time doing their job, and are always willing to help each other out and learn from each other.

So, no grudges, no frustrations? Grudges, no – frustrations, yes. But considering I’ve been here for more than three years, the frustrations are surprisingly few and small.

So, thank you, Steria! It’s been a great time!

Tomorrow I’m joining Statkraft, Europe’s largest renewable energy company – as an IT project manager. There are several reasons I’m starting there. One is that I’m going to be working with Christian Hauknes, a person I really respect. We get along quite well on all professional matters, and I’m excited to discover what we can accomplish together! Another is that Statkraft is in an extremely important business. I mean, kind of linked-into-the-whole-future-of-this-planet-important. Energy, and especially renewable energy, isn’t going to go out of fashion anytime soon. A third is that I have lots of ideas on what the customer side of projects should be doing, and as a consultant, I’ve only had very limited influence on this most important part of projects. Hopefully, now I’ll be able to put more of those ideas into practice.

All in all, though, I know very little of what the future in Statkraft will bring. It must be really good to top Steria, but evidently, I’m optimistic in that regard!

So, leaving Steria, joining Statkraft. Life’s exciting.

So the thing that clicked is this:

The most important things for a good presentation is that the presenter is seen as honest and passionate about his subject. The best way to accomplish this, is to actually be honest and talk about something that I’m passionate about (imagine that!). This is nothing new, I think.

Previously, though, in my attempts at creating good presentations, I’ve focused on building a logical, un-attackable line of argumentation that naturally and un-attackably leads to my conclusion.

But there’s nothing personal in logic! No personal honesty, no passion or any other emotion in it! I’m not even sure I can tack honesty and engagement on top of a logical presentation. Even though I’ve mostly been passionate about the subject I’m presenting, my presentations have been so rational that the passion simply wasn’t let out to play.

Furthermore, Thinking about this, I realized this follows from the process I use to create my presentations. Figure out the main point. Brainstorm elements I want. Create logical groups out of those elements. Find a good structure for the presentation. Work explicitly on the opening and closing sentences. All logical and good.

Using a logical process is a good way to create a logical presentation. It does not work well – for me, at least – when I want  to create a passionate presentation.

So today I took a totally different approach. I simply started writing my thoughts, trying not to censor as I wrote. Getting my words on paper, never mind incoherency or poor choice of words, and then I can start verbalizing, adjusting, making something coherent from it. Starting from a badly written, but honest and passionate text, rather than using the logical process I’ve used previously.

Incidentally, this can be seen as parallells to different ways to approach projects. The logical process I’ve used is in many ways similar to a waterfall approach, whereas the creative, iterative approach is much more similar to an agile approach.

But wait, there’s more! I started by focusing on the qualities – honesty, passion – instead of focusing on the “requirements”; the points I wanted to make. Then I chose a process that supports those qualities. This corresponds just nicely with the theme of the presentation I’m creating.

I’m excited as to what this will result in. XP 2010 is my first presentation for an international audience. It must be good.

Customer collaboration over contract negotiation

- implicitly saying that “we” are not the customers.

To reap the largest benefits of agile philosophies, the customer side of projects also need to work in an agile manner. This involves more than providing the developer teams with a Product Owner. The customer side of a project doesn’t only have to work with the developers, but also their own organization and other stakeholders. Most importantly, the customer side of a project has to figure out what goals the product should reach in order to create real value to the stakeholders.

So, I wonder, what would the agile manifesto have looked like if it was created by customers instead of suppliers?

Here’s my take.

Agile Values

We are uncovering better ways of running software projects by doing it and helping others do it. Through this work we have come to value:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Delivering stakeholder value over completing features
• Collaboration with suppliers and organization over contract negotiation
• Responding to change over following a plan

Agile Principles

(Note: In the following, I’ve left the original principles in  so that you can easily see the similarities and the differences.)

We follow these principles:

• (NEW)
  There is no use in doing things right if we don’t do the right things. We must continuously work with our organization and our end users to figure out what the right things are.
  
  
• Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
  Our highest priority is to create value for our stakeholders through early and continuous delivery of software.
  
  
• Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
  Welcome changing requirements, even late in the project. Agile processes harness change for our organization’s competitive advantage.
  
  
• Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
  Deliver valuable solutions frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
  
  
• Business people and developers must work together daily throughout the project.
  We must work together with the stakeholders and the developers continuously throughout the project.
  
  
• Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
  Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
  
  
• The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
  The most efficient and effective method of communication is talking face-to-face while visualizing the subject on paper or whiteboard. Use other means only when their added value is greater than their added costs.
  
  
• Working software is the primary measure of progress.
  Value realized by the stakeholders is the primary measure of progress.
  
  
• Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
  Agile processes promote sustainable development. The sponsors, stakeholders and developers should be able to maintain a constant pace indefinitely.
  
  
• Continuous attention to technical excellence and good design enhances agility.
  Continuous attention to high technical quality enhances agility.
  
  
• Simplicity–the art of maximizing the amount of work not done–is essential.
  Simplicity–the art of maximizing the amount of work not done–is essential.
  
  
• The best architectures, requirements, and designs emerge from self-organizing teams.
  The best solutions emerge from self-organizing teams with clear goals.
  
  
• At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
  At regular intervals, all parties reflect on how to become more effective, then tune and adjust their behavior accordingly.
  

Conclusion

I have stayed close to the original values and principles – perhaps too close. Staying close to the original may be of value – it sort of gives the customer and supplier side a common ground. But it may also mean that I miss something important. However, it’s not my intention here to write a totally new manifesto (how could I?), but rather play around with the “what if…” and maybe learn something valuable about the differences between developer and customer perspectives.

What do you think?

(This article can also be found in Norwegian at Sterk Blanding, Steria Norway’s blog. Thanks to my reviewers Johannes, Eli and Simen for improving this article.)

First, here’s the main data for the project as outlined in Part 1:

• It is scheduled to last for 12 months
• During that time it costs 5 million USD
• The resulting product will provide a financial benefit of USD 200,000 per month (extra revenue or saved costs minus any monthly expenses), until
• The product abruptly stops producing its benefit 4 years after the project is started. You may say there’s a 4-year window of opportunity for this particular product.
• (I also assume a 10 percent discount rate in the NPV calculations)

Baseline: Waterfall As Planned

We’ll reuse the baseline project from Part 1. If all goes according to plan, the product is released after 12 months and will generate 36 months x USD 200,000 = USD 7,200,000. The project will have cost 5,000,000. All in all, a nice net profit of 2,200,000.

This is what the cash flow will look like:

Yikes! A Four Month Delay

The alarm goes – the project is going to be 4 months delayed! Suddenly, the project doesn’t look so good…

The product, when released, doesn’t bring any less benefit on a monthly basis. However, it starts producing the benefit four months later and is still abruptly put out of production four years after the project started. What’s more, the development of the product is more expensive. Net effect? The value of the project, NPV, is negative. The initial investment is never paid back. The project is no longer financially sound.

Frequent Releases to the Rescue

Let’s say we’ve already managed to prioritize the functionality and that 20% of the functionality provides 80% of the value. Also, say we’re sticking to a “release every 3 months” strategy. Will that save a project that isn’t proceeding as fast as it should? In this example case: Yes!

As we can see, the project is turned from a waste of money into something profitable. Even though the total delay still hits us, the early release means we start to get some benefit early, and the project doesn’t look so grim. In fact, the “frequent release” project with a four month delay is nearly as profitable as the waterfall project would be without any delays! How’s that for a risk reduction strategy?

In the next article, which might be viewed as part 3 of this series, I’ll take these concepts to their logical endpoint: What if we only develop and release the 20% most valuable parts of a product, and then move on?

I use some terms that you may or may not be familiar with: NPV (net present value), IRR (internal rate of return), payback period and ROI (return on investment). You’ll find these terms explained briefly towards the end.

Now, on to the juice.

(Note: The following calculations are technically correct – but if you find any errors anyway, be sure to let me know

Our Fictional Project

First, let’s imagine a project:

• It is scheduled to last for 12 months
• During that time it costs 5 million USD
• The resulting product will provide a financial benefit of USD 200,000 per month (extra revenue or saved costs minus any monthly expenses), until
• The product abruptly stops producing its benefit 4 years after the project is started. You may say there’s a 4-year window of opportunity for this particular product.
• (I also assume a 10 percent discount rate in the NPV calculations

You may download the spreadsheet used for the calculations and graphs (Excel 2003 format)

Waterfall: The Baseline Project

I want to have a waterfall project as a baseline. If all goes according to the waterfall plan, the product is released after 12 months and will generate 36 months x USD 200,000 = USD 7,200,000. The project will have cost 5,000,000.  All in all, a nice net profit of 2,200,000.

This is what the cash flow will look like:

A reasonably good project, I think most of us would agree on.

One interim release

Now, instead of releasing after 12 months, let’s have an interim release after 6 months that realizes half of the value, i.e. it generates a financial benefit of USD 100,000 per month for six months until the final release that realizes all of the value:

Amazing! We didn’t change a thing in the product itself, we only added an interim release containing half of the value we eventually will have – and that increased the value of the project, NPV, from USD 920,000 to USD 1,477,000 – a 60% increase!

Release every 3 months

Hmm, maybe even more releases would be even better? Let’s see what it would look like if we released every 3 months, with each release realizing an incremental quarter of the value:

By doing this one, single thing; releasing every 3 months instead of once after 12 months, we nearly doubled the value of the project! We also see that the increase in return is diminishing when we release more and more often. With a costly release process, there is a limit to how often one should release. However, if you streamline the release process…

Prioritize the functionality

So far we’ve assumed that all released functionality has equal value. But what if this isn’t true? What if some functionality has higher value than other functionality? And that we can prioritize, so that the most valuable functionality is released first?

Just to put numbers on it, let’s assume that 20 percent of the functionality represents 80 percent of the value. This may sound overoptimistic, but it’s kind of a magic rule and it illustrates the point I’m trying to make:

From applying these two, simple principles: Prioritize and release often, we’ve increased the value of the project from a baseline NPV of USD 920,000 to USD 2,420,000. Even though the product itself has the same value as before, the value of the project is 2,6 times the baseline value!

In part 2 of CFO’s Case for Frequent Releases, we’ll take a look at what happens when things don’t go exactly according to plan…

Spreadsheet used for calculations

Download CFO case for frequent releases – spreadsheet (Excel 2003 format)

Brief explanation of terms

Payback period: If you invest something now that will give you a return in the future, how long does it take until you have recouped your original investment (disregarding the time value of money)? This is the payback period. For more, check Wikipedia on payback period.

ROI (Return On Investment): There are various definitions and formulas for calculating ROI. However, the main point is always: What’s the payback related to the investment?  In this article I’ve used the simple single-period formula (Return – Investment)/Investment – a much-used variation of ROI. For more, check Wikipedia on ROI.

NPV (Net Present Value): The main point is that a dollar today is worth more to you than a dollar a year from now, and even more than a dollar five years from now. If you are able to put, say, 100 dollars to use so that you can get 110 dollars back in one year, then the NPV of getting 110 dollars one year into the future is 100 dollars. In the article, I’ve applied this concept to the future cash flow to generate the entire project’s NPV. To generate the NPV of a cash flow, you must decide on a discount rate that should reflect how much return you would normally expect to get from an alternative investment with the same risk profile. In the article I’ve simply used 10 percent as the discount rate. For more, check Wikipedia on NPV.

IRR (Internal Rate of Return): Given a time series of cash flows and a discount rate, we can calculate the NPV. The NPV is affected by what discount rate we use. By using a specific discount rate, the NPV will be 0 – zero. This is the IRR – the interest rate we can use in the NPV calculations that will result in a NPV of 0. For more, check Wikipedia on IRR.