"How could I apply the same level of governance to the Agile project as to the others?"

"In budgeting Agile projects, you decide how much to invest and then spend that sum in equal instalments over the agreed number of months."

"Even without waiting for another chance to run another Agile project — which I would definitely do — I am borrowing and adapting Agile techniques for use in more traditional projects."

Understanding I was running (if I was) an Agile project led me to contemplate the difference between Agile and chaos. Just one of the portfolio of projects I was managing for a client was Agile. How could I apply the same level of governance over the Agile project as to the others? The Agile approach was different. For instance, the whole documentation seemed to consist of a White Board.

Mostly Companies just do stuff, they don't necessarily turn it into a project. If they have a problem they add something to a system, knock out a spreadsheet, change a process, buy a new package or bespoke a part of an existing system. This is not Agile development.

No such outcomes were evident in the Agile project. The outcome — the software — seemed to change every two weeks and the project meeting was a 'stand up' where there seemed to be no notes or no agenda points. This stand-up consisted of the 'scrum master' showcasing the system after which the developers went off to do further work driven by user stories which were Blu-Tacked onto the White Board.

At the same time this was happening, the Steering Board was asking whether we had achieved the target for the level of functionality for version 1. Who knew? I certainly didn't. The Steering Board had an expectation of a traditionally managed project but Agile projects are a long way off meeting such expectations.

In all work — but especially in complex projects — those involved sometimes have difficulty explaining what is happening in a way which can be understood by those leading the organisation. What they often do want to say is "wait, just wait, we know what we are doing". That is hard to do when there is a desire to understand and document what is happening. Especially when the organisation is depending on the project and it has a large budget which they fear is being wasted.

Whether it is eventually wasted, budgeting for an Agile project is incredibly easy: usually a project manager has the triangle of cost, scope and time. When a project loses time (and there is no time contingency built in) the only options are to increase the cost, reduce the scope or potentially (if you can) take longer. In budgeting Agile projects, you decide how much to invest and then spend that sum in equal instalments over the agreed number of months.

The team is assembled depending on the expertise you believe is required and the cost of the team is more or less the cost of the project. At the end of the timeframe you assess whether you have delivered what you were hoping to deliver. When working in an Agile manner there is always scope for flex as, in essence, you are always setting the time and the money.

In the end, I concluded that it is not true that Agile projects cannot be controlled and that is possible to distinguish between Agile and chaos. One difference in Agile is that you have a Goal. The goal is achieved through gathering user stories; user stories are acted upon and can be rolled together to form an Epic. And a set of Epics become an outcome or version. As in other project approaches you do have something that you are aiming for, so that is not chaos. But how you reach that aim is decidedly different. And that has advantages.

Many who have worked on traditionally run projects understand that apparently immutable the goalposts can move. As users gain experience and knowledge the original outcomes that they wanted from a project may no longer seem quite so necessary or desirable. By the time the project finishes the users may well feel that they would have asked for something different if only they had known.

People can struggle to imagine systems, processes or products which we can't see or haven't experienced. Producing a basic model usually provokes the response "That is no good" and proceed to reel off a list of their requirements. Asking what they would be able to do with their requirements enables those working on the project to produce more user stories to quickly deliver what users see as the next most important thing.

When buying an off-the-shelf package or solution, there is no choice but to present it to people and hope that they will start to use it. Often to encourage that adoption, there needs to be a bunch of change management questions wrapped around the package in order to kick start users. In contrast in Agile development change management, user engagement and adoption can all wrapped up seamlessly in the one process.

Even without waiting for another chance to run another Agile project — which I would definitely do — I am borrowing and adapting Agile techniques for use in more traditional projects. For instance, in a system integration testing on an ERP, changes that may be useful are capable of being controlled in an Agile way that avoids regression or system integration testing.

In this particular Agile project, Release 1 provoked howls of pain; Release 2 was received with reluctant acceptance; by the time Release 2.5 was in existence there were vociferous demands to move to release 3. What was first resistance to change, eventually moved to a demand for more change. And much of that shift is attributable to Agile.

And I even figured out how to document the process and keep the (my fellow suits) steering committee happy.