Thursday, July 27, 2017

No validation? No project!

Project Business Case Validation
For large or high risk projects (what is large depends on your organization) it should be mandatory to do business case validation before you dive head on in executing the project. In the Project Portfolio Funnel of the Agile Project Portfolio Management Framework you will see a phase that is called "Validation" after selection of a project has taken place. In this phase you typically have a business case validation and/or a technical validation in the form of a proof of concept. This article will be about the project's business case validation.

Project portfolio management is about doing the right projects. And as Peter Drucker has said many times:

Nothing is less productive than to make more efficient what should not be done at all.


Jon Lay and Zsolt Kocsmárszky from Hanno have defined a process for lean product validation at https://leanvalidation.hanno.co/. I used their process as a base for business case validation for projects.

We will distinct between four different kind of validations. Depending on the project that you want to validate the business case for you do only one, two, three or all four of them. When your project is about launching a new product or service I would advise to do all four validations before executing the project. The results of these validations form your business case validation. Or the opposite of course, they can show you that you should not do this project as well.

1. Validate the problem: Is this a problem worth solving? If users don’t think this is a Major problem, your solution won’t be appealing.

2. Validate the market: Some users might agree that this is a problem worth solving. But are there enough of them to make up a market for your product or service?

3. Validate the product/service/solution: The problem might exist, but does your product/service/solution actually solve it?

4. Validate the willingness to pay: there might be market demand and a great product or service. But will people actually be willing to reach into their wallets and pay for it?

As you can see these validations focus on the introduction of a new product or service for your clients. But you can easily reframe them for all of your projects. Your market can be your employees instead of customers. For example when you think about implementing a new CRM, but only a very small but vocal number of users see the benefit of it, and are actually quite happy with what they currently have your market is too small. Or how about the willingness to pay for the accounting department for a new solution that triples the yearly operational costs?

You can decide per project which validations make sense, and what row order makes sense. For example in some cases it can be much harder to build a prototype (to validate the product or service) than it would be to build a landing page (to validate market demand).

But by working through these validations, you’re sure to receive heaps of feedback from potential users and stakeholders. With this deeper understanding, you might realize that it makes no sense to do this project, or you might realize there’s a bigger opportunity to tackle. In this case, you should feel free to pivot your project idea!

Validate the problem

No matter how confident you are in the project idea, you first need to figure out whether the problem is a real one that needs solving. To do this, your best option is to talk to potential users and stakeholders directly. The focus here is on getting qualitative validation of the project idea.

First, you start with a small number of properly sampled, representative users and verify that the problem exists for them. Then, you optimize and verify this later on with more users and at greater scale. Have a look at our artcile about jobs to be done on how to frame and discuss the problem with users.

The learning you take from these interviews will give you the confidence you need to move the idea forward. Or it’ll show you that you need to pivot the idea as you learn more about the real underlying Problems.

Validate the market

Once you’ve spoken with users and validated that the problem exists, you need to make sure the market is large enough to justify taking the idea further. Where will your users come from, and how much potential revenue or savings lies in the market opportunity? In other words, what is the potential value of the project.

By gathering as much information as you can about the potential market, you’ll be able to make an educated guess as to the size of your target audience and the number of customers you can acquire. It will also help you to figure out a possible pricing structure for the product or service, which will be valuable as you start to make other financial projections.

Here are a couple of tools you might use to validate the market for your product or service:

- Google Trends allows you to compare the relative volume of search terms. It shows you how demand for each term has changed over the last 12 months.

- Google AdWords’ Keyword Planner reveals the average monthly searches for a given keyword. It also gives you an estimate for competitors and suggested bids. Using this data, you can estimate how much traffic you can drive to your website using Google AdWords paid ads or by reaching the top of search engine results.

- Deep competitor research enables you to understand how your future competitors are trying to solve the same problem. If you’re focusing on a small market, finding just one competitor might be enough. But if you’re focusing on a bigger market, search for more, at least three. Besides searching for direct competitors, look up those that offer similar products and solutions. Then, find out as much as possible about them. Crawl their profiles, read their blogs, look for media coverage. Learn about the size of their team, pricing structure, finances and product features.

If you can’t find any competitors, then most likely you’ve either missed something in your research or you’re working on a problem that doesn’t really exist. There’s an exception, however. If you’re starting up a very small niche business, there’s a chance you don’t have any competition… yet.

Another area to look at when conducting competitor analysis is companies that might attempt to move quickly into a new product or service area when competition arises in their market. While this isn’t of immediate concern, it pays to roughly identify fast followers who might step up to offer a similar product to yours to win the market. This will help you to prepare and come up with a plan to handle the situation should it arise.

Validate the product or service

There’s only one way to make sure your product or service solves the problem you’re focusing on: to get your hands dirty and build a prototype. It doesn’t matter if you don’t have much technical experience, you don’t need an engineer to build a great prototype. Instead of choosing expensive and time-consuming prototyping techniques, keep things lean.

Once you’ve built the prototype, you’ll begin to run tests with users to gather feedback and learn from them as much as possible. Finding people around you to be test subjects is a great starting point. Ideally, look for users in your target audience. However, in the very earliest stages of testing, you can get useful feedback just by grabbing people around you and running simple tests.

Once you learn more from these quick tests and potentially iterate on your product or service, taking into account the feedback you gather, you can move on to more structured tests with your target audience.

The goal of product/service validation, whether remote or in person, is to make sure that your product or service is solving the right problem in the most effective way. It’s highly unlikely that you’ll manage to do this perfectly the first time around — but that’s perfectly fine! Iterations, tweaks and pivots are a natural part of the product validation process and are one of the reasons why prototyping is such a valuable technique.

Validate the willingness to pay

There are many ways to validate willingness to pay, but one of the big challenges is that we can’t necessarily trust people’s words. We all know those people who say “Of course, I’d totally buy that!” but who then drop out when the time comes to commit. As far as possible, we want to get people to put money behind their words.

A single-page website is already adequate for validation, especially as a first step. But if you want to gradually iterate and add more pages and content to increase fidelity and learn more, that’s an option, too.If you have the technical resources you could design and code this yourself, but most companies are better off using a template website builder. You’ll want to include following elements in your simple website:

- Explain what your product or service does, clearly and concisely.

- Highlight the product or service’s unique selling points.

- Address any key concerns that users had during testing. If they were worried about security, performance or comfort, explain your solution.

- Add a direct call to action to bring users to the checkout and payment part of the website. This should be clear and unequivocal — something like “Buy now for $99!” or "Sign up for early access!".

- Make sure the payment page has an email collection form, so that you can gather the addresses of prospective customers.

- Instead of confirming the user’s order, you should show them a “Sorry” page that explains why you’re conducting the experiment. This way, they won’t have false expectations about receiving the product.

- Run analytics on the website to track how people are interacting with it. Google Analytics is simple and free.

Once the validation website is up and running, you’ll need to drive traffic to it. Be a little cautious about doing this within your network of long time clients and colleauges. You don’t want to fall into the trap of collecting false positives, people who sign up just because they know you personally. The best technique for bringing unbiased traffic to a validation website is to spend some money on Facebook Ads or on a simple Google AdWords campaign.

Facebook and Google AdWords have robust targeting possibilities that let you showcase your solution to the right audience, which you would have identified in the “Validate the problem” phase. You can also further optimize your ad by factoring in data from your initial ads, such as number of clicks, likes and shares received and the location of people engaging with it. Getting started with an ad campaign on Facebook or Google AdWords is pretty straightforward.

What’s next?

Even if you validate your project's business case, your project isn’t guaranteed to succeed. The process of validation is just the start. But if you’ve worked through the relevant validations, you’ll be in a far better position to judge if you should stop, continue or change your project.

The goal of the validation phase is to delay the expensive and time-consuming work of projects as late as possible in the process. It’s the best way to keep yourself focused, to minimize costs and to maximize your chance of a successful project.

The Agile Project Portfolio Management Framework

Based on this article series I have written The Agile Project Portfolio Management Framework Guide. Besides this guide, I have written many more articles on Agile Project Portfolio Management. You can find those here.

Workshop Agile Project Portfolio Management

When you want to learn more about Agile Project Portfolio Management then join one of our workshops on this topic.

Read more…

Wednesday, July 26, 2017

When is your Project Backlog Item "Ready" for selection?

As defined in the Agile Project Portfolio Management Framework Guide, the Project Backlog is an ordered list of all projects that might be needed in the organization and is the single source of projects for any changes to be made in the organization. The Portfolio Owner is responsible for the Project Backlog, including its content, availability, and ordering.

The Project Backlog lists all projects, ideas, proposals, enhancements, and fixes that constitute the changes to be made to the organization in the future. See my article on Demand Management for ideas on how to collect all these ideas.

 A Project Backlog is never complete. The earliest development of it only lays out the initially known and best-understood projects. The Project Backlog evolves as the organization and the environment in which it operates evolves. The Project Backlog is dynamic; it constantly changes to identify what the organization needs to be appropriate, competitive, and useful. As long as an organization exists, its Project Backlog also exists.

Project Backlog refinement is the act of adding detail, estimates, and order to items in the Project Backlog. This is an ongoing process in which the Product Owner and the PMO Team collaborate on the details of Project Backlog items. During Project Backlog refinement, items are reviewed and revised. The Portfolio Team decides how and when refinement is done. Refinement usually consumes 50% of the capacity of the Portfolio Owner and PMO Team. However, Project Backlog items can be updated at any time by the Product Owner or at the Product Owner’s discretion.

Higher ordered Project Backlog items are usually clearer and more detailed than lower ordered ones. More precise estimates are made based on the greater clarity and increased detail; the lower the order, the less detail. Project Backlog items that will occupy the Portfolio Team for the upcoming Portfolio Cycle are refined so that any one item can be decided on within the Portfolio Planning Meeting. Project Backlog items that can be decided on by the Portfolio Team within a Portfolio Planning Meeting are deemed “Ready” for selection in a Portfolio Planning. Project Backlog items usually acquire this degree of transparency through the above-described refining activities.

The Project Backlog Item

Depending on your organization and your portfolio you will need different information for your Project Backlog Items to make the right decisions. But my experience has shown that the list below will give you a good start.

Sponsorship
Who would be the project sponsor?
Finance
What are the estimated costs? Estimate the following:  
1. Project costs: internal and cash out
2. Yearly operational costs
3. Total Cost of Ownership for 5 years (or shorter when the life expectancy of the project result is shorter)

As explained in our article on Categorization the most effective estimates for the Project Backlog are Range Based Estimates.
Driver
What business problem does the project solve?
Strategy alignment
Which strategic goals does this project align with? See the article on Categorization on how to link project backlog items with strategy. Add regulatory/compliance and operational as option as well.
Risk
Describe what is the impact of not doing this project?
Describe what is the risk of doing this project?
Give one risk valuation High, Medium, Low for use in the risk-value portfolio bubble chart.
Benefits
What is the value of this project to the organization. Express in CHF as well describing in text. List the expected benefits.
Success metrics
How will we measure success? For example:

- Stakeholder satisfaction
- Customer satisfaction
- Quality delivered to customer
- Return on Investment
- Meeting business case objectives
- Customer adoption
- Meeting governance criteria
- Benefits realization

Full scope, on time and in budget has nothing to do with success! It just tells you something about the ouality of your estimations, not the results of your project.
Culture
Is the organization culture right for this kind of project? Describe and give a valuation Yes or No. 
Technology
Do we bring in new technology inhouse or do we build with and upon existing technology? Describe and give a valuation. A categorization that I have used many times is the following: 1) Technology exists in the organization, 2) Technology is easily acquired, 3) Technology is hard to acquire, 4) Technology needs to be created, 5) No technology needed
Approach
Would we buy or make?
Time criticality
Should it be executed in a certain timeframe in order to give benefits? Describe and give a valuation Yes or No.
Client Impact
Would there be a lot of change for our clients? Discontinuing a service could have a very high impact for some Clients. Describe and give one valuation High, Medium or Low.
Employee Impact
Would there be a lot of change for our employees? For example, a new ERP system would have a very high Impact. Describe and give one valuation High, Medium or Low.
Training
Will staff training be required? Add to costs!
Portfolio
How does this project links to other projects in the portfolio? Dependencies? Shared platforms? Double work? Describe.

The moment you have collected the information above you are "Ready" for evaluation and possible selection of this project for you portfolio.

The Agile Project Portfolio Management Framework

Based on this article series I have written The Agile Project Portfolio Management Framework Guide. Besides this guide, I have written many more articles on Agile Project Portfolio Management. You can find those here.

Workshop Agile Project Portfolio Management

When you want to learn more about Agile Project Portfolio Management then join one of our workshops on this topic.

Read more…

Monday, July 24, 2017

The Agile Project Portfolio Funnel

When you look at the project portfolio funnel of the Agile Project Portfolio Management Framework (APPMF) it looks like the diagram below. Like I explained in previous articles, this is not greatly different from how PMI defines the project portfolio funnel. What is greatly different, is how you manage your funnel. APPMF is a framework within which people can address complex portfolio management problems while productively and creatively delivering projects of the highest possible value. The APPMF works well with any project delivery method. From Scrum to Waterfall, and anything in between.
So lets walk through this funnel step by step to understand the dynamics of a project portfolio funnel. For this example we will start with an empty funnel at timepoint X. We will follow the suggestion of the APPMF Guide and have monthly portfolio cycles. At timepoint X we have a bunch of project ideas on our Project Backlog. These ideas are collected by the demand management process.
These eight ideas will be categorized and afterwards evaluated. During categorization or in the evaluation phase ideas can be removed from the Project Backlog for reasons as described in the linked articles. In short: when it is clear there is no value in the idea at this point of time it will be marked as such and removed from the project backlog.       
At a portfolio planning meeting the remaining ideas have the chance of being selected for validation. When they are selected for validation the ideas are placed on the Portfolio Backlog and additional information will be gathered. This can be a business case validation or a technical proof of concept.
On succesful validation the execution phase of the project will start. Duration of the validation phase can be different for each project, depending on the needs and accepted risk. In the funnel below you see that two projects are still in the validation phase, and for one project the delivery phase has started.
Ofcourse one result of the validation phase can be that the project will not be executed. This is shown in the funnel below. One project continuous to the delivery phase and is joing the one that was allready started, and one project is stopped.
When all goes well the project (or parts of it) will be delivered and you can start monitoring its benefits. When it does not go well or the priorities of the portfolio have changed the portfolio comittee can decide to stop a project as well in a portfolio review meeting. Both are shown in the funnel below.
After a while of monitoring the benefits (or lack of them) you then do a project retrospective. This is essential for learning and improving within the organization. But like I said, this retrospective only make sence after a phase of benefits monitoring and not directly after closing of the project.
The above example of the project portfolio funnel is ofcourse extremly simplified because in reality new ideas will come in on an ongoing base, and every portfolio cycle new ideas need to be evaluated and could be selected.
The duration of the phases after evaluation can span between one and many portfolio cycles.
Projects will be delivered, and new ideas keep on coming in.
Benefit monitoring starts, and still new ideas keep on coming. Which is a very good thing. When you run out of ideas your portfolio quality will suffer greatly.

So after a while of running Agile Project Portfolio Management your funnel will look like below. And that is why transparency and backlog management are essential for managing your portfolio. Displaying this funnel in the form of a Kanban Board is a great start.

The Agile Project Portfolio Management Framework

Based on this article series I have written The Agile Project Portfolio Management Framework Guide. Besides this guide, I have written many more articles on Agile Project Portfolio Management. You can find those here.

Workshop Agile Project Portfolio Management

When you want to learn more about Agile Project Portfolio Management then join one of our workshops on this topic.

Read more…

Thursday, July 13, 2017

No more user stories! There are jobs to be done

Creating new and better products that thousands or millions of customers actually love is a top priority for almost every company. Agile frameworks and techniques have been hailed as a solution for exactly this problem. It started with eXtreme Programming (XP), where a conversation between the development team and the customer is the base for all requirements. And in theory this is the way to go, right? But there are two issues with this line of thinking. The first is that it does not work for start-ups and new products were it is not clear yet who the customer is - the Lean Startup Methodology from Eric Ries is based around this fact. And the second issue is something Clayton Christensen has discovered.

Clayton Christensen, the famed Harvard Business School Professor known for coining the term “disruptive innovation”, believes that one of his most enduring legacies will be an idea he first put forward in his 2003 book "The Innovator’s Solution": don’t sell products and services to customers, but rather try to help people address their jobs to be done. This seemingly simple idea has profound implications for re-framing industries and products. 

Never have companies known more about their customers. Thanks to the big data revolution, companies now can collect an enormous variety and volume of customer information, at unprecedented speed, and perform sophisticated analyses of it. Many firms have established structured, disciplined innovation processes and brought in highly skilled talent to run them. Direct access  to customers is not a problem, and customers are more then willing to voice there opinion on social media or interviews.

So why is it still so difficult to get products right, and actually have a market for them?

The fundamental problem is, most of the masses of customer data companies create is structured to show correlations: This customer looks like that one, or 68% of customers say they prefer version A to version B. While it’s exciting to find patterns in the numbers, they don’t mean that one thing actually caused another. And though it’s no surprise that correlation isn’t causality, Clayton Christensen and his team suspect that most managers have grown comfortable basing decisions on correlations.

Why is this misguided? Consider the case of myself. I am 36 years old. I am 1.74m tall. My shoe size is 43. Me and my wife have one child. I drive a Volvo CX60, and go to work by train. I have a lot of characteristics, but none of them has caused me to go out and buy my new Salomon trail running shoes. My reasons for buying these shoes are much more specific. I buy it because I need shoes to run in the mountains and my previous pair were not giving enough support anymore after running to much kilometer on them. Marketers who collect demographic or psychographic information about me—and look for correlations with other buyer segments—are not going to capture those reasons.

After decades of watching great companies fail, Christensen and his team has come to the conclusion that the focus on correlation—and on knowing more and more about customers—is taking companies in the wrong direction. What they really need to home in on is the progress that the customer is trying to make in a given circumstance—what the customer hopes to accomplish. This is what he has come to call the job to be done.

We all have many jobs to be done in our lives. Some are little (pass the time while waiting in line); some are big (find a more fulfilling career). Some surface unpredictably (dress for an out-of-town business meeting after the airline lost my suitcase); some regularly (pack a healthful lunch for my daughter to take to school). When we buy a product, we essentially “hire” it to help us do a job. If it does the job well, the next time we’re confronted with the same job, we tend to hire that product again. And if it does a crummy job, we “fire” it and look for an alternative. (I am using the word “product” here as shorthand for any solution that companies can sell; of course, the full set of “candidates” we consider hiring can often go well beyond just offerings from companies.)
Jobs-to-be-done theory transforms our understanding of customer choice in a way that no amount of data ever could, because it gets at the causal driver behind a purchase.

If you didn't have the opportunity to listen Prof. Clayton Christensen presenting the jobs to be done concept, or to read his latest book "Competing Against Luck", please invest a few minutes in listening to his milkshake example story.


So what has this to do with user stories?

In the Agile world we make the same mistake! We focus on persona and/or roles. Instead of the job that needs to be done. Another problem with user stories is that it contains too many assumptions and doesn’t acknowledge causality. When a task is put in the format of a user story ( As a [persona/role], I want to [action], so that [outcome/benefit] ) there’s no room to ask ‘why’ — you’re essentially locked into a particular sequence with no context. Alan Klement from https://jtbd.info/ puts it very nicely in an Image.


Job stories slightly revise the format to be less prescriptive of a user action, and thereby give more meaningful information for the designer and developer to build for the user’s expected outcome.


Here are a few examples of the same feature story in user story and job story format:

User Story: As a subject matter expert, I want a badge on my profile that when I am a top poster, so people know I am a top poster.

Job Story: When I am one of the top posters for a topic I want it to show on my profile so that people know that I am an expert in a subject.

User Story: As a visitor, I want to see the number of posts in a topic for another user, so I can see where their experience lies.

Job Story: When I visit someones profile page I want to see how many posts that they have in each topic so that I have an understanding of where they have the most knowledge.

User Story: As a tax specialist that has used the application multiple times, I should get an alert to contribute

Job Story: When I have used the application multiple times I get nudged to contribute so that I am encouraged to contribute.

There is a very slight but meaningful difference between the two. By removing “As a __ ” from the user story, we remove any sort of biases that the team might have for that persona. Personas create assumptions about the users that might not be validated.

In my experience, user stories have a tendency to be easily manipulated to proposing a solution rather than explaining an expected outcome for that particular user. In particular, I’ve found people leave off the “so that __” in a user story with the feeling that it is optional. This leaves off the benefit that the user would get from adding new functionality.

In a job story we replace “As a __ ” with “When __ ”. This gives the team more context for the user’s situation and allows us to share his or her viewpoint. Next, the “I want to __” is transformed into situational motivation in the job story, as opposed to a prescriptive solution for a persona in the user story.

Because the differences in wording are negligible, it is an easy transition to shift from writing user stories to job stories. By placing the user’s situation upfront, you have a better understanding how it feels to be in the user’s shoes, as opposed to thinking about a particular persona. This allowed for more discussion of the expected outcome and how to best go about achieving said outcome for the user. Which in the end will result in a better product.

Read more…

Sunday, July 02, 2017

Kanban - Card, Board, System or Method?

Kanban Card, Board, System or Method?
Kanban is a term that can mean many things. Two people talking about Kanban usually have different levels of understanding and thinking about it. Is it a card, a board, a manufacturing system or a software development method? The short answer is – Kanban is all of them. Kanban means literally both card and board. The word ‘kanban’ has its origin in both Hiragana (Japanese language) and Kanji (Chinese language). In Hiragana, it means a ‘signal card’ while is Kanji it means a ‘sign’ or ‘large visual board’.

Kanban System

Beyond the etymology, ‘Kanban’ as a concept was popularized by Toyota in the 40’s who took inspiration from how supermarkets stock their shelves and promoted the idea of Just-in-Time manufacturing – using ‘Kanban Cards‘ as a signal between two dependent processes to facilitate smoother – and just in time – flow of parts between them. With time, the idea of Kanban evolved to be more than just a signal card. First in the manufacturing world, and now in IT industry, a ‘Kanban System’ is characterized by two key features:

1. Visualization of work items – using signal cards, or some other means.
2. A pull-based system, where work is pulled by the next process, based on available capacity, rather than pushed by the previous process.

A team that uses Kanban System to track and manage the flow of work may often use a board to visualize the items that are in progress. Such a board is called ‘Kanban Board’. Those practicing Scrum may think of a Scrum board as a simplified version of a Kanban Board. See an example of such a board below.

Kanban Board example

Kanban Method

Kanban Method’ is a term coined and popularized by David J Anderson who, over the past ten years, has evolved the Kanban concept into a management method to improve service delivery and evolve the business to be ‘fit for purpose’. It is not project management method or a process framework that tells how to develop software, but is a set of principles and practices that help you pursue incremental, evolutionary change in your organization.

In other words, it will not replace your existing process, but evolve it to be a better ‘fit for purpose’ – be it Scrum or waterfall. The six key practices outlined in the Kanban Method include:

1. Visualize your work
2. Limit work-in-progress
3. Measure and manage flow
4. Make policies explicit
5. Implement feedback loops
6. Improve collaboratively, evolve experimentally

While the idea of Kanban has evolved from a signal card to a management method, its emphasis on visualization and pull-based work management have remained intact.

Read more…