A Mandate By A CIO Drives Agile Success

The challenge we see in many Enterprise IT shops is that it is hard to get everyone across the business who touches application development ‘on board’ with an agile approach. In this blog post I want to share how the CIO drives agile success by a set of guidelines which help push agile project delivery across the business.

The customer is a large Portuguese food distribution and consumer goods manufacturing company, with an international presence. With nearly 25,000 employees they are used to having huge IT projects, involving multiple departments with complex requirements, large budgets and long timelines.

CIO drives agile success with a decree

Before agile, many of these projects were delivered late, over budget and in some cases actually failed. In 2005 they became an OutSystems customer; embracing the Agile Platform and an agile methodology. As they matured in their agile practices, the CIO saw the value and today they operate under the CIO’s mandate that only projects scoped with a timeline of less than three months and a budget under 300K will be approved. 

What happened before the CIO mandate was put in place?  Here’s what they told us:

1. They would spend two to three months in meetings, aligning all opinions in order to create a huge requirements document;

2. When they finally started developing the systems the business team had disappeared and in most cases forgotten about the project;

3. By the time the project was ready to be tested the key users had changed, the business had changed and the project delivery team immediately entered into a lengthy negotiation phase to reconcile what was delivered versus what the business really needed.

This customer states that with the agile methodology and their new CIO mandate they improved the success rate of their projects in several ways:

1. The business team is more motivated and involved as they are able to see how the projects are progressing on a regular basis;

2. The business gets to be more responsible for the decisions that shape the project direction because they see and constantly test the application;

3. The business and IT avoid the costly, wasteful exercise of building complex requirements documents because they now fully realize that they can never document every detail in a specification;

4. From very early on in the project, IT can see if the project is really what the company needs and identify any mis-matches quickly to reduce the amount of time, dollars and resources that might be wasted.

5. Even for big projects, Agile methodology is used – and forces the team to split the project into phases. This exercise divides the scope into smaller, manageable projects with incremental releases and decreased risk.

So, both for this CIO and many others, we are finding that an agile approach to application development really helps increase project success rate and reduce risks. Even in a company like this one that has complex application needs, lots of departments and bureaucracy – agile really works!

What are the technical leaders in your company doing to help drive agile project delivery?  Or, what would you like to see them doing?

Share their rules, guidelines and mandates along with your ideas!


About the author

Mike Jones

Mike is a professed 'hater' of complexity. He has been in the IT industry since the mid 80's where he learned his technical skills at EDS and Texas Instruments. He believes there is a simpler way for IT professionals to deliver business value that requires a pragmatic mix of agile methods and application development tools.


Thanks for this post Mike. It’s great to hear of Agile success stories in large companies.
I’m curious as to why the CIO had to mandate that projects no longer than 3 months and larger than $300K had to be implemented? Was this needed due to the culture of the company so that they could get people more involved? Do you think that they could have been successful with Agile w/out the mandate?

Robert, my understanding is that the CIO mandate is helping the whole company shift their thinking from a large monolithic project mentality to one where they break down their problems into smaller chunks – important for Agile success.
As for the 3 month window and project $ size I did not probe but assumed this was the threshold where longer projects got out of control. I will reach out and see if we can get more detail re your question. Stay tuned!


@Robert – Maybe the point was that a large six month project could be broken into two three month projects, thus delivering a portion of what was needed quickly.
Also, constraints tend to focus people on what is most important.

@Mike: makes sense. Any additional insight would be great.
@Andrew: that makes sense. Constraints are typically a great thing.


The issue is to pressure business to focus on what is really important and plan things incrementally.
Trying to add every requirement and every little detail into an analysis phase as they were used to tend turn specifications into a never ending project. By trying to limit and focus business and IT into this all new process and methodology also starts in the beginning of every project estimates. Of course this does not mean that they do not have big projects but they budgeted and planed into different phases.

Pete Ruth

I’ve been a proponent and practitioner of agile-like methods since long before the Agile Manifesto changed the face and the rules of effective software development. Back in the day, that was regarded as treason by the MIS departments, even though the benefits could be clearly demonstrated to the business people. No one in those days could have gotten away with the strategy employed by the CIO of the Portugese food distributor; it was just too radical, unproven and unbelievable an approach for anyone to contemplate. Today, it’s clear that agile methods have the power to change the way business thinks about software, and makes possible the substantially more complex applications that business is demanding. Thanks for a great story.

Leave Your Comment