Fixed scope (fixed cost) versus an agile project. Which works best? For my customers, agile has been hugely successful. The most painful projects, with the least success, have been fixed scope.
With fixed scope projects, even though many people review a specification, people don’t truly care about “all the details”, nor is the entire team on the same page. As the project owner, you just want your vision delivered and hands down; agile is best. If you’re an accountant, it’s how you think and work every day.
I recently built two wooden planter boxes based on a vision I had. I drew up a rough plan on paper, had measurements, tools and some old pallets I pulled apart to use as the material. As I was building the first planter, I was reminded of some BI projects I worked on that were not as loosely planned as my planters. In fact, they were very well planned, to great detail. And they were also disasters! Not because I can’t deliver good outcomes, but because of the development process. The owners of the project were only involved in the specification stages. Here is what I was reminded of with my little planter project.
- You don’t really know what you’re getting until you start building something.
I smiled to myself as I began to mock up a basic planter with clamps holding them temporarily in place. I used my initial measurements, but it turned out I had made a miscalculation, and the planters would be too small. If I hadn’t completed a quick mock up to cross check how it would look. I would've had to restart with new wood to cut all over again. This also occurs in BI projects as well. All too often I have seen very expensive projects signed off without a mockup. In financial reporting, that’s reasonably easy. I encourage my people to share and review their work often so everyone can see progress, and understand any road blocks and make final decisions on what should be focused on next.
- You will miss exciting options that you weren't aware of in the planning stages
I was looking for some short, beautiful old pieces of wood because I wanted the planters to look rustic, so the more imperfect the wood looked, the better. Then I came across two beautiful long pieces of wood that I didn’t have a place for on the planters, but I liked them so much that I wanted to use them. So I changed my design, added them, and the planters look better because of it. Having the flexibility to change throughout a project is a must and Agile allows for this. Agile projects give the BI developer the opportunity to share their latest work with a customer to make sure they are on track. While sharing the current status, it's also a great time to share new options for the next step in the project, which are often options the project owner never know existed. Many times these options mean saving money, saving time, and create a better product in the end.
- You asked for more than you need
I originally wanted to add a top border to the planters, but once I had the rest of the planter built, I realized I didn’t need it and it looked great the way it was. Knowing you can stop your project at any time and start using what has been built already is a great result for everyone involved. Sometimes your vision was a little over zealous and if stopping short still means you have all the functionally and speed you need for reporting. You can then save your pennies and time for the next project!
- There may be other things you'd prefer in the outcome
I had initially decided I would stain the planters with a light stain but while at Lowes, I found a dark stain that blew my socks off and I fell in love with it. I was really happy with that change. Being given choices throughout your Business Intelligence project means you have all the control you need to make the project a success. As time passes, your ideas change and your vision of your desired outcome will change too with new information. As long as the modification is presented at the right time, and it is not monumental enough to require a restart, having new ideas injected and applied along the way always gives a better outcome. Does this means the project will cost more? Maybe, and if it does, you’re getting far more value. Otherwise, you wouldn’t make the change, would you?
- You often don’t feel like you got enough value out of a project.
The only planter box analogy I can think of here is if I built a chair when I wanted planters, but that’s crazy because I am hands on, in this project. Hang on, a project with hard specifications is sometimes just like that. Once you sign off on the spec, you're now hands off and don't see anything till near the end of the project. Only when the project is complete do you get to see it and play with it and this is too late. It’s then that you realise that Cash Flow to you means something very different to a software developer, so you got a chair and not a planter. An Agile approach sees you, the business owner of the project constantly involved, guiding, making decisions, shaping and creating the outcome you envisioned from the start.