How to provide traditional upper management early analyses in an agile project?

Question

I was discussing moving our process to become more agile with our (mostly traditional) Chief Information Officer (CIO).The CIO's stance was that >=80% of the requirements need to be defined (and set in stone) up-front, before work on the project can begin. Essentially, fixed scope.I argued that frequent feedback and fixed schedule would result in better products, and would not need such a large percentage of the scope to be fixed at the onset. That when new scope came up, either other scope should be removed or the schedule be renegotiated.The CIO then posed to me a question which I was unsure how to answer - namely, how to then justify the original project schedule/cost to the CEO at the beginning to the project. The CEO expects gap and cost analyses before a project begins.I could argue that agile development processes would overall provide more value to the business, but, given the biases involved (on both sides), I don't think that would be sufficient justification to change if the CIO doesn't continue to provide the analyses that the CEO expects.So, my question:How can sufficient upfront analysis be done to satisfy a traditional CEO without locking down a project's scope from the beginning, thereby hobbling much of agile's benefits? Is it impossible? Or am I simply on the wrong track here, and I'm missing something?

Answer 1

Stated in various ways, I get this question often. A common thread is, Agile practitioners wish that those who make strategic business decisions would truly understand the benefits of Agile.

The cold hard fact is, no one lasts long at the strategic management level allowing high visibility projects or initiatives to go on without a reasonable definition of a) requirements, b) rough cost estimates and c) time to completion. I'll through in one more; d) risk assessment.

All of this together is your scope!

Your job is to bridge the language gap between that of a logistic-executor and strategic manager.

Here's how I suggest you begin.Show the CIO and CEO that you are genuinely interested in understanding what they need to know before the project is approved, what will they want before the project kicks-off, and what do they expect to see (and how often) during execution. Don't forget to ask how they want to receive the information and who-all should receive it.

Keep your initial "scope" high level -- but provide enough to make it clear that you've thought things through as-if your failure to do so risks the jobs of everyone involved -- possibly the entire organization. That after-all is how an executive thinks.

Finally, when you begin to design and develop the product -- assuming you're working with a product owner -- make sure that ANY changes to scope that alter the expectations you set with the CIO and CEO are communicated back to them. Reset expectations. Utilize the Product Owner in this communication because you may need backing for the justification.

Good luck!