I work for a rather large insurance company. We aren't the largest, but we are big enough to have our own SDLC (System Development Lifecycle) that comes packed with paper work, protocol and bureaucracy. Do not misunderstand me - these processes ensure the projects that are active are delivering on time and within budget. My last two efforts 20,000+ hours each have both come in a -2% of budget and were delivered on time. This has been largely due to the depth of documentation in terms of business requirements and tech design that had been accomplished by the time we needed to provide Execution estimates. Pretty remarkable in my opinion. So, what is the problem? Namely 14 months of project work before ANY benefit was delivered to our business partners. We changed direction with this last project - we are trying something new, and even though we've had our fair share of challenges, bumps and bruises, I'm happy with how we've progressed.
It all started when our estimates for delivery based on some scope definition and identification of high-level requirements landed us in July of 2009 - these estimates were given in August of 2008. Our project was denied the approval to continue. We were told to go back and figure out how to deliver in December 2008 or very early first quarter of 2009. Being challenged on estimates is just part of the game, but being asked to cut the effort in half and deliver the same quality of product in half the time is very difficult, if not impossible; we just don't inflate our estimates enough to trim that much fat.
Faced with this challenge, I started researching different project methodologies, different approaches, new ideas. Eventually this search landed me squarely on Agile Development. I pitched the idea to my project manager.
A couple of days later all main players of the project team were assembled. Architects, designers, developers, business analysts, business partners, project management and quality assurance were all together under one room. We reviewed the outlined objectives and in two days had an informal model of the end-state drawn up on a whiteboard. We broke the project into releases and timeboxed iterations (reqs, code, testing) to one month. Release 1 (we term 'Bare Minimum') comprised of the fewest changes needed to deliver an acceptable level of functionality to our business partners.
Release 1 is schedule to transfer later this month - not July. We will have delivered the major infrastructure needed within four iterations. The 2nd release will be within the following month - much quicker. I have a feeling that's how this project will start progressing. With the major infrastructure in place we should be able to role releases out very quickly!
We have learned many, many, many valuable lessons along the way. I'll write about those a separate time. I've been asked by others in our enterprise (different divisions than me) how I was able to persuade the executive sponsors to move to a iterative approach. I think it was a combination of a couple different factors: 1) serious time constraints, our business partners knew it and were willing to try something new; 2) willingness by a few to research, learn and introduce the team to iterative/agile principals; 3) a talented IT team who is willing, able and hungry to try new challenges and succeed in new ways.
Chase Petsche, BA III