The Agile approach is more adaptable with respect to three key project variables; only the last of which, in my experience, is considered flexible in the waterfall world of engineering.

• Scope.
• Time.
• Resources.

Scope contraction.

Scope flexibility is something of a taboo subject. Scope is something that is added to in both a controlled manner — providing additional revenue — or uncontrolled creep. But the point of any project is delivering something that achieves the customers business goals. This is not necessarily the product that they, or the development team, initially envisaged.

One uncomfortably overspent project lead to the realisation that I could have achieved the business objective well under budget by actually drastically reducing the scope. It wouldn’t have delivered exactly what the customer expected, but it would easily have achieved their goal.

Which is more important, expectation or results? If you have a customer representative on the team it’s much easier to explain your rationale, and the chances are they’ll like the idea of results with less work as much as you do.

Timescales.

If you have a customer that doesn’t mind when you deliver, you’re a rare and lucky project manager, though you’ll never actually finish anything; deadlines do provide focus. So set plenty of deadlines, that’s what iterations and releases are about.

Try to answer the most pressing question as quickly as possible. Leave refinements and those ever present scope changes to the next iteration, it’s probably only a few days away.

This rapid cycle provides useful results, whilst allowing the flexibility to quickly change direction without that wasteful churn: just tidy this up a bit then I’ll be with you.

And the resources?

I’m afraid the project manager has to earn their money too. Line management will always have the urge to reassign any of your key people they feel aren’t being fully employed. It’s important to emphasise that the productivity of any team depends on preventing this happening.

Agile teams don’t strictly segregate workload on the basis of job descriptions, that’s why you need versatile individuals. Unfortunately, these are exactly the type of individuals that those managers will want to steal away. Removing the demarcation of tasks will help ensure everyone is kept busy and that work is conducted using the minimum number of people.

Better than the Waterfall.

I’ve found actual project goals shift too frequently for effective use of the Waterfall approach to project management. Using iterations within this framework always felt unnatural; how do you decide how may there will be and when will you actually deliver something?

An Agile approach perversely leaves me feeling more in control by worrying less about control. There are a huge array of Agile software development techniques, many of which can be adapted to other engineering disciplines.

For Software Engineering, I would recommend reading The Art of Agile Development. The Agile Alliance promote the use of Agile techniques, so take a look at the Manifesto for Agile Software Development upon which it’s all based.

Define your business.

When developing business processes try to keep everything as simple as possible. Simple processes are likely to be followed: complex ones won’t. This is definitely true of written procedures, but human employees have the ability to sift through the junk and ignore it; you may not like that but it’s true.

Computers on the other hand don’t share this aptitude. Your software developers may try to ensure the software follows your monolithic procedures, but the conflicts ignored by human employees will have to be resolved; a long and expensive process.

A systematic approach to this analysis can help, especially with the inevitable documentation, take a look at business process modeling and the OMG notation.

Well implemented processes will be familiar to your staff and any software based on them equally so, saving a fortune on training.

What is success?

Now you’ve got a minimalist set of effective processes, you’re in a position to consider how the application of software and hardware systems might improve or expand your business, and bear in mind that it might not.

What will success would look like? It too needs to be defined as simply as possible if you’re going to recognise it. Frequently at the start of projects everyone is so excited that this step is lost. It is either overlooked or results in a requirements document so complex nobody can be bothered to read it.

Ask yourself how many other business purchases you would make without actually considering what you’re expecting to have delivered. Would you be happy if you were hoping for a photocopier and ended up with a filing cabinet?

Get involved.

Most organisations expect their involvement to end once they’ve specified their requirements. The developer will go away, build the software, and deliver it perfect and on schedule. OK, maybe that’s an exaggeration, but placing your staff in the development team is not an optional extra.

They’re likely to spend substantial time working closely with the developers, it’ll be worth it, you’re likely to get a better system. Most will be involved in user testing, but the customer representative is a key role representing the business interests within the team. Customers are not project managers, they are focused on the benefits to the business and its operational goals.

Primarily involve people that actually undertake the work this system is meant to enhance, and those that will continue to use it. There’s a huge temptation for senior management to attempt to fulfil this role, but they usually know next to nothing about the processes in question, so resist it. There is a vital role for senior sponsorship, but it’s not in the development team.

Resulting software will be intuitive, and the computer literate will be able to understand it based on their knowledge of their current job, and of course your procedures.

The pay back.

Get the basics right — develop good business processes, define success, and build an effective team — and your project has a much better chance of delivering satisfaction, on time, and to budget.