6

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?

Improve this question
7
  • Do you have another project at the company that has a firm set of features identified? If so, then you could do a pilot with that project and then use the resulting metrics to help identify cost/schedule for a new project and provide data for justification of resource use.
    – Polymath
    Commented May 9, 2018 at 18:27
  • 3
    How accurate are the company's current schedule/cost analyses given at the start of projects? If they're super accurate, you don't need agile. If they're super useless, there´s no need for them.
    – Erik
    Commented May 9, 2018 at 20:02
  • @Polymath Perhaps worth attempting, but the last time I suggested something similar the result was that we had no 'non-crucial' projects that could afford being done as pilots.
    – Sarov
    Commented May 10, 2018 at 13:14
  • @Erik They range from <1 month over for a 1-2 month-long project to years over for a 6-months-long project. But whenever things go too far over, the prevailing view is that it's either IT's fault for not working fast enough or the user's fault for keeping changing what they asked for. It's never seen as the fault of a faulty estimate.
    – Sarov
    Commented May 10, 2018 at 13:18
  • @Erik Also, even if they are useless, the CEO wants them and thus they're non-optional. While hypothetically possible to convince the CEO otherwise, that'd be a large enough undertaking to merit a Question of its own (or perhaps a broadening of the scope of this one).
    – Sarov
    Commented May 10, 2018 at 13:22

3 Answers 3

Reset to default
2

We have a similar problem here. Our IT department has too many masters who don't understand that if we have to work on EVERYONES projects it's going to take longer than if we only needed to THEIR project.

Basically it wasn't sufficiently visible for them what the schedule impact of additional work is. I think the same applies to your situation.

Who decides what gets done? Do you have a single product owner? Or is the responsibility for scope a hot potato that nobody wants to deal with? If diffusion of responsibility is the name of the game then your only option might be to do exactly what your CEO expects. Build precicely what you originally estimated. CYA mode.

How closely are updates given? Nobody wants to build something they know will not meet demands. Hence your push towards Agile. But it seems to me that the CEO only ever receives the initial analysis and then sees the project as a black box that just never meets the deadline. Every scope change/creep needs to be passed along.

Are you prioritizing tasks? Even if you don't officially have "permission" to skip part of the original scope to accommodate new more pressing features, you should still work on things according to priority. Once a project is nearing or past its deadline and you can demonstrate that everything important is done, attitudes can change more easily and less important scope can often be cut.

If the CEO or CIO has the comfortable positon of only having to approve the original estimate and never having to approve the inevitable scope creep then he has no reason to support any change. It's easy to say "Of course foo department needs the bar widget, make it so!" It's harder to say "I authorize your estimated N weeks for the implementation of the bar widget" and to deal with the whole influx of new demands. Change always needs sufficient pain before it can happen.

TL/DR: Find out who has the authority. Inform them closely about the consequences of any change. Offer choices. Nail them on their decisions. Document everything.

Improve this answer
5
  • "Who decides what gets done?" - The CIO. New requests fit into four forms. 1) Future enhancement, don't add it to the scope. 2) It's small. Add it and the schedule doesn't change. 3) It's big. Add it and I'll add another week to the project 4) We missed this in requirements-gathering. It's a bug. Add it and the schedule doesn't change.
    – Sarov
    Commented May 11, 2018 at 13:08
  • "How closely are updates given?" - Functionality updates are given to users infrequently - though that's one thing that will hopefully improve. We tried giving the CIO functionality-updates frequently, but that went badly so it was changed to only (sometimes) showing a 'finished' product. The CIO is the one to approve all request-updates, so he knows all of those. The CEO never sees the product and gets a schedule-update from the CIO every quarter or so. "scope change/creep needs to be passed along [to the CEO]" is basically impossible. "Why are you bringing me your problems? Get it done."
    – Sarov
    Commented May 11, 2018 at 13:17
  • @Sarov Who evaluates how much impact a new request has? I understand that the CEO might not want to be bothered all the time with new items but there needs to be a workable deal on the table. Either somethink like bringing them to him in batches (here are all new requests with my respective estimates. Pick which you want us to do) or a carte blanche to let you extend the schedule to accomodate the small but important stuff and postpone the gilding so you only have to bother the CEO with the major items. But really if the CEO doesn't want to be bothered then you need a PO.
    – Kempeth
    Commented May 11, 2018 at 14:36
  • Sometimes the developers, sometimes the CIO. The CIO is (sort of) acting as PO.
    – Sarov
    Commented May 11, 2018 at 14:46
  • @Sarov Try to preempt any estimation. It's a lot easier to put up the first estimate than it is to overturn it. Then at each point of the chain from the dev to the CEO there has to be a balance between authority, responsibility and available time to make decisions. It doesn't matter how many links are in that chain as long as all are balanced and the distribution is clear.
    – Kempeth
    Commented May 14, 2018 at 13:28
0

In agile we aim to deliver working software frequently.

This changes the whole dynamic of development reporting because:

  • It is much simpler to end a project early if there is insufficient value being delivered
  • There is frequent feedback from users/customers so that it is easier to adjust priorities and expectations
  • The up-front investment is reduced (ideally the initial investment is that which gets you through the first iteration)
  • Risk is reduced as there is less investment before value is returned

There are lots of things you can do to provide your boss with the metrics they are asking for, such as using release burn-down charts, estimating based on sprint costs, etc. However, to do these things ignores the reasons we are adopting agile in the first place, which is to respond quickly to change and to deliver value frequently.

Improve this answer
3
  • I'm aware there are ways to provide the metrics, but the question posed to me was how to provide, at the beginning of the project, gap/cost analyses in order for the CIO to justify the project to the CEO. Am I correct in interpreting your Answer as "Don't; just fail fast and you won't need to justify at the beginning."?
    – Sarov
    Commented May 11, 2018 at 16:32
  • It's a classic dilemma. If you want give the CEO gap and cost analysis on day 1 then you will need to nail down requirements and almost eliminate technical/project risks. That is the opposite of agile, which says nailing things down is pointless, much better to accept that change will happen and plan accordingly.
    – Barnaby Golden
    Commented May 11, 2018 at 19:47
  • 1
    I think you’re getting it. Don’t justify the cost of the entire project before starting. Instead, justify enough cost to run the initial stages for a few weeks and then see what is delivered. If it has value, keep going. If not, change direction and deliver something else. Keep iterating, and you’ll hit on something valuable a lot sooner and for less money than if you tried to hit a target a year away.
    – RibaldEddie
    Commented May 13, 2018 at 19:46
0

Read up on Storymapping. Do a workshop with your team, requirements people, CIO.

Storymapping addresses ALL the requirements and features people think the system needs. Each requirement is addressed, it's not a matter of yes-or-no. Some requirements simply end up lower in the storymap.

You can start to argue about how to deliver value (save money / make money) before the final feature is delivered. Most organizations are not averse to making money.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.