New about it is that we start building software after a very limited starting up phase. When we reach the moment that the customer wants to hire us and we can start, we form a mixed team and spend in total just a few days to get an understanding of what kind of system and what specific behaviour and requirements are expected.
Then we try to define the result we expect to reach and go live with after 1 calendar month. Then we start to reach the finish of the first month result as good and as fast as we can! It's sometimes hard to imagine that you can actually deliver working software after a few days or weeks, but we (we as the pro's in the IT industry) really can!
Ok. Then what's the improved part? The improved part is that we only want to fullfil the needs our customers needs. We focus on the functionality that helps out customers to do their jobs/services better and make money with it. Here is where we improve the way we work with the customer: we team up with the customer. Yes, the customer pays us. But we have to do the excellent job together!
That means, we are more intense involved with each other. Communication about what is wanted, what the priorities are, what makes money, what insights changed, etc will help to gain a better basis to reach the successful end results. Of course there is the risk of scope creep but we will also communicate about that of course. Here comes in the trust we require at both sides. The customer should be aware that moving and changing the target "while flying" costs time and money. We, the "result engineers", should help to keep the number of changes low by asking the right questions and make sure that we have the same target vision (results and business value). Together we do all this!
Some uncertainties in software development are still there. We approach the way we deliver software in a new and improved way but we can't eliminate all risks. The fact that we apply Continuous Integration, Automated Testing and a Testing Environment makes the time between running into and solving eventual risks short and thus a lot easier to mitigate. This applies on both the technical as the business issues.
After the first month we may be done or may just have delivered a piece of a bigger system. This type of months keep on repeating until we are not able to add enough value or the end result has been reached. Changing requirements in the future will normally be a set of various changes, approached by us in about the same way we did the project.
"One Month Project" is how we named this approach and will be offered to our clients from now (2010). Stock and capacity are limited but we plan to expand if we can or should.
There are lots of opportunities for customers to be done in about 1 month. We can help a customer to:
- build new business
- make efficiency steps;
- raise service levels;
- fix a problem;
- gain competitive advantage by making small (monthly) steps;
- make IT helpful (instead of blocking);
- innovate and excel;
- etc.
I'll write more about this OneMonthProject appoach here, so if you like it: stay tuned.
Some info about the toolbox we use: agile, scrum, ruby on rails, java, jruby, linux, ruby, oracle, mysql, etc.