The "Funnel" Prioritization Technique

I've been developing a website called Flyc for about a year or so, mainly in my spare time. Flyc stands for 'For Launching your Career' and is aimed at helping job seekers track their jobs online.

Yesterday while working on the site's user stories and schematics, I hit a road block. It was mainly psychological at first, but then after re-thinking my approach I noticed that I was just overwhelmed with the amount of 'stuff' I was planning on achieving in a short timeframe.

So I started thinking about how do I go about prioritizing my work. I was mainly thinking about the 'scope' I wanted to define for the 2nd release of the recruitment site. So I defined 70-odd user stories which match needs I gathered from potential users of this site.

Now I could have used 2 familiar techniques to prioritize the User Stories:
1. Use the 100-500 Business Value technique
2. Prioritize by sorting them (user stories at the top are more important and user stories at the bottom are less important)

Both techniques are good. While using the 100-500 business value scale on some projects in the past I found it quite hard to get a good reflection of the priorities in one go and most of the times it takes a few iterations to get to a good comfort level. I developed this approach of first 'grouping' the user stories into 5 or more groups where each covers a range of business values. E.g. The 401-500 group / range includes user stories that are really high-priority, the 301-400 group / range includes ones that are a bit lower ni priority and so on. You can also break these groups further into smaller groups if needed (i.e. 351-400, 401-450 etc).

This in fact introduces some form of a grouping mechanism which psychologically helps people prioritize and scope work to be done.

The interesting 'prioritization' bit kicks in once the project is under way and 'deadlines' are approaching. From personal experience as a developer recently, sometimes the amount of functionality desired is too much of a stretch to achieve good 'momentum' and keep the morale / motivation high.

So getting close to a date I wanted to release the first stable version of the site, I started 'culling' functionality. By doing this I was able to determine the 'bare' minimum that would yield 'acceptable' value. It worked.

So I figured, what if at the outset of a project we prioritize the work into fine grained groups which are only based on 'business value'??

So here comes the 'funnel' prioritization approach which is based on a logical and human-centric technique for distilling down to the most important bits.

1. 1st Prioritization - Divide the entire scope into groups based only on their 'business value'. Grouping could be done initially by dividing all user stories into 3 main groups: high value, medium value and low value
2. 2nd Prioritization - Put the medium and low value groups aside and divide the high value group into smaller groups
3. Continue dividing the top-most group recursively until you reach small groups of 5 user stories. The top group (should now give you a good indication of what could be the 'bare' minimum required to provide some tangible value
4. Now follow the above steps for the medium and low value groups. This will give you a fine grained grouping of value-based functionality

The interesting thing is that this approach is focused on 'value' creation and not necessarily agile / 'scrum's view of prioritization which takes into account the 'how big?' factor combined with the business value. Looking at this I think the 'business value' will determine the overall and incremental scope of a project. As more often than we know, some projects don't deliver all functionality 'desired' or the 'money' runs out. So to be able to 'always' pull the plug at the end of each release, the releases should be driven by 'business value' prioritization perhaps using the 'Funnel' technique above.

This approach is a bit different to the traditional agile / scrum approach and takes into account true 'business value' and 'pulling the plug' ability. This may introduce 'releases' / iterations that are not similar in duration. I believe this approach is more realist in most organisations where many people work on multiple projects at the same time.

This of course has big impact on software architectures and frameworks as they will have to be reasonable fluid and refactorable until such time as the scope is committed by all stakeholders (including money and time commitments).

In a nutshell, I think a 'Funnel' prioritization approach is another simple and effective way of distilling large amounts of functionality or requirements into small, value-based, manageable chunks.

What do you think?

3 key elements of a successful project

There are 3 key elements that make a project successful:

1. The "Done" factor

2. Repeatable project process

3. Online collaborative simple tool to support the "Done" factor and the project process

Recently while working on a new project which has the following risks:

* Timeline is tight and budget is not reflective of effort needed to accomplish the tasks

* Implementation platform is new to the team

I have taken the approach of gathering requirements using agile methods and defined appropriate User Stories. I then estimated the User Stories with the team and was able to put some effort and budget figures against each User Story. This provided me with a more realistic view of the project overall effort and budget.

I realized very quickly that in order to ensure the project will deliver to its agreed timeline and to keep spending under control we must be able to determine and measure when we start and finish a piece of functionality. The key emphasis is 'measure'. I realized that if we can realize when we 'finished' something we can then evaluate the effort invested into that piece of functionality and project it on the remaining User Stories. This is in essence the premise of agile and sometimes more specifically Scrum.

So, I set on a journey to determine when something is 'Done'. The 'Done' factor.

1. The "Done" Factor

It is 'essential to determine when a piece of work is done. Something is 'Done' when the client 'signs it off'. That's simple. But the big question is, especially when I put myself as a client, what does that mean?

Well it means a few key things:

* Determine that what's given works

* Determine that what's given meets the 'specification' or 'requirements'

* As a client, I'm happy to take it with me and go

Taking the above in the context of software development, this translates to one question:

What 'things' in the project can the client evaluate? and how?

So, in this particular project we have the following functions:

* Wireframes

* Design

* Development

* Design Integration

* Testing

* UAT

The 'things' the client can evaluate are simply:

* Wireframes

* Design

* Tested product

Wireframes and Designs are tangible deliverables that appear on the screen or a piece of paper. They can easily be reviewed and 'signed-off' by the client. Tested product is more complex. How does the client 'evaluate' and 'sign-off' a tested product.

This to me means that the client must be able to have the tools or techniques to be able to evaluate and sign-off. Tools meaning testing tools and techniques could include people who have the skills to evaluate the received product. Evaluation of the received product would be against tangible deliverables (requirements, specifications, designs, wireframes etc).

So now that we know how to get the 'Done' factor, how do we integrate it into the project process?

Using Agile methods we can create and repeat an end-to-end delivery process multiple times throughout the project. Using releases and iterations we can develop User Stories and go through the entire 'process' and get them 'done' in a timely fashion. 'Repeatable process' is the key to enable this continuous and effective way of delivering and signing off User Stories.

2. Repeatable process

It's essential to have a crystal clear process that could be followed time and time again by the book which will provide tangible and accurate results.

Based on the functions mentioned above, here is a sample 'Repeatable Process'

--- Requirements, test cases and designs

1. Clarify requirements

2. Develop test cases

3. Develop wireframes

4. Review with client ("Iteration Depth" concept will ensure a fixed number of iterations is performed with the client

- Review with team (feasibility of wireframes)

- Sign-off by client

5. Develop designs

6. Review with client (fixed number of iterations)

- Review with team (feasibility of designs)

- Sign-off by client

7. Update requirements

8. Update test cases

9. Sign-off requirements

10. Sign-off test cases (as they could be used by the client to test the product as well)

--- Development

11. Development of back-end functionality

12. Conversion of designs into HTML/CSS templates

13. Integration of designs and code

14. Unit and Integration Testing

15. Close release

--- Functional and other testing (Staging environment)

16. Deploy to a staging environment

17. Communicate release to testing team

18. Perform testing on staging environment

19. Iterative bug fixes

--- UAT testing

20. Deploy to UAT environment

21. Communicate release to UAT team (client's team)

22. UAT testing (against requirements and/or test cases)

23. Iterative bug fixes

24. Sign-off release

The above is obviously one example and some projects will differ slightly or greatly as per the needs of that particular project.

3. Online collaborative simple tool to support the "Done" factor and the project process

Now we only need an online collaborative simple tool to facilitate the 'Done' factor and ensure the repeatable process is established and followed each iteration and release.

Simple isn't it?

T

Controlling Scope, Budget and Time using the "Iteration Depth" Concept

The 'size' of the project is normally different at the start and at the end of the project. There is an effective way to define and control the project 'size' by defining and controlling the "Iteration Depth". "Iteration Depth" is the number of iterations to be executed for the creation of each deliverable in the project.

"ITERATION DEPTH" EXPLAINED

If we look at the 'Deliverables Layer' (my way of looking at the Deliverables of a project), then each deliverable will go through it's own life-cycle until it's completed. Completed would mean, reviewed, tested, accepted and signed-off.

The diagram below shows this concept.

Deliverables such as documents or reports will go through a standard revisioning process where each revision will include activities such as (an example):

Iteration 0: (concept from Scrum) - equivalent to an 'Inception' phase of creating a deliverable

* Writing content

* Create revision

* Distribute to stakeholders

Iteration 1:

* Review (internal and external)

* Provide feedback

* Update deliverable

* Create revision

* Distribute to stakeholders

Iteration 2+: continue same process as above

I think projects can adopt the same approach to all deliverables and improve the delivery quality and stakeholder satisfaction. Agile / Scrum software development projects use the same concept as a delivery framework.

Take the 'Release Plan' and the 'Releases' from Scrum. Each Release is in effect a deliverable and each Release has a set of iterations (if we have monthly releases, we could expect 1-4 iterations, depending on the size of the team, complexity of technology etc).

This concept works best for deliverables that invite continuous modifications such as wireframes, screen flows, user story creation, designs, usability testing etc. These deliverables easily create a 'never ending' process whereby the client always wants to change something. This is especially critical on 'Fixed-Price' projects where the effort invested by the project team to work on a single iteration is absorbed by the project team. In this instance, it's very easy to blow a budget!

CASE STUDY

I saw this concept in action especially when a project is run to a tight timeframe and deadline. On one project I was involved in, we were required to provide a design for a company within 4 days. Now after scratching our heads and staring at each other, we agreed that in order to pull this off we will need the client to commit to the following:

* Agree ahead of time to a defined number of iterations (3 in our case)

* Make decisions and 'sign-off' at the end of each iteration

* Have a single point of contact who is responsible for making the 'final' decision

The client agreed to it and stuck to the schedule. This approach enabled us to deliver to client requirements and at the same time control the scope, time and evidently the budget for this small piece of work.

BENEFITS OF "ITERATION DEPTH"

By controlling the number of iterations we can:

* Estimate effort more accurately (by allocating resources and time to Iteration 0 and subsequent iterations including activities such as meetings, reviewing, travel etc)

* Engage the client more professionally and effectively. The client will know their responsibility and commitment (it's not going to be an uncertain open-ended process until the client is happy). This will cause the client to think twice or put the extra mile for each iteration

This concept sits well with the agile software development approach

* Control project timeline. By controlling the effort for each iteration, we can more accurately define and control the overall timeline. If there are any delays from a client's perspective, these delays could be raised as project issues and dealt with straight away

* Control project budget. By providing better estimates, we in fact control the spend of the project

* Control project scope. By ensuring the number of iterations are kept, the number of times feedback will be collected is defined and controlled

* Project momentum is gained. By following this concept, the wider team (both internal and external) will be focused on progress and will ensure all hands on deck for each iteration

WHAT THE CLIENT WANTS

I must point out that at the end of the day, the 'process' for executing the project will be up to the client and some clients may want an 'open-ended' "Iteration Depth" and at the same time allowing the project to use T&M (Time and Material) as the basis for charging for each iteration.

This is of course an extreme example and normally doesn't provide the client the value they require, but it is a scenario that does happen.

The "Iteration Depth" therefore provides much needed controls to be able to better promise and control scope, budget, time and quality of a project.

T :-)