Doc4 delivers top-shelf software development and we do it with small teams, tight budgets, and more often than not, a cannonball schedule.
How?
One answer is we've learned to improve our outcomes by improving our objectives using a "FIRE" approach:
Fast, Inexpensive, Restrained, Elegant.
This approach was created by renowned innovation consultant Dan Ward in his ground-breaking book F.I.R.E : How Fast, Inexpensive, Restrained, Elegant Methods Ignite Innovation.
The FIRE approach is great for improving software development projects across the entire project life cycle. In addition to making it easier to innovate, FIRE saves time and money, frees up staff and improves their value, and ultimately leads to leaner and more profitable growth down the line.
A short schedule fosters stability and reduces your exposure to the forces of change.
We start by creating a well-defined project objective and build a timeline that is just long enough to reach that objective: a short schedule fosters stability and reduces your exposure to the forces of change. This also enhances accountability and learning.
At the same time, note that ‘fast' does *not* equal ‘frantic'. It can be an easy mistake to take the superficial appearance of speed for going fast, but everything could fail if we cut corners or skip essential steps.
How do we do this exactly? First, we account for what is actually needed, and what resources we will actually have. No self-delusions or pie-in-the-sky thinking allowed. Second, we need to be willing to solve problems in ways other than simply adding days to the schedule.
One quick question, who do you think sleeps better at night? The guy in charge of the second behind-schedule and over-budget Death Star , or Q, head of James Bond's gadget division ?
Think of your budget as a constraint, not a starting point. Just like your schedule, if you want to innovate you can't just keep adding zeroes to a budget and expect the solution to be worth the trouble. For your project to be worth it, it has to be cost-effective!
At the same time, remember that inexpensive ≠ cheap. A low-cost solution that doesn't actually work will end up being a pretty expensive solution at the end of the day.
This is critical to getting your project to the point that it is fast and inexpensive. Practice project self-control with:
The biggest innovations often solve problems in pleasingly ingenious and simple ways. A lot of people confuse complexity for sophistication. But, complexity is nothing to brag about.
Keeping your project elegant happens to be a key to staying on-schedule and under-budget. Elegant solutions cut through the noise, and get right down to what actually matters to hitting your objective.
Start with what you actually need, "if only we had..." Then begin a search for the resources you already have
The data tells us that tight limits are paradoxically freeing, leading to faster, cheaper, and more elegant solutions to problems.
There's a reason that the Browning M2 has been continuously in production since 1933. In spite of all of the innovations in other aspects of warfare, a tool that just works makes all of those other innovations possible.
When you hit a problem, start with what you actually need, "if only we had..." Then begin a search for the resources you already have that can be applied to your problem. In The Princess Bride, Westley thinks that there's no way to save his love, Buttercup, that all hope is lost, until ...
When the deadline is firm, the only place to add more time is putting it on the front end, to start BEFORE you start.
Have small teams of talented people. Large teams dilute and mute talented members and a crowd can keep your stars from acting or feeling responsible. Small teams help talented and highly competent team members make BIG contributions.
Empower your team to make decisions at the lowest possible level, as close to the scene of action as possible.
Adding in excess complexity in technology, systems, org charts, etc. will not lead to good outcomes anywhere down the line.
Time spent understanding your problem almost always translates into time saved when you are solving the right problem when you need it solved.
Discovering a unique problem OR a unique solution is unlikely, so make sure that you know who else has found and solved a problem already. Let someone else do the dirty work, and spend your time and effort effectively.
Most projects are going to experience the "Snowball Effect," where budgets only ever seem to get bigger and deadlines only get pushed further as a project goes on. If you want to minimize, or even reverse, this, start with a smaller snowball and roll it down a shorter hill. Starting at any part of a project, add constraints to the timeline, the size of the team, your budget, or anywhere else that you find time, costs, or problems snowballing.
Start with a smaller snowball and roll it down a shorter hill