Editor's Note: This is the first in a new series of articles where CIOs share first-person accounts of success stories that helped impact the bottom line.
If you've got enough money to do a project right, chances are you'll have more problems than if you don't. It sounds counterintuitive at first, but if you'll bear with me you'll see how small budgets and smart projects go hand in hand.
As I began developing a cloud-based supply chain application for my new company, SCM Globe, there were many times I regretted not having the staff and budget I had in my last CIO position. But then at the last company I didn't have the money or resources that my competitors had. And both times I did well. I got things done faster than other people thought possible and for less money.
When I have all the time and money I need, there is no need to be agile. And disciplined use of agile software development techniques is my formula for success. Over time I do wind up spending almost as much as I would if I used traditional software development practices. But the money is much better spent because of two big benefits I get from being agile that I never got using traditional practices.
The first benefit is that I don't get bogged down in lengthy requirement-gathering. We don't produce hundreds of pages of specifications that nobody reads that quickly become obsolete. Instead, we focus on the most important features that can be delivered in 30-60-90 day cycles.
People always know what the most important features are because it's the stuff that keeps them up at night. They can tell you what they are pretty quickly. Those features define the minimum viable product (MVP). I segment the MVP into software delivery cycles that are 30 to 90 days long. So people see IT is getting things done, and that builds momentum and credibility for the project.
The second benefit is that people get to start using what we deliver right away. And in doing so, they discover new things that they could not know without getting started.
Outside of well-defined and regulated activities, it just isn't possible for people to know what they really need by talking about a new application. No matter how much time is spent in requirements gathering, people cannot know all the things they will need in a new application because it is new, and they haven't done it before.
When I deliver the first version of the MVP and people start using it, I get feedback and then embark on the second iteration where we add new features to the MVP. And we deliver that quickly. With each iteration, people get more and more of what they want.
In this way I avoid spending time and money on things people thought they wanted, but then learned they don't need. This makes the business side happy, and making business people happy is central to having success as a CIO.