The short answer is that you can't, if by 'budget' you mean that you plan to know exactly what you're going to spend on it and reduce the amount of time/energy/money you plan to spend on collaborative excitement if you need that time to do other things.
But what you can do is to plan and make space for it in your project - make sure that the time is there for brainstorming and excitement and creativity. If you do that then the energy you create will help the budget problem take care of itself.
ID-GEM is a new product we've just rolled out Amadeus. It's joint effort between a few groups (sales, estimation, software, marketing) within the company. It encapsulates and expands on our business development and requirements gathering process that we've been refining over the years. I also wrote a blog post about it for work here.
The core of the product is that software projects almost always fall into one of five categories, and if you spend the time up front to think about which category you're in and how you want to achieve your goals, you can have a great framework for making crucial decisions down the road as your product or project moves through its life cycle. Here are the categories:
Capturing Market Share
Revenue (Increase/Create) B2C
Revenue (Increase/Create) B2B
Reduce Costs or Increase Efficiency
Improve Community or Well-Being of Users
We looked back over 20 years of consulting to determine these categories, as well as what we felt were the most telling, challenging, and crucial questions for projects to wrestle with at the beginning. This enables you to have the right answers in place when things get challenging down the road. The questions can be quite different depending on which of the categories you fall into.
If you are considering a software venture of some kind, you should take a look. It's free and easy to use.
In software we leverage some construction terms when we talk about software projects.
Greenfield - a new software project that is not built on a previous project. AKA - blue sky, carte blanche.
Brownfield - a project that is adding onto an existing product. AKA - enhancements, feature work, new version development.
I am going to add to this the idea of Bluefield. This is a project that is a rebuild, from the ground up, of an existing application.
This is very particular to software and I don't know if it has a counterpart in traditional construction.
This project is neither Greenfield (not brand new because it must fulfill requirements of the original system) nor Brownfield (not built on an existing product).
Why are the fields blue?
Let's say that Bluefield projects are akin to the blue sky of a new project (you often have a clean slate on technology), but you can have some sadness about the passing of a tried-and-true system that served you well for some period of time.
Blue is also associated with harmony, faithfulness, and imagination all traits that should be valued in our rebuild project -
Harmony in important features.
Faithfulness to the business intent.
Imagination required to overcome project challenges.
Rebuilding software applications is something I've thought a lot about in the last 18 months.
Rebuilds are special and have special considerations.
I wrote a blog about it for work you can read here which talks about some obvious pitfalls.
Here is another thought - what people like about their old system is actually more important than what they don't like.
This may seem obvious but here is the hard part: they are not going to tell you the things that they like. They are going to spend their time telling you what they hate about their current system.
This can happen for a number of reasons. It can happen because complaining is fun. It can happen because it is easy to criticize. And, it can happen because people do not want to be allied with the old regime once the winds of change have begun to blow.
Often, hated features are simply old and would have been corrected by updating the system.
You have to be careful and look hard for what they love, what was great, and what they have to have.
And here is the biggest catch of all. Sometimes people love features that they do not know they love because those features are so well done that they don't even realize that those features are there.
How will you know they love them? How will you be able to recreate or improve upon a feature that is so great that it is barely perceptible?
I see the converse of this (Code is Poetry) show up here and there on the internet. I agree with the sentiment behind it, which I will sum up this way: Code is Art.
I agree with that, but I think we should let code be its own art.
The art of writing eloquent code is more closely related to construction, engineering, or architecture.
Is the Eiffel Tower beautiful? If you think it is then you can probably appreciate the beauty in a well-written piece of code.
This is the Modernist idea of beauty in materials or beauty in the way materials may interact to produce an effect.
Code isn't poetry because code has no sound, and poetry is about sound and words.
Code can't be pronounced, spoken, or voiced. At least, I've never seen anyone do it in a way that made sense.
It might be interesting to see someone try.
But what about the title of this blog post, which is looking at it the other way? How is poetry like code? How are the things that go into development - design, testing, compilation, and execution - analogous to things that happen in the writing, reading, and hearing of poetry? That to me is (mostly) unexplored territory and seems interesting.
I recently rebuilt our employee recognition tool using AngularJS.
The old tool had been built as an add-on to our case management tool, which we are migrating away from.
Since Angular is our preferred web direction, I believed it beneficial for me to dabble a bit and rebuild it using a modern, strategic technology.
The process was challenging for me mostly because I was not much of a JavaScript developer back when I did a lot of development. So, to do almost all my development using JavaScript required a fair amount of brute-force-through-googling just to get me past the basics.
Once I was able to do that, it was relatively simple to get done what I needed. My app was about 6 pages with 2 input forms, 3 grids, and a port of an old jquery-centric billboard form with some basic fade-in/fade-out animation.
This was no enterprise system mind you, but it had enough moving parts for me to learn the basics and prove to myself how hard it was going to be for others to learn.
For our existing JavaScript stars this will be an easy technology jump, but for others it will involve training on both JavaScript and AngularJS best practices.
The Amadeus Innovation Team has already developed a lot of our AngularJS best practices so that portion of the transition process is covered. There's a fair amount to think about in terms of project structure and approach, but I have left that to the more expert development minds.
Jonathan Fries on .