** Evolutionary  **
THE LEARNING PROJECT

Swedish/English
Updated 061226
version 1.3

GREAT PROJECT TOOLS!!    METHOLOGY!!    POWERFUL AND EFFECTIVE!

Purpose with Evo.
The purpose is to offer an alternative way of working in projects where new or unsure results are expected. When it is obvious that a similar solution does not exist or have failed before.
Evo:s way of work facilitates a significant reduction of risk in the project.

There is a need for more management capacity compared to waterfall projects.
Management capacity is needed for resource and relation handling as well as for goal steering.
Evo. demands a clear vision and well defined goals to achieve expected results.

During the execution phase user requirements, the result itself and the way of production are refined in a learning process. The Evo. work method takes care of existing knowledge and systems in the user environment.
A planned Evo. step during the execution phase is short and effective, major driving force are user participation and learning (immediate feedback).

System integration and test are taken well care of during execution.
Test and integration will not be a problem at the end of the project.
Huge problems and technical difficulties will surface fast due to Evo's priority planning rules.
Each step is normally 2%-4% of the projects total estimated time. 2% is recommended.

Evo. is not recommended when the orderer/customer want's to change a whole system/product to a new one.

When you want to ... run a project with fuzzy/untested requirements and new technical design (High-High risk) implement a vision in steps and improve the possibility to meet the market window with something working use partial results as a mean for follow up (for orderer/steering group e.g..) get early feedback from your users get early feedback on the result (product) get early feedback on the process of result design control project risks with a high degree of result/work break down meet a "burning" need up front

Benefit... facilitates a high degree of goal focus in the project. This creates high project productivity investigates and describes a new way of working together with users gives a continuous series of improvements in the user organization creates a result that is integrated with it's surroundings takes care of existing data, systems and information. That's easily forgotten during "normal" development projects facilitates learning by it's small controlled steps where it's allowed to make experiments. A whole step can be abandoned. That's learning. Experiments and mistakes in fair amount are allowed

Advantages Drawbacks Obstacles with Evo. Why Evo?

Why are companies like Ericsson, IBM, HP and many others on this track.

My ambition is that you will be sure enough or at least curios of the evolutionary concept.

You will also be able to compare different development models for large or medium sized development projects. The question, why projects with one or few deliveries must be redesigned from start, will be answered.

How to work in an evolutionary project

Project initiation (outside Evo.):

• Initiation- prerequisites (my suggestion)
• Maturity evaluation, process status (in user organization)
• Gain approval for, get commitments from user management, motivation
• How to package and sell Evo. Project's (if you are a consultant or internal supplier)

Evo. Main planning process:
1. Investigate known, needed benefits of the desired vision.
- Perform a user organization study
2. Prepare/define benefits and measurable goals.
3. Risk analyze
4. Suggest project strategies, brainstorming / seminar around strategies
5. Do impact evaluation of chosen strategies and ideas / seminar ?
5a. Decide upon project goals
(Those function- and quality goals the project takes responsibility for)
6. Complete/adjust/remove strategies
7. Do Impact estimation / evaluation
8. If not 150-300% go to 6
9. Make a step plan, and time schedule
10. If needed perform a new risk analyze
11. Step planning
- define use-scenarios, group functions. Planning tip
12. Prioritize (most benefit and high risk first) - see planning example
13. Staff the project - key roles (user manager, design manager, project management)
14. Personal Commitment from project staff
15. Start of execution phase

Evo project execution:

Follow up of overall project:

• Progress:- Infrastructure/technology- Achieved benefit (user org.)
  and cost so far
• Adjust step plan/strategies
• Resources/consumption (users and project team)
• Follow up, Guide for measurements ß
• (Project analyse)
  

Execution of an Evo. step:

• Decide upon improvement goals for actual step
• Choose and decide upon ideas - solution strategies
• Evaluate ideas (Goal/benefit Impact estimation)
  - What's the impact on important goal's from each idea and strategy
  - Learning (lessons learned) from earlier steps
  - Assumed benefit from coming steps
• Do step (develop) or buy a result/solution for the step
• Do internal test in the development group
  - Usually a task for the user liaison (user coordinator).
• Deliver and execute the step result with user (s),
• Study results / benefit
  - Engage users in decision making about next step
• Update plan - time e.g.

PROJECT ORGANIZATION DURING EXECUTION

Example of a step plan for a system development project.

Contents priority rules are to place user scenarios with most impact of project goals (most user benefit) in the first steps together with functions with high technical risk.
In step's late in the projects time schedule scenarios with low benefit and win low technical risk are placed.

How well something is done Quality goals: - usability - availability - profitability - spread - demand - testability - maintenance ability - access (data) - simplicity - sound level

Project goals can be both quality- and function goals. Benefit can be partly or all three. The BUSINESS DEAL decides.

The function itself Function goals: - transport - response time - throughput... - "task nn" - installation - component. - product

Other Gilb info:

• NEWS 2005:  A few nice documents from Tom; Agile Spec, Design Evalu, Real Req and Firm
• Toms article about the evolutionary method, September 1996 written by Tom himself
• An interesting comparison between different development models, Evolutionary, Incremental and waterfall
• Introduction to Practical (INDUSTRIAL) Creativity by Tom Gilb
  
• Hewlet Packard journal, experiances from real projects
  
• EVO_mini.ZIP [520k] Requirements - Driven Management using Planguage. Old copy! A handbook for advanced practical management and engineering methods for leading-edge competitiveness. A guide to critical thinking about complex ideas problems or systems
• REQUIRE.ZIP [569k] Requirements - Driven Management using Planguage. OLD VERSION.
• Website for Software Research Institute

Tom Gilb alias Thomas Gilb

Advantages with Evo:

• Runs through the full cycle from user and customer needs and benefit to usable step results. This promotes a high degree of learning for all involved and between each step.
• Challenging for the team, demands a good mix of different competence.
• Creates usable early results, normally 2, at most 4 weeks after start of execution phase.
• Builds user and orderer confidence by a succession of usable deliveries with benefit.
• Integration, test and result approval is a part of each step. This will not become a difficult obstacle at the end of the project.
• Installation and start of production are also done in each step and will not become a problem at the end.
• Gives early feedback from real production. This facilitates that maintenance goals are met.
• Gives feedback from real experience of chosen technology.
• Gives early proof if chosen design and strategies are enough. (Due to Evo. planning priority rules)
• It the project is cancelled/aborted before it is competed, all results achieved up to that date are in practical use
• It's easy to follow project progress on results in practical use
• Evo. suits well for projects working with object technology

Drawbacks with Evo:

• Evo. expects competence for defining goals and competence for working with user management in this
• it can be difficult to find and identify small steps with user benefit
• most project members are not used to work and think this way
• Evo. uses new ways for project (and management) decisions
• all involved needs good insight in the Evo. method itself
• there might be resistance from system maintenance staff (to? many deliveries)
• the orderer/customer will not get the whole result at the only (and first) delivery
• the orderer/customer will have difficulties with replacing the result when the project have finished
  

Some obstacles:

• do not start without a clear vision and not without well defined goals
• plan for extra roles and project management capacity
• plan for installations and get commitment and understanding from current maintenance staff
• do not start with simple tasks without real usability (user benefit)
• plan for introduction/education of project members in the new Evo. work method
• if you do not get a first delivery within 2-4 weeks, it's probably not going to be an Evo. project
  

Why Evo with add-ons.:

• Evo. needs resource management (missing)
• Evo. needs a conclusion process as well as a good project review (missing)
• Evo. points out a need for a number strategic decisions during the project
  Evo. also offers a Impact evaluation tool for strategy and idea's
• Evo. have got the most developed way of describing goals on market today

From Chapter/section 9.6. Advanced ideas: Evolutionary Management

How to decompose systems into small evolutionary steps.

1. Believe there is a way to do it, you just have not found it yet!
2. Identify obstacles, but don't use them as excuses: use your imagination to get rid of them!
3. Focus on some usefulness for the user or customer, however small.
4. Do not focus on the design ideas themselves, they are distracting, especially for small initial cycles. Sometimes you have to ignore them entirely in the short term!
5. Think; one customer, tomorrow, one interesting improvement.
6. Focus on the results (which you should have defined in your goals, moving toward PLAN levels).
7. Don't be afraid to use temporary-scaffolding designs. Their cost must be seen in the light of the value of making some progress, and getting practical experience.
8. Don't be worried that your design is inelegant; it is resultsthat count, not style.
9. Don't be afraid that the customer won't like it. If you are focusing on results they want, then by definition, they should like it. If you are not, then do!
10. Don't get so worried about "what might happen afterwards" that you can make no practical progress.
11. You cannot foresee everything. Don't even think about it!
12. If you focus on helping your customer in practice, now, where they really need it, you will be forgiven a lot of 'sins'!
13. You can understand things much better, by getting some practical experience (and removing some of your fears).
14. Do early cycles, on willing local mature parts of your user community.
15. When some cycles, like a purchase-order cycle, take a long time, initiate them early, and do other useful cycles while you wait.
16. If something seems to need to wait for 'the big new system', ask if you cannot usefully do it with the 'awful old system', so as to pilot it realistically, and perhaps alleviate some 'pain' in the old system.
17. If something seems too costly to buy, for limited initial use, see if you can negotiate some kind of 'pay as you really use' contract. Most suppliers would like to do this to get your patronage, and to avoid competitors making the same deal.
18. If you can't think of some useful small cycles, then talk directly with the real 'customer' or end user. They probably have dozens of suggestions.
19. Talk with end users in any case, they have insights you need.
20. Don't be afraid to use the old system and the old 'culture' as a launching platform for the radical new system. There is a lot of merit in this, and many people overlook it.

THE FUNDAMENTAL - EVOLUTIONARY PLANNING POLICY - EVOLUTIONARY PLANNING POLICY

PP1:Budget: No project cycle shall exceed 2% of total budget before delivering measurable results to a real environment.

PP2:Deadline: No project cycle will exceed 2% of total project time (one week for a year's projects) before it demonstrates practical measurable improvement, of the kind targeted.

PP3:Priority: Project cycles which deliver the most planned results to customers, for the resources they claim, shall be delivered first, to the customer.