The birth of a project

Most often at OpendTect, we don't do a lot of formal stuff to embark on certain new developments. We discuss wishes from our (internal) users, they prioritize, and the seniors distribute amongst the team members. Priorities from users are driven by usability for their projects. The commercial people of course want a larger user base.

We also make paid stuff for external parties (mostly, oil companies). In these projects, we now have a sort of standard way to handle to process of going from the initial idea to a real concrete project.

Muy bonita!

I have, yesterday night, been investigating what it is we do. Why? Because I was trying out a real nice piece of Open Source software: Bonita Open Solution, a Business Process Modeling (BPM) tool.

I think the central thing different from the traditional way of handling things is the central role of design/architecture. Check out this process I made:

In the tool you can define actors (client, team, managers, ...), add variables (for example project name=text), which makes the model executable. I'm sure you can make everything real beautiful if you use Java or XML to get your data, and use the model as a real executable. Good stuff in general, but nobody will ever start a project using such a tool, so I won't go further into that here.

The ingredients

Let's take a look at the separate 'activities':

1. Initial ideas. Are generated by literally everybody: team members, clients, users, family members, ... anyone.
   
2. Gathering information is essential. Figuring out what exactly they mean, and very importantly what not. Traditional exploratory analysis - but ...
   
3. What information do you gather? The focus is set by the design/architecture environment. In our case, usually what is already available in OpendTect. In theory you could investigate every possible implementation, but we know we have limits. We need to map everything on the structure of our solution space. This is central. It determines what we can offer at what 'price' (time cost, but also things like: how much synergy is there with the current environment?, are we willing to support this for years to come?, ...)
   
4. Using the design/architecture mapping we can now think about the extent and therefore time cost of all parts of the solution. We usually keep these estimates in a wiki page.
   
5. When you're satisfied you have a realistic set of possibilities, decision makers can start pondering about what they *really* want, now they have the overview with cost and extent of everything.
   
6. Usually, there's a 'Go', very often with everything proposed, but sometimes large parts disappear. Well, disappear, they stay there as 'sleeping' items that may get added if there's time left. Sometimes clients/users discover they've made the wrong choices - during development. In Agile projects, this is not a problem. We just move our focus because of the new insights. Because very often, at the end we see that we couldn't foresee half of what is eventually implemented - to everybody's satisfaction.
   

Why?

All in all you can say: Agile is meant to tackle the problem of un-foreseeability, but you have to start somewhere. And why should the start be very different from the way we always work?